开发应该放弃伪敏捷

2018-06-13  本文已影响36人  jeri_shi

Ron(敏捷宣言的签署人、XP的作者之一)这两天贴出了一个Blog,建议的是放弃号称敏捷的敏捷(伪敏捷)。他给开发人员的建议是:the best I know is to do good work, keep it visible, running, tested, and integrated, and help people to see reality

不要管你所在的组织在推行什么样的敏捷,优秀的开发让自己所做的开发工作保持可见,能运行,被测试过并且已经集成,最后帮助周围的人看清事实。

原文在此:https://ronjeffries.com/articles/018-01ff/abandon-1/

读后感:

Ron对于开发给出了三大原则,我细化一下:我自己认为对于开发来讲,好的开发工作流程或步骤应该是这样的:

- 选取一个最高优先级的功能

- 调研代码现有逻辑和架构

- 拆分功能为若干用户可用的小功能

- 创建本地代码分支

- 做一点点重构,以便可以书写测试代码(如果代码不可测试),本地运行测试代码并确保通过

- 编写测试代码保护现有功能(如果代码没有被保护),本地运行测试代码保证通过

- 实现一个小功能,保持代码简洁,进行必要的简单重构,本地运行测试代码通过

- 编写测试代码,保护好新写的小功能,保证全部的测试代码运行通过

- 编写集成测试代码,保证覆盖重要的业务场景,保证所有测试代码运行通过

- 运行静态代码扫描,修改代码并消除所有警告信息。

- 编写或补充性能测试代码,确保没有性能下降,线程并发,升级,内存泄漏,磁盘占用等问题。在本地运行测试代码通过。

- 同步最新代码,修改冲突。确保本地所有测试代码运行通过。

- 任务完成,提交代码到正式代码库。等待CI通知所有的静态扫描、集成测试完成通过的通知。

- 为小功能(多个或一个)创建代码审查,等待审查结果。修改代码保证本地的测试全部运行通过,再次提交代码,并创建二次审查并确保通过。

- 开始下一项小功能,重复上面的步骤。

- 完成所有小功能后,为这个功能总结最必要的开发设计文档,放到Wiki上。

- 向PO/Master询问下一个最高优先级的工作是什么,重复上述所有步骤。

经过以上的步骤,基本上就不会有BUG产生,开发人员从而可以真正的解放自己。

你有什么好建议给开发吗?

上一篇下一篇

猜你喜欢

热点阅读