和我们一起工作过的很多Scrum软件开发团队刚开始都无法在一个SPRint束时开发出可用的软件增量。由于他们以前使用的流程不具有透明性,因此通常没有足够的技术技能或者适当的工具来开发具有透明性的软件功能。
在表中,第一列显示了一个开发团队将产品待办列表中的需求转化成可以工作的功能通常所需完成的工作。第二列被标识为“传统”,表示在一个传统的预测型项目中,软件开发团队完成对应任务通常所需要的单位工作量的个数。例如,开发人员习惯在需求分析上面花费12个单位的工作量,而在设计组件架构上花费10个单位。这些都是相对值,也就是说开发人员在前者上需要多花2个单位的工作量,或者说多出20%工作量。
第三列被标识为“完成”,表示要开发完整、具备透明性的功能增量,对应任务所需要的单位工作量的个数。从表中可以看出,要软件开发出具有透明性的增量需要的总工作量为171个单位。很多开发人员在转换到Scrum项目的时候,都习惯于只完成第二列中所列出的71个单位的工作,而对每个功能中剩下的100个单位的工作置之不理。而随着 Sprint一个接一个地进行,这些未完成的工作快速积累,直到项目结束时爆发出来。
在开始第一个 Sprint之前,需要让 Scrum master和软件开发团队一起对表进行评估,并为即将开发的软件制订一个新的表格。然后让他们在开始第一个 Sprint之前确定完成工作的方法。为了检查他们的工作,你可以在任意一个Sprint结束时要求试用一个或多个软件增量。如果他们说还没有准备好,或者你试用过以后发现增量无法正常工作,那么就意味着团队的开发人员需要更多培训和练习。
Adobe和其技术债务
Adode Premiere pro是业界领先的图形设计、视频编辑、网页软件开发应用程序的套件,以视频制为目标市场。The Tonight Show等BBC节目就是使用这套产品制作的。 Adobe的部门副总裁 Steve Warne负责 Premiere pro的管理工作。 Peter Green曾经是 Creative Suite的项目经理。不断涌现的标准和对新功能的需求迫使他们不得不快速发布重要的新版本。
Premier pro cs3( Creative Suite,版本3.0)在2007年6月发布。开发这个版本所使用的是传统开发流程。在软件开发团队奋战了18个月后,该版本作为当时的重磅产品发布。当发布日期日渐临近时,开发人员开始将CS3的发布版本整合起来。但是他们却发现这当中有很多问题(缺陷或者错误)。而这个时候已经没有足够的时间修复所有问题了,于是他们尽力在限期之内将版本整合到最好,然后发布。下面是一些客户对Cs3的评价。
但是,如果你想要一个易用、友好的视频处理程序,那么这个软件将不是你最佳选择。我期望的一些功能它并没有,或者说我不知道怎么用这款软件实现我想要的效果。
这个软件是差得出了名的编码器,会产生内存泄漏。如果你想要将大型的视频文件编码成mpeg2格式, premiere会由于糟糕的内存管理而经常崩溃。而唯一的解决办法,就是重启你的系统,然后祈祷这样的事情不要再发生。”
在下一个版本,也就是 Premier pro cs4中,团队的目标是修复cs3中的问题。CS4致力于改进产品的易用性、稳定性和速度,以及解决内存泄漏的问题。 PeterGreen听说短周期的开发方法能够让Adobe在每个 Sprint都开发出完整的增量,于是他决定一试。这些增量加到一起,就组成了客户喜欢的可用功能。 Peter还想知道每个Sprint的实际情况,于是他让其中几个参与cs4软件开发的团队实施Scrum流程,这样就可以了解 Scrum是否可行。
Adobe中有18个Scum软件团队,总共超过100位开发人员参与了cs4版本的开发。所有人都认为,要在每个Spn都将18个团队开发的增量集成在一起,工作量实在是太大了。于是他们决定等到项目快要结
束的时候再进行集成。就在CS4发布日期之前,团队尝试将相互独立的模块集成到一个软件产品里面。但是这个时候,他们才发现很多差异和未解决的依赖关系问题。它们造成了很多软件错误,使CS4的各个组件之间无法协同工作,导致集成无法完成。开始集成之前缺陷个数缓慢上升,然后突然快速减少。软件开发人员尽其所能超人般地解决了很多问题,但是发布的日期还是比原计划推迟了,而且版本还带有重大的缺陷。在 Adobe中,由于压力过大和过度工作导致生病住院的开发人员都成为了传奇人物。
cS4在2008年9月发布,然而业界和客户都对这个版本做出了很差的评价。 Adobe采用Scum提升了生产效率,但可惜提升的不是整个产品而是软件开发团队各自的生产效率。各个团队开发的组件没有集成在起,不具有透明性。潜在的集成冋题被短期隐藏了,因此短期的生产效率看似提高了。然而代价却是产品质量、业界认可度、新特性的发布时机、客户的满意度以及员工的士气和健康的恶化。因此,他们需要改变。
Steve和Pete决定在CS5的开发中,尽可能广泛地使用 Scrum他们对所有软件开发人员和项目经理进行了培训。Pete的新任务是培训和指导团队,令他们可以在每个Sprint都开发出质量过关的软件。在每个 Sprint,所有团队开发的所有增量都会进行集成和测试。这样就能够在每个 Sprint都拥有一个可发布的CS5版本。可以看出,在整个过程中,缺陷的数量从来没有出现过不受控制的情况。出乎所有人的意料,软件开发人员居然提前完成了这个版本。那些由于没有集成而潜伏的问题再也没有拖慢他们的步伐。在剩余的时间里,他们还修复了CS4遗留下来的部分问题。CS5在2010年4月发布,这次他们获得了业界和客户的一致好评。
Peter制订了一份在 Adobe内部管理 Scrum开发的指标列表。他列举了3个指标。第一个就是在CS5开发期间员工对Scrum的满意度以及员工对Scrum能够改进开发软件方法的信任度。 Adobe对来自25个软件团队的200名开发人员派发了这份有50个问题的调查问卷0。这些调查的结果会按照团队和问题来分类并进行分析,从而找出需要改进的领域。令人印象深刻的是,80%软件开发人员认为即使没有管理层的要求也会继续使用Scrum,所有表现最好团队都表示认同。结果是缺陷率大大降低,交付的产品几乎没有任何潜伏的缺陷,客户的满意度也大大提高。
Adobe尝试使用Scrum来解决日渐严重的问题。在决心、训练和共同努力的推动下,解决了许多问题,版本发布也变得更及时,软件的质量也更高了。
文章来源于：http://www.aussiebushcues.com/sitemap.xml
网友评论