敏捷之路-初体验

说起来第一次听到敏捷开发这个词是2004年与之一起的是XP编程，当时刚刚加入挨踢大军还没多长时间，和很多程序员一样对于项目管理、项目文档持极端反感的态度。曾经老板尝试使用IBM的静室软件工程来实施ERP软件开发，带来的结果是一个项目组在公司办公室讨论一个月了项目文档还没有弄清楚，几乎脱离了实际情况。最后还是凭借个人能力完成这一旷日持久的ERP项目。

目前我所在的团队是2012年组建的，一年多以来基本还是按照以前的工作模式进行工作，随着业务量的增加逐渐发现项目越来越不可控，项目的进展完全看个人能力，而我一个人的力量毕竟是有限的，慢慢的开始认识到必须得好好管理管理项目了。

开始的时候只是想能有一个工具能够把任务分解，让每个成员清楚自己的任务，于是先用上了TFS。

TFS里面建团队项目的时候会给两个默认模板：CMMI和敏捷，我们只是一个小团队CMMI这样的巨无霸让我有点恐惧，于是选择了适合小团队的敏捷，当时对敏捷开发的认识只停留在敏捷这两个字上，当TFS用上了之后我们团队开始探索这个巨无霸（为什么说TFS是巨无霸，安装过的人一定知道）。

=======项目管理的力量======

我们的团队分成了两个组，分别开发两个项目，我们先在小一点的组中试用TFS，之所以选中这个组，一是因为人员少只有两个人，好管理，二是因为这个组的主力成员有过日企开发经验，项目管理上的理解更好，工作积极主动。

我们的探索从开发任务的管理开始，开项目会先召集成员讨论下一阶段做什么事情，然后把任务逐一分解，并增加到TFS中，这时对于TFS中的用户情况还不理解，我们只是用了任务和BUG，任务或BUG完成后把任务关闭掉，这个时候可以说TFS只是起到了任务管理的作用。

在平常的工作中大家把客户反馈过来的问题或自己发现的问题也记录为BUG增加到TFS中，有了新的需求也会及时记录到TFS中。

与此同时做为部门负责人一直在研究TFS的功能，看能给我们带来什么样的管理方式，这时发现了燃烧图，也大概明白了用户情景可以理解为用户需求/功能点，其中可以统计出来一些任务进展情况、开发人员的工作效率等数据。

经过近两个星期的探索，这个小组的工作有了明显的提升，该做哪些事情很清楚了，这期间给一个新客户部署了一套系统，我们也开会总结出了一套系统部署的标准工作流程，并反推出部署一套系统所需要的时间/人力成本。合作伙伴、公司老板、团队成员对这个组的变化都看在眼里喜在心上。

用一句话总结一下这个阶段就是：管和不管有很大区别，这时我才意识到小团队也是可以有高效管理的。

这一时期我们解决了以下几个问题：

1、每个人对自己要做的工作不清晰，只知道有很多事要做，但是具体有哪些，需要多长时间，没数。

2、把每个人的工作像玩游戏一样做为任务清单，让有强迫症的程序员效率提升不少。

3、形成了一部分标准工作流程。

当然也发现了新的急需解决的问题：

1、任务每周都会有增加，有时候程序员只看到任务数量在增加，看不到减少，渐渐失去动力，没有里程碑，看不到出头之日。

2、游戏里完成了任务有任务奖励，可是个这没有任务奖励，对无强迫症患者的程序员效果不明显。

3、无法通过TFS准确的看到进度，原因不明。

方法总结：改变从小处开始。共党一直都喜欢搞试点不是没有道理的，这一阶段的改变从一个小组开始，见到了效果，很容易大家都接受了，另外一个组几乎没有障碍的用上了TFS，也见到了点效果。

=========开始认识敏捷=========

到了这个时候可以说遇到了一个小瓶颈，幸运的是我们看到了项目管理给我们带来的好处，值得继续探索。

更加幸运的是老板带领我们团队的两个成员奔波千里到了大连参加软交会，我带着我的问题来到美丽的大连探索我们的项目管理之路，目标锁定项目管理论坛！

其实上一年也参加了软交会，项目管理论坛也参加了，但是并没有什么深刻的体会，这一次我们带着问题来了：什么是敏捷？为什么被挨踢大军如果推崇？

在此之前我们还搞不清楚迭代/用户情景/任务之间的关系，通过一天的论坛学习对敏捷开发恶补了一下，这一天最深刻的收获就是四个字：持续改进！

相比之下敏捷的四句话宣言对我的印象前不深刻，或者说在我看来敏捷真正的精髓并不是敏捷宣言，而是"持续改进”这个四字，从这时开始，持续改进成为了我们每一次部门会议上必须探讨的话题。

