TOC之关键链项目管理遇到软件工程7原则

编著者：张克强    微博：张克强-敏捷307

软件工程7原则简介

美国著名软件工程专家鲍伊姆(B.W.Boehm，也又另译为勃姆)在总结软件工程准则和信条的基础上，于1983年提出软件工程的7条基本原则，也是软件项目管理应该遵循原则。勃姆认为，这7条原则是确保软件产品质量和开发效率的最小集合，相互独立但结合得相当完备。

1. Manage using a phased life-cycle plan. 用分阶段的生命周期计划来管理
2. Perform continuous validation. 进行持续的确认
3. Maintain disciplined product control. 坚持有纪律的产品控制
4. Use modern programming practices. 利用现代编程实践
5. Maintain clear accountability for results. 维护对结果的清晰责任追究
6. Use better and fewer people. 使用少而精的人员
7. Maintain a commitment to improve the process. 保持提升过程的承诺

约束理论TOC的关键链项目管理

关键链项目管理（Critical Chain Project Management，CCPM)方法是Eliyahu Goldratt博士在其小说体专著《关键链》(Critical Chain)中提出的一种新的方法，其支持者们认为，这是一种全新的、革命性的思维方式，可以有效地缩短工期，提高项目满足进度与预算约束的能力；但是也有人认为，CCPM的独特性仅仅体现在这一术语上。---摘自百度百科

关键链被用来替代 关键路径分析方法。关键链区别于关键路径的主要特征如下：

使用资源依赖 缺乏寻求最佳方案的方法。这意味着一个“足够好”的解决方法已经足够了，因为： 就目前所知，没有任何分析方法能找到一个绝对的最佳的（比如，总体的最短关键链）。 估算上的固有的不确定性，远远大于最优和接近最优（即“足够好”的解决方案）之间的差异。 插入缓冲 项目缓冲（Project Buffer，缩写为PB） 输入缓冲（Feeding Buffer，缩写为FB） 资源缓冲（Resource Buffer，缩写为RB） 监测项目的进展和缓冲的使用率，而不是规划个别任务的进展速度。  ---摘自百度百科

讨论的缘起

@TOC中国 发了条微博 ： 1.项目的客户为什么需要设定里程碑？ 2.客户希望用里程碑达到什么目的？

     张克强-敏捷307 ： 好多项目管理类和软件工程的书都是这么说的。toc 如何破 ？

    TOC中国：回复@张克强-敏捷307:回复@张克强-敏捷307:破什么?

    张克强-敏捷307：《关键链》对此有新做法，我以为你会提，你是要提否？

张克强-敏捷307：回复@TOC中国:在软件开发领域，请查看鲍伊姆-软件工程七原则，发表于上世纪80年代初。

然后，我找到个介绍鲍伊姆-软件工程七原则的网络文章，做了推荐: 

@张克强-敏捷307   勃姆的 软件工程 7条基本原则-文章页-PChome手机版  http://t.cn/Rv6ah88   @TOC中国

开始争论

拯救与逍遥：不同层次的管理人员必须严格按照计划各尽其职地管理软件开发与维护工作，绝不能受顾客或上级人员的影响而擅自背离预定计划。【第一条就是自说自话了。】

           张克强-敏捷307：怎么自说自话了？scrum是符合此条的

拯救与逍遥：SCRUM说了“绝不能受顾客或上级人员的影响而擅自背离预定计划”？

       Glen-Wang：一切经PO

       张克强-敏捷307：sprint backlog的修改是需各方同意的，注意原文中的“擅自”

 

拯救与逍遥：一方面说 “不成功的软件项目中约有一半左右源自计划不周”，另一面有说“绝不能受顾客或上级人员的影响而擅自背离预定计划”。 这不是逻辑混乱吗？加上“擅自”不过是留个退路的修辞。如果了解过TOC的 CCPM 项目管理方式，就会知道基于严格里程碑计划的复杂项目，必将失败。(6月9日 17:23)

     张克强-敏捷307：回复@拯救与逍遥:我认为其逻辑很正常。计划不好，项目容易会失败；未经各方同意修改计划，更容易失败。另，scrum的review meeting实质上是里程碑评审，忠实的满足了此条软工原则。 (6月9日 18:27)

