讨论：国内项目中至少可以运用的软件工程方法？

[10jqkA]

前言
为更好地开发软件，必须在项目组中引入一些软件工程手段和方法。本文试讨论了无论公司情况如何，一个项目经理都应该可以在项目组中实行的一些手段和方法；当然，公司情况良好则有更加可行的、更多的方法可以选择；这里只讨论了最差情况下可以采用的方法。
本文按照最简单的瀑布模式的各个阶段分别列举了一些方法，在其他模式中应该也可以采用。
需求阶段
需求的管理应该是贯穿整个开发过程。在这个阶段，可以采用的方法有：
² CCB(变更控制委员会)
建立CCB（change control board）是需求管理的前提，否则需求管理将成为一句空话。
CCB必须包含客户方的决策人士，项目经理，项目经理的领导，关键设计人员，测试负责人，SQA.等，以5-7人左右为宜。
需求确认，发生变更等活动必须由CCB以会议形式批准。
CCB对整个项目有最高权力（不仅负责需求变更，还负责听取项目经理汇报、关键中间工作产品评审等重要决策）
² 需求评审，纳入基线
原始需求必须形成文档，被CCB评审，然后纳入基线管理，所有变更都需要CCB评审。
该评审一般步骤：
1. 项目经理提出被评审对象，指出受影响、被牵涉对象，评估影响（主要是带来的规模、工作量、成本），提出计划和计划执行人，举出可能风险；
2. CCB来决定是否同意或要求项目经理修改上述项；
3. 之后，项目经理提交执行情况汇报。
4. 最后，CCB指定代表或由SQA进行核实。
如果变更过小，过多，可以进行周汇总评审。
项目计划阶段
项目计划是开发的指导或脚本，事实上，在每一个阶段开始时，都应该重新、小范围修订一下计划。
² 选择合适的软件开发生命周期
关于生命周期的选择上，一直有而且会有很多争议。目前，国内运用最多的是纯瀑布生命周期；本人的看法是：一定有更好的选择，但这是一个最安全、最少在实际中有争议的选择。
选择合适的生命周期的要点是：一定要有选择原因的陈述—本项目的特点，团队特点，开发特点和公司或部门的特点；该问题必须事先在项目组中、CCB内被讨论过并得到一定认可。
² 划分阶段--小里程碑
根据选定的生命周期模型，考虑到可以投入的人员，各个开发阶段就呼之欲出了。每个阶段的结束一定是一个里程碑。如果里程碑超过一个月，那么应该在每经过一个月左右选择合适的点作为小里程碑。
每达到一个里程碑时，项目经理应该提交本阶段工作报告，一般应该包括：
1. 本阶段活动统计和估计的数值和它们差异的原因
2. 工作产品完成情况
3. 需求变更情况统计
4. 问题及其解决情况的统计
5. 总结优点和缺点，指出对下一步工作的影响
CCB听取该报告并评价该阶段工作。
小里程碑可以防止项目失控，使项目经理、项目组和其上的管理层能够正确认识到项目进展情况，并能协助项目开展、出谋划策，项目可视化好；避免项目发生大问题。
² 决定工作产品和含中间工作产品
在最混乱的项目中，工作产品和中间工作产品都没有被明确定义，或者可以朝令夕改，随意添加或去除产品。决定工作产品和中间工作产品，是为了确定各个产品的重要性，计算其上的工作量以合理地投入足够的、合适人员来开发它。
² 项目工作分解
一般是将系统分解成模块甚至更细，要分多细由项目经理或分析员根据实际对项目产品的认识和人力、进度的压力而定；一个忠告：开始做的细、做的认真，以后的工作都会相应容易很多。
一般人只分解产品。实际上，管理工作也应该分解的，而且也比较容易作。
² 估计
估计常常被忽略掉，因为估计的结果往往会严重超出预算，让人大吃一惊。而到了最后，结果又往往接近当初估计的数字。
估计应该每个阶段作为更新计划的一部分进行一次，每个新的估计都会更加准确。
估计应该选取有经验的人士参与，应该选择合适的方法
估计的结果应该用于指导编制下一阶段的计划，即使不被正式接受，项目组也不应该忘记这些数字，时刻作为参照。
² 明确职责—团队建设
根据项目特点和人员特点，应该选择合适的模式来组建团队进行开发，每个人都应该有明确的责任和工作。
最低限度，每个人都应该有明确的责任和工作。
² 约定沟通方式、渠道
建立沟通渠道这一条可以不成文，但要成规矩。沟通渠道应该开放，畅通。为每个人指定汇报的领导、汇报的周期、汇报的方式和越级汇报的领导、条件和方式。
建议在项目中开展项目日志，周报制度，具体的方式方法可以参考PSP,TSP。该制度的要点是：日志首先是对自己负责，不能作为评价员工的依据，它是属于成员“开放的隐私“。如果要求每天填满8小时工作，这样的日志没有任何意义；事实上，在本人的项目组中，根据日志，一般没有人每周投入工作的时间超过35小时，平均只有28小时左右—当然，你依然可以看到他们每天都很忙碌的样子，有时还有加班呢。
周例会制度是本文推荐最有可行性的软件开发管理手段。每周用1-1.5小时左右，每个人简要汇报本周工作和下周计划的工作，工作中的问题和难点，这时，他会得到整个项目组的建议和帮助；项目经理可以印证了解到的项目进展情况；团队气氛由此加强。如果还有很多富余的时间，项目组可以讨论一下开发技术、技巧，进行一些技术交流。
总之，沟通不足是软件开发中很大的问题，而且越是大项目就越严重。
² 约定开发纪律、规范
没有规矩，不成方圆。项目组一定要有一些纪律，不能完全依靠自律。
这方面，有公司文化、氛围积淀为基础是最好，否则就应该制订一些规矩了。
这也是保持团队的重要组成部分。
至于开发规范，根据项目不同而有所不同，要点是：必须有，哪怕不完美！
而且，应该开诚布公，尽早公示。
² 风险估计和预备应对计划
风险估计应该每个阶段都进行一次，一般是根据风险列表，大家一起来估计。
其实也是让大家充分认识到项目的处境和潜在的困难。
这件事，做了总比不做好。
² CCB评审项目计划
项目计划必须得到CCB会议形式的认可，否则一定会有问题！
设计阶段
² 周期性内部评审和走查
在这个阶段，周期性内部评审和走查的目的更多是为了交流，检查模块间是否能够协作、是否有矛盾和遗漏，作为平时非正式沟通的一个强有力的补充，大家取长补短，集思广益，几个人的脑袋总比一个脑袋强；第二个目的是质量控制。第三个目的才是控制进度。
根据上述特点，评审自然应该采用会议方式，也许会有人觉得冗长、拖沓，浪费了一些人不必要的时间；但是该方式的效费比非常好，是值得的；至于组织会议的人，一般是项目经理，应该多动脑子，调动大家的积极性。有人会提出使用checklist的方式，本人的经验是：该方式削弱了沟通量，而且需要良好的制度的支持，否则容易走形式。
² 项目跟踪
项目计划制订后，项目跟踪工作就要开始了。跟踪表应该每周填写，这样项目中的问题会被及时发现；而且最好不要用project跟踪，而是自己制作一张或寻找合适的软件。一般是根据项目计划制订，有下列内容：任务包，计划的规模、工作量、进度，实际的规模、工作量、进度，二者的误差以及原因分析。
任务包完成的百分比应该如何填？本人的标准是：如果只是听成员汇报，没有100%完成的都是0%，是0-100原则；听了成员汇报，自己简单察看过工作产品的，是0-50-100原则；仔细检查过的，可以参照成员的汇报，按0-25-50-75-100原则填写。如果一个5工作日的工作包，上边写着完成43%，那是一点意义也没有的。
项目跟踪的结果用于分析项目进展情况，里程碑报告，务必真实。
² 变更控制
变更控制的具体手段请参照需求阶段的原则。在本阶段，一般只是开发人员发现需求不合理，或相互设计矛盾而要求变更。一些非基线变更的控制不需要那么严格，意思是不需要CCB评审，但项目经理要根据实际情况决定是否召集项目组内相关人员的评审。
同时，应该在这个阶段让大家养成遵守变更规定的习惯。
编码阶段
² 重新进行工作估计，有必要时修订计划
进入到编码阶段，对项目的认识已经非常清晰了。根据设计，甚至可以计算出未来的代码行数。重新进行工作估计，可以更好地分配人员到合适各人技术特点和兴趣的方面，提高项目组的积极性；同时，可以使管理层清晰认识到项目进展的真实情况，做出正确的决定或避免他们做出错误的决定。