当然也明白了如何做迭代、如何做用户情景、任务。带着我收获我回到了团队，并分享给了大家，同时开始了我们的持续改进之路！

首先要做的就是洗脑。

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

对于这四句话中的前三句话基本每一个程序员都可以认同。

但是第四句话就有点难了，一直以来为了避免用户需求变化，我们总是尽可以的把需求调查清楚，功能尽可能设计的完美，考虑周全。但事实情况是设计的再完美，到实际使用的时候各种问题都会出来，甚至会完全推翻。

其实对于团队来说需要洗脑的并不是团队成员，而是团队的领导和客户。程序员们大多数会跟着领导走，领导怎么说我们就怎么做，除非在团队中有可以挑战领导的人存在，幸运的是我的团队暂时没有这样的人。对于程序员们其实只要大家看到了变化，看到了好处，自然会接受这一思想，所以洗脑工作并没有下多大的力气，只是和客户深谈了一次，客户基本接受了我的想法，到目前为止还比较配合。

其次，把敏捷开发的方法尝试应用在我们的团队中。

我们做了下面的工作：

1、向大家讲解迭代/用户情景/任务/BUG之间的关系，以及在TFS中如何使用，以及分解用户需求和任务的原则。

2、把当时剩余的工作梳理了一便，按着紧急/重要分类，挑出一部分任务放在以后再解决，确定了2周左右的迭代。

3、把任务分解到6个小时之内。之所以选择6个小时，是希望每一个成员每天至少能够完成一个任务，之所以不是8个小时，是留2个小时让程序员们处理其它的杂事，并且要求大家每天至少完成6个小时的任务。

4、布置站立会议，每天向团队成员通报当天任务情况，站立会议原则：

　　总时间不超过15分钟

　　每个人只讲三件事：昨天做了什么/今天要完成什么/是否需要帮助

5、这些依然还是在小团队中试点。

6、贯彻持续改进的思想。

7、布置了看板，把大家的任务贴在看板上，每日更新。

经过一段时间的尝试，这个小组的迭代提前完成，让我们看到了希望，同时TFS中的报表清晰了，能够相对准确的看到任务进展。

于是另外两个组（又增加了一个两个小组，开始另外一个项目的开发）也开始了敏捷之路，其中一个组效果明显，提前1天完成，另一个人最多的组晚了三天完成迭代。

同时又发现了很多新的问题，其中有一些是我在下一阶段想要重点解决的：

1、很多程序员并没有及时在TFS中更新任务完成情况，一直到了迭代最后才一起更新，甚至很多程序员平常都不看TFS。

2、任务评估不准确，导致部分任务严重超时。

3、责任不明确，一个功能模块的代码好几个人改过，出了问题找BUG非常困难。

4、TFS的很多功能还是搞不清楚，使用起来也有点麻烦，进度不直观。

不管怎么样这个月三个组的迭代都完成了，我们团队还是取得了不小的胜利，大家心情都挺不错。于是在人事的提醒下，向老板申请了一笔活动经费，带着大家去腐败。

腐败之后继续改进。

========开始持续改进==========

 此时正好到了月底，我们又有些的改进措施：

1、考虑到程序员们对任务的敏感度降低，在下一个月的月度考核中加入了任务考核：

任务目标分为及格目标和卓越目标，并把目标达成作为月度考核中重要的占比（60%），并且完成卓越目标还有加分，鼓励大家向卓越前进。

2、鉴于TFS使用的效果不理想，我们安装了SCRUMWORKS，在使用TFS效果不好的小组中推行，经过两个星期的使用，效果比用TFS有好转，在使用SCRUMWORKS之后这个小组的下一个迭代按时完成，虽然还有一些问题，比上一次迭代已经好了很多，最值得欣慰的是团队成员在我没有出面的一次站立会议中自行讨论如何按时完成迭代，这个小组具有了一点自我修复能力。

3、在这个月的月度例会中开始尝试明确职责，明确了SCRUM框架中的几种角色：Product Owner/Scrum Master/Scrum Team

随着一点点措施的开展，对于敏捷我也有了一点自己的认识：

1、敏捷开发的核心是持续改进，这一思想应该不仅仅适用于软件项目管理，对于任何管理同样适用。

2、任何工具、管理方法包括SCRUM、XP、宣言、敏捷十二条原则都是工具，适用就用，不适用就改。

3、敏捷开发与考核必须挂钩，没有诱惑任何好的方法慢慢都会褪色。

4、考核、管理方法也要持续改进。

最后想说一句话：持续改进只有开始，没有结束。