Scrum敏捷项目管理

scrumcn1335926917

如果30天内无法将Idea转换成具备商业模式及可操作性的项目,
如果2个月内无法找到团队核心并组成初创团队,
如果3个月内你的Idea还没被团队充分理解并预期付诸实践,
如果6个月内你还在筹划半年前的那个Idea,
这个Idea已经过时勒,请下一个,这里是互联网!

更迅捷的项目管理,
更快速的项目决断,
更舒适的用户体验,
更早地实现Idea,
好与不好交由公众来评断,
不要闭门造车以为一切尽在掌握。

— Reinhardt

项目的开始至完成绝不可能是一帆风顺的过程,即使完美主义者也会不可避免地遭遇挑战,”自上而下”或”自下而上”的过程都有其无可掩盖的缺点,只有不断在实践中迭代前进,才能一步步接近真相。

— Reinhardt

项目自始至终周期过长,会造成心理放松,对于项目危机感缺失,以至于造成前期浪费时间,后期加班赶时间的窘相。所以我们需要通过不断地迭代,在一次次循环中完成可交付的增量,基于事实的决策远比前端预测型决策更为有效。

— Reinhardt

scrumcn1335927181

Scrum有3种职能者:ScrumMaster,Product Manager,Team,相互之间不渗透,各司其职。ScurmMaster负责Scrum流程顺利完成,即迭代地不断进行,Product Manager根据产品需求及市场预期制定产品Backlog,Team在自发性驱使下完成Sprint。通常过程中,30天为一个迭代周期,称之为Sprint,流程如下:

Scrum Start -> Sprint 计划会议(第一部分分析Product Backlog,第二部分解答产品Backlog,并制定Sprint Backlog) –> Sprint 迭代开始 –> Daily Scrum(Sprint 迭代)–> Sprint 评审会议(展示,提问,调整)–> Sprint 评审会议(团队总结,调整)–> Sprint 迭代结束 –> Scrum End
scrumcn1335927246

图:Product Backlog
scrumcn1335927313

图:Task Board

Product Backlog: 是否代表所有利益相关者的最近需求,提醒大家关注最近的将来(利益相关者:投资方,团队,目标用户)

Sprint Backlog: Sprint迭代周期内,团队需要完成的项目细则,并确保Sprint周期结束后,项目的潜在可交付性

Scrum计划过程涉及3个问题的解答:

1. 项目投资人希望项目结束时能取得哪些成果?
2. 每个Sprint应作出哪些进展?
3. 如何使项目投资人相信该项目是有价值的投资,以及项目申报者有能力交付预期收益?
4. 计划的目的之一是说服投资者为项目注资

Daily Scrum(全天工作的第一件事):

1. 自上次的Daily Scrum后我做了什么?
2. 现在到下次Daily Scrum我准备做什么?
3. 在工作中遇到了什么困难?

Scrum基本原理:

1. Scrum是经验型方法,是”可能性的艺术“
2. Scrum使得所有事项充分可见,使“秘密交易”最小化
3. Scrum的运作基础是个人和团队的承诺,而非严密的规划及控制。相对于强行控制计划,其忠诚度、自组织和员工责任感是更为有效的机制
4. 团队成员只有事先集体负责,承诺在固定时间内交付实际产品后,才算真正掌握Scrum

ScrumMaster

ScrumManager主要职责:

1. ScrumMaster与传统项目经理区别:从传统的控制者到引导者的转变
2. ScrumMaster需要对团队作出承诺,让团队感受到有人全心全意关注其工作,在任何情况下提供保护和援助。
3. ScrumMaster使团队在Sprint过程中免受干预
4. 产品负责人谈论业务需求和目标,团队则讲技术。由于产品负责人很难掌握技术,ScrumMaster的主要职责之一就是教会团队谈论商业需求和目标。团队与产品负责人之间的公分母是产品Backlog

ScrumMaster职责:

1. 排除产品开发和负责人之间的障碍,确保产品负责人直接推动开发工作
2. 教授产品负责人如何实现投资回报最大化,以及如何利用Scrum达成目标
3. 激发创造力和放权,从而改善开发团队的环境
4. 千方百计提高开发团队的生产力
5. 改善工程实践和工具,确保每个功能增量都具备潜在可交付性
6. 向各方确保团队工作进展实时更新并高度可视

