敏捷项目管理-Scrum

Scrum团队由一名产品负责人、开发团队、Scrum Master组成。Scrum团队是跨职能的自组织团队，团队成员本身选择如何以最好的方式完成工做，而不是由团队以外的人来指导。理论上来说，团队拥有完成工做所需的所有技能，不须要依赖团队以外的人。

Scrum团队迭代增量式交付产品，经过这种方式最大的得到反馈的机会，增量式交付”完成“产品保证一个能够工做产品的。

---

产品负责人PO：Product Owner角色定义，产品负责人的职责是将开发团队研发的产品价值最大化，为产品回报率负责，负责维护Product Backlog的人，表明利益相关者的利益。相似常常在电影中的一个场景：”连长，打吧“在一群义愤填膺的呼喊中，连长眉头紧锁，压住满腔怒火道：”同志们，敌人很可恨，咱们必定要抗争到底。可是，如今的形势不利于敌后运动，咱们择机再战“。产品负责人须要在复杂的工做环境中肯定产品的功能、产品里程碑及发布的日期和内容，为产品ROL负责；根据市场价值肯定功能优先级，在每一个冲刺中，根据须要调整功能和优先级；参与Scrum Planning Meetings、Sprint 评审会和回顾会。

---

Product Backlog是产品惟一的待办列表，一样产品负责人是pro backlog惟一的负责人，只有PO才有权利改动pro backlog；产品待办列表管理包含：清晰地表述产品待办列表事项；对产品待办列表项进行排序，使其更好的实现目标和产品利益最大化；优化研发团队所执行的工做价值；确保产品待办列表对全部人是可见、透明和清晰的，同时确保团队成员对probacklog深刻的理解和对当前工做事项清晰明白；

---

Scrum Master：敏捷教练，为团队和团队以外的人进行服务，联系团队和团队以外的，确保团队以外的人理解敏捷团队在作什么，其带来的优点是什么，经过改变团队成员和团队以外的人互动来确保最大化的发挥敏捷团队，把团队的价值发挥到极致。

工做职责:

1. 确保合理利用资源；
2. 保证各个角色及职责良好协做；
3. 结果团队在研发中所遇到的障碍；
4. 协调团队和外部人员，解决沟通中的问题；
5. 保证研发按计划正常进行，组织各项会议（sprint 计划会议、每日站会、评审会、回顾会）；
6. 服务于产品负责人和研发组员，确保团队成员对目标清晰、对产品及范围明了；
7. 指导研发团队理解并实践敏捷性；
8. .....

---

敏捷教练在团队中承担的几种角色：

1. 引导者：相似政委的工做；指引团队达到他们想要达到的目标，经过各类方式、激励措施、培训等；最重要一点，让外部人员了解敏捷团队，充当沟通的桥梁和防火墙，阻止外界越界指挥和干扰团队；

2. 教练：指导团队和PO遵循敏捷的价值观，经过每日站会、冲刺计划会议、评审会、回顾会来确保项目正常进行；开会不是目的，目的：1.团队成员清晰知道目前存在的问题和找出解决方法；2.按照敏捷的开发方式，遵守计划，自组织地向目标前进；
   　　*注意一点，会议虽好，但不要滥用，避免浮在表面，忽略实际问题；

3. 仆人：教会整个团队如何作，跟进天天进度、风险控制、按期总结、计划安排。记住一点，教练是服务型的，避免”干吼“，刚柔并济；

---

敏捷团队：

理想中的敏捷研发团队：执行冲刺、每日站会、随时检视和调整、梳理产品列表、更新Kanban等等。最重要一点：团队成员要明白，完成的定义。在研发中，会有组员认为，我编码完成了；是真的完成吗？答案：”不是“。不少研发人员对完成定义：”编码完成，有BUG是正常的“，必定要让团队人员清晰的知道”完成“的定义，“完成”：”一个可用并经过测试的功能，这才是完成。“

至于开发团队的自组织、T型人才、救火员状态、我为人人、人人为我，等等，在国内目前的环境，这是很理想的状态。一个企业，要达到敏捷团队所需的各项特征，很难。涉及到人员成本、人员水平、持续的组建团队。国内的IT团队最大的做用，在BOSS眼中，以最短的时间、最低的成本（最好是24*7天的工做状态，不要工资）作出最好的产品，而后市场人员卖出大的价格。否则阿米巴之类的毒鸡汤怎么会在国内横行呢。

总结：

企业推行敏捷团队，就像制造业推行ERP同样，先上MRP再来推ERP会好推一点。敏捷团队的组建，最好是从上到下，企业决策层要充分理解和认识到敏捷团队所带来的好处，给予坚决的支持，避免”伪敏捷“。

其次，团队成员要有意愿，自我改变的意愿，清晰的知道本身的职业规划，有自驱力。承担的责任越大，其得到经验就越多，运用的方式越多，其视野就越开阔。工做是给老板作的，但经验和眼界是本身积累和拓宽的，有了主观意识，加上敏捷教练所传授的经验和方法，何愁实现不了理想？