《scrum敏捷项目管理》读书笔记

今年开始尝试做PM, 在我看来PM貌似就是个打杂的角色, 不管了, 先尝试一下, 因此找了一些书来看看, scrum也是我今年规划中需要了解的一个东东, 因此就选了这本书.

这本书据说是scrum的入门书, 也是scrum的鼻祖ken schwaber的大作. 以前也在网上对scrum有过只言片语的了解, 从这本书, 可以了解scrum个大概,  里面基本上是通过一个个案例来讲解在scrum中的角色(scrummaster, 产品负责人, 团队), 非常通俗易懂.

看完之后发现scrum还算简单, 而且我们目前的日常开发管理, 与scrum非常类似, 计划安排也算是仅仅有条. 不过scrum中有一些东西规定的非常死, 还不是很理解, 比如说一个sprint是30个日历日(为什么不是60, 不是15? 实际上我们是两周), 每天必须开晨会(我们团队内部从开始每天早上一次, 到每隔一天一次, 到现在干脆不开了, 貌似也没什么问题, 关键是我们team人少, 感觉没有开的必要), 还有燃尽图, 这本书中我没有看到详细的介绍, 主要是任务时间估算方面的,

对了, 我们是采用JIRA来做项目管理, 每两周发一个版本, 一个版本中的任务列表类似sprint backlog. 我们基本没有产品backlog, 当然我们的需求会源源不断的进来, 算是产品驱动, 如果技术无法支撑现有的需求, 我们会起一个项目来对系统做一次变革升级, 也可以说是技术驱动. 从需求, 技术方案, 代码编写基本上开发都全程参与, 自我管理算是不错了, 不过sprint结束时的验证主要通过测试人员(单元测试, 功能测试, 回归测试)来完成. 每一个sprint的开发进度跟踪由开发人员轮流担任.


====================以下是读书笔记的分割线===================
处理复杂问题时, scrum强调将控制权下放到独立个体

项目复杂度越高, 便越需要将决策权委派到工作前线的独立个体.

团队规定30天的工作内容, 以交付最优先的商业价值

scrum的科学原理
产品负责人代表项目中每位利益相关者的权益, 并为项目产出的软件系统负责

产品负责人的职责就是利用产品backlog, 督促团队优先开发最具有价值的功能, 并在其基础上继续开发.

产品负责人必须频繁检视产品待开发需求的优先次序, 将最具有价值的开发需求安排在下一次迭代中完成.

团队的任务是开发软件功能, 他们是自我管理, 自我组织和跨职能的, 他们负责找出实现待开发需求的实现方法, 并管理自身的工作, 以达到这一目标.

scrummaster对scrum过程负责, 向所有成员讲授scrum方法, 负责实施scrum, 确保它符合企业文化, 又能交付预期利益, 还需督促全体成员遵从scrum规则和实践.

scrum区分两类人("猪"和"鸡"):
对承担项目责任的人赋予权力, 使其完成必要的工作. 确保项目成功
无责任人员则无权对项目施加不必要的干涉.

必须时刻区分责任人和出主意的.

哪些人对投资回报负责,哪些在投资回报中分成, 但不承担责任.

scrum规则区分鸡和猪, 提高生产力, 创造势头, 防止混乱局面.

产品backlog排列出不同优先级, 最易产出价值的事项享有最高优先级.

分出优先级的产品backlog是项目的起点, 中途内容和优先级也会发生变化.

产品负责人从最优先级的待开发事项列表中进行筛选, 告知团队其预期目标, 团队在接下来的sprint中

sprint计划会议包括两部分, 第一部分4小时, 产品负责人向团队提供最高优先等级的产品backlog, 后4小时团队计划本sprint的安排

晨会内容:
昨天做了什么, 今天准备做什么, 在实现目标中遇到了哪些困难

sprint结束后的评审会议, 限定为4小时

产品backlog是初始设计, 会随着产品和环境的变化而变化.

scrum中心原则之一是团队管理自身事务, 企业中的其他管理者均扮演"鸡"类角色.

scrummaster类似传统管理中的项目经理一职, 但又有区别, 项目经理负责界定工作范围和管理工作, 而scrummaster负责管理scrum流程, 即确保scrum正常运转.

项目中的个人类似空旷草场上的羊, scrummaster类似牧羊犬, 将羊团结在一起, 防止饿狼靠近.

产品负责人利用产品backlog将具有最高商业价值的需求界定为最高优先等级事项.

产品负责人的职责是提升项目的投资回报.

在scrum中由团队决定每个sprint的工作内容.

一般理想团队是7个人

scrummaster负责使项目成功, 帮助产品负责人挑选最具有价值的产品backlog

scrummaster只是项目的推动者.

学习scrum类似学自行车, 开始需要一点时间, 然后自然而然地掌握骑车方法之后, 一切都会轻而易举.

没有完全理解scrum的scrummaster就像在主干道上行驶的自行车新手.

scrummaster的角色转换: 从控制者转变为建导者, 从上司转变为教练.

牧羊犬绝不会擅自离开羊群, scrummaster也一样.

团队必须感受到有人全心全意关注其工作, 并在任何情况下, 都能提供保护和帮助, scrummaster的态度将反映项目的重要性

