如何用Worktile 实现研发项目管理 —— BB-Talk #003回顾
前言
BB-Talk 是什么？
BB-Talk 是由Worktile 特别推出的线上分享活动，聚焦互联网时代更高效的工作流，横跨TMT、电商、律师、教育等各行业，覆盖研发、产品、设计、市场、运营、HR、行政等各职业。
每期邀请一位相关领域的大牛嘉宾，通过微信群内的语音、文字、图片等形式，分享干货、自在交流。
本文为7月5日BB-Talk 第二期嘉宾分享与互动提问的总结。
本期嘉宾
贺天卓
Worktile 前端架构师，10年从业经验、参与开发过多个RIA 复杂应用系统，对复杂前端应用构建和性能调优有过大量实践。
专注 Web 开发领域技术，对 H5 及前端相关 MVC & MVVM 框架有较多的使用经验和思考。
内容概要
BB-Talk 走过两期之后，对于研发，我们了解了Scrum 理论的套路、摸清了敏捷实践的坑，也更加清晰地认识到工具扮演的角色已经不可或缺。
越来越多的参与者开始问询，在研发项目管理当中，怎样才能让Worktile 的作用得到更好地发挥、帮助大家提高团队工作效率？BB-Talk No.3 将为你带来最真诚的回答。
分享内容
这次的分享主要是结合前两期敏捷和Scrum 的理论课程，为大家讲述现在Worktile 研发团队是怎么使用Worktile 来进行敏捷研发。
如果直接告诉大家 Worktile 团队是怎样做会导致文章很枯燥，而且知其然不知其所以然，每个公司项目情况都不一样，大家看完后也很难针对自身的项目特点进行取舍，所以在讲如何做之前，我们先聊一聊研发管理的两种极端的项目管理方式。
第一种：没有流程，反复无常。
需求杂乱无章，销售人员、产品经理没有想清楚需求就提交给了研发人员，新需求、变更需求随时随地的出现；口头需求多，没有记录；
研发一团乱麻，分工不明确，底层代码被随意改写，源码分支混乱，编码没有规范。
流程混乱，测试人员拿到过期的版本，产品发布部署总是出现低级错误。
第二种：严刑峻法
有大量的规范和标准，和全面覆盖的文档，但不知到规范背后的原因
过度的架构设计和约定
会议多，效率低下，最后只有用高强度的加班弥补开发时间
测试与研发过于分离，产品质量完全是由测试人员保障
这两种不好的研发管理方式第一种过于混乱，第二种过于死板。从最开始的没有管理，到后来的管理过度，都已经不适合现在的互联网、软件项目研发的需求了。
Worktile 作为一个互联网产品，要通过快速的迭代发布新功能来验证其商业价值，也要通过快速的冲刺来与竞争对手拉开距离。
好的研发管理应该是能够动态适应公司定位、市场环境、团队能力、产品生命周期不同阶段等等的一个动态管理过程。
所以我们利用 Worktile 自身的“任务看板”和各个模块，搭建了一套“可见性好、可逐级检查，可动态改进适应” 的研发管理流程。
一.合理的项目组织架构
Worktile 是一个非常灵活的工具，对于团队数，项目数和团队成员的数量都没有进行任何限制，很容易产生一些过大的项目，这样会导致一些管理上的混乱，Scrum建议的单个团队成员数不宜过多，那么对于一个单个部门大于 10人的组织架构怎么能敏捷起来呢？
这次主要是讲研发管理，虽然刚才产品组也在研发部内，但是此次还是关注狭义的研发管理所以不展开讨论。
上面说到在Worktile 里是不限制项目数量的，而且一个团队成员也可以同时加入多个项目。所以建议大家不要在一个公司里申请多个公司或创建多个团队来工作，这样会导致后期的 “任务”和“成员”被隔断的情况。
这张图里面的横向就是不同的项目，右侧是需要加入到这些项目中的具体团队成员。
反馈收集项目比较特殊，全公司的人还有我们的一些狂热粉丝在这个项目里为Worktile 出谋划策。
二.团队角色选定
Product Owner 产品负责人，目前在Worktile 是由整个产品组担当，他们输出统一的Backlog 并对其价值排序。而Scrum教练是由开发组的负责人来担当。
需要说明的是，Product Owner 和Scrum Master 都不推荐同一个人来担任，因为Product Owner 是代表客户利益，而Scrum Master 主要带领团队提升研发产能。
三.任务看板管理
Worktile任务看板中三种主要元素构成：
任务看板（Board），用来放置项目相关的需求、任务等工作内容；
列表（List），代表内容所处的不同阶段；
任务卡片（Card），代表各种工作任务。
在这里我们直接使用 Worktile Web 项目举例说明
【收件箱】存放所有希望开展的工作内容、
工作内容来源主要有 产品组的产品规划和用户反馈的bug、问题和建议组成。
由产品负责人员在每个Sprint 迭代开始的时候重新排定优先级。
【要做】
由产品负责人员从收件箱放入，并排定优先级
【设计中】
由产品负责人员配合设计师来完成该阶段的工作。
【开发中】
由具体研发工程师从【要做】和【设计中】选择自己要开发的任务卡。
【完成】
由研发工程师自测完成后，移动到【完成】列表
【测试过】
由产品负责人和对 【完成】中的任务进行测试，测试通过后移动到 【测试过】列表。
【部署】
测试通过后，运维人员会对功能进行部署，部署后，从【测试过】中移动到【部署】列表。
一个功能需求从 收集进入到->产品设计->界面设计->开发->测试->部署都在一个项目中完成。
最后部分值得介绍给用户的功能卡片，等到 “部署”后，会“拷贝”到 “运营部的项目中”，运营部同事会对新功能撰写新功能介绍。
最后迭代结束时 “部署”的任务会被“归档”到历史中。
这里需要注意“任务列”不要是越多越好，只有阶段性的推进才有必要创建任务列，有一个判断的标准就是，只有当任务有了新的交付物或者需要新的接收人时才是创建一个列表的时候。如果只是 任务本身状态的细微变化，就不要创建任务列。
四.任务拆分粒度和强大的检查项、标签：
任务的拆分和设置是保障项目顺畅推进的重要因素。
• 应该拆分1-2小时，不能出现超过 8小时的任务。
• 如果任务牵涉到多人任务，应该通过检查项细分到人。
• 被其他任务依赖的需要设置截止时间且适当提高价值排序。
检查项，能够细化任务，还有其他一些用法可以更有效地提高任务的执行效率
• 定义完成，避免研发和产品对何为完成产生歧义。
• 分解任务步骤和通过@符号指定具体负责人
• 轻量级的子任务
• 检查依赖的物料文件是否准备完备
• 也可以进行 列表记录，比如头脑风暴记录
标签能够在看板上直观的感受到卡片的状态
• 定义任务类别：功能、Bug 修复、优化……
• 重要性：不重要、重要、重要且紧急……
• 处理结果：无法重现、无法实现、无法解决、被阻塞
五.日程不光是会议
日程和任务定位不同，日程没有执行者、没有完成状态，日程更加强调时间因素和参与者，体现为提醒而非执行。Worktile 日程支持以日，周，月，年四种维度的重复日程，目前我们主要用在以下场景中
• Sprint 周期例会
• Roadmap 阶段里程碑
• Team build 的安排公告
• 个人请假告知同事
六.Scrum 仪式会议选着开
我们现在的一个Sprint 周期为 2周，一个迭代。 在2周时间内,除了“小于30分钟的任务”和“紧急任务”，不会添加新任务到此次Sprint 中。
值得一提的是，我们将Sprint 评审和计划会议合并，评审演示上期冲刺完成情况和效果，马上讨论接下来的工作内容。我们没有每日站会，因为团队成员间对“谁做了什么”、“接下来要做什么”通过看板都很清楚，只有当任务被阻塞的时候，会下班前一对一进行沟通。
每天下班后测试过的功能会自动发布到 内部测试服务器中，第二天大家都会对昨天开发的功能进行使用测试。
七.文档不是没有必要的
Scrum 不推崇文档，但在实际的项目开展中，必要的文档还是对规范开发很有帮助，目前我们撰写以下这些文档，便于新员工参与工作，也积累工作经验
八.文件
目前在研发项目中，文件功能只作为附属模块，主要存放设计稿件。
####九.统计
统计模块是项目趋势的仪表盘，主要是显示总体项目情况，不同的项目类型趋势会有不同的特点。像产品型的项目，因为需求不是初期就设置好的，所以并不能出现燃尽的效果，因为需求是不停的发生的。
为什么Worktile 适合项目管理？
因为灵活、可适应：
- “看板”视图，将 Scrum 中的 “待做任务”和 “团队成员”进行组配
- 提高了团队成员和项目进展的透明度
- 团队可以通过多个迭代，调整任务列来适应不同项目类型和成员分工
- 通过细分任务控制 任务的复杂性和进度不可预测性
- Worktile 将工作信息结构化，不采用平摊式的信息流，以任务为核心链接工作所需的其他信息
- 成员间清楚的知道每一个任务是由哪位成员去完成，截止日期是哪天，以及最新进展
- 每一次对话，每一份文件都有相应的任务背景，将无用的信息排除在外，让我们更加专注于任务本身，提升团队效率
Q&A
Q1：一个任务既要研发又要测试，分配的时候需要把两个人同时加进来吗 @王霜
A：我们现在的做法是只有在任务测试完成的时候，测试人员才会把自己的这个头像加到测试完成的这个上面去。因为每一个大部分的研发任务都需要测试，所以在起始的时候就把它加上去的话，会显得这个具体的负责人是不是很明晰的。
Q2：您好，听完您的讲解，感觉成员的自律性以及负责人对时间和节奏的严格把控在敏捷开发中占用很大比重。除此之外，还有那些属于敏捷开发中举足轻重的因素？ @REVEES
A：Scrum 本身就是一个希望大家都尽量向前冲刺的做法。他的比喻是大家都是橄榄球运动员，所以团队成员的自主性肯定是比较重要的，但是我觉得啊，就是他给了成长的这个步骤。就是如果哪怕全是大牛吧，他也有一个磨合期，所以呢，它其实是在不断的调节任务和迭代的关系。
Q3： Worktile Web 项目的 任务列表上，关于测试，为什么没有 测试中 这个列表，而只设计了【测试过】， 这种方式有什么好处吗？ @周补刀
A：Worktile Web 的测试更多的是一些点击测试和业务逻辑测试，所以“测试中”是一个非常快的过程，目前没有设置。
Q4：任务拖拽过程，是前面列表往后推，还是后面从前拉 @王霜
A：目前是从左往右拖。
Q5：:是否考虑前沿领域VR 设备与Worktile 的结合，以突破当前PC 与移动端的条列数量限制，增强大型项目的直观进度把控感。 @李杰
A：有好的形态肯定会做，这个需要产品同事来跟进，Worktile 就是想让协作变得又酷又简单。
