《scrum敏捷软件开发》读书笔记

一本scrum方面的大部头, 很多内容讲的比较细, 也比较全, 很多地方都涉及到项目管理的知识, 当然还有敏捷相关的知识, 不过较少, 有选择性的看了看, 算是其他scrum书籍的一个补充吧.


----------------我是读书笔记的分割线--------------------------------------

scrum这个游戏如同围棋, 入门容易, 成为九段高手难

在scrum领域, 没有最佳实践, 只有最合适, 最有效的实践.

scrum不在于让你现在有多优秀, 而在于你下个月有没有变得更好.

衡量开发人员的效率是不可能的(martin flower)

对于scrum团队成员来说, 不要考虑是你的任务还是我的任务, 而应该考虑是我们的任务.

scrummaster一方面是团队的领导, 另一方面是毫无行政权力的普通人

scrummaster的存在是为了帮助团队使用scrum, 他类似于健身教练, 教会你用正确的方式进行各种练习, 但是教练的权利又是有限的. 他不能强迫你参加你不喜欢的运动, 他们的权利是客户授予的. 而scrummaster的权利是团队授予的.

如果团队不能按时交付软件, 那一定是流程上出了问题. 而scrummaster的权利不能超越流程之外.

对于scrummaster的权利, 举个例子: 某团队成员在提交代码之前, 必须进行code review, 这个虽然是个好主意, 但是不应该是scrummaster来决定, 因为它超出了流程之外, 这个是要求团队怎么工作的决定.

优秀的scrummaster能够并愿意承担责任的人.

scrummaster不应该对项目的成功负责, 这个是团队的责任.

scrummaster必须对团队产出最大化以及支持团队使用scrum负责.

scrummaster相当于乐队的指挥, 二者都必须对团队的行为进行引导.

优秀的scrummaster不会以自我为中心. 应该帮助团队实现目标提供任何帮助.

scrummaster必须保证团队中存在一种互相协作的文化, 需要确保团队成员能将问题拿出来公开讨论. 善于合作的scrummaster应该鼓励团队用共赢的方式思考, 而不是以赢家和输家的方式思考.

如果团队发现障碍经常不能很快得到清除, 那么应该提醒scrummaster积极投入团队的重要性.

成功的scrummaster应该影响团队内和团队外的人, scrummaster应该懂得向别人施加影响, 同时又要避免独裁.

scrummaster不仅要有scrum知识, 还必须具有技术, 市场和其他专业知识, 帮助团队实现目标.

scrummaster的职责是提供指导而非答案, 团队必须自己找答案.

scrummaster是这样的人: 保证团队一起顺利工作, 迅速清理挡路石, 团队有效朝着目标前进. 而产品负责人则是保证团队朝着正确目标前进的人.

产品负责人不仅仅是一名项目经理, 同时还必须撰写需求和排列优先级.

需求边界必须由负责人提出并且经常表现为限制条件, 比如: 我六月需要它;我需要减少一半的开销; 它的速度要加倍; 内存占用要减半等.

产品负责人的工作分两部分: 对外了解市场趋势, 对内与团队一起建造产品.

产品负责人的品质
必须要有非常强的业务背景.
能与各种干系人等友好相处, 是一个良好的沟通者.
当团队成员遇到问题找你时, 产品负责人必须给出一个解决方案或决定.
要懂得授权.

产品负责人通常会要求的更多, scrummaster必须在这种情况下站出来与之抗衡从而保护团队.

scrum基本原则: 相信团队能解决问题.

scrum并没有规定必须有测试, 必须结对编程, 它只要求团队在每个sprint结束时能交付高质量, 可工作的软件.

不断的重构, 让小问题在变成大问题之前修复他们, 保证我们的应用不会腐烂.

如果能保证我们在提交代码的时候比我们更新代码干净一点点, 那么我们的代码就不会变烂

集体所有制鼓励成员对程序的任何部分都承担责任, 以便团队成员能在任何一个模块工作.

必须确保开发人员不会变得太专业以至于只能在某一方面做出贡献.
确保没有一个地方变得太复杂以至于只有一个开发人员可以明白和完成其工作.

结对编程
如果偶尔的代码检查能带来好处, 那么为何不将代码检查持续下去?
在一起工作对学习如何做驱动测试更容易.
结对编程能创造出代码集体所有制的感觉.
能保证我们以低错误率完成一些复杂的产品.
相当于一个人在键盘上工作时有了两个脑袋.
结对编程有利于知识传递.
增加的成本可以通过缩短周期提高产品质量换来.
在最难的模块采用结对编程, 可以得到更少的缺陷, 甚至零缺陷.
如果赶时间, 这正是结对编程的时候.
期望在延期的项目上增加人手, 这也是采用结对编程的理想时机.

