《走出硝烟的精益敏捷：我们如何实施Scrum和Kanban》的原文摘录
-
sprint会议是为了让团队获得足够的信息，能够在几个星期内不受干扰地工作，是scrum中最重要的活动。 sprint计划会议需要一些实实在在的结果： 1：sprint目标 2：团队成员名单以及投入程度 3：sprint backlog 4：确定好sprint演示日期 5：确定每日scrum会议的时间和地点 (查看原文) —— 引自第16页 -
我们已经证实，如果团队拥有高度的代码集体所有权，这个团队就会非常健壮，比如某些关键人物生病了，当前的sprint也不会因此隔屁着凉。 (查看原文) —— 引自第107页 -
对待离自身尚远的事物时，人们 可以把它分析的淋漓尽致；但到了自己身上，就往往成了当局者迷， 旁观者清。譬如青春、譬如爱情、譬如敏捷软件开发。 (查看原文) —— 引自章节：这个序。。。= = -
通常我们会把 backlog 存放在共享的 Excel 文档里面（是为了多个 用户可以同时编辑它）。虽然正规意义上这个文档应该归产品负责 人所有，但是我们并不想把其他用户排斥在外。开发人员常常要打 开这个文档，弄清一些事情，或者修改估算值。 基于同样原因，我们没有把这个文档放到版本控制仓库上，而是放 到共享的驱动器里面。我们发现，要想保证多用户同时编辑而不会 导致锁操作或是合并冲突，这是最简单的方式。 (查看原文) —— 引自章节：共享文件夹 -
短的 sprint=短反馈周期=更频繁的交付=更频繁的客户反馈=在错 误方向上花的时间更少=学习和改进的速度更快，众多好处接踵而 来。 但是，时间长的 sprint 也不错。团队可以有更多时间充分准备、解 决发生的问题、继续达成 sprint 目标，你也不会被接二连三的 sprint 计划会议、演示等等压得不堪重负。 产品负责人一般会喜欢短一点的sprint，而开发人员喜欢时间长的 sprint。所以sprint的长度是妥协后的产物。做过多次实验后，我们 最终总结出了最喜欢的长度：三个星期。 (查看原文) —— 引自章节：周期 -
羞辱式做法： “如果你不知道怎么帮助团队，我建议你还 是回家去，或者看书，或者怎么都行。要不也可以找个地 方坐下，等别人需要帮忙的时候你就过去。” 守旧式做法：简单给他们分配个任务了事。 施加同事压力的做法： 对他们说，“Joe，还有 Lisa，你 们两个可以放松点，我们会站在这里慢慢等，直到你们找 到帮助我们完成目标的事情为止。” 奴役式做法：对他们说，“你们今天可以给大伙儿干干杂 活。倒咖啡、做按摩、清理垃圾、做午饭，一切一切大家 今天让你们做的事情。”你会惊讶的发现 Joe 和 Lisa 在霎 那之间就找出了有用的技术任务:o) (查看原文) —— 引自章节：^^ -
如果每个人（所有的团队成员和产品负责人）离开会场时都面带微笑，第二天醒来时面带微笑，在第一次的每日例会上面带微笑，那sprint 计划会议就是成功的。 (查看原文) —— 引自第41页 -
迭代开发的基本需求: • 迭代要有固定时长(被称为“时间盒——timebox”),不能超过六个星期。 • 在每一次迭代的结尾,代码都必须经过 QA 的测试,能够正常工作。 Nokia 的 Scrum标准: • Scrum 团队必须要有产品负责人,而且团队都清楚这个人是谁。 • 产品负责人必须要有产品 Backlog,其中包括团队对它进行的估算。 • 团队必须要有燃尽图,而且要了解他们自己的生产率。 • 在一个 Sprint 中,外人不能干涉团队的工作。 (查看原文) —— 引自章节：序——Jeff Sutherland -
http://agilemanifesto.org/ http://www.mountaingoatsoftware.com/scrum http://www.xprogramming.com/xpmag/whatisxp.htm (查看原文) —— 引自第3页 -
只要发现这种面向技术的故事,我一般都会问产品负责人 “但是为什么呢”这样的问题,一直问下去,直到我们发现内在的目标为止。然后再用真正的目标来改写这个故事(“提高在后台系统中搜索并生成表单的响应速度”)。最开始的技术描述只会作为一个注解存在(“为事件表添加索引可能会解决这个问题”)。 (查看原文) —— 引自第7页 -
只能有一个产品 backlog 和一个产品负责人(对于一个产品而言)。 (查看原文) —— 引自第8页 -
经验告诉我:牺牲内部质量是一个糟糕透顶的想法。现在节省下来一点时间,接下来的日子里你就要一直为它付出代价。一旦我们放松要求,允许代码库中暗藏问题,后面就很难恢复质量了。 (查看原文) —— 引自第13页 -
Sprint 目标需要回答这个根本的问题,“我们为什么要进行这个sprint?为什么我们不直接放假算了?”要想从产品负责人的口中哄骗出 sprint 目标,你不妨一字不差的问他这个问题看看。 (查看原文) —— 引自第17页 -
注意,这里的实际生产率建立在每个故事的原始估算基础之上。在sprint 过程中对故事时间进行的修改都被忽略了。 把事情完全做完!达到可以交付的状态!事情只做了一半,它的价值就是 0(也许还会是负数)。你可以看看 Donald Reinertsen 的“Managing the Design Factory”或是 Poppendieck 的书,从中能够了解更多信息。 (查看原文) —— 引自第22页 -
我们审视上个 sprint 的投入程度和实际生产率。我们审视这个 sprint总共可用的资源,估算一个投入程度。我们讨论这两个投入程度之间的区别,必要时进行调整。 (查看原文) —— 引自第26页 -
我们尽可能使用这样的定义:“随时可以上线”,不过有时候我们也这样说:“已经部署到测试服务器上,准备进行验收测试”。 如果你常常对怎样定义完成感到困惑(就像我们刚开始一样),你或许应该在每个故事上都添加一个字段,起名为“何谓完成”。 (查看原文) —— 引自第30页 -
我们的回顾会议一般没有太规整的结构。不过潜在的主题都是一样的:“我们怎样才能在下个 sprint 中做的更好”。 (查看原文) —— 引自第69页 -
图中的三列分别是: Good:如果我们可以重做同一个 sprint,哪些做法可以保持。 Could have done better:如果我们可以重做同一个 sprint,哪些做法需要改变。 Improvements:有关将来如何改进的具体想法。 第一列和第二列是回顾过去,第三列是展望将来。 (查看原文) —— 引自第70页 -
一般我们完成一个 sprint 以后就会开始进行下一个。但是我们会在接下来的 sprint 中花一些时间解决过往 sprint 中留下的 bug。 (查看原文) —— 引自第98页 -
5 到 9 个人被公认为是“最佳的”团队构成人数。 从到目前为止观察到的情况来看,我同意这种说法。不过我会建议说 3 到 8 个人。而且我相信,为了达到这种团队规模,花上一定代价还是值得的。 (查看原文) —— 引自第103页
作者: Henrik Kniberg, Mattias Skarin
isbn: 7302538638
书名: 走出硝烟的精益敏捷：我们如何实施Scrum和Kanban
译者: 李剑
定价: 69.80元
出版社: 清华大学出版社
出版年: 2019-11
装帧: 平装