不可否认，敏捷确实于左岸更合适，但我依然坚信，右岸也可以做敏捷。敏捷不仅仅是一个IT范畴的事情，它是一种思想，这种思想可以用于指导各行各业，提升其工作效率。自年初，我从左岸项目将敏捷引入代理财政组件，在教练的指导和自己的摸索下，至今也已迭代了两三个版本，现在也是时候做一些总结了。
第一次引入敏捷时，我们竖起了白板，开起了计划会和回顾会，学着将需求转换为故事卡，模仿着所有自己能看到“敏捷”行为。但试行了一段时间后，发现似乎并没有对工作效率有什么明显的提升。于是团队内部也开始出现一种声音：敏捷还是不适合右岸啊，没有觉得敏捷有什么用处。我自己也开始动摇起来，难道敏捷真的只是一个噱头？
回过头看看左岸项目，他们实行敏捷后团队整体氛围、积极性、精神面貌确实与之前有明显不同，难道是我们没用对“敏捷”？带着这些疑问，我开始翻看各种敏捷资料，开始找魏教练请教，正好中心也在搞一些敏捷培训交流的讲座…随着了解的深入，我开始意识到，我们似乎只是学到了表象，却没有理解敏捷的内在思想。
拿故事卡拆分来说，它其实强调的是PO要站在用户的角度来思考、设计这个系统。作为用户你最想要什么，你的需求是什么，你希望系统能帮你做些什么？只有从用户的角度来考虑这个系统，才有可能做出用户真正想要的系统，也才能准确的定义所有故事的优先级、故事点等。如果仅仅是将原有的需求项“搬到”便签纸上，又怎么实现“交付有价值的软件使客户满意”呢？
再说站会和看板，这是大部分初做敏捷的团队最先想到和引入的东西，我们也不例外。但是一段时间的站会开下来，我发现看似满满当当、均匀分布在不同甬道的便签纸，有时候一两天居然没有一点变化。说它堵塞在哪个环节吧，从看板来看，也没见哪个甬道任务特别多的。说它运转正常吧，但实际上没有流动性，经常卡个四五天没有动静，一动却又是一大片任务卡同时移动。不正常，不合理。于是我请来魏教练帮忙把脉，又看了一些看板和站会相关的文章，慢慢发现了问题所在：我们虽然也用了故事卡，用了看板，但我们还是旧的开发思维，需求评审完后就把所有任务一次性全部分配下去，开发人员也就一次性把所有任务全部领到对应的甬道，出现任务卡长时间不流动也就正常了。这个时候我才真正理解了什么叫“限制在制品”，才真正理解了什么叫“加强流动性”。从那以后，我们团队就约定，所有的任务卡，一次只领一张，做完移动之后才领下一张，保证每张故事卡（也就是每个独立功能）都能以最短的时间流转至用户验收环节。看板看似简单，实在内涵无穷，其他问题就不一一赘述，但每一个问题的解决，都能让我们对敏捷的思想加深一分认识。
最后说到回顾会。这是我做敏捷之前就一直在坚持做的一件事，也是我认为非常重要，非常有必要做的一件事。回顾会可以让团队能经常回过头看看曾经走过的路，犯过的错，总结经验，吸取教训，这样才能让团队在未来的每一步走的更踏实更稳当。但我们之前的回顾会更多的是反思错误，这样难免会让整个会议过程比较压抑，使意志不坚之人，甚至可能会产生深深的挫败感，也不利于整个团队氛围积极向上，保持活力。引入敏捷之后，我们也试着在回顾会上对一些过去做的好的事情进行总结，鼓励大家；对于团队未来的前进方向和组织措施，征集大家意见，共同出谋划策；对于达成的一些共识，写下来贴在看板上，提醒大家遵照执行…
除了上面这些，还有一些在规划中的事情，例如电子看板、自动化测试、devops集成等等，但限于一些外部原因或者暂时也有一些可以替代的虽然效果稍微差点的做法，一直还未实施起来，这也是我们下半年打算重点推进的事情。但不管任何工具、方法论等，都不能只学表象，要去理解其背后所隐含的深刻道理，并将之与我们的工作结合起来，最终找到那条属于自己的敏捷之路。
网友评论