CDC

Place to Be & Show Yourself

完成的定义:DoD Definition of Done

题记

在敏捷软件开发和DevOps实践中,要求每个程序员小步快跑、持续集成、持续部署已经完成的User Story。但是怎么样才算是真正完成,并且可以部署了呢?

关于完成的对话

“Hi Mark!” Lin把脑袋探向了Mark的工位。“新功能完成了吗?”
Mark点了点头,“稍等一下。” Mark一边说一边继续敲打着键盘。一阵疾风骤雨般的击键以一个兴奋的手势结束。“搞定!” Mark站起身来看着Lin,“半天就完成了!”
“哇,太了不起了。” Lin说,“我以为它要花你一天甚至两天的时间。我现在可以看看嘛?”
“呃,暂时还不行。” Mark说,“新代码还没有集成。”
“好吧,”Lin说,“不过等你集成完,我就可以看到了,对吧?我急着给我们的新客户Demo一下呢。他们正式因为这个功能才选择跟我们合作的。我要把新版本安装到他们的测试环境里,让他们试试看。”
Mark皱起了眉头。“可是,我不能把它Demo给任何人。代码还没有经过测试呢。而且也无法安装到任何地方—-我还没有更新安装包和数据库生成器。”
“我没明白你的意思,”Lin抱怨说,“我以为你说你完成了!”
“我是完成了啊,”Mark坚持道,“我在你进来的时候刚好完成了编码。喏,就在这儿,你看好了。”
“不不不,我不需要看代码,”Lin答到,“我需要一个可以Demo给客户看的东西,而这个东西应该是全部完成的。”
“既然这样,你为啥不说清楚呢?”Mark说,“新Feature已经完成了,技术上已经没有难度了—-我是说代码已经完工。只是还没有彻底做完。再给我几天时间吧。”

Production Ready的feature

如果一点完成了某个Story,就再也不需要回来整理它,那该多好啊。这就是所谓“全部完成”背后的故事。一个Story完成之后不会是一堆没有集成的、未经测试的代码。它应该是为部署做好了准备

部分完成的Story将会导致项目中未知的开销。当发布时间来临时,我们将不得不面对完成未知工作量的挑战,也会使计划变得不可靠。要回避这个问题,在每个迭代周期结束时,请确保计划中的Story、Task是“全部完成”。尽管这样可能会等待更多的Feature完成,在每次迭代结束的时候,软件都应该是可以部署、交付的。

一个软件达到“全部完成”需要多少代价?这个取决于你的组织,我经常解释说只有当客户可以按照预期的方式使用这个软件的时候这个Story才算全部完成。建立一个包含Story完成标准的清单:

  • 编码完成(所有代码完工)
  • 测试完成(所有单元测试、集成测试、客户测试完成)
  • 设计完成(修改代码,直到团队满意)
  • 集成完成(Story从头到尾可以顺利完成,从UI到DB,并与其它部分相适应)
  • 成功构建(构建脚本包含了所有新模块)
  • 成功安装(构建脚本将Story包含在自动安装程序中)
  • 成功移植(如有必要,安装程序需要移植原有数据)
  • 评审完成(客户完成对Story的评审,确认已满足需求)
  • 修复完成(所有bug都已经修复或者安排到新迭代中)
  • 用户接受(用户同意确认故事已完成)

当然有的时候“撰写文档”也需要添加到这个列表中,这意味着有完整的文档来描述User Story,并提供了帮助文件。

如果没有清晰的完成的定义,导致的结果将会是10%的时间完成了90%的进度,剩下10%的进度却花费了90%的时间,甚至不知道什么时候会真正的完成。也会导致计划不可控。90%的时间挤占了新的User Story的开发时间。

点赞

发表评论

电子邮件地址不会被公开。