作者：terry
从2019年初，我们团队准备开发一款适合研发团队使用的敏捷开发管理工具，那时候我们也在思考，到底什么样的工具才算是优秀的研发管理工具，研发管理的场景、方法和流派有很多，市面上关于研发管理工具的产品也是层出不穷，我们从哪里入手才能真正帮助研发团队提高研发效能?基于以下两点考虑，我们选择了从敏捷开发管理进入：
1. 敏捷开发自1999年以来，经过20多年的发展，已经被大多数开发团队所接受，近几年devops的流行，更是把敏捷推向了更高的位置，国内太多的团队需要做敏捷转型。
2. 敏捷开发在中国落地的专业度还不够，以至于出现了“中华田园敏捷”的说法，中国的开发者需要一款简单易上手的、专业的敏捷开发管理工具，来帮助他们在团队中更好的落地敏捷。虽然只靠一款敏捷开发工具并不能帮助企业在敏捷转型中成功，但好的工具却能让企业敏捷转型事半功倍。
专业的scrum流程管理
在scrum guide中已经对于scrum过程中的活动、事件、产出等定义的非常清晰，这里不再重复，只想重点解释一下在落地scrum过程中经常被忽视的两个问题。
1. 绝大部分团队在实施scrum过程中只重视迭代管理，不重视版本管理，当然这已经超出了scrum本身的范畴，但是好的研发管理中应该是迭代管理和版本管理并存，他们之间是一个互相依赖的关系。
迭代管理是针对scrum团队的，它定义的是一个时间盒的概念，用于团队容量管理和进度管理，对于不同的团队来说，明确在一个迭代的时间盒内的产出，这个产出最终以迭代review为标准，通过了review并不意味着一定发布出去。
版本管理是针对产品的，它定义的是一个批量的概念，用于版本进度管理和交付风险管理，明确在一个版本中最终的交付物。目前市面上大部分敏捷开发管理工具，都能够很好的支持迭代管理，却忽视了版本管理。
图1 worktile agile中的版本管理
2. 在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. 扩大场景覆盖，当下我们的关注点在于如何做好敏捷项目管理和测试管理这两个场景上，未来不排除还会延伸到别的场景，比如多项目组合管理等。
-完-
