华为敏捷 DevOps 实践：如何从 Excel 管理软件的方式中走出来

业界有个小段子，研发不是请客吃饭，是倾家荡产。

是的，研发人员，尤其是从事软件的工程师门，普遍是比较傲娇的，在软件产品没有卖出去形成收入前，软件工程师的投入都是刚性成本。所以，为什么很多软件企业的老板对于敏捷，DevOps 其实并没有深入了解，但是依然很欢迎呢，因为“快”这个词吸引了他们，早一点把软件交付给客户，形成收入，才能让他们早点给软件工程师付工资和薪水啊。对了，软件工程师需要的基础设施（空调，办公位，服务器，计算机，云主机，云存储，各种研发工程工具）也都是很大的一块刚性成本。交付晚了，可能真的倾家荡产，血本无归的。

软件工程师是宝贝，所以华为其实一直坚持，尽量让这些傲娇的宝贝疙瘩们，不要做一些低价值，重复性的工作，浪费钱，也浪费软件工程师建造数字化世界的激情。

我相信，没有哪个软件工程师希望整天整 Excel 表格的，因为整 Excel 表格其实挺无聊低效的。如果不幸在用 Excel 管理软件项目了，本文希望能提供一些方法来一步一步迁移。根据笔者的经验，可以分场景来看看现在专业的敏捷协同管理的工具具备哪些能力，是如何替代覆盖 Excel 的。

如果正在使用 Excel 管理需求

软件产品的需求永远是需要管理的，而需求往往是需要分配给不同的成员去交付，并且希望跟踪需求的进展，是不是在开发中了？是不是可以部署到现网了？因此这个场景是一个多人协作，集中呈现管理的场景，需求管理切忌你看到的和我看到的不一样，所以不能使用本地的任何文件来管理，因为你改了，别人可能就不是最新的。因此这个时候，应该优先选择一个云端的敏捷需求协同管理软件，不要小瞧现在业界的主流需求协同管理工，类似 excel 的列表模式，早就非常普遍了，比如：

• 可以像 Excel 那样过滤，排序，还可以多字段过滤，过滤条件可以保存为常用，换任何电脑都能继续使用；

• 需求作业流是可以流动的，可以从一个状态换到另一个状态，一个处理人再交给另外一个处理人，这个用 Excel 这样平面表格处理起来有些麻烦；

• 需求的分解很轻松，快速新建子需求/子工作项，父子需求关联，需求依赖一览无余，通常还预置了业界通用的需求类型（Epic/Feature/Story/Task）;

• 修改需求的状态，分配成员，简单勾选即可，自动联想或搜索，很高效；

• 还可以在线的社交评论，对需求的意见都可以公开在线讨论；

• 需求的状态变化，处理人或项目经理还可以收到站内信或邮件通知；

• 同时还可以查看操作记录，谁在什么时候改了，改的啥一目了然。

这样，办公室再也听不见“那谁谁，你最新的需求 Excel 给我发一下了“，因为最新的永远在云端，你在任何有浏览器的地方打开就可以了，也包括手机。无图无真相，以华为云 DevCloud 为例，有可拖拽的需求卡片模式，还可以随心切换列表模式。

如果正在使用 Excel 管理迭代计划

无论敏捷迭代，还是瀑布里程碑，软件的开发总是需要一个计划的，给老大，投资者，客户以期望，在这个 Big  Bang 的时代，软件工程师好贵的时代，不可能让你一个劲的放飞自我。计划管理无非就是什么时候交付什么需求或解决那些问题，软件的计划至少得有个开始时间、结束时间和计划交付的内容。Excel 可以做的，但是每个计划时间内的需求或缺陷，要引用其他 Sheet 页，表格引用挺麻烦的，而专业的敏捷软件，很简单的，建立项目的迭代计划，将需求安排到迭代计划，很简单就知道每个迭代计划要交付哪些了。我使用一个华为云 DevCloud 的迭代图当例子，如下。

如果正在使用 Excel 管理缺陷

软件的不可见性和复杂性，决定了软件缺陷是软件生命周期管理永远需要妥善管理和跟踪的。<插个话，不知道

AI 出来后，能不能破软件不可见性和复杂性的这个百年困局，啥时候有集中的大段时间，是可以写写 AI 对于软件开发可能带来的正面和负面影响>。扯回来，一般用 Excel 管理缺陷，就是一行行的记录缺陷，列都是描述定义缺陷的字段：谁发现的？什么类型的缺陷？计划什么时候解决？由谁解决？缺陷当前的进展。

如果正在使用 Excel 开回顾会议之类的

记录一些遗留问题啊，风险啊。这还是一个多人协作的场景，遗留问题总得跟踪解决吧，Excel 只有进入多人协作场景就会有些不便利，这时候，可以使用 wiki 这样的多人协作，轻量级的在线文档协作，团队成员看到的都是同一份，遗留问题的进展自己更新自己的。当然也可以使用很多敏捷协同管理软件提供的看板，建个跟踪任务，管理团队的日常事务也妥妥的方便。华为云 DevCloud 也提供很丰富华为实践的 Wiki 模板，有了通用的模板，格式和标准就可以批量继承重复使用了，如下图：

如果正在使用 Excel 管理测试用例

测试用例至少需要用例名称，编号，执行用例的责任人，前置条件/后置条件，测试步骤，测试预期结果等，而且很多时候自动化的测试用例要能快捷的生成测试执行的脚本的，运行一个测试用例很多时候需要执行很多测试脚本，因此通过 Excel 管理的测试用例除了记录测试用例外，几乎不具备执行的可能。所以测试管理使用 Excel 其实并不是适用，现在很多研发工具软件都有专业性很强的测试用例管理，并和测试执行打通。如下图是华为云 DevCloud 提供的手工测试用例截图，肯定还是比 Excel 管理起来要人性化多了。

如果正在使用 Excle 管理代码提交

通过 Excel 管理代码提交，我最初听到时，是非常震惊的，绝不夸张，下巴还好没有掉。我这大半年跑了国内很多软件企业的客户，还真听说有客户就是在用 Excel 管理代码提交的，因为没有专门的代码配置管理工具，开发人员也不多，就直接把代码合并到代码文件服务器上，因为是文件服务器，不知道谁提交了哪些代码段/代码行，就让开发人员填写 Excel。毫不留情的说，我个人是非常反对这种做法的，应该尽快使用专业的代码配置管理工具或代码托管的云服务。代码是软件的核心，代码的关联是严肃、严谨、严格、严苛的。任何商业化交付的软件，都应该尊敬代码。

写在最后

诚然 Excel 依然是目前最好用的表格办公软件之一，但是在软件研发这个专业的领域内，把自己花费在 Excel 上的时间交给更专业软件工具，是更尊重自己这么多年摸爬滚打的正确姿势。

而且，时代真的在变化，现在市场上的各种专业的敏捷、DevOps 的工具服务，已经在很多企业得到广泛的应用了，如上面介绍的主要 Excel 场景，都已经稳稳的支持得更好了。

为了让你的价值得到更大的发挥，可以尝试从 Excel 中一步步走出来。

软件工程师是数字世界的构建者，加油，致敬！