“设计”工作应该放在迭代中吗?

在教练敏捷团队的过程中,一些团队反映“某些用户故事不好拆分,无法在一个迭代内完成”。对于这些故事,一些团队的做法是先指定资深人员作为“设计师”,他从“需求分析师”或业务方拿到需求后,花上1个迭代的时间进行“设计”,然后由他将编码任务进一步分配给“开发人员”,并且负责验收代码。这些故事往往就会持续1~2个迭代才能完成,甚至还来不及测试。

那么对于团队提出的疑问,经过观察和了解,我们发现所谓的不好分拆的大型“设计”任务包括:
代码考古(很多组织在迁移升级旧系统时都会做这一步)
系统架构设计,包括与关联系统的接口讨论和定义
消化第三方提供的算法,包括翻译咨询机构提供的伪码,将其转换为与现实系统相符的数据结构
确定公共数据库表的结构,特别是当被依赖的关联系统较多时,讨论时间会是持久战。(而这可能不包含数据库优化。)
基础设施与环境部署方案
其他各种信息收集和讨论
这些”设计”任务根本不应该进入迭代!

以上这些正是对技术需求的分析细化与确认。这是任务出现在迭代中,其中一个原因是隐性或技术需求没有在迭代开始前得到充分的准备,以至于不得不在迭代开始后还在细化分析需求,制定所谓的方案。深入团队了解以后,虽然项目已经开始,上线时间也规定得比较紧张,但是需求的产出和细化却远远跟不上团队逐渐上升的产能。如果这些知识没有得到及时明确,也就难怪开发人员无法开展工作,并且在做的过程中要不停的确认需求,举步维艰。当然,深入发掘的话,可能还会看到业务方背后对于产品愿景的摇摆或者内部协调等问题,按下不表。

团队中的“设计师”难道不是在担任SA/PO的替身吗?!

这些设计和方案只是最初的设想和预估,是知识的学习和信息的收集,其中一部分也是为了给众人统一大方向,形成沟通的基础和规范。但那绝对不是最终实现结果。因为,谁能料到真正运行后会不会出现意想不到的问题呢?

到底什么是设计?

还记得1992年Jack Reeves的那篇著名文章吗?他前瞻性地提出”Source code is the design”,而Linus大神也讲过”Talking is cheap. Show me the code.”。这意味着只有能够运行起来的代码才是真正的设计,设计一定是要经过验证正确才算完成。至于各种”设计”文档与方案,充其量是辅助思考的中间产物,是信息空间的草稿。没有哪个其他行业的设计工作是纸上谈兵的,硬件制造、建筑等产出的文档,一定要通过工程和数学方法进行验证和锤炼后,才敢交予生产。

敏捷开发模式的目标是持续地交付,每个迭代的工作内容能够稳定地流动。(另外一个目标是团队持续地改进。) 要达到平稳的持续交付状态,分拆BI时要遵循INVEST,特别是Independent。每个BI都要在迭代结束时满足“完成”的定义,即DoD,通常来说是要部署到集成环境并测试通过,再加上一些其他团队认为合适的质量保证手段。

因此在迭代开始前,团队与业务方一起确定BI的范围,并且约定好如何进行测试和验收。越是不确定性大的内容,越是自身响应变化能力越差的部分,越是要更加提前。DoR(或称迭代准入条件)的概念作为一种有益的补充越来越多地引起人们的重视。

敏捷不提倡对整个项目周期做完全的计划,但是绝对地提倡冻结即将开始的迭代内容。这样,在迭代结束时BI才可以有依据进行验收完成。通常来说,提前1~2个迭代对将来要做的BI确认验收条件(Acceptance Criteria)是一种通用并有效的方式,也就是常说的ATDD实践。这是对业务方/SA/PO提出了更高的要求,既然要敏捷,大家都要协调地动起来才有好的效果。就像左右脚走路一般,需求分拆和沟通总是先于迭代半步。

结论:以上这些“设计”都还只是“需求分析和细化”,不应进入迭代中,而是提前1~2个迭代就应该准备好验收条件。而能够跑起来的代码才是实实在在的设计。
团队反映的这个问题并非”需求太大,不好拆分”的问题。对于敏捷团队遇到的问题,作为顾问和教练应该透过现象去挖掘背后的原因。


觉得本文有帮助,长按二维码进行微信打赏