让你的故事墙动起来

在敏捷项目中，我们经常提到一个工作流，这个工作流就是故事墙，通过对故事墙的维护，我们可以看到每个迭代当前的状况。

一个成熟的敏捷项目，故事墙具有完全适合于项目的工作流，项目成员会自主的维护故事墙，而敏捷教练基本可以不用过多的关注此类事情。

我也见过很多毫无生机的故事墙，他们放在那个角落里，犹如被人遗弃的街角，墙上还画着过去的涂鸦。下面为大家分享一下我们的工作流故事墙是如何一步一步动起来的。

当时项目遇到种种困难与问题，我们不得不进行变革，按照当时的情景，借助敏捷工具tapd，我们决定使用敏捷开发，并且得到大家的一致认可。

这时的工作流及其简单，实例如下：

该项目是公司内部的一个后端项目，项目前期主要是进行增量迭代，当时也没有太多规范性东西，所以一开始的工作流比较简单。我们对故事墙也只是简单使用而已。

随着项目时间推移，一个普通的后端项目开始纳入更多的功能，公司全面使用，各种新需求与优化蜂拥而至。后端项目开始升级为业务中台。于是我们经过优化，形成了下面工作流：

产品不停输出，迭代池留存大量功能，同时迭代的版本数量增多，有段时间我们4个迭代版本同时进行。

大家都能切身感受到迭代的增加，故事墙变的丰富起来，如果不及时维护迭代墙就会变得混乱不堪，在敏捷教练的指导下，大家开始自主维护好故事墙。

我们只需要看一下故事墙就知道现在项目的迭代情况，特别是在多个迭代同时进行的时候，可以说每天的故事墙都很生动形象。

慢慢的我们将故事墙设置为首页，进入敏捷工具的第一时间就是查看故事墙，如果遇到有同事忘记维护的，大家都会相互提醒，项目成员已经可以进行自管理。

经过敏捷开发的摸索和实践，这套工作流虽然简单，但是展示为故事墙却非常直观好用。

后来新的项目，我们对该敏捷开发模式和工具配置进行复制，并且优化后，做了一套简单的通用规范。

可是每个项目总有自己的特点特色，于是根据每个项目的不同，进行私有化改动，比如我们增加了研发数据库设计评审，测试用例评审等流程。我们不进行限制，只要符合当前项目的，都可以调整。

不得不说，我们的一个普通团队，要实施敏捷还是比较困难的，所以大多数提议都由敏捷教练提出，由项目成员共同参与讨论，敏捷教练进行指导，最后制定出让大家都赞同的方案。然后经过不断的复盘进行调整优化。

所以如果在项目团队比较弱的情况下，还是需要有人进行指导和督促。

故事墙只是敏捷中的一个板块，有时候看起来可有可无，可是当认真使用起来的时候，真的非常棒，每个人都参与其中，享受敏捷思想在项目中的成果。