张克强-敏捷307：回复@拯救与逍遥:你要是用toc能证明软工原则是错的，或者已经过时，你就是新一代软工大师。如果你真有所得，建议写成论文，有道理的话，发表出来，想来轰动世界。以上我是认真的，绝非嘲讽。(6月9日 18:36)

    拯救与逍遥：回复@张克强-敏捷307:我就问一个问题，每个里程碑都按时达成是整个plan按时达成的充分条件 还是 必要条件？至于ccpm项目管理方式已经被收入到pmbok中了，论文早已轮不到我这样的后生晚辈写了。 (6月9日 18:51)

             张克强-敏捷307：你这问题本身不恰当。pmbok是如何说ccpm的？有链接否？

            张克强-敏捷307：pmbok收ccpm可并不一定说明软工原则失效，项目管理与软件工程有重合，但不等同

            拯救与逍遥：我是在pmbok上看到过，不过说的很简略。具体哪里要问下pmp专家了 @京东PMO蔡德辉 。网上有更多详细的介绍，搜一下吧。有本toc的企管小说《关键链》讲这个，有兴趣还可以参加近期上海的ccpm的培训班。

            李凯-社会化营销：回复@拯救与逍遥:这里其实存在两种不同的假设：里程碑思维里，大概拖延症，早完成隐瞒不报，多任务下带来的时间延长等问题是完全可以消除或控制的，进一步就是保护局部就等于保护全局。而TOC是承认这些不确定性的，因此其对应之策是保护影响全局的关键路径，对其他局部采取宽松政策。(6月9日 19:12)

分析

张克强-敏捷307：我认为关键链是考虑了资源瓶颈的关键路径，软件项目矩阵管理其实已经覆盖了关键链的要点，而且关键链下并不是完全取消里程碑，而是识别了更关键的里程碑。我精读过此书//@拯救与逍遥:有本toc的企管小说《关键链》

拯救与逍遥：那克强认为ccpm相对于传统方式的特点在哪里呢？ 

张克强-敏捷307：我已经说了啊，其效果在软件领域不会明显，在积累大量数据的建筑领域也不会明显，在其它领域我估计效果会不错

        赵智平_极普TOC：CCPM,1颠覆了关键路径CPM,2去除学生综合症及帕金森综合症对项目的影响，3设置缓冲因应不确定性并给出预警机制

拯救与逍遥：在软件领域不明显的理由是？

张克强-敏捷307：在软件开发领域，矩阵管理，敏捷团队，cmmi，各类模型等等已经覆盖并超越了关键链，建筑领域类似

        拯救与逍遥：这个逻辑好奇怪//@张克强-敏捷307:在软件开发领域

        张克强-敏捷307：回复@拯救与逍遥:锦上添花 vs. 雪中送炭啊！

        李凯-社会化营销：因为对这些方法不懂，所以只能问最基本的问题：这些方法的追求目标是不是与CCPM并不完全一致，实际上还超越了它?

          张克强-敏捷307：窃以为大目标是一致的，这些覆盖并超越了ccpm//@李凯-社会化营销:因为对这些方法不懂

                李凯-社会化营销：那么大目标是什么呢？超越的部分又是哪些?这是一个值得学习的突破口  

赵智平_极普TOC：软件开发的最大不确定性是什么?是完成任务的时间?软件需求?CCPM处理的最大不确定性是任务时间

张克强-敏捷307：敏捷迭代开发利用时间箱，别的行业很难模仿

赵智平_极普TOC：为何要迭代?因为可以锁定需求?需求被锁定,不确定性为任务的时间?//@张克强-敏捷307:敏捷迭代开发利用时间箱，别的行业很难模仿

张克强-敏捷307：反过来，锁定时间，拥抱变化//@赵智平_极普TOC:为何要迭代？

赵智平_极普TOC：以时间缓冲(余量)决定可接受的需求变化,或可引用缓冲侵蚀做决策;需求是最大的不确定性,小批量逐次确认//@张克强-敏捷307:反过来,锁定时间,拥抱变化  

           张克强-敏捷307：nod，好多toc术语，敏捷骚年一般不喜欢

           深圳老曲：ccpm中对人性的解释（不良多工、帕金森定律、学生综合症、墨菲定律等）可以用于敏捷的导入，但ccpm本身缺乏对软件开发实践的支持。 //@张克强-敏捷307:nod，好多toc术语，敏捷骚年一般不喜欢

           赵智平_极普TOC：CCPM可以支持的最大不确定性是任务时间及有限度地"拥抱"变化//@深圳老曲: ccpm中对人性的解释

                         深圳老曲 ：ccpm以及传统的项目管理，背后的假设都是项目的内容、工期、质量是能够同时兼顾的。在软件工程领域，这个假设是是不成立的，所以敏捷则是固定时间、保证质量，首先交付价值最高的功能。

                       赵智平_极普TOC:如果我懂SDBR及C#,需求已使用UML定义,可以使用CCPM管理开发进度吗?

                       深圳老曲：可惜的是，包括UML在内的几乎所有方法，都不能清晰、准确地把需求定义出来，特别是比较大或没有参考对象的项目。