硝烟中敏捷的我们

记得公司大张旗鼓轰轰烈烈的开展敏捷是在前年的十二月份。当时公司刚来了一个项目经理A君，处于各种需求敏捷就在那时开展了起来。当时公司买了一本关于敏捷的书《用户故事与敏捷方法》。但是感觉当时搞的太形式化了，就像解放伊始的大生产运动。对头一年过去了基本上现在项目又恢复了一片混战的状态。现在回忆起来简直就像一场闹剧，堪比喜剧。归结一句话不敏捷的人你用什么方法都没办法是整个团队敏捷起来。

一个技术团队中头儿决定了这个团队的方向，成员决定了这个团队的战斗力。其实每个程序员都应该是全栈工程师，尤其是对于创业公司来说。主动进入并且能够进入创业公司的开发者都有这些潜质，而且创业公司正好提供了培养全栈工程师的沃土。上到需求下到运维，然后开发用到的各种技术，数据库，编程语言样样精通。我崇尚两种文化，一种是狼文化，一种是海盗文化。前者是我个人对这种神圣的动物比较热衷；后者深受《Steve Jobs》这本书中的感触。每种团队都有自己的文化和观念，但是重要的是坚持贯彻下去。

《硝烟中的Scrum和Xp》这本书很早就从InfoQ下载下来了。这本精简版书本身非常的薄就一百多页，一天时间就可以看完了。下边是一些笔录。

团队和项目负责人如何左右一个Sprint中要完成哪些故事：

    1. 假如项目负责人感觉某个故事是需要加入进来的，那么它可以这样：调整估时的优先级；或者缩小现有估时的范围。

    2. 团队成员可以凭借经验直觉来左右一个故事是否加入这个Sprint；借鉴以往的生产率。

生产率的计算公式：

生产效率估算方式：直觉反应、基于昨日天气的生产率计算、基于可用人-天和估算投入程度的生产率计算

对每个故事的估时：可以每个人经过完整的思考，然后输出自己心中的数字，如果差距不大则没问题，但是如果两个人的误差非常大的话则要重新讨论了。这个也可以综合考虑技术的实现方案，难易程度，多由程序员完成较好。

确保每个成员对故事是有一定的理解的，也就理解的需求是对的，否则会造成估时的误差，如果Sprint已经开始也会造成一些不必要的工作。如何解决这个问题：可以通过丰富每个估时，比如如何demo。

技术故事：技术故事是开发人员提出的一些需求，比如重构，部署服务器。这些估时产品负责人是不会关系这些东西的，因为这些东西不能带来直接的利益。但是一个技术性的项目这些东西是基础，所以也要摆在一个重要的位置，说服产品负责人。   

测试驱动开发：测试驱动开发意味着你要先写一个自动测试，然后编写恰好够用的代码，让它通过这个测试，接着对代码进行重构，主要是提高它的可读性和消除重复。整理一下，然后继续。

整本书读下来没什么特别东西：就是一个公司试试敏捷今年后的一些经验教训总结。其中的一些章节我没有看“多个团队的敏捷管理”、“跨地域团队的敏捷管理”这些章节也不是我想看的。不过是敏捷也好还是团队内部总结出来的一套管理方案也好，都需要不断地调整调试总结提高。和技术一样这方面也没有银弹，适合自己的才是最好的。

在这个浮躁的社会如何让团队内部的人踏实下来才是最重要的，对于一个创业公司从上到下更是要踏踏实实的才是。这是一个创业者的年代，但是没有几个成功的，一百个都没有一个。任何管理方式最终都落实到执行力上，团队管理制度要有绝对的执行力，团队成员要有执行力。我们团队的一个例子：基本每次晨会中总会有几个人汇报着干了几天的工作。这是团队管理者最好能够了解一下他们的工作，如果任务安排合理，恐怕这些人是出现了什么问题。如果这些人拒绝把自己的工作交代清楚，或者支支吾吾，就得采取一些措施了。这些人继续在团队都会影响整个团队的纪律。

对了上边还提到了多总结，这个恐怕是团队最不想做的事情了。至少我们团队是这样的，第一个Sprint试试的最好，各项工作安排进行的都比较正常。然后慢慢慢的就没有然后了。到中途晨会A君都不想再去组织。如果没有对每个Sprint的总结的话就会造成我们这样的后果，至少我们要计算一下每一个迭代的生产率，完成程度，观察燃尽图等等，以便于下个迭代能够更高效。虎头蛇尾绝对不是好事。

还有一个就是对于Bug的管理，这个东西一会是让我比较头疼的东西。永远不要纵容一个Bug，因为这个东西会产生雪球效应，越攒越多，到最后不想有人碰。每个迭代做好能够抽出一天来衡量一下这个迭代的bug，尽量斩尽杀绝。再者说如果bug增长正向的话，该看看代码质量了。哎，说多了都是泪水。