² 标准制订和培训
编码的标准在现在已经逐渐趋向统一，但是仍然有必要在项目组中推行或制订编码标准。
统一的编码标准，可以使项目组内可以容易地互相协助、交流，为走查、测试等工作奠定良好的基础。
编码标准制订后，首先要进行项目组内培训。不过与其说是培训，不如说是讨论和统一认识，建立未来强制执行和检查的前提。（不教而诛谓为虐，教而后诛谓为化）
² 周期性走查
根据经验和一些统计数字，走查的效果要优于测试。
走查要以统一的编码标准为基础，反过来，统一的编码标准也是通过走查而在项目组中建立起来的。本人的经验是：开始时，安排每周2次走查，每次1小时，只检查一个人的一个功能，重点是编码标准，其次是BUG；大家可以通过走查学习他人的优良风格，改正自己的不足；两周后整个项目组基本上风格就统一了，这之后就应该把重点放在程序功能上，其次是BUG。
² 周创建或日创建
² 项目跟踪
项目跟踪在本阶段较容易，因为量化的东西比较多，虚的东西比较少。基本方法与上个阶段相同。通过跟踪，已经可以看出那些模块在上个阶段没有设计好。
跟踪要有分析，分析有了结果要有行动。
² 变更控制
在这个阶段，一般是开发人员在实现时发现一些设计错误而要求变更；这时，就要求项目经理严格把关，与设计人员、开发人员一起研究是否真的需要变更，还是实现者没有领会设计者的意图。如果需要变更，则要谨慎地研究影响范围，评估损失。
在这个阶段的中、后期，随着部分产品逐渐成形，客户会提出变更要求；此时要注意原则，同时要搞好关系，当然，首先是原则—CCB同意。
² 版本控制
事实上，版本控制在项目一开始时就应该展开，但未必所有的项目组都能够做到，能做好的就更加寥寥无几了。但在编码

