本文提供了一套更精巧的软件开发程序。
建立系统化软件开发程序的障碍之一，就是项目团队害怕自己会在面对太多开发程序项目时出错，害怕他们执行这些程序后，会变得太官僚化，对项目执行造成太大负担。这通常不构成显著的危险，因为：
◆使用本文做法的项目会有个相当精细的开发程序，不会带来太多负担。
◆软件项目常常比第一眼看起来的要大得多。多数项目的问题出在本身，而不是出在开发程序中。
◆比较好的做法是开始先设定较多的开发程序以供执行、再视情况调整，比开头毫无章法其后再追加额外程序项目要容易。
◆多设定些程序项目所花的成本与时间代价要远低于不重视这档子事。接下来，就告诉你为何如此。
上下游
好的软件开发程序可及早处理项目中的问题。
你有时会听到经验老到的软件开发人员提起软件项目中的“上游”跟“下游”部分。“上游”这字眼只是用来表示项目的开始部分，“下游”则是指项目的末尾部分。
“上下游”的分法对于思考项目上的问题是很有用的。开发人员在项目开始所做的，在末尾未必有收获。如果一开始工作处理得当，末尾的收获就会健全并有助于项目成功。如果开始工作做得不好，后来的结果就可能严重影响成果，不客气地说，甚至可能让项目无法完成。
研究人员发现诸如规格或架构上的错误，事后才修正会比一开始就修正错误要花费多出50～200倍的代价。图3-5说明了这种效应。
要能让规格中的一句话很容易变成几个设计方式，而这些设计方式之后能再变成几百行的源代码、几打的测试情形、许多页的使用文件、线上求助画面及许多技术支持部门的操作说明等等东西。
当项目团队有机会阶段性修正错误，立刻修正错误会比过一阵子再去修正受影响之处要有意义。这种在错误发生的阶段内找出错误并马上休正的构想称作“阶段围堵”策略。
============================================
成功的项目借由仔细审查、要求规格与架构来制
造机会修正上游问题。
============================================
在上游动作时还没写出任何程序，找寻及修正错误，虽然可能让项目“该做的工作”表面上看来被拖延了，实际上却刚好相反。这些工作是在替项目的成功铺路。
过多程序项目的错误会越发的增加项目的负担，不过缺乏程序规划的问题会让错误变成必须花费50～200倍的效率成本才能修正的大麻烦。因此宁可多设定开发程序事项，也比不做开发程序设定来得好。
不确定性的角锥
上游错误要多花费50～200倍的代价才能在下游修正的一个原因是，上游决定的范围比下游的要广。
在项目初期，项目团队面对的是大问题，例如要不要同时支持Windows NT或Macintosh或是只支持Windows NT就好了，还有报表格式是使用者自订还是固定格式。在项目进行中，项目团队面对的是中型问题：有多少子系统；如何按一般情形处理错误状况；或是如何把一个打印例程从过去的项目移植到现在的项目中。
到了项目末期，项目团队面对的是小问题，像是要采用哪一种技术算法，或者要不要让使用者能够取消还没完成的动作等等。如图3-6所示，软件开发是个持续渐进的程序，将问题由大到小分开处理，从决定大势走向到解决个别的小问题。推动软件项目所花费的时间，就是彻底思考并解决问题所需要的时间。
本图中的角锥状图形为项目中决策方向未定的事务量。软件项目中对问题的决策尺度由大到小。除非团队成员完成了前一个阶段的大部分工作，不然无法知道一个特定阶段中到底有多少需要决定执行方向的问题。
项目团队最擅于处理大型的决策问题，不过有时无法预见（而且不可预知的）的问题会在后头因为大型决策不当而出现，若要中途取消一个行动则表示项目团队得重新设计一个常式、一个模块甚至一整个子系统。
在某一尺度的决策敲定后，应可以事先精确预估下一尺度将面对的决策种类。不过项目团队或许可以先做好前头的决定，但对项目后头的决策问题只可能作出一般性的猜测。如果你想知道软件开发的工作为何，了解项目团队所有该思考的问题，并明白一个团队得在充分了解下一个阶段工作的内容之前便决定好现阶段中所有的执行方向，就成了重要的事情。
不确定性的角锥对项目预估的意义
不确定性的角锥对软件项目的预估有着强烈的意义。它不光表示在前期阶段精确评估项目的困难性，还说明那在理论上不可能办到。在需求规格阶段末尾，项目的范围还得由一大堆在购架阶段、细节设计阶段和构建阶段要作出的决策所决定。宣称能够预估未定决策对项目影响有多大的人如果不是先知，就是对于软件开发的本质不太了解的人。
另一方面，寻求控制决策方向以符合项目预计时间或预算目标的人是明智的。只要你愿意痛下决心砍掉一些规划功能，在项目初期就确立精确的时间表和预算目标，并在之后一直按部就班。成功的关键在于以这样的方式达成目标要求，做法包括在项目初期设定明确而不冲突的目标，保持产品概念非常有弹性，并主动追踪控制项目中的开发工作。
==============================================================
在项目开头，你能制定实在的成本和时间目标，或是制定充实的功能
组合，但是你不能强求两边的目标都要达成。
==============================================================[@more@]
建立系统化软件开发程序的障碍之一，就是项目团队害怕自己会在面对太多开发程序项目时出错，害怕他们执行这些程序后，会变得太官僚化，对项目执行造成太大负担。这通常不构成显著的危险，因为：
◆使用本文做法的项目会有个相当精细的开发程序，不会带来太多负担。
◆软件项目常常比第一眼看起来的要大得多。多数项目的问题出在本身，而不是出在开发程序中。
◆比较好的做法是开始先设定较多的开发程序以供执行、再视情况调整，比开头毫无章法其后再追加额外程序项目要容易。
◆多设定些程序项目所花的成本与时间代价要远低于不重视这档子事。接下来，就告诉你为何如此。
上下游
好的软件开发程序可及早处理项目中的问题。
你有时会听到经验老到的软件开发人员提起软件项目中的“上游”跟“下游”部分。“上游”这字眼只是用来表示项目的开始部分，“下游”则是指项目的末尾部分。
“上下游”的分法对于思考项目上的问题是很有用的。开发人员在项目开始所做的，在末尾未必有收获。如果一开始工作处理得当，末尾的收获就会健全并有助于项目成功。如果开始工作做得不好，后来的结果就可能严重影响成果，不客气地说，甚至可能让项目无法完成。
研究人员发现诸如规格或架构上的错误，事后才修正会比一开始就修正错误要花费多出50～200倍的代价。图3-5说明了这种效应。
要能让规格中的一句话很容易变成几个设计方式，而这些设计方式之后能再变成几百行的源代码、几打的测试情形、许多页的使用文件、线上求助画面及许多技术支持部门的操作说明等等东西。
当项目团队有机会阶段性修正错误，立刻修正错误会比过一阵子再去修正受影响之处要有意义。这种在错误发生的阶段内找出错误并马上休正的构想称作“阶段围堵”策略。
============================================
成功的项目借由仔细审查、要求规格与架构来制
造机会修正上游问题。
============================================
在上游动作时还没写出任何程序，找寻及修正错误，虽然可能让项目“该做的工作”表面上看来被拖延了，实际上却刚好相反。这些工作是在替项目的成功铺路。
过多程序项目的错误会越发的增加项目的负担，不过缺乏程序规划的问题会让错误变成必须花费50～200倍的效率成本才能修正的大麻烦。因此宁可多设定开发程序事项，也比不做开发程序设定来得好。
不确定性的角锥
上游错误要多花费50～200倍的代价才能在下游修正的一个原因是，上游决定的范围比下游的要广。
在项目初期，项目团队面对的是大问题，例如要不要同时支持Windows NT或Macintosh或是只支持Windows NT就好了，还有报表格式是使用者自订还是固定格式。在项目进行中，项目团队面对的是中型问题：有多少子系统；如何按一般情形处理错误状况；或是如何把一个打印例程从过去的项目移植到现在的项目中。
到了项目末期，项目团队面对的是小问题，像是要采用哪一种技术算法，或者要不要让使用者能够取消还没完成的动作等等。如图3-6所示，软件开发是个持续渐进的程序，将问题由大到小分开处理，从决定大势走向到解决个别的小问题。推动软件项目所花费的时间，就是彻底思考并解决问题所需要的时间。
本图中的角锥状图形为项目中决策方向未定的事务量。软件项目中对问题的决策尺度由大到小。除非团队成员完成了前一个阶段的大部分工作，不然无法知道一个特定阶段中到底有多少需要决定执行方向的问题。
项目团队最擅于处理大型的决策问题，不过有时无法预见（而且不可预知的）的问题会在后头因为大型决策不当而出现，若要中途取消一个行动则表示项目团队得重新设计一个常式、一个模块甚至一整个子系统。
在某一尺度的决策敲定后，应可以事先精确预估下一尺度将面对的决策种类。不过项目团队或许可以先做好前头的决定，但对项目后头的决策问题只可能作出一般性的猜测。如果你想知道软件开发的工作为何，了解项目团队所有该思考的问题，并明白一个团队得在充分了解下一个阶段工作的内容之前便决定好现阶段中所有的执行方向，就成了重要的事情。
不确定性的角锥对项目预估的意义
不确定性的角锥对软件项目的预估有着强烈的意义。它不光表示在前期阶段精确评估项目的困难性，还说明那在理论上不可能办到。在需求规格阶段末尾，项目的范围还得由一大堆在购架阶段、细节设计阶段和构建阶段要作出的决策所决定。宣称能够预估未定决策对项目影响有多大的人如果不是先知，就是对于软件开发的本质不太了解的人。
另一方面，寻求控制决策方向以符合项目预计时间或预算目标的人是明智的。只要你愿意痛下决心砍掉一些规划功能，在项目初期就确立精确的时间表和预算目标，并在之后一直按部就班。成功的关键在于以这样的方式达成目标要求，做法包括在项目初期设定明确而不冲突的目标，保持产品概念非常有弹性，并主动追踪控制项目中的开发工作。
==============================================================
在项目开头，你能制定实在的成本和时间目标，或是制定充实的功能
组合，但是你不能强求两边的目标都要达成。
==============================================================[@more@]
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7839396/viewspace-942020/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/7839396/viewspace-942020/
109
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
