拥抱敏捷

• 前言

      有关项目管理和软件开发方法，我曾经面临了不少的困惑，也在思想和实践上做了一些探索。下边的文字就是近期的一些探索成果，我花了小半个早上和大半个下午，将其整理成文字，想跟大家一起交流一下，怎样才能把软件开发管理工作做的更好。在此仅仅是抛砖引玉，还请大家多多发表高见。

 

 

• 与敏捷结缘的历史

      Scrum和XP都都属于敏捷软件开发方法，但两者的侧重点不同，一个强调项目管理上的敏捷，一个强调技术实现上的敏捷。现在，已经有很多公司结合使用两种敏捷软件开发方法，并取得了显著的成效。

      我曾经在4年前接触到XP，当时也着实激动了一番，正好那个时候我在负责一个项目，所以就运用了一些XP中的方法。但是当时并没有意识到TDD（测试驱动开发）的重要性，对PP（结队编程）也有一些排斥情绪，所以其实并没有真正的实施XP，但是运用到XP中的一些 方法还是让我感觉到对项目管理带来了不小的好处，比如团队角色、每日短会、user story等。

      去年开始，Scrum逐渐进入了我的视线，一开始是在javaeye上看到Scrum这个名词的，当时并没有引起太大的注意。后来我在javaeye上发 了一篇有关项目管理辅助工具和规范化项目管理的困惑的帖子，也引来了一些javaeyers的讨论，其中就有以前的一个同事，现在上海某家公司 Scrum团队成员xxx同学的回帖，大概说了一下他们的Scrum实践。这时候，Scrum才真正走入了我的视线。原来Scrum已经为那么多公司项目团队所采用，取得了管理和产品质量双重的提升。又前一段时间，看到InfoQ上的一本迷你书《硝烟中的Scrum和XP》，作者是Henrik Kniberg，李剑翻译。通读了一遍后，一个感觉，那就是－－醍醐灌顶，作者的Scrum和XP实践中的一些方法，正是长期困惑我的一些问题的解决方法，书中描述的一些东西，正是我以前一直想要的。后来我又读了一遍该书，心中的想法也逐渐变的明晰起来，我想是该在项目中实施Scrum和XP的时候了。

 

 

• 困惑的“心里没底”

      以前我们一些项目，我觉得都处于一个“心里没底”的状态。

      首先，开发人员心里没底。由于传统的任务分派方式，使得开发人员只关注于分给自己开发的一亩三分地，没有项目全局观也不知道自己接下来做什么，对于项目没 有一个宏观概念。对于普通的程序员可能仅仅满足于自己的任务完成就ok了，至于什么代码优化，重构根本就是浮云，说到单元测试，不是浮云更是神马。通常， 简单的覆盖率很低的功能性测试或者凭着自信根本没有测试就交差了，更别说QA来负责质量。对于有责任心的程序员，可能会程序优化，也可能会做少量单元测试 代码，也可能会做功能测试，但为了赶进度，这些事情都没有做完善，所以程序员处于心里没底的状态。自己写的程序，是不是跟设计符合，程序是否能正确执行， 程序的健壮性如何，程序代码结构如何，是否具有可扩展性，是否具有可维护性，都是一个迷。

      其次，项目管理人员心里没底。建立在开发人员责任心基础之上的开发，首先就面临着质量的良莠不齐，因为责任心强的开发人员提供的代码质量往往会较高，而责 任心弱的开发人员提供的代码质量往往比较低。没有质量控制，项目管理人员对于开发出来的东西是不是用户想要的东西，其正确性、稳定性、可能会存在多少 bug都不清楚，这些数据又是一个迷。

      再次，高层管理人员心里没底。因为项目进展缺乏透明度，高层管理人员对于项目的整体进展情况往往不清楚，从项目管理人员口中得到的信息可能并不是自己想要 的，或者有的时候仅仅是凭想象的一厢情愿。项目团队人员是否被合理安排工作，项目能否按时交付，用户对项目会有怎样的满意度等等，这些也都是迷。

      最后，用户心里没底。因为缺乏跟用户的交流，或者用户对项目的参与程度少。就会造成用户和项目脱节，项目实现的功能可能跟用户所想的相差十万八千里。另外，项目进展到什么程度了，项目是不是能按照预先的进度上线，这些也都是迷。

      这些心里没底和众多的谜团造成的结果就是：项目在提交给用户后，用户发现所做的东西跟原先所设想的相差很远，而且bug奇多，用户间接成了QA。那么接下 来就是大量bug修改和需求变动，而程序代码由于本身质量不高，灵活性较差，需求变动带来的代码修改和编程量无限加大。于是，项目上线日期一再延后，开发 人员加班加点怨声载道，用户满意度直线下降。后期，为了挽回用户满意度，又得额外采用其它手段，这样开发人员再次加班加点就也再所难免了。

      这样的一种项目状况是否能避免，我觉得可以，至少可以改善。通过适当的管理手段，运用合理的软件开发方法，应该可以使得项目良好运行，至少大多数的项目应 该良好运行。通过书籍和网络资源，Scrum和XP给了我信心，因为我了解到很多团队使用这种软件开发管理方法取得了显著成效，我觉得对于我们的开发，Scrum和XP应该是会带来好处的。

 

 