企业向敏捷转型的一个重要方面就在于预见性和适应性之间找到一个合理平衡.

在前期进行大量的设计和分析可以让后期的变更数目下降, 但是一旦变更, 就比较昂贵.

产品负责人的真正工作是最大化某一个时间段内的功能交付.

敏捷编程鼓励简单, 局部的方式来适应变更, 以避免大的重构, 测试和系统构建.

团队的优势在于让事情很快的完成, 比一个人做要快得多, 坏处是带来了大量的潜在的沟通成本

amazon称他们的团队为两个披萨的团队, 指他们的团队规模人数一顿吃两个披萨就够了.

当一个团队人数超过10~12人, 就很难建立信任感, 共同的责任感和凝聚力.

为一个大团队安排一次会议非常麻烦.

在一个大团队, 团队活动和讨论的参与度较低.

一个大团队会导致差异增加, 不利于组成一个有凝聚力, 高效的团队.

最好不要频繁调整团队结构, 因为团队需要时间形成凝聚力.

如果一个人的工作量不饱和, 那多任务是可以接受的.

宁可让少数人承担多任务, 也不要让每个人有少量的多任务

一个人被安排到一个团队的时候, 至少60%的时间在这个团队中.

scrum来自于这样一种场景:产品开发团队必须像一支橄榄球队, 一组运动员作为一个整体沿着球场传球.

要成为高效的scrum团队, 首要目标就是要确认团队责任制, 即"谁为...负责"

尝试是最好的学习方法之一

如果大家觉得做这件事没有安全感, 他们就不会去做.

多数团队发现每个sprint用大约半个小时到半天时间寻找改进的方法是值得做的.

敏捷开发的目标在于找到文档和讨论之间的合理平衡, 而过去我们更偏向于文档.

当文档用于任务的交接时, 那它就是邪恶的, 如果是为了捕捉交谈记录而不为忘记, 这是有价值的.

用户故事是团队将用户需求从编写转换到讨论的最佳方式, 它从该功能的用户角度出发来进行简短的描述

用户故事模板:
作为一个<用户类型>, 我想<某个目标>, 以便于<一些原因>
为了<实现某个价值>, 作为什么<用户类型>, 我想<某个目标>.

story card 不需要记录所有的细节, 细节在产品负责人和团队讨论之后产生.

一旦使用软件工具管理产品backlog, 就说明你不能做到敏捷. 如果你使用笔和纸, 你就会更加敏捷, 只要能采用这种低技术含量方式, 请尽量使用它.(好扯^_^)

用例所表现的功能比常见的用户故事要大.

scrum团队能更好的处理比通常用例更小的任务.

故事卡片上的问题都是可以讨论的, 所以不要包含所有的细节.

总有一些只有在系统成型之后才想到的东西. "可恶, 我们居然没有想到..."

涌现的需求不允许你完美的预测进度

涌现的需求被认为是计划太早或者包含过多细节导致的结果, 不能看成计划的失败.

对需求的变化就像对天气的抱怨, 你不能改变大自然的规律, 但是你可以找到方法来应对它, 你不能让雨停, 但是你可以带一把伞.

产品backlog中, 团队很快要实现的那些内容必须拥有足够的细节, 以便每一个内容都能在一个sprint中编码实现, 测试和集成.

在产品backlog中, 那些位置靠前的用户故事, 一定是更小更容易理解, 包含更过的细节, 位置靠后的用户故事则更大, 更粗略, 只能大致进行估算和排列优先级, 整个产品backlog呈现冰山状的结构.

如果位置靠后的故事对前面的故事有影响, 那么就应该花一些时间来理解它.

一个大需求被拆分为小需求的例子:
大需求: 作为一个用户, 我需要登录系统, 以便只有我才能访问的信息.
分拆成小需求:
作为一名已注册的用户, 我能用我的用户名和密码登录
作为一名新用户, 我能创建用户名和密码, 并让系统记住我的信息.
作为一名已注册的用户, 我能修改我的密码, 让我保证它是安全和容易记忆
作为一名已注册的用户, 系统能在我的密码在被猜测时, 提醒我, 从而保证我的信息安全.
作为一名健忘用户, 系统能让我申请一个新的密码, 避免忘记密码账号被锁住.
作为一个已注册的用户, 我不想看到由于用户错误, 密码错误或者二者都错误导致的信息, 让其他人冒充我.
作为一名已注册用户, 我能在我的账户出现三次错误尝试后得到通知, 让我知道是否有人尝试访问我的账户.

