编著者：张克强 微博：张克强-敏捷307
软件project7原则简单介绍
美国著名软件project专家鲍伊姆(B.W.Boehm，也又另译为勃姆)在总结软件project准则和信条的基础上，于1983年提出软件project的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的独特性只体如今这一术语上。---摘自百度百科
讨论的缘起
2.客户希望用里程碑达到什么目的？
张克强-敏捷307：好多项目管理类和软件project的书都是这么说的。toc怎样破？
TOC中国：回复@张克强-敏捷307:回复@张克强-敏捷307:破什么?
张克强-敏捷307：《关键链》对此有新做法，我以为你会提，你是要提否？
张克强-敏捷307：回复@TOC中国:在软件开发领域。请查看鲍伊姆-软件project七原则，发表于上世纪80年代初。
然后，我找到个介绍鲍伊姆-软件project七原则的网络文章，做了推荐:
開始争论
】
Glen-Wang：一切经PO
backlog的改动是需各方允许的，注意原文中的“擅自”
“不成功的软件项目中约有一半左右源自计划不周”，还有一面有说“绝不能受顾客或上级人员的影响而擅自背离预定计划”。 这不是逻辑混乱吗？加上“擅自”只是是留个退路的修辞。假设了解过TOC的 CCPM 项目管理方式，就会知道基于严格里程碑计划的复杂项目。必将失败。(6月9日 17:23)
张克强-敏捷307：回复@解救与逍遥:我觉得其逻辑非常正常。计划不好，项目easy会失败；未经各方允许改动计划。更easy失败。
另。scrum的review
meeting实质上是里程碑评审。忠实的满足了此条软工原则。
(6月9日 18:27)
(6月9日
18:36)
解救与逍遥：回复@张克强-敏捷307:我就问一个问题，每一个里程碑都按时达成是整个plan按时达成的充分条件
还是 必要条件？至于ccpm项目管理方式已经被收入到pmbok中了，论文早已轮不到我这种后生晚辈写了。
(6月9日 18:51)
张克强-敏捷307：你这问题本身不恰当。pmbok是怎样说ccpm的？有链接否？
张克强-敏捷307：pmbok收ccpm可并不一定说明软工原则失效，项目管理与软件project有重合。但不等同
解救与逍遥：我是在pmbok上看到过，只是说的非常简略。具体哪里要问下pmp专家了 @京东PMO蔡德辉 。
网上有很多其它具体的介绍。搜一下吧。有本toc的企管小说《关键链》讲这个。有兴趣还能够參加最近上海的ccpm的培训班。
李凯-社会化营销
from=main" style="font-size:14px; line-height:21px; text-decoration:none; color:rgb(108,99,81); background-color:rgb(250,250,250)">
：回复@解救与逍遥:这里事实上存在两种不同的如果：里程碑思维里。大概迟延症，早完毕隐瞒不报，多任务下带来的时间延长等问题是全然能够消除或控制的。进一步就是保护局部就等于保护全局。而TOC是承认这些不确定性的，因此其相应之策是保护影响全局的关键路径，对其它局部採取宽松政策。(6月9日
19:12)
分析
我精读过此书//@解救与逍遥:有本toc的企管小说《关键链》
赵智平_极普TOC：CCPM,1颠覆了关键路径CPM,2去除学生综合症及帕金森综合症对项目的影响，3设置缓冲因应不确定性并给出预警机制
李凯-社会化营销
from=main" style="text-decoration:none; color:rgb(108,99,81); line-height:21px; background-color:rgb(250,250,250)">
：由于对这些方法不懂。所以仅仅能问最主要的问题：这些方法的追求目标是不是与CCPM并不全然一致，实际上还超越了它?是完毕任务的时间?软件需求?CCPM处理的最大不确定性是任务时间
由于能够锁定需求?需求被锁定,不确定性为任务的时间?//@张克强-敏捷307:敏捷迭代开发利用时间箱，别的行业非常难模仿
深圳老曲：ccpm中对人性的解释（不良多工、帕金森定律、学生综合症、墨菲定律等）能够用于敏捷的导入。但ccpm本身缺乏对软件开发实践的支持。
//@张克强-敏捷307:nod，好多toc术语。敏捷骚年一般不喜欢
在软件project领域，这个如果是是不成立的，所以敏捷则是固定时间、保证质量。首先交付价值最高的功能。