远远不如图3-1所示水准稳定的生产性工作比例、不太注重开发程序的中型项目一般都经历了如图3-3中所示的生产力变化方式：
图中，项目经历了推动中工作过节状况递增的情形。等项目推动到途中，团队才会明白工作脱节耗去了许多时间，如果能进行一些对应的开发处理程序是会有好处的，不过已为时晚矣，对项目的伤害都已经出现了。项目团队试着增加开发处理程序的功效，可是这样的努力做得再多也弥补不了工作脱节的严重情形。有时努力步伐太慢一样会让工作脱节得更严重。
较幸运的项目还可以在仍有残余的工作时间里把产品赶出来，不幸的项目就没办法在工作脱节之前完成产品。这种情形持续数周或数个月后，这些项目一般都会因为主管或客户明白项目推动进度受阻而遭到取消。如果你认为项目中的开发程序设定是件不必要的额外负担，想想看一件被取消的项目可能让你更划不来吧。
补救程序
幸运的是对这样凄凉的场景，还有些变通的补救办法，最令人高兴的是完全不用依赖那些“死板而没效率的开发程序”。（译注：“死板而没效率的开发程序”原文为rigid，inefficient processes，缩写成R.I.P，刚好跟请死者“安息”的rest in peace的缩写相同。）
当然，有些软件开发程序确实死板而没有效率，所以我不建议把这些处理方式用在项目中。本章要描述的是使用能够增进项目弹性与效率的那些开发程序。
当这些开发程序被用到项目中时，项目的工作效率比例就会变成图3-4中的样子。
在项目进行的头几周，程序导向的团队似乎比害怕使用开发程序的团队更没生产力，因为两边工作脱节程度都差不多，而程序导向的团队会花费较多的时间来执行开发程序，这项投资稍后就会在项目中显出成效了。
等项目进行到一半，先前就重视开发程序处理的团队跟之前比较，工作脱节的程度会开始降低，程序的执行也会开始顺畅起来。同时害怕使用开发程序的团队则开始明白工作脱节已无法掩饰，开始自己寻求补救办法。
等项目接近尾声时，程序导向团队正处于顺畅运作状态，很少出现脱节的情形，而程序的执行也感觉不出有什么费时。少许的工作脱节状况难免存在，因为为消除这些脱节现象所花费的精力实在不划算。当上述提到的开发程序都被执行后，程序导向团队比起害怕使用开发程序的团队会更早进入状态。
================================================
项目一开始对开发程序所做的努力终究有所回馈。
================================================
明确注重改善开发程序的组织，可以在几年中把产品的上市时间缩减了一半，错误发生率降低了60%～90%倍。在五年里，洛克希德公司（Lockheed）把产品开发成本降低了75%，时间则缩减了40%，而错误发生率也降低了90%。在六年半的时间里，Raytheon公司的生产力提升了三倍，投资回报率（Return On Investment，ROI）达到八倍。Bull HN公司在经历四年的软件开发程序改进后，投资回报率也达到四倍。Schlumberger公司在花三年半的时间改善软件开发程序后，把投资回报率提升到接近九倍。NASA的软件工程实验室在八年中把每个任务的平均成本缩减了一半，错误发生率降低了75%，同时大幅度增进了每个任务中使用软件的复杂度。类似成果也出现在休斯、Loral、摩托罗拉、全录与其他注重系统化改善软件开发程序的公司中。
最好的消息是，你猜猜看，这些生产力、质量与时程表现的改善花费的成本是多少？只花费了整体开发成本的2%的代价而已——通常每名开发人员每年约花费1500美金而已。
开发程序对创意与士气
对于系统化开发程序的一个反对意见是认为这样会限制程序写作人员的创意。程序员们确实很需要有创意，不过主管与项目主持人也需要让项目维持在可掌握的范围内，让项目进展看得出来，而且满足时间、预算与其他目标。
系统化开发程序会限制开发人员创意的说法，是由于对开发人员创意与达成项目目标管理两者之间一些矛盾的想法所致。两者并行不悖的环境当然是可能的，而且许多公司都已经做到了，就像建立一个能够同时满足不同目标间的协调并完成这些目标的环境一样可行。
注重开发程序的公司已经发现有效率的程序可以支持开发人员的创意与士气。在一个针对约五十家公司的调查中，发现只有少数开发程序导向公司的人将自己公司评为“士气良好”或“士气高昂”。在对软件开发程序付出更多注意的组织中，约有一半的人将自己公司评为“士气良好”或“士气高昂”。而在最注重开发程序的组织中，有60%的人将自己公司评为“士气良好”或“士气高昂”。
当程序写作人员最具生产力时，他们的感觉也最好。好的项目领导者建立清楚的目标远景，并利用一套开发程序构架让程序员们觉得自己拥有不可思议的生产力。程序员们讨厌阻碍工作的各种障碍，他们不得不抛开眼高手低、毫无章法的脆弱领导者。程序员们欣赏有远见、有见识与有魄力的开明领导者。
在此对开发程序与创意之间所谓矛盾的适当响应就是，本文中没有任何一个程序规划会以任何方式限制程序写作人员的创意，最多是提供一个支持架构，让程序员们能够自由地对相关的技术性工作发挥创意，让他们免于分心在那些消耗注意力的琐事上。
过渡到系统化开发程序
如果一支项目团队目前没采用系统化程序，一个最简单的过渡办法就是描绘出目前的软件开发程序的细节，将没用的部分标示出来，试着改正那些地方。虽然项目团队有时会宣称他们目前没有规划开发程序，每个项目团队实际上都有自己的开发程序做法（如果他们说目前没采取开发程序的做法，他们大概只是没有一套好的开发程序规划）。
最粗糙的开发程序做法一般是这样的：
1．讨论要写出怎样的软件。
2．写出些程序来。
3．测试程序，找出缺陷。
4．除错，找出错误的根源来。
5．修正缺陷。
6．如果项目还没完成，回到第一步。
[@more@]
图中，项目经历了推动中工作过节状况递增的情形。等项目推动到途中，团队才会明白工作脱节耗去了许多时间，如果能进行一些对应的开发处理程序是会有好处的，不过已为时晚矣，对项目的伤害都已经出现了。项目团队试着增加开发处理程序的功效，可是这样的努力做得再多也弥补不了工作脱节的严重情形。有时努力步伐太慢一样会让工作脱节得更严重。
较幸运的项目还可以在仍有残余的工作时间里把产品赶出来，不幸的项目就没办法在工作脱节之前完成产品。这种情形持续数周或数个月后，这些项目一般都会因为主管或客户明白项目推动进度受阻而遭到取消。如果你认为项目中的开发程序设定是件不必要的额外负担，想想看一件被取消的项目可能让你更划不来吧。
补救程序
幸运的是对这样凄凉的场景，还有些变通的补救办法，最令人高兴的是完全不用依赖那些“死板而没效率的开发程序”。（译注：“死板而没效率的开发程序”原文为rigid，inefficient processes，缩写成R.I.P，刚好跟请死者“安息”的rest in peace的缩写相同。）
当然，有些软件开发程序确实死板而没有效率，所以我不建议把这些处理方式用在项目中。本章要描述的是使用能够增进项目弹性与效率的那些开发程序。
当这些开发程序被用到项目中时，项目的工作效率比例就会变成图3-4中的样子。
在项目进行的头几周，程序导向的团队似乎比害怕使用开发程序的团队更没生产力，因为两边工作脱节程度都差不多，而程序导向的团队会花费较多的时间来执行开发程序，这项投资稍后就会在项目中显出成效了。
等项目进行到一半，先前就重视开发程序处理的团队跟之前比较，工作脱节的程度会开始降低，程序的执行也会开始顺畅起来。同时害怕使用开发程序的团队则开始明白工作脱节已无法掩饰，开始自己寻求补救办法。
等项目接近尾声时，程序导向团队正处于顺畅运作状态，很少出现脱节的情形，而程序的执行也感觉不出有什么费时。少许的工作脱节状况难免存在，因为为消除这些脱节现象所花费的精力实在不划算。当上述提到的开发程序都被执行后，程序导向团队比起害怕使用开发程序的团队会更早进入状态。
================================================
项目一开始对开发程序所做的努力终究有所回馈。
================================================
明确注重改善开发程序的组织，可以在几年中把产品的上市时间缩减了一半，错误发生率降低了60%～90%倍。在五年里，洛克希德公司（Lockheed）把产品开发成本降低了75%，时间则缩减了40%，而错误发生率也降低了90%。在六年半的时间里，Raytheon公司的生产力提升了三倍，投资回报率（Return On Investment，ROI）达到八倍。Bull HN公司在经历四年的软件开发程序改进后，投资回报率也达到四倍。Schlumberger公司在花三年半的时间改善软件开发程序后，把投资回报率提升到接近九倍。NASA的软件工程实验室在八年中把每个任务的平均成本缩减了一半，错误发生率降低了75%，同时大幅度增进了每个任务中使用软件的复杂度。类似成果也出现在休斯、Loral、摩托罗拉、全录与其他注重系统化改善软件开发程序的公司中。
最好的消息是，你猜猜看，这些生产力、质量与时程表现的改善花费的成本是多少？只花费了整体开发成本的2%的代价而已——通常每名开发人员每年约花费1500美金而已。
开发程序对创意与士气
对于系统化开发程序的一个反对意见是认为这样会限制程序写作人员的创意。程序员们确实很需要有创意，不过主管与项目主持人也需要让项目维持在可掌握的范围内，让项目进展看得出来，而且满足时间、预算与其他目标。
系统化开发程序会限制开发人员创意的说法，是由于对开发人员创意与达成项目目标管理两者之间一些矛盾的想法所致。两者并行不悖的环境当然是可能的，而且许多公司都已经做到了，就像建立一个能够同时满足不同目标间的协调并完成这些目标的环境一样可行。
注重开发程序的公司已经发现有效率的程序可以支持开发人员的创意与士气。在一个针对约五十家公司的调查中，发现只有少数开发程序导向公司的人将自己公司评为“士气良好”或“士气高昂”。在对软件开发程序付出更多注意的组织中，约有一半的人将自己公司评为“士气良好”或“士气高昂”。而在最注重开发程序的组织中，有60%的人将自己公司评为“士气良好”或“士气高昂”。
当程序写作人员最具生产力时，他们的感觉也最好。好的项目领导者建立清楚的目标远景，并利用一套开发程序构架让程序员们觉得自己拥有不可思议的生产力。程序员们讨厌阻碍工作的各种障碍，他们不得不抛开眼高手低、毫无章法的脆弱领导者。程序员们欣赏有远见、有见识与有魄力的开明领导者。
在此对开发程序与创意之间所谓矛盾的适当响应就是，本文中没有任何一个程序规划会以任何方式限制程序写作人员的创意，最多是提供一个支持架构，让程序员们能够自由地对相关的技术性工作发挥创意，让他们免于分心在那些消耗注意力的琐事上。
过渡到系统化开发程序
如果一支项目团队目前没采用系统化程序，一个最简单的过渡办法就是描绘出目前的软件开发程序的细节，将没用的部分标示出来，试着改正那些地方。虽然项目团队有时会宣称他们目前没有规划开发程序，每个项目团队实际上都有自己的开发程序做法（如果他们说目前没采取开发程序的做法，他们大概只是没有一套好的开发程序规划）。
最粗糙的开发程序做法一般是这样的：
1．讨论要写出怎样的软件。
2．写出些程序来。
3．测试程序，找出缺陷。
4．除错，找出错误的根源来。
5．修正缺陷。
6．如果项目还没完成，回到第一步。
[@more@]
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7839396/viewspace-942019/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/7839396/viewspace-942019/
1550
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
