近期基于Scrum的开发流程的感受
之前写过一篇接触过的敏捷开发，近期工作方式又开始了新的调整。
之前团队人少，每次做需求都是粥多僧少，怎么排工作都是做不完，而且每个人不是固定在一个域，来回切换，时间长了就像救火队员，而且对于个人说很难沉淀出一些实在的东西。对于leader来说，更是捉襟见肘。做个项目，周期长，结果拿的比较慢。
所以团队引进了响应的工具和流程来进行改变。但前提也是招到了足够的人。
首先用一个任务管理工具来将所有任务管理跟踪起来，这样的工具有很多，比如Jira、GitHub Projects等。
这些工具的重要特点是：可以收集记录每一个任务，跟踪管理任务的整个生命周期。
而对于其中的每一个任务，要有清晰的：
- 标题：概要性的说明任务
- 内容：任务的详细内容
- 类型：Bug、需求、调研等
- 重要性/优先级：重要性和紧急程度
- 负责人：任务谁来负责
- 状态：当前任务的进展：等待处理、进行中、测试验收、完成 等
- 打分：这个任务大概需要多少时间完成
只有用工具把所有任务都跟踪管理起来，开发人员才能清楚的知道自己该去哪里拿任务，该优先做哪一项任务。对于管理者也一样，只有用工具管理起来，才能清楚的知道每个开发人员在做的事情，进展如何，长期看还能知道每个开发者的产出多少。
然后需要一个清晰的工作流程
现在的工作流程是基于Scrum的开发流程，一个Sprint（开发周期）一个Sprint的迭代开发，每一个阶段都有明确要做的事情。
- Sprint计划
Backlog里面有多少高优先级的任务，根据优先级从高到低选取任务。
每个任务打分多少？需要开发人员参与对每个任务进行打分，分数过高的任务应该进一步拆分成多个小任务。
接下来这个Sprint大致能完成多少分？上个Sprint还有多少遗留的任务？要留多少buffer？
这里的打分其实后续会得到一个团队任务平均值，以此来衡量团队的开发效率。（制定KPI）
- 任务说明、需求说明
有些任务比较复杂，需要单独安排会议，让产品经理一起参与介绍清楚任务的详细内容，需求文档，设计规范等等。
在新的Sprint开始前就要把这些工作做好，这样开发人员才可以正常的开始任务。
-
开发和测试
当Sprint开始后，开发人员就可以从任务管理系统里面去按照优先级选取高优先级的TODO（待开发的）任务了。
当一个任务开始了，状态就要变成In Progress（进行中），开发完成后，借助CI部署到测试环境，就可以让任务进入Testing（测试）。
任务在测试的时候，如果测试通过，就可以将状态标记为Done（完成），如果测试不通过，那么就需要将状态重新标记为TODO，再进入In Progress，然后Testing，知道测试通过后变成Done。 -
发布
当快到了发布的时间，就需要将所有验收通过的任务一起打包发布，再完整的回归测试，没完成的就滚动到下一个Sprint。 -
演示和总结
项目发布后，让开发演示一下自己的作品，既可以让大家都知道我们发布了什么，又可以让开发得到一定的肯定和鼓励
事后总结复盘可以让以后做的更好。 -
每日例会
每天简短的沟通一下，看每个人的昨天做的事情、今天要做的事情、有没有任何障碍，这样遇到问题可以及时沟通，避免最后时间到了才发现差一大截。
并非说一定要Scrum，但基本流程都是类似的，也是必须的：
- 每个版本的计划，要发布哪些任务。
- 让开发和测试清楚的知道每一个任务的详细内容。
- 要跟踪任务的状态，从TODO到DONE有个清晰的流程。
- 要日常定时沟通，及时发现问题及时调整。
- 事后总结，不断完善。
在之前管理过的团队为什么没有实施起来，我的感受。
- 人数。目前这套流程其实基本盘是有足够的人来长期维持某个域。
- 人员梯队。团队人员技术水平差距不大。（很少很少的初级工程师，实习生完全没有）
- 每个域都专职的PMO。团队配套人员也要匹配上。
- Backlog里的任务打分，目前还没有深入执行，之后再更新。