当大故事拆分成小故事, 大故事就可以从backlog中删除了

如果遇到更大的故事, 可以首先拆成一些中等规模的故事, 然后再拆成更小的.

当故事拆分到足够小, 能在一个sprint中完成, 拆分就到此为止.

当故事拆分到足够小之后, 可以通过向故事中添加满意条件来继续提炼需求. 满意条件是某个简单的验收测试, 如果故事完成, 那么该条件就为真. 满意条件可以是支持什么, 包含什么, 也可以是不支持什么, 不包含什么, 通过满意条件我们知道产品负责人对该功能的期望.

向scrum转型并取得长期的成功, 必须学会在没有完整的细节说明书的情况, 如何启动项目.

详细说明书的一个不足就是他们很少保持更新, 写一份文档之前, 问问自己是否愿意一直更新该文档.

利用事例可以帮助我们更好的沟通, 也更容易帮助我们发现不一致的地方.

因为存在交接, 所以需要文档, 如果一起讨论, 文档的工作就得到简化.

可工作软件的作用:
能鼓励反馈
能衡量它们的进度
允许软件在需要时发布

在sprint结束时, 我们得到的产品是可用的, 或者称之为潜在可交付的, 即: 对于正在开发的特性, 功能不全, 但是可以工作.

潜在可交付的意味着测试通过. 但并不意味着系统功能的完整.

每个sprint提交有价值的东西的两个主要好处: 可以尽早的反馈和确保团队不会误解项目的进度

如果那个功能还不能被最终的用户认识到或见到, 那么至少产品负责人能理解目前完成工作的价值.

在任何一个sprint中应该有10%的时间准备下一个sprint

产品backlog的优先级与所包含的细节成正比, 优先级越高的任务, 所包含的细节越多.

如果项目开始做了非常详细的假设, 而该计划基于非常多的假设, 随着项目的进展, 我们会发现这些假设是不对的, 这样会导致这些基于假设的设计是无效的.

逐步完善的计划可以帮助团队避免落入项目一开始就做太多决定的陷阱, 随着项目的推进, 细节的掌握, 我们才能逐渐做出决定, 今天不能做的决定, 完全可以推迟到明天.

程序员往往会低估做一件事情要花费的时间.

增加能源的最好方法之一是增加热情, 项目中充满热情的人越多, 团队就越有可能充满能量, 其中产品负责人是关键, 他需要传达一个引人注目的产品愿景, 让团队充满热情工作.

定时的短暂休息, 比如一个20分钟的散步, 或者和同事聊天可以快速的恢复对主要任务的关注和能量.

人会有一个90~120分钟的周期, 在这个周期中, 人的身体逐渐从精力旺盛过度到生理的低谷期. 每隔半个小时最好休息休息, 如果不休息, 你就会累, 就会精神不集中, 会容易犯错, 变得急躁, 并出现意外.

范围,成本, 进度是项目管理的铁三角. 同时只能满足任意两个. 而铁三角中间的内容就是产品的质量, 这个是万万碰不得的. 而错误的做法往往是将质量作为第四条边.

作为向scrum转型的一部分, 项目关键的干系人, 开发人员以及产品负责人需要学会把改变范围作为第一选择. 即我们偏向于调整范围去适应可用的资源和进度.

测试不能作为事后的纠正, 而是验证在之前的开发有没有引入错误

缺乏自动化是一种技术债

至少必须对系统中最复杂的部分做彻底的代码检查

自动化测试的金字塔:UI<服务<单元

一个自动化的单元测试可以缩小检查的范围, 而且单元测试和开发语言相同, 写起来更得心应手.

自动化的用户界面测试放在金字塔的顶端, 是因为我们想尽量少做它(脆弱, 成本高, 耗时).

对于涉及到硬件和外部系统的集成, 不应该采用自动化

手工测试应该作为探索式测试, 这种测试应该以短尾特色.

经验告诉我们程序员以后回头为可工作的代码补充单元测试是很少见的.

技术债: 代码不成熟, 或不太正确导致的成本的增加.

第一次提交代码就像借债, 只要通过重构快速地归还, 小的债务是可以加速开发的. 问题的关键是必须快速的偿还债务