昨天在公司敏捷核心圈做了一次分享，题目是Getting Real，是我很欣赏的一家公司总结的，Getting Real谈到的方法和公司实际情况比较符合，非常适合web团队借鉴。
Getting Real :The smarter, faster, easier way to build a successful web application是一种更小规模，更快速，更高质量的web类软件构建方法。
进一步阅读：Slideshare上的分享
| Scoring: | |
| 50 points | Agile maven |
| 40-49 points | Agilist all the way |
| 30-39 points | Agilist in training |
| 20-29 points | Closet agilist |
| 10-19 points | Thanks for taking the test |
另外，判断团队不是敏捷的10个问题：
呵呵，试试看，你的团队敏捷了吗？
敏捷团队要能达到自管理的能力，除了理解敏捷的理念和必要的素质外，其实空间（协作空间）环境也很重要。信息辐射器（Information Radiator，The Ideal Agile Workspace）中介绍了好几种常用的方式，稍微整理一下，分享如下：
信息化工作空间的关键是信息，最终目的是使任何人只要进入一个团队的工作区域，就可以立刻了解项目的进度，项目的运行情况，现有的问 题，每个人现在的任务，一些团队需要改进的地方等等。大家每天来上班，只要看一下板，立刻就知道自己该做什么。不光是团队成员，一些 Stakeholder也可以到工作区域去看一看信息辐射器，了解最新的状况。即使Stakeholder不能到现场，只要经常发送一些照片，或者经常参 加一些演示，效果也会不错。实现信息化工作空间的前提是团队成员要坐在一起，如果不能坐在一起，那只能通过一些电子手段进行同步。当然信息辐射器也不能太 多，太多也会导致混乱。
周五，参加了一个团队项目IPM会议，整个会议从原定的计划1小时完成变成3个小时完成，我在参加其中的约40分钟的过程中发现了很多问题，问题列举如下：
1、没有目标或目标不清晰。我从进去到离开，没有了解到任何一个信息，是关于这次迭代会议的目标的，唯一听到的是这次讨论的是要改进产品的交互，但是改进那些地方？如何改进？改进到什么程度？这个事前没有任何的结论性东西，而是在会议上通过不同角色，所有人员的发散，我相信这样的IPM会议，我离开以后情况会是一样的。
2、没有回顾上一个迭代的情况。也许甚至都不知道上一个迭代做了什么，上一个迭代的目标是什么？这里有一个很大的问题，会导致所有的项目成员对产品的持续发展目标感觉到迷茫，没有延续性。同时也不知道上一个迭代做的是好，是坏？当然，做得好是坏应该是项目回顾的时候做的，但是团队可以调整，把项目回顾结合到IPM会议上去做，花时10-15分钟，应该效果非常明显；
3、IPM会议变成纯粹的讨论会。这个与目标不清晰有关，也与会前准备工作有关，同时还有一个非常大的问题就是在讨论某些问题的时候，是跳跃式的讨论，比如讨论一个产品的交互的时候，由于会前对这个交互没有什么思考（比如，这个应该是产品经理在IPM会议前就要做好的，产品经理应该输出本次迭代要实现的产品的交互，然后可以供大家讨论，同时不允许讨论太长时间），因此会议主持人就在页面上晃来晃去，大家也不知道要讨论些啥，也不知道这个产品交互究竟存在什么问题？ 因此，这样的讨论就变成了一锅粥。
4、陷于细节。IPM会议的目标是确定本次迭代的产品目标， 划分项目开发范围，分配工作并透明化，评估产品特性价值和优先级。而如此的IPM会议，大家往往直接就陷入了细节，要花非常多的时间去讨论这些细节，而这样的讨论显然是没有任何结论的，从而会造成大家对产品应该如何发展非常的迷茫。
5、缺乏master角色。会议出现了问题，比如大家陷入细节，发散讨论等等，这些都会直接影响IPM的效果，然后并没有明确的master 角色的人员跳出来指正或制止。
6、没有timebox等等…… 其实还有一些问题，但是可能还不是当前影响最大的。
总结以上这些问题，那天会上，我离开前在笔记本上记录了应该如何开一个比较成功的IPM会议。我们先从IPM会议的目标来展开。
为什么要IPM会议？
对于采用敏捷迭代式软件开发的团队来说，通常一个迭代代表一个产品开发的阶段，迭代的结束也是产品结束了上一迭代开发并输出成果的时刻。IPM会议就是在这个时候召开的关于团队对下一迭代目标展望和行动分工的会议。它对团队非常重要，与较传统的项目组织形式不同，由于迭代时间通常在2周-4周，时间不长，因此在这样的时刻开项目组会议更容易去发现上一阶段的问题和困难，更容易去清晰下一迭代的工作目标。
开IPM会议前该准备什么？
很多人有这样的误区，以为IPM会议就是团队一起讨论并明确团队工作目标的会议，是的，没有错，但是，如果随便的发散讨论，这样的IPM是得不到一致的目标的，因此IPM会议还要求会前做一些准备，我总结一下，目前觉得至少应该包括：
如何开IPM会议？
初步觉得步骤如下：
1、项目经理回顾上一迭代的成果（已经准备好的）；
2、项目经理总结上一迭代碰到的问题，困难和风险；（已经准备好的）
3、项目经理介绍本次迭代的总体目标（会议准备期间已经和产品经理讨论一致），目标的描述一定要清晰，条理，可达到，容易让团队成员理解
4、产品经理介绍本次迭代的产品目标和特性范围。（陈述本次迭代总体产品目标，包括那些产品方面的特性，准备解决那些用户的问题和场景，能给用户带来什么好处，希望产品特性做成什么样子，达到什么目标…)
5、如果开发人员对产品经理所描述的不清楚，可以直接示意提问，直至把产品特性所描述的问题定义清楚。项目经理在这个时候要控制，不允许针对一些对产品特性如何实现陷入技术细节或发散到其它与本次迭代无关的事务上去；
6、产品经理对大家明确一致的特性描述用户价值（从产品规划，用户需求，用户场景等方面评估），并传递给所有团队成员；
7、项目经理组织开发人员对产品特性进行评估（评估工作量，采取集体评估方式）并认领；如果集体评估某个特性有实现难度，则项目经理可以在最后环节安排15-30分钟的讨论，如果没有办法解决这些技术难题，则建议在会后单独讨论，并找其它资源（技术顾问）共同商讨解决方案；
8、最后，项目经理把本次迭代会议讨论的产品特性和认领分工情况列入迭代计划，并宣布，本次迭代设置timebox，轻易不能进行变更，需要变更时候，需有产品经理，项目经理，开发人员等等角色共同确认；
IPM会后还需要做些什么？
IPM开完了，还有3个重要的事项要做。
1、发会议纪要，总结本次迭代会的目标，特性范围，技术难题，人员认领分工情况等等，让团队成员以及项目干系人等都了解；
2、每日晨会上，要围绕IPM会议制定的问题进行，每天都要强调目标，包括产品的目标，项目的进展，碰到的问题，特性的进展，技术难题是否已经得到解决等等。
3、项目经理和产品经理开始筹备和思考下一迭代的产品目标和项目目标；
以上是上次参加了一个IPM会后感受到的问题，希望通过这篇日志的总结，帮助团队的各个成员去思考自己的职责，有准备有目标的召开IPM会议，从而保证迭代的节奏是正常的，稳定的，保证团队目标是一致的。
在Scrum中，提倡每日站立会议，XP里面也提倡站立会议。其实大家都已经实践过站立会议了。但是如何开一个好的站立会议？如何避免站立会议形式化呢？
简单回顾一下站立会议存在的价值：如果觉得会议很重要，那么站立会议就是一种极致化的会议形式；如果觉得透明化对团队很重要，那么站立会议就是一种将透明化极致化的形式；如果觉得了解项目进度很重要，那么站立会议同样是一种极致化的了解形式…..
站立会议每天都要重复以下事项：
1. What did you do yesterday? 你昨天做了什么？
2. What will you do today? 你今天计划做什么？
3. Are there any impediments in your way? 你碰到了什么障碍？
站立会议的目的在于团队之间对项目状态，成员状态的一种检查和更新，它是一种极致的（时间段，周期段，频繁）的项目沟通会议，同时，它也希望是适可而止（时间控制30分钟以内就刚刚好，不分散团队注意力，达到了解彼此状态就刚刚好）。为此，站立会议提出了如下的要求：
1、同一时间同一地点，避免过度的寻找一个开会的地方，避免团队成员过度的考虑什么时候，什么地方开站立会议。因此，最好的地方也许就是座位周围，快而方便；
2、站立会议要准时开，同时不要超过30分钟，同时可以根据项目组的实际情况看，比如人员规模，但是不应该超越站立会议应该做的那3件事情，否则站立会议将失去意义；
3、站立会议必须有人决策并及时阻制不必要的讨论，Scrum里面是master，但是根据实际项目而定，项目经理应该承担这样的职责；
4、站立会议必须有人专门跟进团队成员碰到的障碍，Scrum里面是master，但是根据实际项目而定，项目经理应该承担这样的职责。因此对于项目经理，参加站立会议不仅仅是做以上3个事情，项目经理实际上在站立会议的时候要记录每个成员描述的状态，碰到的障碍，在站立会议之后，要形成解决的action item，去协调资源完成，并在下一次站立会议上跟成员update；
5、站立会议需要看到每个成员的工作情况，如白板上的story wall，这样可以更清晰的了解到每个人的情况。这个很重要，否则站立会议会变为各说各的，彼此也不太理解说了什么，而且说的东西也没有延续性；
6、站立会议上除了做好以上3个事项外，还允许讨论问题，但是问题不要超出3个，同时不能超出时间（30分钟）否则项目经理就要控制和记录下，再单独解决问题；
7、站立会议对组织纪律性要求高，要求团队成员自觉，拒绝迟到；否则会导致站立会议缺乏延续性；
8、如果有某个成员update 状态不清晰，必须提出疑问，让陈述更加清晰，以免对其它成员带来误解；
另外，经常有人问，为啥开晨会要站着？难道是为了站着大家比较辛苦，所以会比较守时吗？据国外的研究者表明，站立的益处可能在于notification. 具体大家可以去查查。总而言之，站立会议的目的很简单，时间很短，内容不多，也不能有太多的参与者（7人其实最合适），但是同时，站立会议也仅仅是一种形式，如果在实践中能加于创新，保证站立会议不落于形式和枯燥，又何尝不会成为最佳实践呢？
正在实践的同事们，也许，是时候反省一下，我们的站立会议已经落入形式了吗？
今天例会的时候听到Lion将要介绍yahoo敏捷实践的东东，网上搜索了一把，发现yahoo其实已经实施3年多了，而且据说获得了比较大的成功，3年后，Yahoo!已经有了200多个开发团队在使用敏捷实践。明天记得找boots 要点资料哈。此外，这本书是yahoo人写的，可以考虑购买看看哦：敏捷估计与规划
Scrum 产生的收益在开发团队经验中体现在不同的方面。在Yahoo!公司，在上18 个月中将近50 个开发项目采用Scrum，一共近600 人参与，采用Scrum 的团队数量在快速发展。这些项目从客户界面，网页设计如Yahoo! Photos, 到后端基础构造服务如服务上百万客户的Yahoo!Mail；从全新的产品如Yahoo! Podcasts，其利用Scrum 作为从构思到发布的流程（并获得该年度同类产品的Webby 奖），到一些增量的项目，包括开发新的部件并维修bug 和其他的维护工作；我们也利用Scrum 来分配分布式项目。每一个季度，我们对Yahoo!公司每一位Scrum 的使用者进行调查（包括产品所有者，开发团队成员，ScrumMaster 和这些人员的经理），并让他们将Scrum 于以前的开发方式做一对比。我们正在准备Yahoo!公司的深入调查报告，以下是相关的资料显示：
ADTmag.com的编辑Kurt Mackie与Gabrielle Benefield（这些团队的核心组织者之一）就Scrum在Yahoo中的应用情况进行了对话。
Kurt问到，是什么原因促使Yahoo!转向了敏捷和Scrum开发，Benefield说：
有些公司一起步官僚习气就很严重。可是，Yahoo刚开始时规模很小、发展很快，他们最开始的做法非常敏捷，几个创始人坐在一间屋子里面开发软件。然而当规模扩大到某种需要更加频繁交流的阶段后，他们提出了使用传统的瀑布流程……但是在我们这种创业型文化中，它很难实现。我们的员工都很聪明，富有创新能力，他们习惯于时时刻刻提出自己的想法。瀑布流程对他们来说太古板太做作了，它降低了他们的效率。于是，团队中的一名工程师开始给大家布道，他说：“嘿，我们应该更敏捷一些”……所以在2005年2月，我们就启动了一个敏捷开发的试点项目。
随后Benefield又谈到其在实施敏捷开发的过程中的一些心得体会：
…… 那些我曾参与其中的敏捷团队，尤其是那些对其进行过大量辅导的团队，他们的生产力很容易就提升了200～300%。有些团队做的尤为出色，因为他们真正地 实施了敏捷。某些团队可能由于没经过太多的辅导和训练，或存在系统性的阻碍，所以改进情况就不那么明显。但从整体来看——包括那些最差的情况——生产力的 提升幅度大约在35～36%之间。综合所有情况考虑，这个估算还是相当保守的。
Kurt又问道：“在敏捷/Scrum的世界里，变化是好事吗？”Benefield坦然道：
我 们 的想法发生变化是很自然的事情。当你开始构建一个产品并看到一些结果后，你就会想做出一些改变。我们不会说“你不能改它”，我们是在拥抱变化。在互联网上 面，你不得不拥有快速变化的能力。举个例子来说，当我们搭建Yahoo邮件的大规模存储后端时，中途有一个竞争对手提供了容量更庞大的邮箱存储空间。我们 当时必须迅速做出响应，假如当时我们用的是传统的瀑布模型的话，我们势必无计可施，但最终我们成功地对抗了对手的威胁。在开发产品的过程中，我们曾一次又 一次面临这样的局面。
当其被问到开发中想法常常变化所带来的影响时，Benefield说道：
敏 捷有着严格的纪律。对于类似所有的代码都有全方位的测试这种事情，我们是纪律严明的，所以你有勇气去尝试变化，理解变化所造成 的影响。这里不会出现那种所有人都在尝试自己念头的无序状态。我们允许团队进行自组织，各种想法从团队中源源涌出。但管理层和产品所有者对选用哪种想法来 实施有着最终决定权，会从业务层面上来制定优先级，因为他们对其了如指掌。他们从根本上控制着何时发布产品、发布哪些功能，而团队自己决定如何完成工作。
在最后，Benefield以下面这段话结束了本次访谈：
在Yahoo，我们永远不会命令别人使用这个过程。我认为过程的优点要靠它自身体现出来，人们也应该有选择的自由。敏捷正在Yahoo中慢慢取得主导地位……我相信，随着时间的推移，为了能够在竞争中真正胜出，敏捷会是公司最佳的选择。
节选《程序员第9期》 作者钱安川。
上周在Infoq活动中参会人员提问很多的问题就是pair program这个问题，当时针对各个问题并没有时间来详细的解答，今天看到钱安川的这篇blog，对pair做了比较详细的解释，就节选其中精华，梳理在这里，供给团队的同事们参考。
在Thoughtworks公司，开发者不仅仅是pair 编程，而且还pair做很多很多其它事情，如文档（估计是采用wiki协同编写）、学习（跟我们的小组学习估计类似）等等，看来真正的敏捷公司也是非常“XP”的，呵呵。
钱安川谈到pair的好处如下：
1、Pair 可以最大化的提高工作效率
软 件开发并不只是程序员堆砌代码的过程，它更多的是一个创新的过程，是一个发现问题、分析问题、解决问题的过程。一个人编程时，往往有了一丝零碎的想法就开 始编写代码。写完代码之后，忽然发现这个方案行不通，只好废弃这些代码，重新开始新的想法。当一个人在遇到疑难问题时，很容易走入“死角”。而Pair则不同，一个人有了想法，首先要表达出来，让自己的同伴理解，经过深刻的讨论，一致认可之后才开始编写代码。一个人编写代码，另一个则在旁边思考，会为下一步的工作提出建设性的意见。发现了问题可以及时的指正。大大的提高了代码质量。
一个人一天有效工作时间不超过3－4个小时。两个人一起Pair。 一个人编写代码，另一个人则从设计的角度思考下一步的工作，有了想法之后，互相讨论，再互换角色。在开发过程中，设计思考和编码实现不停的进行交换，保持 了良好的开发节奏。同时可以互相督促，使彼此更加认真的工作。遇到问题和压力时，可以一起面对，互相鼓励。可以一起分享解决问题的成就和乐趣。
2、Pair 是知识传播的最好途径。
很多软件公司都建立有自己的知识库，有的还建立自己的培训部门，甚至高薪聘请一些专家做技术培训。但发现效果并不理想。培训之后，开发人员面临实际的项目，还是一片茫然。而与有经验的同事一起Pair则是在实际项目中学习，具有非常强的针对性。你学到的不仅是一些技术和技巧，更多是他们思考问题方式、解决问题的方法。和各种不同经验的同事一起Pair，你的经验和能力可以得到快速的提高。
3、Pair 可以打造出最佳的合作团队
很多软件公司都建立有自己的知识库，有的还建立自己的培训部门，甚至高薪聘请一些专家做技术培训。但发现效果并不理想。培训之后，开发人员面临实际的项目，还是一片茫然。而与有经验的同事一起Pair则是在实际项目中学习，具有非常强的针对性。你学到的不仅是一些技术和技巧，更多是他们思考问题方式、解决问题的方法。和各种不同经验的同事一起Pair，你的经验和能力可以得到快速的提高。
同时针对pair带来的问题，也有很多反对的声音，主要顾虑如下：
1、 Pair 浪费资源
以前是一个人完成的工作，而现在却是由两个人一起完成。一个人在写程序，而另一个却在旁边观望。为开发人员支付报酬的老板是多么心疼那些白花花的银子。
可是，作为老板的你可曾做过统计过，每天加班工作12小时，满脸疲惫的开发人员到底为你创造了多少的价值？在这漫长的12小时中，能高效工作的时间又能有多少呢？一个开发人员每天编写几百行的代码，可是真正具有实效性的代码又有多少呢？
软件的本质就是很难用一种标准去衡量它的进度和实效性。开发人员能力的高与低、经验的多与少、工作的主动与被动，对软件开发的成本有非常大的影响。前期糟糕的代码，在后期修正，是需要付出几倍甚至更多的代价。在软件的行业里，人月和代码行永远是神话。
在1999年，犹他州立大学（University of Utah）做了一项试验。.两组学生，一组独自工作（一共13人），一组Pair（一共28人，即14对）。他们完成相同的任务（由助教预先设计和开发了测试案例）。
下面的表格（图－1）是完成相同的四个程序，独自工作和Pair工作使测试案例成功通过的百分比。
（图－1）
下面的柱状图（图－2）则是完成相同的程序，两组所花费的时间比。虽然Pair的学生在刚开始的阶段比独自工作的学生花在同样任务的时间较多，但很快Pair的学生的时间开始大幅度的下降。而独立工作的学生需要花费比Pairs更多的时间来达到接近的代码质量。
（图－2）
而且，在具体项目中。Pair会带来比上面结果更高的价值。一、在实际开发中，如果错误越多，就要花费越多的时间去修复它。在我们的试验中，没有统计修复错误所花费的时间。二、从图－1可以看出，Pair在产生高质量代码时，也即意味着对需求的准确理解。个人团队对需求理解偏差比较大，后期也要花费更大的代价来纠正。三、从图－2可以看到，Pair的团队开发能力提高很快，这是潜在的价值。在比较试验之后的问卷调查之后发现：
ü Pair能用较少的时间生产更高质量的代码。
ü Pair的学生们认为自己比一个人的时候更勤奋和更聪明的工作，因为不想让自己的partner失望。
ü Pair的学生认为自己比一个人的时候更专著,紧凑和由纪律的工作，而且是持续的。而独立工作的学生也可以专著和紧凑的工作，但往往不持续。
ü 在紧张时间安排和繁重的工作压力下，独自工作的学生很容易蜕变为没有纪律的程序员。
2、人手不够。
也许，在你的公司，昨天又有一个老员工递交了辞职申请。老板看着一张张新的面孔，很无奈的摇了摇头。招聘员工并不困难。但如何让新员工快速进入角色，掌握公司的技术和业务呢？
人员的流动一直是让很多软件公司非常困扰的问题。特别是老员工的离去，也就意味着公司多年的技术和业务积累的流失。
而在Pair工作的团队中，几乎不用担心这个问题。Pair可以快速的进行知识传递，通过Pair和Pair伙伴的交换，知识不再是掌握在一个人的手中，而是整个团队一起共享。
3、开发者不能很好的合作，Pair 对开发者要求太高。
真的要求很高吗？看看求职简历，不是每个开发者都口口声称自己具有很好的团队合作精神吗？如果你不能很好的和别人Pair，团队精神又从何谈起呢？
那任何两个人都可以搭配进行Pair吗？
不，Pair对开发者是有要求的。它要求开发者乐意和别人沟通、合作，要求开发者能够彼此尊重，愿意和别人分享自己的知识。这不正是我们一直倡导的团队合作精神嘛！
Pair的搭配是一个有趣的问题。有人说，最好的搭配就是两个人能力相当。其实不然，Pair应该是一种多样的变换组合。在Pair的团队中，经验丰富的开发者有责任带领新人，传知授道解惑，同时可以享受传道的乐趣。新人，更应主动找有经验的伙伴Pair，快速学习提高自己。Pair的核心就是沟通，只要两个人能很好的进行沟通，那么他们就可以很好的搭配。
关于Pair的实施，其实并不困难。我们需要的只是经验，当然经验也只会来源于实践。
参考资料：
http://www.pairprogramming.com/ 这是一个专门介绍和研究Pair的一个网站
AgileLog，是一个SAAS应用的敏捷项目管理工具，提供了Single Server的支持，以及1-10个用户，10-20，20-50个用户支持的Hosting服务。最高的服务模式每月租用是$329/month，价格不菲啊！
在当前经济危机的形式下，也许敏捷的项目管理服务会是一个机会，而且敏捷的热潮正在国内开展起来了！
AgileLog其实是一个很简单的tools，也许它是讲敏捷发挥到了极致，提供了对backlog的跟踪管理，提供了对时间的跟踪管理，同时也支持对多个项目的跟踪管理。这里有个例子介绍了AgileLog的workflow，也许我们也可以参考一下，怎么实现最简单的敏捷workflow呢！
“AgileLog has proven to be true to its purpose by providing a simple and clean interface to manage backlogs for multiple projects. It remains loyal to the spirit of the Agile movement by allowing teams to stay focused to their commitment of delivery.” 使用Agilelog的客户如是说
怎样，体验更多的Agile Tool吧，作为产品经理的你，怎么能不动心呢？快快去吧：AgileLog
三个和尚没水喝的故事大家都听过，话说三个和尚终于解决了挑水的问题，可光喝水是喝不饱的，粥还是要吃的，于是一个新问题出现了，一锅粥三个人吃怎 么分？三个小和尚虽说都是天性善良，但毕竟没有得道成佛，不免自私自利，怎么样公平的把一锅粥平均分给三个人，这的确是个头痛的问题，于是，我们的故事开 始了：
第一个月，三个小和尚抽签决定一个分粥的人，二师兄抽到了签，获得了分粥的权利，可是出现一个问题，二师兄的碗里的粥总是最多最好，三师弟的粥却总是 清汤寡水的。慢慢大家明白了这样一个道理：权力导致腐败，绝对的权力绝对腐败。熬到月末，厚道的大师兄说话了，不能再这样了，得换个法子。
第二个月，有了前车之鉴，三个小和尚明白了分粥的权利不能绝对化，于是商定轮流坐庄，每人一天，这样轮到谁坐庄，谁就有为自己多分粥的权利。三师弟鉴 于上个月二师兄的不良表现，每当轮到自己坐庄，就给自己分的最多，以至于吃饱了还有剩余，而给二师兄象征性的分一点点，让他饿一天肚子，同样二师兄也是如 此报复三师弟。于是大家饥一顿，饱一顿，熬到月底，不行，毕竟三个小和尚谁也没有骆驼的本事，这样下去会得胃病的，还得想别的法子。
第三个月，大家公推最厚道的大师兄主持分粥，开始半个月大师兄还算公平，可是三师弟以小卖小，分粥的时候总是说吃不饱，大师兄于是就给他多分了一些，二师兄不免有些不满.熬到月底终于爆发了，二师兄强烈抗议大师兄的不公平。不行，还得再想法子。
第四个月，还是大师兄主持分粥，但是其他两位小和尚享有监督的全力，于是乎每天二师兄都要和三师弟吵个没完，都觉得对方的粥多了，直到吵到没有力气再吵的时候为止，可是这时候粥已经凉了，唉，这样下去，恐怕还得得胃病。
像三个和尚没水吃的故事一样，三个小和尚又是一筹莫展，谁也那不出一个好法子来解决这个问题．没办法，故事讲到这里，只好请神仙出场了，就让观音菩萨 来吧。（不要问我为什么请其他神仙出场，哪位神仙都一样，只是观音大士的知名度比较高而已）。观音菩萨给三个小和尚出了一个主意：还是每人一天轮流坐庄，但是分粥的人必须最后一个领粥。令人惊奇的是，这样下来每个人分的粥都是一样多，精确的一塌糊涂，因为每个分粥的人都认识到，如果三个碗里的粥不一样多，他自己无疑将拿到最少的那一份。
于是乎，三个小和尚分粥的问题就这样解决了，故事也就结束了。
这个故事告诉我们一个道理：人是最复杂的，涉及到人的问题没有简单问题，需要寻找好的方法至关紧要。但是越复杂的方法，往往漏洞越多，也越难以执行，最好的方法往往是最简单的方法，可以准确击到人性的痛处，清晰而精妙，简洁又高效。
下面我们把问题说回到敏捷吧，不然就跑题了 ：）
敏捷的最大的革命之处在于把承认了人的重要性，将人提到过程之上，可是毕竟人性的弱点和人性的优点是并存的，总会有各种各样的问题出现。敏捷既然承认 了人的重要性，就不会再像传统的软件工程一样，使用工程学方法去解决人的问题，敏捷引入了一些心理学和群体动力学的方法，这些方法简单而有效。下面举两个 例子：
第一个例子是关于日构建的。日构建在敏捷中的重要性大家都知道。我们这里谈的不是日构建的技术问题，而是组织问题，由谁来负责日构建。指定专门的人来 做？比如让项目经理，那这个人必然是整个团队中下班最晚的人，因为每个人出了问题都会影响日构建的结果。还有没有更好的办法？有。让最当天出问题最多的人 负责下一天的日构建，直至他抓到下一个倒霉鬼为止，这样就不会只累一个人了，并且有助于团队的每个成员在编程时都能时刻留心代码的质量。这个方法与我们前 面讲的故事有异曲同工之妙。
第二个例子是关于开会的。敏捷宣言的第一条就是“人和沟通重于过程和工具”。每天一个小组晨会是必须的，可是开会经常会出现一些问题，比如过多的争 吵，跑题等等。怎么平衡开会的质量呢？当然可以制定一个开会制度，由专人负责维持开会的秩序，但是这样的效果往往会打击团队成员的积极性，也过于繁琐。但 是有一个简单的办法：站立式晨会。开会的时候所有的人都站着，不许坐着。这样当有人说废话的时候，总会有人因站立的劳累而抱怨，这样每个人都会有意识的在 开会前想好问题，并在开会时尽量简明的说明问题，讨论的时候跑题或者固执己见的情况也会减少。如果你是会议的组织者，你需要注意一个细节，你需要经常对某 个人喊“嘿，不要坐在桌子上”“嘿，不要靠在墙上”，也就是说，不要让任何人有偷懒节省体力之行为。
极限编程的意思是：只要你认可这个实践，你就将它发挥到极致的地步。这个就是XP为什么叫极限编程的来由。简单理解一下，比如结对编程，结对编程的出现，目的有几个，主要的是解决codereview，既然认为在开发过程中，code review是一件很重要的事情，那么通过结对编程，就可以把code review做到了极致，这个就是“极限”的原因所在。
Powered by FireStats