2009年实践敏捷开发的心得

       公司领导早就有意尝试敏捷开发，在千挑万选之后，决定在我负责的项目首先试点Scrum敏捷开发，敏捷试点一年多了，有些心得，记录于此：

 

       在2009年有幸在某项目中担任ScrumMaster职务，但是整个团队对于敏捷的认识尚处于初级阶段，更加上组织上CMMI3级的要求，使得这次的敏捷尝试并不尽如人意。

 

      我们项目在项目初期考虑再三，最终采用了Scrum的开发方式，没有采用XP中的一些最佳实践。但从项目开始以来我就坚持Scrum和XP部分结合的方式能够最大的得到敏捷的收益。因为个人认为Scrum很类似于CMMI中的理论模型，Scrum指导项目团队应该要做些什么，但从不指导怎么开发；而XP则类似于CMMI中一些最佳实践，它具体指导如何进行开发 。但无奈部门经理认为XP过于重量级而坚持不采纳，且团队成员也不愿意使用XP，最终仅采用了Scrum的开发模型而并未采用XP。

 

 

      简单介绍一下Scrum，其实Scrum模型很容易理解，这里有个不错的链接（http://plog.longwin.com.tw/document-ebook/2006/12/09/learn_scrum_2006 ）：

 

Scrum 優勢: Scrum把專案開發進程化整為零，適合快速反應需求改變 的專案，以及開發時間緊迫 的專案。

1. Product Backlog
2. Sprint Backlog & Sprint Planning Meeting
3. Sprint (1~4 週) (視專案大小會有 n 個 1~4週), 一個 Sprint不建議超過一個月, 超過一個月最好想辦法再細分
4. Brief Daily Meetin(Daily Scrum Meeting), Daily 主要要報告以下三件事:
   • 昨天做了什麼事？(或 今天做了什麼事, 依開會時間而定)
   • 今天要做什麼事？(或 明天要做什麼事, 依開會時間而定)
   • 工作上是否遇到任何阻礙或問題 ？(主持者(Scrum Master)必須快速解決成員所遇到的困難。)
5. Sprint Review Meeting(檢討會)
6. 繼續重覆上述步驟到專案完成

     值得一提的是，公司内部同时在大力推进CMMI的开发方式，众所周知CMMI与敏捷一直以来水火不容。但部门经理认为2者可以同时兼顾，要求我们这个敏捷开发试点项目的另一目标是尝试融合CMMI与敏捷。个人实践下来，感觉敏捷和CMMI的目的是一样的，都是为了提高软件质量，但价值观却差别很大，CMMI似乎认为面面俱到的文档和标准化的开发流程，就能创造出一个优秀的软件；而敏捷认为人和实际的代码才是最重要的。 所以我个人认为走纯敏捷的路线，且Scrum和XP相结合，才是最优秀的开发团队应该采纳的。

 

 

     好了，来谈谈我们这个项目中的一些不足之处：

1、我本人同时担任ScrumMaster和Coder，往往会在开发进度实在无法完成Sprint时，利用ScrumMaster的身份刻意降低验收标准（因为高要求到最后还是落在自己身上，所以就偷懒）。严格说来，这和我本身的劣根性有关，但不得不考虑ScrumMaster同时担任同一项目的Coder确实有点不妥。

 

2、在项目的后期明显出现的一个问题就是赶项目进度，而且软件质量直线下滑。这一部分在Scrum的模型中也没有考虑到，ProductOwner划分Backlog，并设置其优先级，根据团队的开发能力，按优先级列表拖入Backlog，这里没有考虑到Backlog很长，但又有固定的完成期限的情况。在最初几个Sprint后，临近项目结束的几个Sprint会明显感觉到Backlog无法完成，而强制将更多的Backlog拖入Sprint只会造成赶项目进度的情况。这一点，后来我们采用了对Backlog的规划 的方法，但之前失去的Sprint却补不回来了。

 

3、对Backlog的估算。部门经理要求我们使用部门生产率*估算工作量的方式来估算功能点（XP中叫做Story Point），这点我一开始没发现什么问题，但在项目尾声时才发现了严重的误区，因为这样一来我们无法得到我们本项目自身的生产率 ，原本应该由功能点/工作量来获得的生产率，却被用来反算。当要统计本项目的开发生产率是否提高了的时候，却发现依旧和以前的部门生产率一样。（=。=！）

 

4、Planning Meeting是否有效。按照Scrum的要求，我们应当在Planning Meeting时规划整个Sprint的工作。但当我们在Planning Meeting时不做任何Backlog研究，仅凭想象来估算时，会发现实际的工作量有时会与当初估算的偏差巨大。但当我们采用在Planning Meeting时对Backlog研究时，往往会发现一天的开会时间也不够用，且会议上的临时研究效果也并不明显。所以个人觉得似乎应该在项目准备阶段就已经评估好所有的Backlog功能点（User Point），同时将Planning Meeting拆分成2个会议，第一个会议决定本Sprint的Backlog，而第二个会议则用来估算工作量，2个会议中间的时间，团队成员们应该去粗略的研究下Backlog以在第二个会议中做出估算。

 

5、估算是否准确。我们的Planning Meeting还有个问题就是一般都是谁负责这个模块，谁来估算，所以一般情况下这样的估算会带有明显的感情色彩。个人觉得应该用卡片的方式，大家一同估算并亮出卡片，这样可能比较合理。

 

6、没有使用Xp中的测试驱动开发（个人认为是最重要的实践）、持续构建、结对编程。这3个我一直认为是最要的敏捷实践，却没有在本项目中实现。

 

7、差点漏了一个，本项目最大的一个问题，这是一个升级项目，也就是说团队成员既要维护前一个项目，又同时要进行开发。并且维护的时间往往会大量占用开发时间，部门经理坚持我们维护>开发，“开发可以不做，但维护一定要做好”。但我认为把维护人员和开发人员拆分开来可能会对项目的开发更好。

 

再来看看项目的一些可取之处：

1、团队成员坐在一起。这与XP中的“完整团队”的要求是一致的，随时随地的讨论更能加速团队的开发进度。（但仍旧有部分成员不愿意坐在一起）

 

2、固定的Sprint周期。这与XP中的“可持续的开发速度”要求一致。在适应了固定的开发周期之后，团队成员的紧迫感要好于非敏捷方式的。

 

3、用户展示会。这无疑是Scrum中最能纠正团队开发误区的了，在每次展示后，我们都能发现用户需求与我们开发的产品不符的地方。

 

4、回顾会。也许这个初衷是好的，但是在回顾会上部门经理的发言无疑引导了团队的走向，看起来我虽然担任了ScrumMaster，但始终受部门经理制约。

 

5、每日例会。通过每日例会，每天都能了解项目的最新近况，相信对于项目进度的把握会更有信心。

 

纵观整个项目，也许多一份坚持的话，可以把项目做的更完美，我应当努力反省才是。