敏捷迭代五步曲，人人都是开发主力

工序、流水线和软件研发

在农业时代，有民间作坊式的工序，例如：酿酒、制陶、染布。

在工业上，为了提高普工的生产力、工作效率和产量，引入并广泛使用了流水线，从而使得每个工位只专注某一极小部分、简单而重复的基本工作。1769年，韦奇伍德开办陶瓷厂时进行了劳动分工，把制陶流程拆分成了十几道工序，由不同的专人分工完成。福特汽车也通过流水线生产了人人都可以买得起的汽车。可见，流水线这一概念以及应用在工业制造所发挥的价值和带来的作用。

例如，我们熟悉的不锈钢中板生产流程。

图片来自网络

那么，在信息行业有什么？流水线和工序，对于我们进行软件项目研发又有哪些启发呢？

说句实在话，用户不会太关心我们使用的是什么编程语言，需求方也不会太关心我们用的是敏捷开发、Scrum还是XP编程，他们更为关注的是：“这个需求很简单，今晚就要上线。” 时间就是金钱，当下的时间窗口就是百年一遇的最好时机。纵使行业不同，但本质是相似的，不管是工业时代，还是信息时代，都是为了提升生产力、交付能力、交付速度和交付质量，降低成本，提高市场竞争力。

然而，在软件开发行业，和工业制造有着相似但又颇为不同的之处。相似地，两都会有会专业分工，也需要既定的流程进行配合和流转。明显差距在于，软件开发需要脑力集中型的工作而非体力密集型的劳动；软件团队所面临的问题和待实现的功能都是之前从出现过的，而非可量产、千篇一律的产品；除此之外，软件开发很有可能是一边在会议室改需求、一边在加班加点改代码。

敏捷迭代五步曲

现在，在互联网企业的技术团队，可能接触最多、讨论最多和应用最为广泛当数敏捷开发。但我们是否真的非常了解敏捷开发，以及是否得到了正确的应用和期望的收获？

为了方便大家更好地在实际项目研发中，提升协作效率和团队产出的速度和质量，这里分享一下我总结的协作五步曲。分别是：提需求、建项目、做任务、改Bug、推发布。

虽然只有不到15个字，但请注意每个步骤的关键动词，主导角色，以及在软件研发流程中所承担的作用。

提需求

需求是最初的起点。

提需求，关键在一个字：提。

看似很简单，不就是提个需求吗？但是正是看似最为简单的动作和环节，控制不好就会发生全盘失控的场面。

需求的成分很复杂，并且脾气古怪。如果梳理得当，有明确的商业目标和产品路线图，并且通过产品经理的梳理可以形成技术人员容易理解的PRD，将有助于整个项目周期的迭代、协作和产出。相反，如果只是一句话需求，或者需求未确定、未清晰，或频繁变更需求，就会在源头上造成非常严重和恶劣的影响。

在提需求前，应当根据公司的核心业务划分产品线。

在接收到需求时，产品经理应当梳理成书面的需求文档、PRD。

用户、需求方，包括产品经理提出的需求，都应该先进入需求池。需求池里都是可能需要做的需求。产品经理梳理好需求后，需要和负责这个需求的技术人员、测试人员、需求提出方和相关TL组织需求评审会议，对需求的背景、流程、逻辑和UI交互、注意事项等进行介绍和说明，并接受大家的提问，仅当需求评审无异议时，才能进行下一个环节。同时，如果需求评审时间过长，或者大家的提问源源不断，也要适时中止并打回需求，等需求重新梳理并完整后重新评审。

当需求正式进入开发阶段后，项目干系人可以通过需求排期实时看到自己的需求计划上线时间、当前是什么状态，以及负责人是哪位同事。

建项目

建项目如同盖房子，容不得半点马虎，需要敬畏的态度、严谨的逻辑思维和追求极致的工匠精神。

在创建项目时，YesDev之所以只提供了一个把需求关联项目的入口，是出于这样“用心良苦”的设计：我们希望在进行迭代需求规划时，项目负责人应该在了解当前的需求环境后再进行决策和合理的安排，避免信息不全，或者安排明显超出工作负荷的需求，或者忽略了一些优先级极高或重要的需求。更为重要的是，我们希望大家有这样的共识：需求变更都是有成本的，特别是中途加需求。

当项目创建好后，我们就可以得到项目计划、项目排期、项目的工时。在项目进行过程中，我们可以看到项目燃尽图、实时项目进度。

一个项目，就是一次迭代。要追求100%的进度和100%的质量。

做任务

有了需要做的需求，也有了规划好的项目。接下来，就是具体的“搬砖”过程。

一个项目，需要团队里的多个成员共同参与。做任务，关键字是做，就是执行能力和搞定力。

优秀的开发程师，他会对所负责的需求进行任务评估，预计需要多少时间、什么时候完成、排期怎样，这样可以方便团队内部协作和项目经理进行整体的项目统筹。因此，在做任务前，需要拆任务。

拆完任务，协调排期，接下来重点在于执行。再完美的计划，没有执行，最终也是0分。在执行过程中，还要注重进度同步、快速反馈，和风险预警播报。通过每日站会、任务看板等会议和工具，可以在团队内部进行更好的沟通、协作和反馈。

改Bug

当功能开发完成，就可以进入测试阶段。

这时，测试人员，如有必要，可以提前准备好测试用例和测试计划，并关联到项目。

在测试过程中，可以把发现的Bug记录下来，进行流转、跟踪和回归测试。还可以通过自动生成的测试报告，进行向上汇报。

最后，把全部的Bug跟进到底，关闭全部有效的Bug，为项目贡献那100%的质量。

推发布

当项目的全部任务都完成了，当全部的Bug也关闭了，需求功能也实现了，项目就算是已完成了吗？

非也。

只有当全部的新功能都发布上线或成功交付后，这个项目，也就是这次迭代，才算完成。

项目，是以需求为起点，以发布为终点，构成一次项目迭代。

千万不要以为发布上线是一件很容易的事情。发布上线会消耗团队很多宝贵的时间、精力。例如：代码合并、数据库变更、环境变更、历史数据处理、打包、构建、进行回归测试、进行发布。更为可怕的是，每一个操作都蕴含着风险，稍有不慎，就有可能删错了数据库、配置改错了、因为代码的Bug而造成严重的线上故障。

推发布，其中的推字，既意味着项目在最后时刻加班加点拼尽全力交付的集体努力，也暗含了上线发布所需要的勇气。

人人都是开发主力

回顾本次分享的五步曲：提需求、建项目、做任务、改Bug、推发布。

明确的分工，有助于团队每个成员更好的发挥自己的专业能力和聪明才智。人人都是开发主力，更扁平的协作，更多参与感，更多承担，更多成就。

关于作者