磕磕绊绊的Scrum之行(十二)在不确定下工作

在第十节,我们的项目已经走向了瀑布式,并且效果不错。但最近一周、尤其是今天的情况说明,永远别抱着稳定的心理去做事。

人的心理是很微妙的,说变化,股市变化更大,但依然有很多玩家;因为进入股市之前有一句公开的话来告诫你“股市有风险,入市需谨慎”;而软件行业,尤其是项目开始的时候,却会有一大群人信誓旦旦地保证“需求没有变化”。

现在就是,尽管我们小心翼翼,仔细衡量,投入时间充足,依然不能保证需求足够细致,设计足够周全(我们设计达到的目标是数据结构的稳定和代码不重复)。

12月15号与业务相关人员讨论的结果让我们意识到,A模块可以拆分成a、b两个有关系的子模块,其中b模块由于是新需求,用户的意见是“先让我们看看”,至于a模块,有重大的业务流程、使用者的变化,在操作界面、易用性上,都需要经过可行性论证。

于是我将项目组分成了两个并行的部分,把原计划依次进行的A模块设计停掉,设计人员参与到当前模块B、C的开发中来,争取在12月22号完成开发和单元测试。这个工作昨天已经提前完成,今天测试人员正在部署环境,预计明天开始测试。

接下来,一半的人按原有的瀑布式模式进行D模块的开发,另一半以敏捷的方式进行b模块的开发,b模块分三个迭代,每周出一个版本。运气好的话,第二个版本我们就能把用户目标稳定下来。

考虑过是否为避免并行开发的相互影响而采取分支策略,但是对持续集成很有信心,大家依旧在一个项目解决方案中进行开发。

由于Sprint 3的结束周期是12月31日,我将D模块和b模块加入了进来,这样,与计划会议二中达成的目标相比,只有a模块未开发了。

新图片(6)

12.17燃尽图

新图片(7)

12.22燃尽图(加入了新的工作)

今天遭遇了设计变更:

遭遇数据库设计变更,1/3是要求(非需求)不明,1/3是设计没考虑周全,1/3是减轻未来编码复杂度。大家很崩溃,我因大家崩溃而崩溃。大概有一周的返工量。这些都是项目中的痛点啊。

站在我的角度,我更愿意将它称之为“重构”。好架构是成长起来的。

看得出,大家不怎么舒服,观念的改变不是一时半会能够成功的。

刚刚被打断了十几分钟,因为持续集成中单元测试有五个未通过,正在分析原因。代码覆盖率检查和持续集成真的很强大,在这次变更中,依赖于自动化生成和自动化测试可以非常方便地检查错误。

© 2018 Silent River All Rights Reserved. 本站访客数人次 本站总访问量
Theme by hiero