• 敏捷初探

      敏捷方法论中认为，用户的需求是一直在变化的，我们应该去认识变化，接受变化，拥抱变化。那么在敏捷开发中，我们就应该通过沟通、重构代码，来满足用户需求的不断变化。通过沟通，可以把需求变化减少，通过重构代码，构建灵活的程序结构，使得需求变化带来的程序修改减小到最少。当然，这一切的前提是测试，开发未动，测试先行，可以把测试代码的编写理解为最初的设计，那么TDD（测试驱动开发）就很自然了。

      敏捷软件过程中，一般采用迭代开发的方式。我们学校里接受的传统的软件工程教育都认为，软件实现过程是一个流水线，先需求设计，再程序设计，再测试，再部署实施等等。但是，有项目经验的人，都会发现，这其实是扯淡。一开始的长篇大论的需求设计，很难跟上项目进展过程中的需求变化，在大多数的项目中经常如 此。过去一些项目中，我经常听到开发团队中一些人向我抱怨：什么没准备好，我不能开发；用户需求变化太多，我没法接受等等诸如此类，那么我觉得你肯定是受传统的软件工程理论毒害太深。因为在大多数情况下，用户一开始并不知道他想要什么功能，他只是一个简单的描述，随着项目的进展，他看到你做出来的东西，他 才会对他想要的东西做更清楚的描述。所以，在敏捷软件过程中，它将用户的初期需求整理成user story(XP概念)或者backlog（Scrum概念）,然后通过一次次的迭代，和用户一起来开发出想要的软件。

 

 

• 我们该怎么做

      那么，接下来我们怎么做呢，我觉得应该是这样。

      首先，在项目代码中引入单元测试，通过一段时间的测试代码的编写，让大家觉得开发程序的同时，写测试代码是常态。通过写测试代码，对软件进行重构，增强其灵活性和可维护性。当大家接受了这一概念以后，接下来的TDD就水到渠成了。那么，自动化的集成测试，验收测试也就不再遥远了。当然，结队编程也是后续将要采用的实践之一。

      其次，项目管理过程中采用Scrum框架。

      哪怕是进展到一定程度的项目，也开始用Scrum框架。先对项目接下来要做的事情做详细分析，通过团队的努力形成backlog。然后采用Sprint理论来进行迭代开发。每个Sprint结束以后，要发布可运行的的版本，演示给用户看，同时和用户进行讨论，做的东西是不是用户想要的，另外还要对该 Sprint进行总结，以便于下一个Sprint的开展。backlog和Sprint在项目管理工具上进行公示，加强项目进展的透明性。

      当然，验收测试也要加强，不能再让用户充当我们的QA。除了程序开发人员进行单元测试以外，安排的每个任务在提交之前必须由团队QA进行测试，测试通过才可提交关闭。

      另外就是每日Sprint短会，15钟左右，总结昨天工作进展，好的方式，不好的方式，阻碍等，同时安排今日工作。

      还有就是怎么样刺激团队成员进行代码重构，我觉得一个可行的方法就是代码检查，团队中的高级程序员可以担当这一任务，通过代码检查，要求开发人员对代码进行重构。

      关于奖惩。QA会对验收测试和回归测试中的bug进行统计，代码检查人员也会对程序中需要重构的地方进行统计，当每个Sprint结束的时候，谁的数据最 难看，嘿嘿，你请大家吃一顿大餐吧。谁的数据最好看，奖励一朵小红花，哈哈。这些数据都会在项目管理工具进行公示。

 

 

• 说在最后

      无论Scrum也好，XP也好，我和我的团队也是在理论学习过程中，参考一些别人的实践来准备将其引入到我们的开发过程中，有些可能会不适用，有些可能会对我们特别有帮助。以上一些粗浅的认识，还请大家斧正。