这周的学习内容：这周学习是4个小时，除了上课以为，给自己多增加一个小时来学习，感觉很好，学习了很多，这周主要学习了团队形式1.窝蜂模式 (chaos team) 2.主治医师模式: (Chief-Programmer Team, surgical team) 3.明星模式 (Super-star model) 4. 社区模式 (Community Model) 5. 业余剧团模式 (Amateur Theater Team) 6. 秘密团队 (skunk work team)7.特工 (SWAT) 团队 8.交响乐团模式 (Orchestra) 9. 爵士乐模式 (Jazz Band) 10.功能团队模式 (feature team) 11.官僚模式 (bureaucratic model)。开发流程：我们在开发，运营, 维护软件的过程中有很多技 术, 做法, 习惯, 和思想。软件工程把这些相关的 技术和过程统一到一个体系中, 叫 “软件开发流程”，软件开发流程的目的是为了提高软件 开发,运营, 维护的效率；以及用户满意度, 可靠性，和软件的可维护性。
这周的阅读内容：
过度“敏捷”可能是危险的
这几条重要的价值观,你最好能够背下来。如果你打算学习Scrum和XP这些敏捷方法的话，先把他们多读几遍。
那么你知道敏捷宣言的作者都是谁吗？他们分别是 Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C.Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas。你可以在这里查看他们的资料。
当我们研究一个新的领域时，阅读相关的书籍往往是把握整体内容的最佳途径。因此，我在Amazon上搜索了和上面那些作者有关的书，得到的结果让我很吃惊。为了让你体会到我的感受，我把和那些作者所著的关于敏捷方法的书籍都列在下面，这些书主要是：
- 标题里包含“Agile”或者“Agility”的书
- 介绍了敏捷方法（Scrum，Extreme Programming,等等）的书
- 讲解了重构，测试，代码质量或者其他用来响应变化的技术手段的书
- 体现了实用主义思维并且不局限于某个特定语言(Java, Ruby等)的书
这些作者的书籍数量之庞大，让你感到吃惊吗？真的吗？为了能够广泛传播自己的观点，他们经常需要进行布道，而写书恰好是布道工作的一部分。还有一点让人很吃惊：这些书在Amazon上的评价都很高（至少是4星，5星满分）。这些书都是关于敏捷方法的很好的参考资料，并且这些家伙们在软件工程这个领域里做了大量的工作：我强烈建议每个开发者都去订阅他们的博客（他们大部分人都有写博客，你可以通过搜索引擎去查找）。
不过，看看相反的观点也是很有意思的。Steve Yegge(一个Google员工）在他的文章《Good Agile,bad agile》里这样批评方法论：
- 一般来说，任何自称为“方法论”的东西都是愚蠢的
- 任何东西，如果它需要布道者并且提供研讨班的话，那么它的存在只是为了赚钱
- 任何不提及竞争者和替代者的事物毫无疑问都是自私的
- 一般来说，任何没有重要细节的图表都是愚蠢的
我这里的“愚蠢”这个词语，是来形容用类似于杀鸡用牛刀的行为。
或许，这些观点并不是很客观，并且 Steve 文章的最主要观点是任何公司皆可复制 Google 的模型，但因不同的公司文化，使其观点一直不被认可。我也不同意他的这个观点，当你一味听从他人的意见时，你也是愚蠢的。不过我同意Steve的另一个观点，我们都注意到，当布道工作做的过火时，布道这事已被我们看到无可替代了。
敏捷方法并不适合于所有的项目
最近，我开始担心起“敏捷”这个词了，因为它似乎变成了一个流行词，并且我们大部分人都忘了其实有时候敏捷并不是最好的方法：
- 很难真正做到敏捷
- 敏捷并不一定是最合适的方式
当说到敏捷并非万能之时，我们通常会想到第一条，但也经常忘记第二条。Steve McConnell在畅销书《代码大全》里写道：
在软件行业，顾问经常让你只采取一种软件开发方法，而把其他的方法都排除在外。那样会让你的项目很不幸，因为如果你100%地只采用一种方法，那么你会用这种方法来看待所有的事物。在有些情况下，这会使得你错过一些更加适用于你当前项目的方案。
大部分（所有的？）敏捷宣言的作者都同意Steve关于软件方法的观点。所以，记住这一点就够了。
什么时候敏捷会比较合适呢？
Danc在他的文章《Managing game design risk: Part I》里给出了过程复杂度的分类：
- 简单过程：当需求和实施方案都比较清晰的时候，那么这个项目就可以通过比较简单的过程来控制。一般来说一个简单的checklist就能胜任。单独的一个工人在流水线上重复工作的过程就是简单过程的一个很好的例子。
- 复杂的：当需求和实施方案有时候会有变动的时候，你还是可以通过一个独特的checklist来完成项目。不过，为了完成项目，你需要添加很多规则和一些额外的步骤。桥梁建设是复杂任务的很好的例子。
- 更加复杂的：很多项目都处在一种需求和实施方案都大致确定，但是在很多程度上都存在着变动的危险境地。在这种情况下,敏捷方法能够帮助团队高效进行反馈，领导项目走向成功，并且避免高风险和不确定性。软件开发是更加复杂任务的一个最佳示例。
- 混乱的过程：当需求和实施方案的变数都非常高的时候，项目会陷入无法控制的混乱状态。从实际的过程来看，这种项目的成功与否取决于运气。
结论
首先，你自己不要成为一个布道者，多关注自己的项目，根据项目的实际情况决定哪个方法是最合适的。有时候，敏捷不一定是最好的方法，但是如果你发现项目的需求不是很稳定的时候，敏捷将会是一个很好的选择。
你是否会认为你自己有时候会成为一个布道者呢？