打造Worktile敏捷开发管理工具的思与惑

从2019年初，咱们团队准备开发一款适合研发团队使用的敏捷开发管理工具，那时候咱们也在思考，到底什么样的工具才算是优秀的研发管理工具，研发管理的场景、方法和流派有不少，市面上关于研发管理工具的产品也是层出不穷，咱们从哪里入手才能真正帮助研发团队提升研发效能？基于如下两点考虑，咱们选择了从敏捷开发管理进入：

1. 敏捷开发自1999年以来，通过20多年的发展，已经被大多数开发团队所接受，近几年DevOps的流行，更是把敏捷推向了更高的位置，国内太多的团队须要作敏捷转型。
2. 敏捷开发在中国落地的专业度还不够，以致于出现了“中华田园敏捷”的说法，中国的开发者须要一款简单易上手的、专业的敏捷开发管理工具，来帮助他们在团队中更好的落地敏捷。虽然只靠一款敏捷开发工具并不能帮助企业在敏捷转型中成功，但好的工具却能让企业敏捷转型事半功倍。

专业的Scrum流程管理

在Scrum Guide中已经对于Scrum过程当中的活动、事件、产出等定义的很是清晰，这里再也不重复，只想重点解释一下在落地Scrum过程当中常常被忽视的两个问题。

一、绝大部分团队在实施Scrum过程当中只重视迭代管理，不重视版本管理，固然这已经超出了Scrum自己的范畴，可是好的研发管理中应该是迭代管理和版本管理并存，他们之间是一个互相依赖的关系。

迭代管理是针对Scrum团队的，它定义的是一个时间盒的概念，用于团队容量管理和进度管理，对于不一样的团队来讲，明确在一个迭代的时间盒内的产出，这个产出最终以迭代Review为标准，经过了Review并不意味着必定发布出去。

版本管理是针对产品的，它定义的是一个批量的概念，用于版本进度管理和交付风险管理，明确在一个版本中最终的交付物。目前市面上大部分敏捷开发管理工具，都可以很好的支持迭代管理，却忽视了版本管理。

图1 Worktile Agile中的版本管理

二、在Scrum Guid中定义一个迭代中的四个活动，即迭代计划会议、每日立会、迭代评审会和迭代回顾会，咱们发如今大部分敏捷团队中其实只有前三个活动，而自动忽略迭代回顾会议，偏偏相反，迭代回顾会是Scrum迭代实践中的最后一环，也是最重要的一环，迭代回顾会将整个迭代造成了闭环。Scrum小组都是自组织的，只有经过迭代回顾会不断的总结问题，提出改进项，才能帮助团队不断精进。

图2 Worktile Agile中的迭代回顾面板

什么才是真正的Kanban

Kanban理论已经存在了很长的时间，其适用范围也从最初的车间管理，到如今的硬件制造、软件开发。在软件开发领域内，不少团队都在使用Kanban管理本身的团队，有的使用电子看板，有的使用物理看板。Worktile团队在作电子看板上已经有了7年的经验，一直以来咱们也在探索，到底什么样的看板才是真正的Kanban。在我看来，一个真正意义上的电子看板系统，要可以帮助团队达到如下三点：

• 帮助团队可视化整个链条的价值流动
• 帮助团队识别价值流动中的风险点
• 帮助团队度量价值流动中的各类浪费，并加以消除

基于以上考虑，在一个可视化的电子看板系统中，至少要具有如下一些能力：

• 可以清晰定义在制品WIP
• 可以清晰定义在制品限制WIP Limit
• 明肯定义DoD
• 支持多泳道分割
• 在制品流转中某些操做自动化
• 达到某些风险点时，在制品可以高亮显示

图3 Worktile Agile中的Kanban管理

需求管理如何作

不论是采用哪一种敏捷方法实践，需求管理都是敏捷开发中很是重要的一环。Scrum中定义了两个重要的概念： 产品待办事项Product Backlog 和 迭代待办事项Sprint Backlog ；Kanban中通常采用在制品WIP的概念。

