《精益和敏捷开发》读书笔记

Posted 2020-10-18

对精益不了解, 敏捷开发则是一个到处都在谈论的话题, 我只是跳着看了一些在敏捷方面的做法和观点, 而且主要是scrum相关的, 当然本书的敏捷开发基本上可以等同于scrum. 算是增加了一层对scrum新的认识. 书不敢说是一本好书, 只能各取所需吧. 


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

如果在同一个办公区域, 你记不清所有人的名字, 那么这就是一个大型团队了 

产生非最佳决策的原因是错误的假设和不充分的理由 

守破离法则 
第一步, 守, 遵守规则直到充分并将其视为习惯性的事. 
第二步, 破, 对规则进行反思, 寻找规则的例外并"打破"规则. 
第三步, 离, 在精通规则之后就会基本脱离规则, 抓住精髓和深层能量. 

团队定期反思如何使自己变得更高效, 然后根据反思结果调整行动. 

5个为什么: 帮助培养解决问题和分析根源的能力. 

问题:开发人员没有进行代码重构来保证代码的可维护性 
为什么? 我们对加快工作速度感到有压力 
为什么有压力? 因为我们工作速度慢 
为什么工作速度慢? 因为代码很复杂, 很难开展工作. 
.... 

在scrum中, 优先准则是选择可以提前实现和测试那些具有不确定性或有风险的事物. 因为不可预测的事物可测试性比较低, 所以反馈的价值比较高.可预测的事物不能给我们带来更多的经验. 

工作有节奏可以提高预测, 计划和协调的能力. 

scrum:五项价值 
承诺:愿意对目标做出承诺 
scrum的根源是自组织的团队, 在sprint计划会议上, 团队自己从产品负责人给出的清单中, 选出要做的事情. 没有一项工作是强加给团队的, 没有一个团队被告知要怎么做事. 这样才能做到真正的承诺, 如果你自己可以决定, 在两周或者4周的迭代中能够合情合理的做完哪些工作, 如果你自己能决定完成这些工作, 你才会更愿意做出承诺, 也才能有能力实现诺言 

专注:做你的工作, 把你的心思和能力都用到你所承诺的工作上去, 不管任何其他的东西. 
不完全参与意味着不完整的结果 

开放:scurm把项目中的一切都开放给每一个人看.scrum不存在秘密会议或是隐蔽的项目管理信息. 

尊重:每个人都有他独特的背景和经验, 我们应当尊重组成这个团队不同的个体. 
它要求团队有一个共同的, 清晰的目标(当前迭代要完成的特性); 

勇气: 有勇气行使scrum的规则去改变组织, 或者是一个自组织团队发挥自己的主动权. 不管是个人工作还是团队工作将要前功尽弃的时候, 要有勇气把现状完全公开. 

scrum团队成员除了"团队成员"之外没有其他特别的称谓. 团队中不会强调"开发人员"跟"测试人员"称呼上的不同. 团队的目标是鼓励团队学习更多的技能和"整个团队进行完整特性的开发." 

如果没有接触过大量不同的代码, 这就会阻止他们学习优秀设计的机会 

当我们每时每刻看到这种复杂模糊的1万多行的代码时, 它们开始很自然地变得熟悉和"清楚", 由于长期的接触, 你就不觉得它们有多复杂, 也不会因此一筹莫展, 更没有想深入改进它们的动力 

对卓越技术和良好设计的不断追求将有助于增强敏捷能力. 

无法排除障碍的最常见的原因是"这是我们一直以来的工作方式", "我们不会改变的, 我们已经投入很多" 

scrum是揭露组织问题的简易框架 

scrum是理解容易但很难使用的实践方法, 因为它使组织的所有弱点彻底曝光. 

好的想法和建议随着开发的进展不断涌现, 如果整个开发过程不允许变化的产生, 那么将会遏制创新. 

scrummaster帮助产品团队学习和应用scrum以获得商业价值. 

scrum会使许多干扰团队与产品负责人效率的障碍和危险呈现出来, 这就需要由ScrumMaster全心全意协助铲除这些障碍, 否则团队或产品负责人将会感觉到取得成功非常难. 

优秀的ScrumMaster可以从任何背景和学科产生出来. 

与项目经理不同, ScrumMaster不是简单的分配工作, 他们协助过程顺利进行, 并支持团队自组织和自管理. 

scrum重要实践原则: 团队决定承诺完成多少任务, 而不是产品负责人安排工作, 这就使得任务的交付更可靠, 团队根据自己的分析和计划来承诺工作量, 而不是其他人"安排"交给他们的工作量 

每日例会不是向经理汇报工作进度, 而是自组织的团队互相交流, 某位团队成员会将障碍内容记录下来, ScrumMaster负责协助团队铲除障碍 

每日例会不允许讨论 

通常最好不允许经理或其他管理层参加每日例会, 这样使团队感受到"被监控", 在压力下汇报每日的进程, 而且抑制了问题的汇报. 这些会消弱团队的自组织能力. 如果能协助团队解决问题, 那么参加会议会更有意义. 

如果在sprint计划会议中还包含很多问题, 疑惑, 新的发现, 就说明团队没有进行提炼研讨会(或者会议没有达到目的)

scrum的核心原则之一是sprint的周期不可以延长: 它结束于指定时间, 不论团队是否完成承诺的任务. 

固定的周期可以帮助团队了解他们的实际工作效率, 以便进行正确的估算和制定长期的发布计划. 同时也可以帮助团队保持工作节奏. 

scrum要求准备演示的时间不超过30分钟, 否则就说明团队的工作出了问题. 

scrum回顾会议的最简单方法就是在白板上画出两栏: 分别注明"哪些工作顺利", "哪些工作可以做的更好", 然后让与会者轮流在每一栏下添加条目. 当出现重复条目时, 可以在该条目旁边记正字累计. 并计划在下一个sprint中尝试少量的变更, 改进, 并在下一个sprint回顾会议上评审结果. 

彻底解决问题的第一步就是让问题显现出来, scrum对此正是有强大的促进作用. 

产品负责人和团队应该在每个sprint都进行产品待办事项列表的提炼, 从而不断的为未来工作做准备. 

没有人可以预知未来, 因此工作的重点就应该放在创建和调整计划上来, 以给予发布一个总的方向, 并明确如何对决策做出权衡(范围vs.计划). 

scrum并不解决实际问题, 它只是使问题显现出来, 并提供人们以短周期和小范围改进尝试来探求解决问题的框架. 

一个错误的做法: 让scrum挑战团队固有习惯的时候, 他们会改变scrum, 而不是改变自身的问题.