远程众包平台竟然也能用上迭代管理？- 大数跨境

首页

远程众包平台竟然也能用上迭代管理？

英选

2017-05-05

导读：采用迭代的方式，最重要的目标是让开发阶段的进度和质量可感知，黑盒透明化。

点击“英选”蓝字可关注

无论众包平台或是外包公司，为了减少服务成本，服务方总是倾向于少反馈、少跟进，恨不得一个电话了解清楚所有需求，下一次联系就直接上线。

这种追求依赖于团队成员的自我管理，会产生一些副作用，例如项目过程变成了黑盒子，真正知道项目进度和质量的人很少。

英选的项目管理体系在2017年有质的飞跃，其中非常重要的就是在开发过程引入了迭代管理。

英选自2016年起逐步引入科学的项目管理方法，包括甘特图，项目范围、变更和风险管理等等。工具上也进行了大量的对比和摸索，Trello、Pivotal Tracker、Teambition、Tower甚至Basecamp、Asana我们都进行了测试使用。

踏入2017年，全过程的项目管理体系开始稳定。针对开发阶段，英选采用经过简化的敏捷迭代管理方式。

迭代并不是一个新概念，在很多的产品团队都有不同程度的应用，大多数开发者即使没有真正尝试，也多多少少有所了解。

虽然大家都知道有这把剑，但如何用好对我们来说依旧是很大的挑战。

自由职业状态的开发者不仅让项目预算得以降低，而且技术实力强，可全身心投入项目，按工作日每日8小时安排项目计划。

这些是英选相对其他平台的优势。

但是另外一方面，团队成员之间缺乏了解、远程协作，则是我们在设计流程时面临的困难。

第一部分

关于迭代

在英选，我们一直都使用类似 瀑布流 的项目生命周期管理方式，产品、设计和开发串联式完成，各部分工作有明确的先后顺序。
而迭代管理方式主要是改造 开发阶段 的工作流：

通过将全部开发任务划分到每周一次的封闭时间段，配合回顾、规划、检验等手段，迭代管理让开发过程的成果变得更加可控。

采用迭代的方式，最重要的目标是让 开发阶段的进度和质量可感知，黑盒透明化。

为此，我们的管理必须要有以下特征：

合理、固定频率的沟通，让信息流动地更快，风险可以被更加及时地发现；
减少对开发者本身 时间观念 和 任务管理能力 的依赖，保证工作按照预先定义的进度完成；
为了开发者在英选平台上工作的长期稳定性，流程设计要简单。

出于目标用户和用户体验考虑，我们在诸多项目管理工具中选择Trello作为我们的迭代管理工具。

以下是整个开发阶段的迭代过程中，工作流程和工具使用的描述。

第二部分

迭代计划及会议

项目计划

迭代计划

迭代计划不同于项目计划，它是项目开发过程的整体指导，包含了迭代的数量和各自的目标。后者则包含了产品、设计及其他任何跟项目相关的工作安排。

制定计划：

在原型交互定稿后、开发工作开始前，由项目的开发成员评估需要多少个迭代完成初稿交付，以及撰写每个迭代的目标；
项目经理将迭代计划转化为甘特图等基于日历的材料，计算出项目的开发周期并告知需求方；

调整计划：

开发过程中迭代目标未达到或超额完成，应灵活调整下一迭代内容，如非必要不可延长开发周期；
如需延长开发周期，开发者应详细阐述原因及必要性。在需求方同意的前提下，项目经理可以调整迭代计划，如需求方不同意，则由开发者自身完成开发压力的消化；
为了保证迭代成果可检验，最少每周一次部署迭代成果并保证公开可访问，每周第一次更新部署不迟于周四晚。

迭代会议

迭代会议是用于回顾、规划前后迭代内容，以及沟通问题的固定频率会议。

会议要素：

时间：成员协商约定时间，为了保证迭代时间饱满，原则上不得晚于周一；
工具：微信/Skype；
形式：语音/视频/桌面共享（第一次必须以视频形式进行，用于建立信任）；
人员：项目经理主持，产品经理及所有开发人员均需参与；

会议内容：

总结上一迭代完成情况，讨论出现的问题和解决的方案；
确定本周迭代目标及生产率（可以完成的Scrum点数量）；
讨论开发任务并安排优先级，必要时由产品经理确定检验标准；

产品经理逐一对任务的重要内容进行强调；
开发成员询问存在的产品疑问；
开发成员根据技术实现难度事先判断风险；

按照迭代目标及优先级顺序，安排本迭代所需完成的开发任务。

注意：如非必要，除每周迭代会议外，没有其他任何形式的汇报会议（包括每日站会，这是与敏捷迭代的重要差别）；

第三部分

卡片规则

卡片制作

迭代过程中的任务和流程使用Trello管理，在Trello中卡片（Card）是最为重要的概念，它含有标题、描述和参与者等信息。

在这里，卡片代表了具体的开发任务。

开发者负责开发任务的制作，标题至关重要，要让团队成员一眼就能知道含义；
至少提前拆解2个迭代的开发任务，具体拆解时间由开发者自行安排，一般在迭代任务完成之前，下一迭代会议开始之前；

任务估点

Scrum点代表了任务所需的工作量，在英选的迭代管理方法下，每个Scrum等于1小时。

拆解之后负责开发任务的开发者需评估任务所需的Scrum点，使用Chrome的 Scrum for Trello 插件的Estimated Points（预计点数）对估点结果进行记录；
任务粒度控制在8个Scrum点以内完成，如太小、太大应当做合并或拆分处理；
进入迭代To do列表之后任务的评估Scrum点禁止二次修改，如果一个任务实际实现与评估有很大差别，可以通过Consumed Points（花费点数）进行记录，用于总结。

过程操作

可以在Card里面通过创建Checklist来管理诸如复杂任务步骤、子任务或备忘事项等；
如果开发过程开发者对某一个任务实现的规则和流程产生疑惑，则评论并@产品经理，由产品经理进行Critiria的完善；

第四部分

列表规则

卡片可以被归档或者在各个列表（List，常用于表示不同阶段）间移动。

根据开发任务所处的阶段，我们将项目分为6个列表：

Pool（需求池）
To do（本迭代待办）
Doing（进行中）
Finished（已完成）
Delivered（交付验收）
Accepted（验收通过）

使用规则

在迭代会议中，由项目经理按照迭代目标及优先级顺序，将相应开发任务从Pool移动到To do中；
每个迭代的开始是To do，开发者仅需在迭代会议时关注Pool中的任务Card；
在迭代过程中，开发者将处于工作中的任务从To do中移到Doing，Doing中每个开发者不能同时有两个任务存在；
在迭代过程中，开发者完成某个开发任务后，将其移动到Finished，经线上环境测试后移动到Delivered；
在迭代过程中，产品经理应当及时校验Delivered列表中的任务。如若通过则移动到Accepted，如存在问题则应评论并@相关开发者关注，为项目标记Refused标签并移动到To do；
在每个迭代结束之后、下一次迭代会议前，由项目经理负责将Accepted的所有开发任务移动到新建的Spring X（X代表迭代的序号，如“Spring 1”）列表中，并在迭代会议后归档该列表。