在Worktile Agile中，咱们决定采用业界你们共识的三级需求管理体系，这种表示方式并无一个真正意义上的标准：

• Epic：史诗，表示比较大的特性，开发周期通常是1-3月，用于产品路线图的规划
• Feature：特性，表示相对小一些的特性，开发周期通常是1-3周，用于产品版本的规划
• User Story：用户故事，最小的开发粒度，开发周期通常是1-3天，在Scrum中用User Story来做为Backlog，在Kanban中能够用User Story做为WIP。

图4 Worktile Agile中的Epic、Feature、User Story三级需求管理

联动起来才有价值

在研发场景下，对于团队成员来讲常常整理需求/缺陷是个常态，另外在基于单个工做项沟通时，每每会说起另外一个工做项，做为高效的研发管理工具，要可以清晰的定义工做项之间各类可能的关系。Worktile Agile中咱们定义了超过10种工做项之间的关系：

• parent：定义工做项之间的父子关系
• duplicates：表示两个工做项之间的重复关系
• blocks：表示两个工做项之间的阻塞关系
• 其余的如mention、clone、causes关系等

只可以定义关系还不够，Worktile Agile还作到了在发生某些操做的状况下，自动生成他们之间的关系，若是团队成员在某个工做项评论中提到了另一个工做项，则会在他们之间自动创建一条mention关系。

图5 Worktile Agile中定义工做项之间的关系

工程化不可或缺

在研发管理过程当中，项目管理是很重要的一块，但项目管理自己并不会关注工程化的过程，在我看来，项目管理和工程化实践是确保研发顺利的两个支柱，缺乏哪个都会形成不可预知的影响，把工程化数据与管理过程结合起来，将会极大的减少管理成本，提高研发效率。

工程化的过程环节众多，涉及到的工具数量庞大，如代码托管、单元测试、代码扫描、流水线、打包、制品、部署等等，在Worktile Agile中能够经过REST API的方式，把工程化数据发送到工做项上面并与之关联，这样对于开发人员能够清晰的看到每一次提交涉及到的工做项是哪一个，触发了哪些构建，构建的结果如何，以及当前工做项部署在了哪些个环境。（注：REST API正在内测中，目前还未对外正式发布。）

图6 Worktile Agile中接入DevOps数据

让一切皆可测试

在User Story的INVEST原则中，明确表示一个好的用户故事要必须是可测试的Testable。敏捷开发过程自己是频繁迭代、周期性强而且可以及时、持续地响应客户的反馈，如何正确创建测试策略，确认客户的需求能得以实现而且确保及时的交付最终产品是值得思考的一件事。

在Worktile Testhub中，测试人员能够轻松编写测试用例而且制定相应的测试计划，同时每一个测试用例也能够用Worktile Agile中的User Story关联，让开发人员和产品经理知道这个User Story会如何测试，同时测试的结果也会及时的与Worktile Agile同步。

图7 Worktile Testhub自动生成的测试报告

关于将来的一点想法

最后，简单的谈谈对于将来的一些想法。对于当下来讲最重要的事情把现有的产品进一步打磨好，关于将来咱们也在探索如下几个可能的思路：

1. 简化手工操做，将来必定是智能的世界，在研发管理工具中，要尽量的简化手工操做，让工做自动化起来，对于开发人员来讲更是如此，他们宁肯编写一段自动化脚本，也不肯一遍一遍的执行重复性的操做。
2. 扩大人员覆盖，目前Worktile研发产品矩阵已经覆盖了需求人员、产品、设计、研发和测试等人员，将来咱们还会进一步加大人员的覆盖面，让更多的团队角色能够在Worktile中完成他们的工做，好比对于中高层管理人员、PMO等。
3. 扩大场景覆盖，当下咱们的关注点在于如何作好敏捷项目管理和测试管理这两个场景上，将来不排除还会延伸到别的场景，好比多项目组合管理等。

Worktile 官网：worktile.com

本文做者：Worktile CT0 Terry

文章首发于「Worktile官方博客」，转载请注明出处。