透析SCRUM的自我管理

SCRUM的方法并没有特定的工程实践惯例，但是定义了几个角色例如“团队、Scrum Master， Product Owner”以及角色相应的职责。并且在团队这个角色上注入了“团队自我管理”的使命。团队成员会主动朝着产品研发的进展方向规划自己的迭代计划、日计划，并主动完成其工作。产品围绕着叫做Backlog的列表展开，这个列表最开始作为一个容器容纳所有待完成和已完成的工作项，而每个工作项都可以继续拆分和重新排列优先级，当团队开始了SCRUM的开发时， 团队将从中选择重要且能够完成的Backlog，在2到4周完成这些Backlog的发布，而产品就是通过每每迭代，这里叫做SPRINT，来增量构建这些Backlog而组成的。

 

SCRUM同其他例如XP、Crystal方法一样均属于敏捷Agile 方法范畴，我们回忆一下敏捷宣言，宣言中强调了在项目实施过程中，左边项目要素优于右边优先被考虑。

 

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

 

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

 

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

 

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

 

 

•  拥抱变化（Embrace the change）

 

无论是多么明智，多么正确的决定，也有可能在日后发生改变。因此，团队要能够充分理解我们的STAKEHOLDER和客户代表为什么经常提出新的需求和设计要求，一句话，就是心中有数“唯一不变的是变化”。团队更要信任STAKEHOLDER做出的每次决定和需求的调整都是将产品开发推向更正确的发展方向，新变化将进一步降低风险，实现团队最大化利益，理解这是适应市场变化的必然行为。

 

而在接受变化的同时，我们应该积极的向STAKEHOLDER和客户代表反映实现活动中暴露出来的可能的设计缺陷和错误。在实际工作中，团队成员应该用优先级制度来划分事情和目标先后顺序，在迭代周期内对于还没有最终决定的设计方案可以予以后来实现、测试，不用急于投入资源展开全面的开发、测试活动。这样一来，开发测试团队也会人员也将更加适应，真正拥抱变化。

 

• 客户的参与（With customer representative on site）

 

首先谁是Customer，Customer Representative呢？STAKEHOLDER，或者我们可以理解为我们的客户（Customer），产品的最终使用者（Enduser）， 内部使用者（Insider），商业伙伴（Business Partner）。STAKEHOLDER 作为团队中最了解BUSINESS的人物将帮助开发团队的快速达到目标和做出适时决策。开发团队拥有很好的技术但在BUSINESS方面他们需要STAKEHOLDER的帮助。而通常在敏捷的开发项目中，团队中的任何一个人若需要帮助时，只要简单的邀请大家参加一个15分钟会议，或一封邮件、一个电话便可以解决。

 

但是，如果STAKEHOLDERS各执一词怎么办呢？为解决这个问题，将Product Owner引入到讨论中来， 作为Product Owner他可以作为是STAKEHOLDERS的代表，能够在分歧中做最后抉择。因此，通过这样的客户代表的参与，团队更好的了解了所做事情的价值和意义，其工作效率也因而得到很大提高。

 

STAKEHOLDERS能够帮助团队中的每一个人更好，更快的完成了工作，他们的直接参与成为了敏捷开发、敏捷测试的重要前提。

 

•  较少的文档（With less documents）

 

敏捷开发更重视生产出可用的产品而不是详细文档。而时常有发觉文档又是无论敏捷还是传统开发、测试不可或缺的一部分。笔者认为，传统开发的文档在敏捷开发里仍有大用，只是原来十来页的内容精炼到现在的一页半页。

 

敏捷主义者相信文档不是最佳的沟通方式，他们鼓励通畅的交流和沟通，要求避免和减少陈词滥调和空头支票。尤其是复杂的文档说明只是增加了沟通成本，因而敏捷开发、测试的文档不需要长篇累读，需要的是简洁，清晰。任何一段清楚的文字，甚至一张图片，照片，一封记录着会议记录的邮件都是我们认可的敏捷文档。因为是无论是通过文字板书的文件还是其他的沟通方式和载体都是为了帮助团队进行更高效的交流和沟通。只有团队保持着沟通上、理解上的一致后才能够充分发挥出团队最佳战斗力。但凡这是帮助团队有效沟通的方式，何种开发都不会舍弃的。

 

• 最大化的生产力(Maximize Productivity）

 

敏捷开发模式要最大化的提高团队的工作效率。无论是依靠剪除冗余的文档工作，还是提供民主的、通畅的沟通平台都是为了帮助团队能够集中有限的精力处理有意义的问题。据调查，通常人会在两个、多个任务并行的情况下产生出出最高工作效率。而敏捷也恰恰使用了各种方法得到团队的最大生产力。

 

敏捷开发的Scrum模式，要求在计划阶段，团队成员主动定制迭代周期的所有工作任务，因此，本身从团队开始迭代活动的那时起，已经在在多重工作的压力下紧张工作了。而在日常的迭代生产活动里，各个成员需要当众简单汇报当天的工作进度和承诺下一个24小时的工作计划。因此，通过增加敏捷人员的工作的透明度，无形之中，团队成员的生产力进一步得到提高。

•   自动化冗余工作(Automate the redundant work）

 

将团队成员从冗余的劳动中解放出来，无论是自动化的测试还是自动化工具的开发只要能够节约成本都是敏捷开发、敏捷测试的目标。

 

• 民主的团队(Democracy in team）

 

敏捷团队是一支民主的团队，团队关系是平行的，每个团队成员能够平等的参与讨论，决策。传统开发的垂直的官僚机构在敏捷开发中已是过时的。

 

• l 尊重团队(Respect to team）

 

敏捷团队的决定权交有团队自己，决定是团队统一制定。无论是产品设计方案还是产品的功能实现都是的最佳结果。团队脱离了任何一个成员的工作都是不完整的，所以我们应当足够尊重其他成员的劳动果实和表达对其他成员的充分信任。尊重团队，尊重团队中的每一个成员都是敏捷开发的原则之一。