玩敏捷要避免盲人摸象

敏捷的盲人摸象

     一些团队原本就可以交付很不错的产品，引入敏捷够就对敏捷寄予厚望，但是最终总是产生一些“聊胜于无”的结果，这是因为他们遇到了视角割裂。开发人员考虑的是开发人员的问题，仅会关注测试驱动开发的方法。项目经理考虑的是项目经理的问题，喜欢任务板、项目速度跟踪和燃尽图。团队主管又想通过每日站立会议和回顾会议管理和改进团队。大家都想从项目中得到不同的东西，每个人都只在意对自己有帮助的敏捷实践。大家各自采用这些敏捷实践肯定能对现状有所帮助和改善，但是开发、项目经理、团队主管各自的视角又不尽相同，所以都想让大家都围着自己转，反而会得到相反的效果。

 

敏捷超越了实践本身

    敏捷方法是一组实践的集合，这里还包含了相关的思想及建议，以及大量来自敏捷实践者的知识和经验，敏捷方法的作用就是帮助团队采取敏捷并改变自己的项目。它可以帮团队在具体情境中了解敏捷实践。

    scrum

    scrum是最流行的敏捷方法，可以概括为几点内容：

• 团队将所有要完成的工作制作一个表，这个表叫产品积压工作表（product backlog），既可以是任务列表，也可以是特性列表。
• 每个月从列表最上方取出一部分，此为预估的一个月工作量，并承诺可以月底交付或演示，称为冲刺积压工作表（sprint backlog）。
• 每天花5-10分钟同步进度，交流阻碍，这项活动称为每日站立会议。
• 指派一个scrum主管，负责解决或指派人解决每日站立会议上提出的问题。

    但是每日站立会议往往会称为推卸责任、讨价还价的会议，这样就偏离了scrum的实践方法。

 

    着手采用一整套的方法

    scrum只是敏捷方法中的一种，比较流行的还有极限编程、精益和看板方法，他们都有着一些共同点，就是他们都重点在于是一种思维方式，目的是改变价值观。所有的方法都基于共同的原则，都依赖于团队中的每一位成员齐心协力完成项目中的每一个部分。

    正因为敏捷方法涵盖了实践、思想、建议和团队，所以使用敏捷的团队要使用一整套的敏捷方法，仅使用单个实践的团队看不到加强沟通和响应变化的大目标，从而很难利用实践来提高团队的生产力。

 

    通过敏捷改变自己

    团队使用敏捷后，可以放弃过去的那种项目开始前必须编写的详尽文档。因为敏捷方法着重的是可工作的软件高于详尽文档，那么文档就可以转化为其他的形式，比如写成注释放到代码里，写成用例，写成用户故事等。

    并且做一些人人都会参与的计划，敏捷团队会用一天的时间来制定后面30天的计划，并且每天用10-15分钟对计划进行审阅、探讨，虽然看起来比传统的模式更耗费时间，但是并不会让团队成员感到无聊，因为每个人都参与进去了。

    敏捷又适合各种技能水平的人，由于要制定计划，则要由良好制定计划的能力，而提升这种能力的方式就只能是实践，从而渐渐地初级人员很快就不是初级水平了。

    敏捷要求团队每个人都参与，所以当有人感觉有些实践聊胜于无的时候就会提出，而大家就会积极去想一些事半功倍的实践，一起去讨论敏捷的一些原则。