转:敏捷开发基本流程概念的理解与实践

又是很长时间没有更新博客了,客观原因是真的很忙,主观原因是自己太懒了。但是想想,知识、经验都是慢慢积累起来的,不总结、不反思、不记录,很多时候这些本应该积累的东西,就渐渐被遗忘了。写在博客里,一方面是为了与大家交流分享,另一方面是记录自己走过的路,反思自己做过的事,这样忙工作才不算是白忙。对自己、对大家都有好处。想是这样想,但真正忙起来的时候就什么都顾不了了。所以,趁着五一长假,终于有时间写一点东西,用于分享,用于记录。

公司推行敏捷开发已有些时日了。IBM的顾问每周也还会飞来辅导一下,新的知识已经不多,主要还是跟进解决一些在日常执行中遇到的问题,纠正一些错误的理解。关于敏捷开发的概念和好处这些理论的东西,网上一搜一大把,做咨询的比做开发的讲的更好,这些东西我就不多说了。我仅从一个日常执行者的角度,来梳理一下敏捷开发的基本流程和遇到的一些问题。

用户故事。敏捷开发,首先是基于用户故事的。在实际制定用户故事的时候,需要注意的是用户故事的粒度和其相对独立性。我们在实际执行中,往往会出现用户故事规模估计偏差大,或者故事做到一半发现依赖其他模块的情况。这些问题相信实际进行敏捷开发的同行们都会遇到。开发者往往会因为偏差大而贬低敏捷开发的管理作用,我们的原则是:先僵化、再固化、最后才灵活化。只有这样才能保证敏捷的正常推行。当一切步入正轨之后,再来谈改良的问题。当然对于偏差,我们也采取了一些措施,对评估用户故事规模的人形成反馈,使准确度逐步提高。

统一团队。敏捷开发之所以敏捷,原因就是统一团队(个人理解)。统一团队包括了开发中各种角色的人员,包括SE、UE、UI、QT。这些人员在同一个团队中能很好的交流,就减少了出正式文档的时间成本,误解能第一时间得到纠正。实际执行过程中发现,虽然名义上是一个团队,但不同角色人员的立场不同,有时很难保证真正的“统一”。这就需要各个组的管理者真正站在项目的角度,给执行者更大的自由度,并且平时减少矛盾,多组织团体活动增进默契。

迭代化开发。迭代化就是说将开发时间分成一个一个固定时间长度的小阶段,每个迭代完成相应的用户故事,新的需求与改动按照优先级情况排在下一个迭代以后。迭代化开发基本就是我们实际开发工作中执行敏捷理念的日常流程,与我们的开发工作有着非常密切的关系。每个迭代之初,会进行迭代计划,按照需求的优先级,由敏捷小组成员自己领取适合自己规模的故事。然后,进行用户故事澄清,分解用户故事为一个个精确到人×天或者小时×天的任务,方便管理者掌控进度。每个迭代完成的时候,会有一个迭代回顾会议。迭代回顾会议上,总结完成的故事点数,演示这个迭代的成果,听取组内成员的意见,以持续改进,增进默契。刚开始推行时,每轮迭代回顾会议上会发现许多问题。而会议本身只能暴露问题,并不能解决问题。所以我们在每次迭代回顾会议上,会制定一个迭代改进计划,并在下一次迭代回顾时,对上一个迭代制定的迭代计划的进展情况进行汇报。个人感觉这种方式,取得了较好的效果。

状态栏的维护。为了将迭代化开发的进展情况更直观让领导者清楚。我们会将每个迭代的计划完成故事、分解成的任务以及各故事和任务的状态贴到一张白板上展示。每日敏捷小组成员进行站会,回顾前一工作日所做工作,今天计划要做的工作,遇到的问题和风险,会后更新状态栏,确认哪些工作计划做,哪些工作正在做,哪些工作已经做完。整个组的情况,最后会形成一个燃尽图,以反映这个迭代的剩余工作量再逐步减小,直到迭代结束,理想情况下燃尽图应该“燃尽”。实际过程中,往往出现状态栏更新不及时,本来应该给领导者表现好的情况,结果让领导者更郁闷。。。好的做法是每轮迭代专人负责跟进状态栏更新情况,做到及时。另一个问题就是燃尽图上涨与燃不尽的问题。少量上涨和剩余工作量小的情况属正常,主要是因为预估工作量偏差或者遇到了其他紧急的事情影响了进度。这要根据具体情况具体分析,不过出现好几轮迭代燃不尽的情况,需要引起管理者重视,及时分析原因,防止情况恶化。我们组就出现过初期没有引起很高的重视,导致后来燃尽图到迭代结束时还没过半的情况。

    现在想到的就这些,敏捷开发主要就是让软件开发项目变得更可控,让不了解具体细节的领导者也能直观的明白和管理项目的进度。当然,这只是一个管理工具而已,对于一些技术攻关与预言的项目,适用性似乎并不强。。。

转:http://www.blogjava.net/zh-weir/archive/2011/04/30/349320.html

相关推荐