敏捷团队初探（一）

在这样一个阳光明媚的下午，能够坐下来写一篇BLOG，是多么开心快乐的意见事情啊，

这是给公司同学做敏捷分享的课件，整理出来放在blog上，以备查询。

作为一个比较散漫的程序员，我觉得敏捷可能比较适合我。强控制类型的团队不适合敏捷，敏捷适合松散的团队，大家可以随意的聊天，玩笑。

主要分为以下四个部分：

什么是敏捷？

1、价值观

说到敏捷，不得不提到敏捷的价值观，也有人称之为敏捷宣言，

个人与交互重于开发过程与工具

人，才是一个团队最重要的工件，才是一个项目成功的关键。其实项目说到底只是一群人为了同一个目标进行的一系列活动而已。人的交互，或者说社会学，这些都是一个团队最重要的部分。

开发过程与工具，更重要的是提供一种提高效率的途径和方法。敏捷精神以人为本的方向是很好的一个方面。

可用的软件重于复杂的文档

开发活动的最重要产出是可用的软件，曾听人说这个项目文档打出来有一吨重，但是我们还是失败了，下次我们要写两吨，这样我们就不会失败了。文档固然尤其价值，但是可用的软件是不是更加可贵呢？

寻求客户的合作重于对合同的谈判

谈判虽然带来了可靠的文书和合同，但是更多的还是在于双方达成谅解和合作的过程，寻求合作永远比注重谈判要好的多吧

对变化的响应重于遵循固定的计划

采用敏捷的开发方式，主要是为了响应不断变化的需求，不断变化的UI，不断变化的各种。常言道只有变化是不变的，响应变化对于一个互联网企业，应该是最重要的能力，ms的vista常被用来做遵循固定开发计划开发的反面教材，试想一下如果当时vista采用小步快跑的方式进行开发迭代，是不是能够更加成功呢。

具有敏捷精神的团队，认为敏捷宣言中的右项确实具有其价值，然左项更为重要和有意义。

2、敏捷开发和传统开发的不同

如上图所示，敏捷开发是一个慢慢修正直到导向目标的过程，在不断的细碎的迭代中，不对的修改需求，修改UI，修改代码，直到达到最终的目标，而传统的软件开发将直接指向原目标，然后向修正目标挺进，最后在修正为最终目标，在这一系列的超长时间的迭代中，将带来很多的资金，人力，时间的投入。

当然，你会说只有在需求不确定的情况下才会出现这样的问题。那么，又有多少项目在启动之前需求是完全确定的，完全确定的需求，看看vista吧。

接下来，我们看看传统开发迭代和敏捷迭代的不同

如上图所示，说白了，敏捷的迭代是一个小而美的传统迭代模式的综合，将一个迭代的各个步骤压缩到迭代中，确实是很不错的事情，通过不断的迭代和目标修正，来达成最后的目标。

这样，能够更大限度的避免目标偏离带来的项目风险。

ok，今天就写到这里，接下来我们介绍（二）敏捷框架

有兴趣的朋友也可以到我的小站坐坐：zak的小站