拥抱敏捷

• 前言

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

 

 

• 与敏捷结缘的历史

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

评论

19 楼 cuiguodong 2011-02-22  

挺有道理的，我觉得做软件最重要的是快乐的做出用户需要的东西

18 楼 Frankie199 2011-02-13  

huangyuanmu 写道

Frankie199 写道

    说的有一定道理，客户的需求是永远在变化的，软件永远更不上客户的需求，软件是滞后的，这个和病毒和杀毒软件差不多，首先发现病毒才针对病毒升级杀毒软件。
    但是需求变化也是有个度的，有些该坚持的就一定要坚持，不能随客户要求无间断的修改。我在做的时候一般先有个原型让用户参考一下，如其他地方成熟的系统等等，并且主要的业务功能点都是需要和客户多次讨论清楚的，这样业务核心和界面基本就确定了，然后才搞其他的东西。
    楼主有说到不能让客户充当QA的角色，我到觉得不一定。客户因人而异，有些客户喜欢钻技术等等，就应该让他参与进来一起搞。一来搞好了客户关系，二来有甲方参与开发错也错不到哪里去，是吧。
    倒是现在有个问题困扰我，实施敏捷开发后，有很多东西都是原型，避免不了重复和客户交流讨论的事情。客户不能到你公司来的，你只有下现场。而现在的开发不是一个人可以搞定的，代码人员、项目经理、需求分析设计人员、QA等等一堆人都下去了，出差费用就奇高，一报账就头痛。公司也要崔你验收，哎，很是麻烦。不知道楼主有什么办法解决没有？

不好意思，我可能不太解答得了你的问题，呵呵。因为我们公司的核心业务基本上都在本地的，跟客户的交流还是比较方便的。

但是可以给你一些建议，现在是互联网时代，一切皆有可能。面对面交流固然最好，但是出于节省开支而言，在线交流也是一种折衷的方式。成熟的客户对于项目的进展，应该是很关注的，我想非面对面的沟通和交流他也应该是可以接受的。你可以在一个迭代周期快完成的时候，和客户沟通好，什么时候发布可运行的版本，给客户一个可访问地址，同时给一个可以反馈的途径。我想，这样即便不能面对面，但也达到了沟通的目的。

不好意思，过年没上网，才看到。我们和客户一般还是在线交流为主，但是有些客户数据是封闭的，不可能放到网上的。所有就只有我们下现场交流。去年是下去一堆人，今年我准备只让需求人员下去，其它人都在公司。这样费用倒是节约了，就是客户该有点不满意，呵呵，问题得不到及时修改了。

17 楼 InsonSiu 2011-02-10  

    以前在学校，总是以为外面都是那样的按章做事，但现在工作了，才发现，公司为了赶进度，才不管什么进度，什么质量，在数据库里直接改一下东西，这搞搞那搞搞就给客人了，如果客人不满意，再重复。不要以为我所在的公司不大，是上市公司，而且是做政府的，哎，我真的想知道什么时候才能遇上我心中的冲满激情的团队。各们的团队怎样是怎样的呢？我比较喜欢写j2EE

16 楼 skyfen 2011-02-10  

敏捷只是概念的东西。太理想的东西实施的话问题多多

15 楼 huangyuanmu 2011-02-10  

Frankie199 写道

    说的有一定道理，客户的需求是永远在变化的，软件永远更不上客户的需求，软件是滞后的，这个和病毒和杀毒软件差不多，首先发现病毒才针对病毒升级杀毒软件。
    但是需求变化也是有个度的，有些该坚持的就一定要坚持，不能随客户要求无间断的修改。我在做的时候一般先有个原型让用户参考一下，如其他地方成熟的系统等等，并且主要的业务功能点都是需要和客户多次讨论清楚的，这样业务核心和界面基本就确定了，然后才搞其他的东西。
    楼主有说到不能让客户充当QA的角色，我到觉得不一定。客户因人而异，有些客户喜欢钻技术等等，就应该让他参与进来一起搞。一来搞好了客户关系，二来有甲方参与开发错也错不到哪里去，是吧。
    倒是现在有个问题困扰我，实施敏捷开发后，有很多东西都是原型，避免不了重复和客户交流讨论的事情。客户不能到你公司来的，你只有下现场。而现在的开发不是一个人可以搞定的，代码人员、项目经理、需求分析设计人员、QA等等一堆人都下去了，出差费用就奇高，一报账就头痛。公司也要崔你验收，哎，很是麻烦。不知道楼主有什么办法解决没有？

不好意思，我可能不太解答得了你的问题，呵呵。因为我们公司的核心业务基本上都在本地的，跟客户的交流还是比较方便的。

