硝烟中敏捷的咱们

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

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

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

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

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

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

生产率的计算公式：

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

对每一个故事的估时：能够每一个人通过完整的思考，而后输出本身心中的数字，若是差距不大则没问题，可是若是两我的的偏差很是大的话则要从新讨论了。这个也能够综合考虑技术的实现方案，难易程度，多由程序员完成较好。

确保每一个成员对故事是有必定的理解的，也就理解的需求是对的，不然会形成估时的偏差，若是Sprint已经开始也会形成一些没必要要的工做。如何解决这个问题：能够经过丰富每一个估时，好比如何demo。

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

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

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

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

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

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