简说敏捷转型可视化和可视化敏捷方法

一个项目通常需要很长的时间才能完成,客户经常在描述他们期望的东西后希望可以尽快获得。因此,频繁地给干系人展示项目已经实现的东西就显得很重要,确保他们被及时告知当前项目的状态。在敏捷开发中,我们将能够反映当前开发状态的信息展现统一称为信息发射源,这是一系列高可视化的展示信息的方式,数据表格、大图表、图形以及数据概要信息等,通常在一些高流量的并且最大曝光度的地方被展示。从物理形态上看分为电子(通过互联网分享)和物理(手工写在物理看板上)两种。

在服务企业研发团队的过程中,我们发现不少团队碰到了类似的问题:

* 你经常在思考究竟哪些工作是最重要的?如何避免被无穷无尽的项目与工作淹没?

* 团队成员声称完成了自己的大部分任务,但团队实际交付的需求却寥寥无几?

* 由于某些问题导致工序一直处于等待状态,怎么识别和处理这些延迟?

* 成员之间不知道互相都在干什么?各自鸵鸟式地进行着工作。

* 管理层或职能经理希望知道团队最近的工作重点或是产品开发的进展。

有一句话我本人很认可:看到是改进的开始,让可视化释放生产力。以下简单概括介绍几个常见的可视化工具。其实,每个工具都可以单独来个长篇大论写一个敏捷可视化工具系列。

01 Sprint信息页:我们要让人们了解我们在做什么,这件事非常重要,否则就会有人发出抱怨,甚至对我们的工作作出臆断。可以在wiki上建一个sprint 的页面, spring相关的信息,如每日例会的时间、地点等写在上面,也可以打印出来贴在团队房间外面的墙上,路过的每个人都可以读到。     02 产品待办列表:我们要实现的功能及优先级安排,越靠近列表上面的优先级越高,颗粒度越细。在拥有敏捷价值观的组织中,可以让团队按客户业务价值优先级交付工作,随时都可以被更新。而不必被卷入所有的需求都很重要的漩涡。

03 故事地图(故事映射/特性看板):是大量待处理特性(大故事)的可视化方式,可以说是在看板上展现的产品愿景和路线图,能够让团队时刻保持共同的目标而不至于偏离,并且对较大的用户故事(史诗/特性)的优先级可以随时做出调整,可谓是战略级的视野。

04 看板(任务看板)根据看板中功能的颗粒度不同,分为产品级(通常只有用户故事)和团队(通常就是具体的任务):看板这个概念源于丰田公司生产系统的精益思想,它是一种可视化的管理系统,目的是对生产过程做出渐进的变革,当可视化的方法与敏捷软件开发模式结合,就产生一种叫敏捷看板的概念。 每个人都可以一目了然地了解进度和进程;在 WIP (限制在制品)原则下,看板可以进一步提升研发流程的效率,在当前任务完成之前,禁止开启新的任务,让团队在有限时间、有限资源内更加聚焦于优先级高的任务。

05 累积流量图:是看板方法里的核心度量之一。可以很好地反映工作项在每个流程环节的流动问题或者说跟踪一段时间内项目中处于不同状态的需求累积数量,有助于跨迭代识别潜在的瓶颈,监测项目进展。

06 燃尽图(燃起图):燃尽图可以呈现团队处理用户故事进度,是一种对工作完成情况可视化展示的工具,燃尽图可显示每次迭代工作剩余工作量和可用剩余时间。让每个团队成员都能够看到最新的进度和更新状态,团队需定期更新燃尽图以保持其准确性。存在两种形式的燃尽图,Sprint燃尽图说明迭代的剩余工作量,而发布燃尽图则说明某次发布的剩余工作量。当然如果特别关注缺陷的解决情况,可以将缺陷单独划分出来维护一个缺陷燃尽图(这里省略)。

迭代(冲刺)燃尽图,横轴通常以天为单位,纵轴为迭代中团队成员承诺工时之和。

 

发布(版本)燃尽图,横轴通常以迭代为单位,纵轴为本次发布的故事点数之和。

07 团队速率图:开发期间所有Sprint的速率的历史统计,为团队做Sprint计划提供了量化参考,便于后期的Sprint或发布的效率预测和团队能力改进及绩效的评估。

 

写在最后:在组织中,让敏捷可视化不仅可以帮助敏捷组织内部在交付中分享信息,改进工作,提高效率,同时也可以汇总成对敏捷转型成果的有力证明,帮助管理层继续深化敏捷转型并将敏捷文化永久植入组织。

上文提供了一些敏捷可视化示例,可以改善团队协作和沟通,塑造团队行为,供敏捷软件开发环境中工作的人员和团队参考。这里没有敏捷或Scrum的理论解释。 当然,阐述的内容并不是最佳实践,需要根据团队的背景和需求做调整。可以以任何团队觉得有用的方式整合不同方法。 可以先进行实验和评估。祝大家阅读愉快!

END

希望能在评论区学习到大家的经验和想法~

如果对相关内容感兴趣可以关注我的公众号:捷伴行Agile。公众号与博客持续同步更新。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

error: Content is protected !!