精益看板分析：实用项目管理

美好的旧时光

Teodora从1996年开始担任软件开发项目经理：

我们是个5人团队，年轻有活力。我们为银行开发了一套财务管理系统。

要知道在那时，我们只有一套可以访问互联网的电脑，因此我们每天2-3次要查收团队邮件（而不是每个人分别查收）。手机也像下图中你所见到的那样，没有短信、没有WhatsApp，诸如此类。

“那时我们唯一做的项目，就是说项目之间没有资源共用、没有来自其他开发公司的影响。”

“你也记得那个时候吗？ :-)”

作为一名项目经理，我的职能是对项目工作进行计划、跟踪和汇报。客户期望高质量的产品，并且会提供充分的耐心与我们共同分析需求、给我们充足的时间来对需求实现和测试。

小菜一碟，不是吗？

尽管如此，在交付之前我们仍然必须加班来确定所有工作都运行正常。也就是说，估算值不符合实际值。

估算值与实际值是相同参数的不同值。
不要强行或操作使实际值来精确迎合估算值。

生存与可持续需要实用主义

没有哪个项目经理会认为，自己能够在未来20年中，一直带领一个单一的项目，具备一个完全致力于这个项目的团队、与其他开发没有合作、几乎不被打扰、只有一些可以管理的需求变更、并且主要是技术相关的问题。

有趣的是，项目管理方法的复杂度已经随着软件开发的复杂度一同升高，然而用于做正确决策的时间越来越短并且客户的期望越来越高。

我翻看了过去一些年做的笔记，项目经理对他们工作的分享如下：

• 管理影响项目的多种因素很困难，包括需求的清晰度、技术稳定性、团队成员的知识和技能水平、风险、对其他项目的依赖等。
  
  
• 估算方法越深奥，制定良好计划所需的工作量和时间越多，而且计划只能维持很短暂的时间就需要进行变更。
  
  
• 估算、计划、跟踪和再计划带来很高的管理成本，客户不会为此买单，我们只能默默承受。
  
  
• 要求快速估算并随后遵守估算会带来巨大的压力。
  
  
• 项目协调困难

在这种情况中，我们难道不应当改变基于良好估算的项目管理实践，并找到更实用的管理实践吗？

用复杂的方法来处理复杂的情况只会让情况愈加复杂。

用精益看板方法进行项目管理

那么，项目管理的目的是什么呢？ - 确保项目符合干系人（客户和组织）的要求。Right?

这里已经列出了一些

项目健康度的视角
客户 快速交付（时间） 准时交付（可预测性） 有竞争力的价格 质量（得到正确的产品/服务）	组织 项目水平 估算（时间、成本） 可预测性 质量 项目协调 业务水平* 可持续性 服务定位 生存能力

* 关于看板方法的这三项议题，见David J Anderson的谈话和文章。

然后，项目健康度的维度和响应的分析工具汇总如下：

项目健康度的维度
交付时间 前置时间（直方图、控制图） 吞吐率	可预测性 形成服务水平协议（SLA） 到期性能（Due date performance）
成本 增值活动、事务和协调活动的成本 浪费成本（解决bug、返工、等待等） 废弃的需求/故事 流动效率	质量 bug数量 返工工作量和时间
业务 流动效率 工作流动平滑程度（累积流图 - Cumulative Flow Diagram） 形成SLA（直方图、控制图）

点击链接查看每种工具的使用方法及其能够为项目带来的有价值信息。 

如果你需要验证项目健康度是否符合客户或者组织的标准，看一下所需的工具就会注意到，你需要的仅仅是足够多的、完整的真实数据。对于数据，我们必须记住"Garbage in – Garbage out."（错误的前提导致错误的结论）。

不依靠推测得到的估算，真实数据的力量会给你带来承诺的信心并让你睡个安稳觉，因为真实数据降低了无法兑现承诺的风险。

此外，过去你需要发明或更新一种规范的估算方法并试图根据每个项目的特点对其进行调整，使用真实数据使你能够节省所有这些工作量。

 

对于CMMI公司：

• 交付时间（前置时间）主要在面向服务的项目中得以收集，进而满足对SLA管理的需要。然而，对于软件开发项目，这也是非常有用的数据。
  
  
• 在软件开发项目中，通常会记录一项任务完成所需的工作量，而不是前置时间。
  而工作量与时长并不相同。 
  了解不同工作类型或服务分类的真实前置时间分布有利于制订更符合实际的计划。
  
  
• 了解吞吐率，使你能够快速而可靠地估算实现一系列故事或需求所需的前置时间。（通过使用里特定律 Little’s law）
  
  
• 借助于看板墙的工作可视化，极大的促进了项目协作。（以及拉动的方式）
  
  
• 累积流图也许是度量工作步调（节拍）和风险最好的实时指标。