[qing_li73]

highlight

[10jqkA]

呜呜.......

[mycode]

为更好地开发软件，必须在项目组中引入一些软件工程手段和方法。本文试讨论了无论公司情况如何，一个项目经理都应该可以在项目组中实行的一些手段和方法；
---------------------
如果按以上目的，楼主所说的是不正确的。因为，对于中国大多数的公司而言，CCB就是不成立的。
楼主所提的是一个项目经理日常应该做的工作，我非常同意，这些工作，是一个项目经理，在自己职责范围之内应该实现的一些工作。如果项目如此做了，应该能够很好的把握项目的进度。

[twinsant124]

Your dreams are good, but the real world...

[arfayr]

可以作为软件工程的简版

[ozzzzzz]

it is very good
add in my antipattern list

[10jqkA]

各位大老，俺足足敲了5个小时，你们也多敲几个字吧

[10jqkA]

to: twinsant124(蚂蚁的天空)
这不是dream，已经有不少公司在这样做了；
中国正规化开发软件的日子已经悄悄开始了

[ozzzzzz]

You are right!
Someone had do it .
:)

[skywebnet]

ok,up

[lywjsh]

很好

[10jqkA]

建立CCB，是一个项目经理可以建议并能够被采纳的。
应该是这样的吧？

[hhf0]

收获不小，谢谢楼主。

[yayong]

国内一些非正规的软件公司不但没有 SCM,甚至连源代码的version control都没有，
但是确有全套的项目需求/设计文档，真的很奇怪。
所以我觉得，采用轻量级的方法更有效
比如说，XP或者是敏捷方法，重视scm的自动化，减轻程序员负担，远比为了
软件工程而写一些应付的文档更好的了

[10jqkA]

to:： yayong(鸭泳)
我们不是没有好的软件和好的头脑，而是没有好的制度把我们有效的组织在一起。
程序员的负担重是因为事情被安排的乱七八糟的。
SCM的要点在制度，否则你连版本号规则的原因都会糊涂的，版本一多，恐怕就糊涂了。
需求、设计文档是一定要有的。有一次，我们要把一个已经非常成功的应用进行产品化，可是原先的开发人员都走了，文档也不全，结果必须重新开发；150个人月的创造消失了。

[10jqkA]

再来一段废话：
以上方法的采用，要坚从项目组、公司的实际出发；超越公司、项目组实际情况、实际组织架构的使用，效果很差。
方法一经采用，就要认真执行，不要走形式；走形式只会徒然增加工作量，在小组中产生负面影响。可以不拘泥于形式、名称，而更多地考虑实用。如：CCB对大家来说都比较新，但其实以前的开发中都有项目领导组、项目总控组、协调组这些组织，可以不改名，而让这些组织发挥CCB的作用—关键是发挥需求控制、项目决策的作用。叫什么名字有什么要紧呢？在本人的项目中，项目组只有一个CCB，但它决不仅仅是一个变更控制委员会，还是项目协调组，顾问团，项目监控组，它帮助项目经理进行决策、提供建议、提出批评并承担了一部分责任。一句题外话：CCB中一定要有反对派，一团和气是没有用的，而项目的领导者也应该有容忍反对意见的雅量。
方法在项目组中推行，不能只是发布一下命令这么简单—这是最低能的管理。一条命令得到执行有两种可能：一是原来就有执行这种任务的习惯，二是有明显“利益“驱动接受命令者去完成该命令。如果要推行上述方法中对于项目组和公司都是“新”的方法时，要充分考虑如何推动其开展，并且要准备在方法无效时果断结束它。
对于现在流行的一些新东西，如：PMP,PSP,TSP,CMM,RUP,XP,UML等新方法和概念，要深刻地思考和谨慎的实践，不是所有的东西都可以照搬套用。比如PSP的运用，本人就发现绝大多数程序员连0级都不能坚持完全做好（包括本人）；而CMM，2级许多公司还勉强，3级简直就是天方夜谭；UML经过这一年在国内的实践，证明它确实能给SA以很大的帮助，可是这一套东西太大了，能够完全掌握并有机会在实践中成功运用的人太少，其适合大项目、新项目的特点又限制了使用范围，而且需要培训整个项目组来认识、运用UML，代价相当高。

[headstart]

我只知道要我们公司的程序员写相关文档简直要他的命，都说态浪费时间了

[10jqkA]

没有意见了？
准备给分

[10jqkA]

文档当然是要写有用的，没用的谁都讨厌。
流程图在这方面是最臭名昭著的，基本上都是后来补的；而现在大多数文档都有它的影子。
文档的目的是协助思考，进行交流；没有这个目标，还是别写了。
要文档有用，变更控制和版本控制制度一定要有；如果没有，省省力气吧。