但是可以给你一些建议，现在是互联网时代，一切皆有可能。面对面交流固然最好，但是出于节省开支而言，在线交流也是一种折衷的方式。成熟的客户对于项目的进展，应该是很关注的，我想非面对面的沟通和交流他也应该是可以接受的。你可以在一个迭代周期快完成的时候，和客户沟通好，什么时候发布可运行的版本，给客户一个可访问地址，同时给一个可以反馈的途径。我想，这样即便不能面对面，但也达到了沟通的目的。

14 楼 Frankie199 2011-02-09  

    说的有一定道理，客户的需求是永远在变化的，软件永远更不上客户的需求，软件是滞后的，这个和病毒和杀毒软件差不多，首先发现病毒才针对病毒升级杀毒软件。
    但是需求变化也是有个度的，有些该坚持的就一定要坚持，不能随客户要求无间断的修改。我在做的时候一般先有个原型让用户参考一下，如其他地方成熟的系统等等，并且主要的业务功能点都是需要和客户多次讨论清楚的，这样业务核心和界面基本就确定了，然后才搞其他的东西。
    楼主有说到不能让客户充当QA的角色，我到觉得不一定。客户因人而异，有些客户喜欢钻技术等等，就应该让他参与进来一起搞。一来搞好了客户关系，二来有甲方参与开发错也错不到哪里去，是吧。
    倒是现在有个问题困扰我，实施敏捷开发后，有很多东西都是原型，避免不了重复和客户交流讨论的事情。客户不能到你公司来的，你只有下现场。而现在的开发不是一个人可以搞定的，代码人员、项目经理、需求分析设计人员、QA等等一堆人都下去了，出差费用就奇高，一报账就头痛。公司也要崔你验收，哎，很是麻烦。不知道楼主有什么办法解决没有？

13 楼 crane136 2011-01-30  

教条一下，结合的不深入

12 楼 abraham_xi 2011-01-27  

一句话，大公司和小公司是不一样的，有的东西大公司能做，小公司是万万不能做的

11 楼 tho 2011-01-25  

第一次听到QA这个名词，没什么感觉，最早是外企里有，当时觉得开发至上，QA工资比开发应该低，，再汗一个。。。当时还问人家QA是什么

现在想来，如果有测试，有QA，开发人员再有各个层次的，顾问前期采集需求，还有专门的技术支持。那么做项目是不是简单很多，项目经理需要的就是将这些资源有效地组合起来，促使项目按进度发展就ok了。貌似比较幸福！这种情况下项目经理需要对各个环节都比较清楚，出了问题可以快速定位。

可是到了小公司就完全不一样了，顾问顾了一下就不管了，项目经理就从需求开始接手，开发人员也就那么几个，就像某楼上说的，测试都没有，更没有QA，这些都要项目经理找人来做，甚至亲力亲为。到了实施阶段也一样，无限累....求解！

10 楼 tho 2011-01-25  

支持！
现在想来我是深受老思想的毒害，
另外一个老员工给我设计了一个迭代开发，其实就是敏捷开发的概念，可惜俺愣是不知道，汗...
大家给推荐一条最佳实践的路子吧，推荐好书也可以，
不胜感激。

9 楼 ak121077313 2011-01-25  

什么是敏捷？听过这么多人讨论 一点概念都没

8 楼 huangyuanmu 2011-01-25  

说实话，老外的敏捷概念中，有些带有浓厚的西方文化色彩的，不适合中国人的习惯。

照搬书本上的，那是教条，理论结合实际，确实产生了效果，我觉得那才不白“敏捷”一回。

7 楼 huangyuanmu 2011-01-25  

QA和测试不是一回事，大家都知道，可是小公司能否养得起这些专职角色？专门的测试人员都没有，更不用说QA了，能引入测试和QA这些概念，就已经不错了，大家都是身兼N职，不能跟大公司比的。

6 楼 redouble 2011-01-25  

这里的人都认为QA就是测试人员吗？我晕。

5 楼 xzhome 2011-01-22  

如果开发团队达到一定规模的话,只有自动化测试+QA 人工测试才能解决测试的问题

4 楼 giginet 2011-01-21  

你们公司是QA进行测试？？有些希奇。。。

至于scrum，我觉得还是根据情况自己改装比较好，没必要完全套搬框架。代码Review是必须的，评审者除了高级程序员外，其他一些人也可以参加，能否培养大家的能力。
一般代码Review+单元测试，基本可确保代码质量。
配合后面的黑盒测试（几轮），然后最后由项目经理+QA来检查测试结果，确认是否可以发布。

3 楼 fantasy 2011-01-21  

走适合自己团队的敏捷之路。。。

2 楼 EastMoor 2011-01-21  

支持敏捷，可惜很多数公司的敏捷项目都是概念上的敏捷，把开发周期叫做sprint就算敏捷了。

1 楼 China_xuelei 2011-01-20  

咋没人评论呢？