本文共 3840 字，大约阅读时间需要 12 分钟。
自2000年代中期，“”项目管理（PM）一直统治着软件开发方法。它的迭代结构、频繁会议和清晰的层次结构使其成为受频繁变化的客户需求和条件管制的行业的明显选择。因此，大多数团队习惯基于 Scrum项目管理应用管理开发过程。
\\但是，有新玩家——可视化进入该领域，尽管没有那么普及但是带来很多功能。可视化项目管理是精益生产的现代表现，是早期 Kanban工具，尽管它不等同于两者中的任何一个。不像人工方法，可视化项目管理软件从多个方法中吸收元素，以便自动化和简化现有工作流程。打包成虚拟系统，同时提供实时更新、自定义访问控制、数据分析等等相对应的优势。
\\对采用可视化项目管理感兴趣的团队 Leader往往欣赏其价值，但是不能确定如何克服迁移带来的挑战。本文将为团队平滑过渡和最大化新系统价值罗列最佳实践。
\\它如何不同于 Scrum
\\随着 Scrum的发展，团队成员在 Sprint阶段往往真正以筒仓的形式开发项目。他们在 Sprint结束时或者每日站立会议中协作、分享进度，这需要每天抽出时间。通过实时进度的使用和任务可视化，可视化项目管理为整个 Sprint提供彻底的透明度。虽然这不能彻底消除对专用会议的需求，但是将会减少多余或者不必要的会议——那些仅仅用于让人们“了解最新情况”的会议。
\\同样可视化项目管理不太强调完成可交付的产品增量，更强调在时间盒内工作在一个合理生产力水平。这意味着单个故事质量重于绝对进度。许多时候，可视化项目管理软件甚至会限制某段时间特定团队成员拥有的在制品（WIP）的数量（这能在许多基于 的系统中发现，他们用“卡片”移动单个任务通过可复用的工作流程）。重要的是，每次 Sprint生产出可工作的 Backlog项目，但这并不意味着数量胜过质量；团队成员应该能够以最佳生产力工作，给予每个 Backlog项应有的时间和关注度。
\\为什么一些开发人员不喜欢
\\可视化项目管理其根源在于“”—— Toyota开发的管理系统，广泛用在制造业，用于减少浪费。鉴于流水作业线制造业跟软件开发行业之间的细微差别和复杂性，两者之间的隐式并行令很多开发人员感到厌恶。并且这是事实：强迫一些变化无常的事情比如软件开发，使用严格的模型不会生产出积极的成果。
\\过分简单化的 Kanban平台往往是单维度的，不能提供开发团队需要的复杂度，从而保持对用户体验、应用、产品测试结果和不断重新定义商业价值的市场的响应。
\\这些肯定是有效关注点，但重要的是，需要注意并非所有可视化项目管理应用都受限于基本 Kanban。许多已经证明在软件行业（比如 、和 ）有用的可视化工具，在开发团队习惯使用的 Scrum的基础上，结合了 Kanban和精益生产最好的方面，这也是一些用户称它们为“Scrum-ban”的原因。这些混合的项目管理系统结合强大的可视化工具给团队提供了 Backlog、特性测试、代码库和用户故事的全面控制，和从一个集中、响应式的接口工作的能力。
\\但是即使你热衷可视化项目管理理论，实施一个新系统可能看上去令人生畏。需要完成授权、数据传输和集成，更别说培训你的团队适应新的工作管理风格。这不是在公园散步，但是如果有一个可靠的策略，切换到可视化项目管理就不会妨碍团队的生产力。
\\这里有六个技巧可以实现无缝和无痛过渡。
\\- 设立明确、切合实际的期望：由于实时可视化工具将不可避免地意味着更大的透明度和整个团队的问责制，确保在 Sprint期间为每个开发人员设定明确的目标。你的期望应该是切合实际的，应该考虑 Sprint的长度和每个团队成员能够处理的工作量。\\t
- 确保灵活：精益到可视化项目管理能够提供的灵活度，比如将卡片移到不同“泳道”或改变指定用户和子任务的能力。这将有助于团队避免流水作业线的心态。\\t
- 使用可视化工作流程隔离问题领域：例如，你是否注意到故事多次地被“卡”在测试阶段或者因为不满意的实现重新进入后面的 Sprint，使用根源分析确定瓶颈或冗余的原因。\\t
- 重新考虑你计划故事的方式：与其在 Sprint期间将用户故事推给团队成员，不如让他们从 Backlog中挑选故事，填充自己的泳道。这将给开发人员更多的自治和大大减少 Sprint会议所需的时间；你只需要计算故事的总数量，在设置的时间内保持团队忙碌，当所有或大部分故事被挑选后重新聚集团队成员。\\t
- 确保可视化板能够反映你的工作流程：不要让可视化项目管理的新颖转移你的注意力。紧跟团队熟悉的最佳软件开发生命周期。这将帮助他们更快地适应并认清投资回报率。\\t
- 让远程工作人员参与：开发团队成员（或者整个交接团队）在不同时区不同国家工作并不罕见。可视化项目管理平台可以是个强大的工具，能够让远程团队看到最新的团队进度，给你监控他们工作的能力。\
案例研究
\\很多组织已经在使用可视化项目管理工具，以改善他们的团队工作流程和提高品质和吞吐量的质量。下面是最新的案例：
\\西门子医疗服务
\\西门子医疗服务是全球企业医疗保健 IT解决方案的供应商，包括软件开发、安装、托管、集成和为医院跟较大型联合执业团体（group practice）的外包服务。他们的开发运营集中在宾夕法尼亚州，横跨约50个团队，同时在印度和欧洲也有资产。
\\2005年，西门子 HS开始使用 Scrum和极限编程框架来实现自己的目标，包括 Scrum团队、Sprint、评审、回顾和一套成熟的 Backlog流程。他们把敏捷/Scrum作为主要的项目管理工具，经过六年的使用后，在没有巨大加班压力的前提下，他们仍然会遇到发布截止日期的麻烦。
\\西门子敏捷开发负责人 Bennet Vallet说，他们决定在工作流程中引入 Kanban技术以解决这些挑战。“虽然常规 Scrum/XP提供了很多优秀实践，西门子仍然在有能力实现可预测成果方面面临关键差距，运行效率中持续改进的势头和质量步履蹒跚，”他去年二月，“再者，基于相对故事点数的度量指标和速度图不能为该规模的版本开发管理提供足够的洞察力。”
\\他们在转型中赌上了一切，在跨团队和时区并在项目管理层面部署了 Kanban。
\\西门子团队确实可以在 Sprint期间利用一些温和的可视化工作，比如速度图和燃尽图，但是他们发现由于故事类型的不同，这些工具给出的都是不准确的读取。另一方面 Kanban通过专注持续流和在制品，带来了可预测性和“整个价值流系统性问题和模式的洞见。”
\\Vallet发现 Kanban有助于他们更好地具体化持续改进心态，通过限制在制品满足发布截止日期，并促进协作环境的建立。即使是他们的海外团队在 Sprint期间也感受到了更高的参与度和紧跟步伐。他们的周期时间降至43天或者更少——提高了40%——并保持在一个可预测的范围内。
\\Vallet告诉 InfoQ在第一年中他的团队成果是如此的正面以至于他说服领导将所有产品线迁移至可视化项目管理，这会影响三个不同大陆的40个团队。
\\重要的是要注意西门子实施的是 Kanban的混合和更多传统敏捷技术，比如增量故事开发，频繁测试，持续集成（CI），和跨职能 Scrum团队以实现其积极的成果。尽管备受诟病，“制造业”心态有时已经融入到软件开发中，西门子 HS的一个重大发现是：流程改进需要可预测性。
\\BBC全球
\\这一里程碑式的2009年的是由9人团队完成的，在 BBC全球内12个月内审查精益生产和 Kanban对软件开发流程的影响。该研究由 IEEE工程管理赞助，由 Peter Middleton和 David Joyce指挥。Peter Middleton是 Lean Software Strategies的作者，David Joyce是 ThoughtWorks的首席顾问和系统思考家。
\\BBC团队——从历史上来讲习惯敏捷/Scrum开发——从使用两个中央 Kanban板和四个“信息辐射器”开始，这些都是开发团队进度的大型可视化显示工具。团队被指挥在这些板上记录所有进行中的故事，并不再从事任何未记录的任务。
\\跟西门子团队类似，BBC全球团队开始注意到从基于推的时间盒方法向新方法转变是缓慢的，在新方法中只要生产力允许他们就会挑选 新的工作——换句话说就是限制在制品。Joyce和 Middleton注意到周期时间更加一致，和更好的实现持续改进的能力，因此他们认为新可视化项目管理框架是成功的。
\\可测量的成果：
\\- 交付时间提升37%\\t
- 交付的一致性上涨47%\\t
- 客户报告的缺陷下降24%\
与之前 Scrum-only方法（回顾仅仅提供不确定的项目交付的总结）相比，BBC团队实现了传说中的“持续改进（Kaizen）”天堂。
\\尽管不是对每个团队而言，但是可视化项目管理工具可以提供开发生命周期内更大的灵活性和通过更智能的任务分配提高整个产品的品质。成功的迁移并不需要工作流程和业务优先级的全面检修——只有仔细、有意识的策略和自发的意愿才能收获回报。
\\关于作者
\\
Aleksandr Peterson是 的技术分析师。他涉及 gamifiction、CRM、项目管理和其它新兴业务技术。你可以在 上联系他。
查看英文原文：
转载地址：http://gpjyx.baihongyu.com/