Scrum高效率探究

限期30天Sprint的固有压力,团队成员表示“需有所付出”的相互承诺,自组织原则及跨职能责任,有助于团队成功履行职责承诺机制条理化,增加相互责任心,团队凝聚效应

“限定时间”可向团队灌输“可能”的艺术,避免过分追求完美
“增量交货”的举措改进工程实践
“放权”和“自组织”能够激发创造力,提升员工满意度

(*****) 当人们不能聚在一起面对面交流时,往往会将自己的问题抛给他人
(****) 预估的目的是为了解每个需求自身及相对于其他需求的规模。该信息有助于划分产品Backlog的优先等级,并将之分入各个Sprint

Scrum运行无需过于宽泛的计划,但需足以引导Scrum的经验性过程的检查与适应循环,若成本/收益及假设性数据引导适应环境更有意义地展开,项目必可收益

团队

团队从被管理到自我管理的转变十分困难,但在生产力和工作愉悦度方面的回报显著

在我们的生活和工作经历中,受他人管理的习惯根深蒂固。

Scrum真理:成功的开发需要不断检查和调整

本质:内心深处,认为自己应在一开始便完美安排各事项,确保计划得以严格实施。需要适应调整时,责备自己为实现妥善安排全部事项。从开始就预知结果的人不会存在。

(**) 总体度量,即在最合适的日期交付最佳、最优质的系统。实施其余度量法时应保持谨慎,确保其支持总量度量,避免削弱其效果。我们在设计度量系统时应考虑人类固有的、为取悦他人不计后果的欲望。(e.g. 代码量不应作为绩效考核标准)
(***) 团队通常难以用产品负责人能理解的语言与之交流,若产品负责人只谈商业,团队只谈技术,双方无法交流,也就没有协作

Scrum报告

每个Sprint结束时还需产生正式报告

Scrum报告:

1. 第一份列出上一次Sprint开始时的产品Backlog
2. 第二份为新Sprint开始时的产品Backlog
3. 第三份是“变更报告”,详细列出前两份报告的差别
4. 第四份为产品Backlog的“剩余时间报告”(Burndown Report)

变更报告总结以下内容:

1. Sprint中发生及Sprint审核的情况
2. 项目针对Sprint审核结果所做的适应调整
3. 未来Sprint重构的原因
4. 发布日期或内容重新制定的原因
5. 为何团队在Sprint中完成的需求量比预期少
6. 在产品Backlog中,未完成工作的优先等级重排情况如何
7. 团队为何比预期生产率高(低)

不使用术语,却教会管理层使用Scrum,属于只是一种表现形式。(e.g. Ajax = 无页面刷新)

Scrum扩展项目

Scrum of Scrums

Scrum实践扩展成功的关键:

1. 在扩展前构建必须的基础设施(构建扩展基础设施的非功能性需求必须在扩展开始前完成)
2. 建构基础设施的同时确保交付商业价值
3. 优化原始团队的能力,向其余团队分派至少一名初始团队成员

项目扩展为多个团队的产品Backlog中应加入以下非功能性需求:

1. 分解业务结构以支持整洁界面的多团队开发
2. 分解系统结构以支持整洁界面的多团队开发
3. 必要时,定义并实施特定开发环境,支持多团队并置或分布的环境

e.g. 曳光弹:射击者摸黑开冲锋枪时难以瞄准,若每50发子弹中有一颗曳光弹,便可看清方向,调整瞄准。(指明团队方向,冲破迷雾)
e.g. 马克吐温曾说:“没有东西比绞索更易让人集中精神。”(增加紧迫感,提高效率)
e.g. “癫狂愚顽”:反复做同样的事情,却期待不同的结果。在预定义方法在项目管理中失败时,人们通常将原因归结于未能严格执行预定义方法。断定项目成功的关键在于加强控制和项目定义。(不断重复地用失败的方法华丽地完成另一次更大的失败)