写给项目管理办公室(PMO)的一封信

前几天有个潜在客户发给我了一些他们所编写的敏捷流程，我给出写了很多我对于PMO和敏捷软件流程的理解，脱敏之后也在这里分享给大家。

以下我将以一位敏捷教练或顾问的角度来说一下三个方面的内容：

• 什么是敏捷开发流程？
• 一个流程的定义者（或PMO）将如何从敏捷中获利？
• 建议阅读

好了，正式开始：

什么是敏捷开发流程？

• 敏捷是否存在流程？

  • 存在
  • 敏捷的流程应该是企业内团队最佳实践的总结，总体来说每一个团队不应该拥有相似的流程。每一个团队可以共享一些最佳实践的集合。

• 是否存在标准的流程之说？或具体的指导性的流程？

  • 不存在标准流程之说，但存在最佳流程与工程实践集合的工具包
  • 关键点在于标准化的过程不应该作为团队的限制，而应该是支持团队实现交付价值的支持。

• 敏捷流程区别于CMMi和ISO9000之类的流程区别点在哪里？

  • 最大的区别是在于敏捷是基于原则的而CMMi或者ISO9000之类的事物是基于规则的。
  • 敏捷过程或流程是以适应性为前提，但CMMi或ISO9000是以预测性为前提的。这是从根上的区别，但并不是说敏捷过程和CMMi不可相容，我有让团队实施敏捷同时通过CMMi3级考量的过程方面的经验。详细内容参见：建议阅读

• 敏捷开发流程应该是什么样子的？

  • 敏捷开发流程应该不是文档一份，而是团队时刻坚守的纪律。
  • 你可能会说，这是先有鸡还是先有蛋的问题。那么是否先有一个这样的文档再形成团队的纪律呢？我的答案是不能这样，我们需要有经验的敏捷教练对敏捷过程进行导入，而不是形成这些文档，强制让大家实施。如果这么搞的话，和CMMi又有什么区别？当然能够从团队内部形成纪律再沉淀成为标准流程这种事情需要非常有经验的人来实施，不是说拥有敏捷经验就能来干的。详细内容参见：建议阅读

• 进化过程是什么样子的？

  • 详细内容参见：建议阅读

• 典型初级阶段是什么样子的？

  • 初级阶段应该是对交付价值周期的要求，比如是需求提出1个月内就可以在生产环境下使用。
  • 强调完成的定义，强调团队规则的进化，强调潜在可交付软件增量。
  • 使用一些工具可以让团队无痛的产生一些数据，然后进行统计测量。
  • 列出一些最小集合的实践，比如要求迭代不超过4周等等，可以全部借鉴Scrum框架中的内容，但不可以用其他方法论进行填充，比如极限编程。
  • Scrum Master的挑选必须非常仔细，平时的团队领导不要成为Scrum Master。

一个流程的定义者（或PMO）将如何从敏捷中获利？

• 什么是敏捷真正有效果的原因？

  • 敏捷真正有效果的原因在于其强大的落地能力，首先很多敏捷的实践来源于一线团队的经验总结。其次敏捷把人的位置列为软件开发的重要位置，而不是过程。

• 一个敏捷的项目管理办公室与之前的软件项目管理办公室区别是什么？

  • 敏捷：结果导向和转型动力
  • 传统：过程导向和关注标准

• 挑战是什么？

  • 我们的企业所处的进化位置与员工以及社会的匹配度
  • 企业可能是命令控制型的、追求能力型的、协作型的、养育型的一个。比如是追求能力型的，但员工已经进化成为协作型的或需要养育的。比如企业追求集体的胜利，员工在追求自我价值的实现。
  • 社会都是追求能力的，但企业还是命令和控制型的。

• 我们拥有强大的管理惯性

  • 我们对软件的理解受到管理惯性的理解，也就是我们之前如何定义软件管理？其实敏捷是质变，但我们认为它是量变。没有从各个层次上做好准备。

• 职责到底是什么？（谁负责质量保证？）
  简而言之，员工应该负责交付高质量的软件。
  我们一方面是对团队进行支持，另一方面对团队进行挑战。但需要注意挑战不是压力，支持不是润滑。参见：建议阅读

• 价值从何而来？

  • 如同测试一样，PMO或质量保证部门是间接实现价值的部门。但注意越强调质量其实我们越没有质量，我们需要让软件内建质量而不是监督和审核来提高软件的质量。这样的浪费是极大的。

建议阅读

• 《看专业教练如何让团队直面自己的承诺：团队规则进化｜思维发条》
• 《让看板成为团队的镜子：看板演进｜思维发条》
• 《实现高绩效团队的两个催化剂｜思维发条》

敬请关注公众号【思维发条】，精彩文章，精彩语音