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

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

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

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

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

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

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

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

 

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