scrummaster是领路人, 不是管理者.

当改变不符合企业文化时, scrummaster必须做出让步.

在sprint过程中, 不受外界干扰.

如果出现一个比当前sprint工作更有价值的机会, 管理者可以采取非常手段, 终止当前sprint, 团队, 产品负责人和管理层重新召开sprint计划会议, 若新机会确实具有最高优先级, 可以加入产品backlog

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

scrummaster应该关注能做之事, 不要为不可能之事耿耿于怀.

如果开发工程师像流水线的装配工人各自完成属于自己的任务, 这样会扼杀合作机会, 工作的顺序也会导致工作开开停停 // 不敢苟同

先开发系统中的曳光弹功能, 为其他功能指明方向

scrum向团队放权, 让他们自己找到解决复杂问题的方法.

一个完成的产品所需的工作: 需求收集, 分析, 编码, 测试以及文档编制都应在一个sprint内完成, 并通过sprint功能增量展示, sprint限期不宜过长, 应确保利益相关者在各个sprint结束之前对项目保持兴趣.

规划scrum项目
scrum计划过程涉及回答3个问题:
项目投资人希望项目结束时获得哪些成果?
每个sprint应该有哪些进展?
如何使项目投资人相信该项目是有价值的投资, 以及项目申报者有能力交付预期收益?

在每个sprint结束时汇报进展, 以保持项目可视性.

启动scrum项目最简计划: 一份愿景及产品backlog
愿景描述产品的背景和预期目标, 产品backlog是产品交付时完成的功能和非功能性需求,它要事先划分优先级并经过评估.

产品backlog:
本期sprint:已精确定义且在30天内可完成并产出可执行程序的工作
下一个sprint:次优先级的backlog, 取决于前一个sprint的成果
一个sprint内的sprint backlog是固定的, 仅随当前sprint工作改变, 当前sprint之外的backlog保持变化, 发展并重新划分优先级.

计划的目的之一是说服投资者为项目注资, 计划向投资者提供详细的信息, 证明项目具有价值, 能在规定的时间完成.其收益超出成本及风险, 且项目开发人员有足够的能力执行计划.

预估的目的是了解需求本身, 以及相对其他需求的规模, 该信息有助于划分产品backlog的优先等级, 并将之分到各个sprint

生鱼片法则: sprint审核时演示的潜在可交付产品功能的每一个增量都必须是完整的, 包括分析, 设计, 编程, 文档以及作为完整产品一部分要求的使用步骤.

如果成员不能明确指出其工作内容, 其晨会是无意义的

晨会可以使各个成员工作同步, 否则便没有价值

scrummaster须保持所有事项信息足够详尽可视.

scrum的生产力源于:首先选择正确的事项, 然后高效完成选定事项.

一个团队做出承诺, 时钟便开始倒计时.

晨会是为团队而开的, 各成员不能只看scrummaster, 团队成员在汇报时, 互相之间应该有眼神交流.

scrummaster仅扮演顾问角色或促进对话进展

由于团队负责管理自身开发行为, 他们可以在sprint内只有调整.

scrummaster的职责不是管理团队, 他们应该学会自我管理, 不断调整方法, 提高成功机会.

sprint评审会议也有时限, 防止团队花大量时间追求完美.

scrummaster负责流程和消除障碍, 但不管理功能开发.

scrum有难度, 它需要经常检查和调整, 这是已知的解决复杂问题的唯一控制机制.

经历scrum之后, 培养出来的应该是团队英雄主义, 而不是个人英雄主义.

晨会

每日晨会限时15分钟, 他是全天工作中的第一件事, 便于提醒成员思考前一天的工作和当天的计划.

晨会必须全体成员出席, 迟到者必须接受罚款., scrummaster请他左边的第一位开始汇报工作情况, 按逆时针方向挨个汇报, 每位成员仅回答3个问题:
自上次晨会后的1天里你为该项目做了什么?
从现在到下一个晨会的1天时间里, 你准备为项目做什么?
什么妨碍你尽可能高效地工作?

晨会上成员不得离题讲其他事宜, 设计, 讨论问题或者闲谈, scrummaster必须确保成员轮流且干脆利落地汇报情况

晨会上其他成员是听众, 不可在一旁私下谈话.

晨会上当某成员汇报的情况涉及到其他成员兴趣或者需要协助时, 可在晨会后召集有关人员开会讨论.

晨会上鸡类人员不得讲话, 评论等. 且必须站在团队外围, 以免干扰会议, 若鸡类人员过多, scrummaster必须做出限制.

鸡类人员不可在会后请团队成员深入解释或者向团队提供建议或指示 // 不敢苟同


sprint
在sprint期间, 其他人不可向团队下达通知, 指令, 评论和方向指示, 团队完全进行自我管理.

若sprint发生异常, scrummaster可非正常终止sprint, 召开新计划会议启动下一个sprint.

团队准备sprint审核的时间不得超过1小时

sprint完成的定义是功能已经完成建造, 潜在可交付或实施.

sprint评审会议上全体成员必须回答两个问题:
上一个sprint有哪些成功方面?
下一个sprint应该做出哪些改进?

scrummaster出席会议的目的不是提供答案, 而是促使团队发掘scrum过程的最优方法.