• 00
  • 00小时
  • 00
  • 00
2023敏捷武林大会-上海站,正火热免费报名中...
Search
Close this search box.

敏捷开发方法如何展现项目整体规划

敏捷开发方法近来风气云涌,不少组织、团队开始采用敏捷方法。
敏捷开发方法的阶段划分与传统的瀑布型生命周期是不一样的。敏捷展现出来的是一个又一个迭代,似乎难以展现项目的整体情况。与领导沟通汇报时难以在短时间内说清楚。

下文试图来解决敏捷项目整体规划展现的问题。
首先,识别项目的整体工期限制。
项目的整体限制主要在工期、工作量、成本。
一般常见的限制是项目最终结束日期。比如有些项目是获得了政府资助,那么政府对这些项目在何时结束是有要求的;有些项目是按年度计划的,要在12月结束;有些项目是根据客户合同来的,那么根据客户的时间要求来进行。
也有部分少数项目确实没有明确的工期限制,或者难以估计何时能够完工,这种情况下常见的做法是分期进行,把相对明晰的、优先级高的内容放在第一期中,把未知的、可变的部分放到后面的第二期或第三期。
其次,确定迭代周期
迭代周期是指迭代历时多少时间。常见的迭代周期是2周~4周,也存在1周的迭代周期,一般而言最长的迭代周期是8周,约2个月。
短迭代是敏捷开发方法区别于传统开发方法的最大特征。
迭代的英文原文是Iterative,这个词是舶来词汇,它的英文注释:Iterative是英文Iterate的形容词形式。看一下韦氏大辞典中Iterate一词的定义。
Iterate: To say or do again or againand again (重复地说或者做)。
很显然我们的迭代开发(Iterative)中的迭代取的是它的“不断地做(Doagain and again)”的意思。因此迭代开发背后的思想是一种与传统思维模式截然不同的方式,传统思维方式往往希望一遍做好,一次成功;但是迭代开发意味着反复地 做,不断地根据客户和市场的反馈进行调整。
敏捷开发的首要意图是尽快的将有价值的功能交付到用户手中,识别最高价值的可行的最小功能集,最快速的部署。来自于真实用户的反馈是最佳的标准。这些功能使用的反馈将指导后续的开发,特别是前期需求有误的,通过反馈修正后的功能将更有价值。
所有敏捷中的反馈很重要。敏捷开发的速度需要匹配于项目获得可靠信息的速度,也就是说反馈循环的紧密程度。团队的生产力也受限于所收到反馈的质量。 反馈循环的紧密程度就与迭代周期长短紧密相关。短迭代带来了快速的反馈,能够快速的发现问题,尽早的进行调整。所以敏捷开发方法对迭代的时间长度有限制。
常见问题:迭代周期是否根据每个迭代的情况来调整迭代周期时间长短?
尽量按照固定的迭代周期,把迭代作为一个时间箱来进行。在长跑运动中,保持不变的节奏是最省力气的,同样的,团队按照固定的迭代节奏开展工作,能够让内部外部各方有明确的预期。
对于时间箱而言,如果时间节点到达时尚未开发完所有功能,可以把没有完成的功能在下一个迭代继续开发。
但是如果有外部事件的重要时间节点,可以适当调整时间窗使得某个迭代结束时与外部项目吻合。
当总工期长度和迭代周期确定后,再考虑项目起始和收尾的情况,就可以把全部迭代计划做出。对于项目起始,常见的做法是安排第0迭代,第0迭代一般的时间长度不超过普通迭代的时间长度,主要的任务在于组织团队、建立开发环境及其他一些初始化的工作。
对于项目收尾,根据具体各个组织的要求来安排,诸如考虑进行外部测试、书写项目结题材料、对外宣传材料,等等。
然后,在选择合适中间点进行beta交付。
将得到初步识别的各个核心功能或特性安排到计划的迭代中。
比如下表:
scrumcn1322136097
以上规划中,识别的规模尽量不要超过开发能力的50%,因为敏捷开发不要求开始就有详尽需求分析,不少新的需求会在每个迭代的交流中出现。
根据需要开发的核心功能或特性,组合合适的迭代,安排beta交付或release交付。
常见的,每三个迭代安排一个beta交付;也有每个迭代都进行beta交付的做法;不少互联网的做法是每个迭代都进行release交付。
在迭代开展后,在向领导汇报时,可以这样简短的汇报:本项目总共规划了12个迭代,每个迭代周期是4周,当前进行到第5个迭代,前4个迭代原规划的 功能基本都实现了,除了……,并且新增加了什么什么重要功能。前4个迭代结束后,我们将满足beta发布的版本交付给了某个用户试用,目前收到8条反馈, 正在处理当中。
另外,迭代总体燃尽图也是一个展现项目整体的好工具。
如下是一个项目的功能点迭代燃尽图实例,纵轴是待实现的功能点数,横轴是迭代数。
scrumcn1322136142
通过这个图,已经进行了29个迭代,预示还需要6个迭代,可以把所有功能点数“燃尽”。
下图是上图相同项目的工作量迭代燃尽图。纵轴是还需要的工作量。
scrumcn1322136164
通过这个图上已经进行了29个迭代,预示还需要8个迭代,这就与功能点迭代燃尽图的预测不一致,项目组可以从中分析原因,采取措施,保证最后的工期。
上述图最直观的原因是剩下未完成功能比较难做,而前期已经完成功能可能需要修补。在这种情况下,有必要适当的在第28以后的迭代中加大工作负荷。
综上,对比下瀑布开发和敏捷开发,如果同样是工期为一年的项目,在瀑布开发下,可以作出开发计划、需求、设计、编码、测试等等阶段里程碑的安排,每 个阶段的平均工期约是2个月,而且就算是在编码刚开始的时候,也无法直观的看到需要的软件是什么样子,只能查阅大量篇幅的文档。
而在敏捷开发下,假设一年安排了11个迭代,每个迭代为期1个月左右,把已经识别的关键功能分配到各个迭代当中,每个季度交付一个beta版本,从计划颗粒度上讲就比瀑布开发来得更细,
从执行中的跟踪来讲,可运行的半成品软件较之经过里程碑评审的文档而言更加直观,更加说明已经获得的成果。
因此,敏捷项目整体规划是可以作的,而且其颗粒度并不比传统生命周期更粗。

 

来源:张克强博客

原文地址:敏捷开发方法如何展现项目整体规划?

Search
最新敏捷认证课 ~ 火热报名中
3月30-31日
Scrum Master (CSM) 认证课
张宁宁 Lance Zhang 授课
4月20-21日
Leading SAFe领导大规模敏捷认证课
Eric & Scott 授课
4月20-21日
专业Scrum Master (PSM I) 认证公开课
丁志润 Derek Ding 授课
6月22-23日
专业Scrum产品负责人(PSPO)认证公开课
丁志润 Derek Ding 授课
分类文章
9月15-17日
SAFe ScrumMaster & Leading SAFe官方认证双证班
Eric Liao & Scott Wang 授课
9月18-22日
SAFe认证-SPC SAFe认证培训师导师班
Kurt Jäger & Eric Liao 授课

预约回电

课程顾问将尽快给您回电
电话咨询 400 696 6280