Scrum流程应用反思nbsp

这篇文章和《PDA感悟》一样，是对一年前学习到的相关知识的一个应用反思。

写它，是为了完成每月反思，也是为了完成我这个月的目标，更是为了积累项目流程经验。

之前已经看过刚进公司的时候，由于项目组需要使用Scrum作为流程来进行软件开发，所以当时看了一遍《Scrumandxpfromthetrenches》，主要目的是了解scrum中的主要内容，以促进早日融入项目组，并写了一篇介绍Scrum的入门级别的文章：《Scrum大白话总结》。

至今，时间过去了也有一年多了。在这一年多里，项目组不断使用Scrum进行开发，但是总是感觉有些地方不太对，没有想象中的“敏捷”。直到最近两个月，问题慢慢地突显出来了，“需求不确定”，“估时无章法”，“辛苦回顾的结果不落地”，“会议常延时”，“计划会议难以把握个人重点”……等。

敏捷的团队，需要敏捷个人，身为团队的一份子，有责任去不断反思敏捷团队中所存在的问题，并提出自己的书面建议。这些流程反思不只是PM的责任，更是身处一线的开发人员的责任，否则，被动等待的团队如何能做到敏捷？所以，我决定对项目组中目前所遇到的问题进行归纳总结，并提出个人的相关建议，希望会对项目组有所帮助。在这之前，我不得不先再次重温《Scrumandxpfromthetrenches》一书中的知识，整理别人为什么能做成功，而我们的流程却有许多问题。

书籍知识整理

由于该书90%的内容都在讲他们的团队是如何实践Scrum。所以，这些内容都是来自他们的亲身实践经验，有很大的参考价值。

另外，基于对项目组有帮助的目标下，我只从原书中摘抄出了部分相关的理论方案。这些方案并不一定适用每一个团队，但是它们一定有它们成功的道理。

关于计划会议：会议开始前，PO要准备好接受各式各样问题的挑战。计划会议开始时，应该宣读本次会议议程，并强调Sprint目标。

关于Sprint目标：强调商业价值。

关于团队成员：一个敏捷团队，人数最好在3-5人。

关于Sprint长度：短迭代，意味着敏捷、更多的反馈、更少的错误。理论上，开发人员喜欢长迭代，而PO喜欢短迭代。

关于Sprint故事列表：团队成员定夺最终的故事列表，不是PO，更不是SM。那么，PO如何影响故事列表？“重新排列优先级”，“划分大故事为小故事”，“缩小故事的范围”。团队如何确定Sprint中的任务数？两个方案：“敏捷团队自身感觉”、“计算团队速度”。

关于速度计算：分析历史完成量，计算出团队的专注度；计算迭代中的可用人天；相乘，得出最终速度。

关于indexcard：好处有两点：每个人都能保持高度的参与程度，而不再只是掌握键盘的人；多个任务可以被同时编辑。

关于SprintBacklog：自行定义合适的格式，建议Excel。

关于Sprint回顾会议：目标在于反思！在于长进！找到本期重点不足，并予以改正。

关于测试阶段：最小化测试阶段的时间。开发完成任务之前的时间可以做的事：测试人员需要为接下来的测试做准备；编写测试代码；与开发结队；其它辅助达到sprint目标的事（这些事最好在计划会议中定义）。

我们的团队现象与建议

流程是优化出来的。发现问题，思考方案，解决问题。

第一步就是发现问题。这要求有人







































北京哪里治疗白癜风不用开又便宜
治疗白癜风应到北京那家治最好