谈谈敏捷开发【转载】
我对敏捷开发是源于10多年前看了一本关于迭代开发的书，从而对迭代开发有了一些兴趣。从那时开始有了迭代开发的概念。随着项目经验的增加迭代的重要性也越发觉得明显。随后进入了提倡敏捷开发的公司，被迫式的接触了许多“敏捷开发”，随着项目经历越来越多，慢慢的就开始有了更新的认识和想法。
但是在接触敏捷开发这个体系之前，自己有机会做一个项目，那个时候我开始将自己认为更有利于项目的管理工作做了一些应用，那个阶段我的主要做法是：
1、项目中开始划分更短的制品交互周期，而不是以前那样等待产品开发完毕后发布各种测试版本。
2、更充分与市场人员交流，在市场人员进行需求交底时，让更多的甚至全体成员参与会议，了解产品的原始业务及需求。并且在过程中有问题也及时的解答及沟通。
3、加强沟通力度，开发测试都在一起每天都会开个小会，通报每日的工作成果，将自己的问题说出来。
4、不同以往的发布频率，测试从项目开始便要切入到产品生产过程，而不是等到最后所有功能都完成后。从而大大减少变动对计划的影响。
在做这些工作的时候我并不知道敏捷开发这个东西，直到在2010年进入一个公司非常提倡敏捷开发，已经有了迭代周期、backlog、站立会议、周例会等等，在这个团队中对开发过程有各种规章要求，完全是制度化的，这在我加入的初期非常的不适应。事实上回头想想，那种方式已经变的不敏捷了，完全是一种教条式的应用。
后来自己有机会回到了老东家，开始自己带团队，很巧老东家被收购后开始推广敏捷开发，只不过因为不是总部，所以这次没有范本，完全由我自己来组织及控制。很高兴这个小团队几个月下来，个人觉得比较成功，当然后面也得到了公司的认可。
下面就敏捷开发分享一些应该着重注意的点，解决这些问题我想对任何开发团队都会有很大的帮助。
需求在开发中的重要性
大量的开发过程告诉我，需求在软件开发过程中是极其重要的。传统的开发强调初期的需求调研及需要分析，这个过程对于一些正规的团队会产生大量的文档，而后交由开发展开产品生产。
然而，事实却不是想象这么简单，无数的例子说明了一点，仅仅在需求调研过程中了解到的需求是无法保证的。数不清的例子告诉我们，需求是会变的，变的原因很多。在极端的情况下，有些客户签字的需求在开发完后，有需要变更也很正常。
所以需求是影响软件开发的第一重要因素，需求来源于业务，我们开发的产品不就是因为这些业务才去做的吗？如何需求都无法把握好，还谈什么开发出好用的产品？
然而如何做好需求呢？我想首先要确立需求的地位，然后只有通过不断的沟通、尝试、反馈向真实需求迈进。
强调人与人的交流
不管怎么样开发过程中主要还是靠人的，而且软件开发是个复杂的团体工程，一个小些的产品也会涉及到各类人：客户、业务分析、管理人员、程序员、测试员等等。这么多人在一起做事情，有一方没有处理好结果肯定就会有问题。
有这样一个例子：客户提出了一个会员管理功能需求，需求人员了解后组织了解决方案，于是交付了开发实现。而经过二个月无尽的黑夜之后交付，需求一看有个模块做的有偏差，但是已经来不及修改了。交给客户看后，发现这不是他们要的会员管理功能相差较大，另外在功能开发的这一段时间，客户又有了新想法，要对原先需求做调整。
这种例子可能大家经常经历吧？
这种问题在敏捷开发方法中提出了解决方法，就是通过不断的交付可用的制品。看起来很抽象，其实很简单。同样是上面的例子：
Ø 客户提出会员管理功能需求
Ø 需求人员在了解需求后与开发负责人商量，确定一个快迭代的开发计划，每二周向客户演示一次，并将这个计划与客户确认
Ø 确认后需求人员向全体成员讲解需求背景故事
Ø 开发负责人组织并确定迭代计划内容，明确每个迭代提交的产品目标、开发任务安排、测试跟踪计划
Ø 每个迭代过程中都由需求及测试进行确认每个任务的实现结果是否跑偏
Ø 后面就是每二周向客户演示一次产品，并获得客户的反馈
Ø 根据客户的反馈调整下个迭代计划，并继续下一个迭代
Ø 直到产品交付
通过上面的步骤，就不至于在开发完成后才知道用户的真实想法，因为很多用户对软件开发是没有概念的，他只知道自己有某种需求，但最开始是没有一个完整的概念的。所以就要通过不断的让用户看到产品的模型，这个过程用户才会逐步的对产品产生概念。同样的在过程中客户的提出需求变更也是在一定的可控制范围之内，这样一来可以大大的减少软件返工的情况，自然就不会拖延计划了。
而这个过程中，需求已经完成了一个真正的过渡，不再是一头重的情况了。他让需求从客户那快速的反馈到开发团队中。同样的，在开发不断的交付制品时，需求也更加及时的了解到产品的进度，把握开发人员开发的功能是否符合需求。
当然这并不是一个标准做法，不同的团队可以有不同的处理方式。这里只是想强调需求需要更多的投入到开发过程中去，及时的与客户沟通交流，了解到客户的真实想法。
强调文档的作用
我觉得很多对敏捷开发的一个误解就是不需要文档，敏捷开发并未抛弃文档。只是更强调更有效的方式使用文档。在很多传统开发方法中，特别是很多很正规的开发团队对文档的要求非常苛刻。然而事实是文档不易管理，最痛苦的是不好维护，文档需要随着变化而变化，比如需求调整、技术架构升级、产品维护等等。如果要保证文档的一致性，太难了。特别是对于一些无法进行有效管理的开发团队就更加明显，经常是软件已经几个版本了，文档却是两年前的。
但敏捷真的不需要文档吗？我想不是的，如何把文档做到好维护我想才是最重要的。文档到底指的指的什么？什么样的算文档？
提出上面两个问题，我们先想想经常说的文档的作用是什么？不就是一个传播工具吗？可以用作记录、给他人看、用于以后查看。有很多方法可就解决了这个问题，比如wiki系统。维护一个wiki系统，可以随时写，随时维护，可以方便的查找。嗯，多方便。
另外一个问题就是什么样的工作需要形成文档呢？
记得在前一家公司，维护一个10多年的老系统修改一个公式计算的BUG，但是怎么也不知道这个复杂的公式是什么意思，问过了公司大部分的人也无人可解。这时想，如果当初有那么一份文档，谢天谢地。
像这种关键的内容有份文档还是很重要的，否则随着时间推移，谁也不能保证能记得住当时为什么会这么干。
记得多年前一次记笔记的经历，我看了一篇文章了解了DELPHI实现单实例模式的方法，这种方法很酷。于是整理成了笔记写在了wiki上，第二天就得到了回复，帮助到了别外产品开发组的同事。
嗯，文档就是这样他具有传播性，你不可能跑去跟所有人说出你的想法，但是文档却更容易达成。他也有传承性，有些文档也许10多年后又起了重要作用。
团队协作
1、减少对开发人员的干扰
曾经接手一个产品的开发，最初遇到一个很头痛的问题，原先写好的迭代计划，而且工作量也较大，大家都在忙着。即便在这样的状态下，客服人员却经常跑来找某个程序员A维护各种系统问题，程序员A在一次维护中竟然导致了系统数据出现大面积错误。程序员A心理上承受着巨大的压力，而每天的这些问题又不得不解决，加之新版本又有很重的开发任务无法完成，最终导致整个开发计划变更。
我无法再忍受，找到了需求及客服的负责人，沟通后发现这些问题很多都是重复性的，主要是因为原先系统的不足。于是回去组织人员做了几个后台临时功能，并交付给了客服人员，之后就没有再来找过这位程序员A。后续我又找到了客服负责人，要求不能直接找开发人员解决这类问题，并与负责人约定了处理过程。
这是个例子，在实际情况中还有很多这种事情，甚至有很多开发人员要直接面对客户。我想对于职能型团队来说，开发团队最好是减少这些方面的干忧。当然对于一个人包干的情况就不讨论了。
大部分的人都不是超人，在一个时间段内处理超出自己负荷的工作是很难做好保质保量的。所以对于开发管理人员一定要考虑到这点，尽量让开发人员有比较好的工作进度环境，通过外界的方式来解决一些开发团队的干扰。
我接触过的很多程序员都很反感这种干扰，虽然有些人在这种全面的工作强度下成长很快，但是并非所有人都适应，长期下来会有怨恨和不快，工作效率会下降。心情舒畅还是很重要的，记得有一次迭代总结时，有个程序员总结说：发现心情舒畅自己的工作效率很高。呵呵。我想你也有同感吧。
2、不要忽略测试人员在开发阶段的作用
曾经多少次在项目发布前加班到深夜2点的情景还历历在目，那种感觉即快乐又痛苦。由于和客户签定的合同的交付日期就要到了，产品却迟迟未集成完成，测试只能干等着上网聊QQ。就在下班前的一刻发布了，测试开始了紧张的测试，在屏幕闪动中，一个个的BUG提交，直到流程都无法都走不下去，测试无奈了。第二天就要发布，实施人员就等着制品第二天出差。只有不断的改，再发布，无尽的循环。直到大家都憔悴的看着老大，终于老大说：还剩下的这几个问题无关紧要，大家回去吧。
几个月的开发过去后在总结会上，只能抱怨测试资源不足，时间太短，需求更改太多，需求更改后测试不知道。无数的问题一次一次的出现在同样的总结会议上。
上面的这个例子很多人应该经历过，真的测试只有最后一刻才能体现价值吗？我想不是的。
在后面的项目中我总结了这个问题的，针对每个开发任务要求进行测试验证。而测试如何验证呢？他需要知道这个开发任务的需求是如何，提前做好测试计划及测试用例，在接到开发制品后测试并提交BUG，这个工作是可以开发过程中就能不断的进行的。保证每一个任务的质量，可以大大减少后期集成的错误量。
另外根据敏捷开发的思想，测试团队在开发过程中也需要加强与开发团队的交流，甚至有必要组成虚拟团队，位置调整到一起，这样可以及时快速的交流，参加开发团队的站立会议同样可以及时了解到开发的实际情况及进度，反过来把握测试计划及测试内容。
特别是测试从另一个角度来审视需求，这样也可以一定程度上发现或者改善需求上的不足。
3、发挥团队人员的潜力
敏捷开发比较提倡开发任务由开发自己评估并认领工作任务，这样可以激发开发的潜在动力。
之前在做一个新产品时，需要使用java，而我们团队是使用C#的，面临转型问题。而有一位同事很感兴趣，于是我就让他负责前期的框架探索与搭建。结果就是这位小伙工作效率很高，我最初给他的目标全部都完成了。最有意思的是后面产品开始研发时，这位小伙已经成为了团队的大牛，大家有问题都找他解决。也正是因为这个过程，这位小伙被全面激活，也在大家面前展示了能力。甚至在小伙离职时也被领导给予大幅涨薪来挽留。只不过谁又能想象到这位小伙进入我团队之前是因为被定为裁员的目标而调剂过来的呢!
所以充分发挥好每个人员的特点，让人能够在自己感兴趣的工作中，效果会很多。减少指派方式的任务的分配，充分发挥个人的主动性，这个团队精神面貌也会好很多。
4、管理者不要离团队太远
作为团队的Leader要参与到团队的工作中去，比如一个开发主管一定要写写代码，参与架构等对项目有关的事情，而不是在那里分分任务。这样团队成员才会觉得这个Leader很亲近感。
特别是有些开发主管在带队后离团队越来越远，有时对于开发进度不如意时就说：“这么个简单功能怎么会搞了这么久？”，其实每天都在加班的同事心里想着：“有本事你来？”，即使这个小组长有这个能力，但对于团队来说也不是一件好事，因为大家都抱有怨恨之心，还谈什么好好工作呢？这个小组长就是失职的。所以这种情况下应该主动去了解进度滞后的原因，并且自己要加入到解决问题的工作中去，而不是在边上抱怨别人。
5、小组织不要搞太多的官
中国几千年的文化，官本位一直影响着我们，大家都想坐在那指挥，自己啥事也不用干，想想都惬意。在我们这个行业是不是发现也很类似？大家都想着干几年当个小组长，然后升个部门经理，当上CTO迎娶白富美。
团队的管理基本是事与人的管理，非常的伤脑和心。如果一个组织内，特别是小组织内“官”太多，协调就会非常的难，大家就会经常性的扯皮。
结束
与敏捷开发结缘也有几年，从开始的抵触到后面的认可经历了许多，这个过程并不是一蹴而就的，需要花时间花精力，特别是要去实践、总结。
还有我觉得是不能太教条，很多事情都要有怀疑的心，然后去实践总结，找到合适自己团队的方式方法。
