敏捷开发实践（3） — 培养敏捷开发团队

敏捷开发实践（3） — 培养敏捷开发团队

Agile = 适应性 + 持续可能性

敏捷开发的真谛是适应变化的情况，让开发持续，并改善其过程。它并不是单纯的用来缩短发布时间，提高工作效率，增强产品品质的手段，而是强调一种随机应变，持续改善的理念，一种过程思想。学习敏捷开发，首先考虑的是人。

软件开发以人为本

软件是由人开发出来的，这是软件开发的大前提，不管你是用敏捷还是不用敏捷。

如果回到上世纪8、90年代，软件开发往往让人联想到个人英雄主义；那个时候，新兴的IT行业涌现出了类似求伯君，王江民，梁肇新等为大众所熟悉的高手。在他们身上凝聚了浓厚个人英雄色彩，并被许多那个时候成长起来的程序员所崇拜。但是，日趋庞大的软件项目和复杂需求需要更多人以标准化的软件工程方法去实现。这个过程科学而严谨，软件开发的每个步骤开始细分，程序员的工作定位开始清晰，随之而来，程序员的个人英雄色彩开始逐渐淡化，消失。

现在的一个大型软件项目已不再是依赖几个软件开发高手就能奏效的了。一个团队，一个协调一致的组织架构往往成了项目成功与否的关键因素。

敏捷开发正是一种注重“改造人”的开发手法，培养团队成员，构造成熟团队是敏捷的终极目标。而要培养优秀的敏捷团队， 组织过程架构是其重中之重。

怎样培养敏捷团队

每个敏捷团队都是不一样的，他们事前并没有统一的 组织过程架构。相反作为敏捷团队需要自己去发掘，整理，完善，最终建立适合自己的敏捷开发过程架构。这里从心态和实践两个方面来讨论。

心态1：最初的目标 ≠ 最终目标

敏捷开发过程就是一个持续和反复的过程，其中有一个出现频度很高的词 — 改善；这就是说敏捷过程就是一个逐渐变大，逐渐成长的过程。通过不停的反复，实践，改善，最终完善产品自身和团队本体。

所以说项目开始时并不需要考虑所有的状况，指定终极的目标，以及理想的架构，Just Do it！仅此而已。

过程中发生问题怎么办？没关系，在迭代结束，回顾改善中发现问题，并在下个迭代中改善它既可。也即是说，「问题发生」本身不是问题，只要有应对问题的过程环节就OK。

心态2：组织的过程架构是可以改变的

正如前面讲到的，敏捷开发是一种思想，他并没有给你划定条条框框，一切随实际情况而改变。

但是，我们往往不由自主的陷入体质和过程的怪圈 — 既然作为一个体系，一个过程管理架构，那么我们就要尽量维系它，遵循其起初制定，或其他地方吸收来的规则。而不管该架构形式是否适合自身的团队，一律照搬照抄。一旦出了问题，往往有「敏捷过程就是这样」，「架构没有问题」，「我们哪里用的不对而已」等等想法。不从组织过程架构中找问题是危险的。

组织过程架构是需要敏捷团队去建立和完善的，不管是从其他地方得到的经验，还是自己制定的规则，该体系都有可能在过程中出现不符合实际情况的问题。在迭代改善中发现它，在计划中完善它，在过程中改善它，是我们需要做的；而不要认为它是架构本身的问题而搁置它，不闻不问只会错上加错。

实践1：从小开始

万事开头难，怎样才能减小开端的难度。从小的阶段目标做起，一边确认一边递进式的扩大作业范围。先是在小的规模下（个人或者是pair开发）体验敏捷开发的思想，然后逐渐扩大规模（团队或者组织内部）。随着规模的扩大，关系者的增加，影响范围也随之变大，需要考虑的事情变多，敏捷的难度也会伴随增加。这时，也是验证敏捷开发者应对变化能力的时候。

实践2：持续集成

持续集成是指用自动化的工具验证成果物，并且每天至少一次。持续集成的目的是为了早起发现系统（除过软件成果物本身，整个敏捷架构过程也是该系统一部分）的问题，从而频繁的整合，检查。

每日站立会议

站会顾名思义就是站立着开会，一般会议持续10~15分钟，站久了累了就没有意义了。开站会的目的就是确认工作的进度状况，需要周知的事项，问题点等。基本上每天早晨实施的实例比较多。

站会是一种高效的沟通方式，作为工作开始的合意，问题点的共享等方面往往有意想不到的效果。

如果想更加紧密，频繁地整合敏捷系统，和早会对应，在下班前用5到10分开一下站立的“晚会”往往有更好的效果。这里，我们回顾每日工作的情况，检验本日的工作成果。通过“晚会”，我们可以：

• 强制在约定时间内停止自己的工作
• 作为一天的回顾，营造「团队工作结束」的氛围

如果有加班的情况，在“晚会”上周知团队的其他成员。如果有早退的情况，可以在早会的时候给大家通知，有必要的情况下，可以调整“晚会”的开始时间点。