ABAP开发的项目管理问题
ABAP开发的项目管理问题
（本文来自ITPUB，摘其好贴求共勉）
来源：http://www.itpub.net/thread-878127-1-1.html
作者：http://www.itpub.net/space-uid-148218.html（alex8452）
ABAP开发是基于SAP R/3系统的二次开发，ABAP开发项目是整个SAP ERP系统实施项目中的一部分，项目的输入是来自实施顾问团队的“开发需求”，输出是R/3系统中的程序。
ABAP开发与以产品为核心的开发有很大的不同，开发一个产品通常是软件产品的构思着提出创意、想法，不断的改善设计，形成一个比较完善的产品形象，功能明确、结构清晰。大多数情况下能按照软件工程的一般过程，即需求分析、设计、开发、测试等过程进行。通常是从底层到表层构建一个完整的、独立的软件产品。
ABAP的开发需求是业务顾问团队提出的，业务顾问团队则是分析用户的需要，将其转化为有效的用户需求，提交给开发团队。ABAP开发的性质是二次开发，即在SAP R/3系统之上构建应用，对系统标准功能不能满足的地方进行补充，主要包括离散的各个模块、跨模块报表，标准程序逻辑的增强，基础数据补充维护，SAP标准功能之外的功能性扩充。而这些开发，是离散的，而且是不断提出的，由于通常客户驱动开发进度，且项目进展很大程度上受客户主管意愿之约，因此开发流程控制、过程控制、质量控制往往无法顺利开展。另一个问题就是项目团队往往由多方面组成，且进入项目的时间并不固定，难以达成默契。
虽然我现在只经历过一个ABAP开发项目，但我想ABAP开发项目的混乱，在国内应该是大同小异，控制的好的当然会有，但应该不多，我这个项目的实施方也不是小公司，因此推断整个行业状况大致如此了。
仅从我个人的一点体会提出ABAP开发项目管理的一些原则：
1 开发团队的输入严格界定，即开发需求需经过严格的审批和控制，仅由1人作为沟通点，这个人不是负责需求细节的沟通或开发，而是要控制需求的质量。
2 质量，必须有量化、硬性的指标规定，不能主观判断，因为个人的能力是有限的，不论从工作量还是从知识的了解深度都是有限的，那么量化的指标应当包括：必须填写的项次是否填写准确，需求提出的流程是否符合规范，程序功能是否描述清晰（需细化，如目的、运行方式、用户偏好等），有了量化的指标，才能硬性的执行。
3 责任，需求的提出者、文档的撰写者、程序的开发者、测试者要落实的人，并且在某一时期内负全部责任，负责不表示一定要受到惩罚，但若没有规矩，怎成方圆?
4 约定，无论是业务顾问团队还是开发团队，都应当遵守一定的约定，如：某一字段名称、文本描述，程序命名规范等，约定不可能在项目开始的阶段就制定出来，一定是逐渐出现，但是，一旦出现，就应形成约定，且应严格遵守。
5 审核，各个过程都应当有人负责审核，审核的依据应是量化、硬性的标准，靠个人的判断等于没有审核，原因就在于个人的压力、视野、能力都可能导致判断失真。
6 文档，一份文档在不同的人手中出现多个副本，多个版本，就等于失去了存在的必要，不知道哪个是最新的版本也就失去了参考的价值。因此文档必须管理妥当，尽最大努力避免一份文档出现多个副本。
7 开发与支持，相信绝大多数人都没有意识到ABAP开发和ABAP支持的区别，举一个简单的例子：业务顾问认为一个报表的数据有问题，跟另外一张报表数据对不上，于是业务顾问发送邮件给一个开发人员，希望他能帮忙看看这是怎么回事，那么这名开发人员要做的事情是查看报表、程序逻辑，分析运行结果、差异，答复顾问，这是一个支持过程，而非开发过程；而当业务顾问提出一个报表开发的需求，开发人员需要创建程序，这才是开发过程。当ABAP开发与支持混在一起的时候，两者的效率和质量都大大降低了，遗憾的是，我们的项目中没有区分这两项工作，因此应当明确定义团队成员的职责（可以轮换），而不应该工作内容混杂。
8 管理工具，我认为不使用工具与使用工具之间的差距，直接反映在成本上应在30%以上，因此花费一个项目的开发经费20%以下是完全值得的，而且越早越好。例如我们的开发团队：每年的成本在50万左右，我认为投入10万元购买开发工具用于提高效率是很合适的，况且开发工具的购买往往第二年以后费用会低不少的。开发工具可以帮我们解决很多很多的问题，最主要的是实现信息管理及检索，减少沟通成本以及沟通不畅造成的损失。
9 项目经理，项目经理的职责是通览全局，把握大方向，控制流程，调度开发资源，降低风险。项目经理不应当参与到开发的细节中，不应当亲自跟踪每一个细节（重要的除外，工作狂、精力超级旺盛的除外），他的重点应当在于及早发现导致风险的因素，提出解决方案。遗憾的是，我们的项目中也没有这个角色。
10 例会、个人日报/周报，例行制度可以提高开发人员的纪律性。
最后，也是最重要的，就是 执行。不论什么管理原则、实施方法，如果制定，就一定要执行，否则不仅这一条成为一纸空文，还会成为害群之马，不能执行的规定，相互之间助长气焰、滋生病态的开发过程，最终导致的是人人疲惫不堪，开发漏洞百出。因此，一条原则的坚持执行，远比面面俱到的理想过程要有价值。
第一个项目就有这个想法，勤于思考
功能顾问提出需求（需开发）或提交问题（需调查）
项目经理指定开发人员
设计经理区分开发优先级和修改粗度量（大中小）
abap开发人员运行程序阅读代码找出问题
设计经理、功能顾问、开发人员三方会议做文档复核
开发人员估计开发时间并完成开发和测试
功能顾问测试
================================================
实际上我个人觉得在开发需求文档里应该加上一栏测试数据用于程序员单元测试或debug，我们现在的顾问喜欢用贴图，可是数据都是生产系统的，开发系统很难找。。。
大家共同改进吧
<<1 开发团队的输入严格界定，即开发需求需经过严格的审批和控制，仅由1人作为沟通点，这个人不是负责需求细节的沟通或开发，而是要控制需求的质量。
我感觉这一点目的主要是需求源的控制，不过我不明白楼主所说的“仅由1人作为沟通点”是什么意思，既然这个人“不是负责需求细节的沟通或开发”, 那么他怎么来控制需求的质量？
在我看来能做的也就是合规性检查，也就是看看需求是否按照指定的格式填写，需求是否经过相关领导的审批。这样做是否能起到控制需求的作用呢？也就是说，符合需求样式书和经过流程的需求就是合理的吗？我看未必，如果不看细节的话，这两项合规性要求还是很容易满足的。
因此我认为合规性检查不应该但设一个人来做，根据开发模式应该由开发经理或具体的开发人员执行，理论上不合规的需求可以拒绝进行开发。
<<2 质量，必须有量化、硬性的指标规定，不能主观判断，因为个人的能力是有限的，不论从工作量还是从知识的了解深度都是有限的，那么量化的指标应当包括：必须填写的项次是否填写准确，需求提出的流程是否符合规范，程序功能是否描述清晰（需细化，如目的、运行方式、用户偏好等），有了量化的指标，才能硬性的执行。
我看楼主罗列的指标大多是需求文档的质量指标，我觉得这方面除了一些合规性的检查，大部分情况是需要人主观判断的。
就"程序功能是否描述清晰"这个例子，我觉得很难定出一个量化的指标。比方说程序的目的，可以写的很简单，如查看销售情况，查看库存情况，你觉得描述清楚程序的目的了吗？
<<5 审核，各个过程都应当有人负责审核，审核的依据应是量化、硬性的标准，靠个人的判断等于没有审核，原因就在于个人的压力、视野、能力都可能导致判断失真。
和第1,2点是同样的问题，我觉得这一点可行性不大。当然一些合规性的检查还是有必要的，督促大家按照规则办事。
<<6 文档，一份文档在不同的人手中出现多个副本，多个版本，就等于失去了存在的必要，不知道哪个是最新的版本也就失去了参考的价值。因此文档必须管理妥当，尽最大努力避免一份文档出现多个副本。
文档是我现在最头痛的事情，为了开发的效率，我们很多时候文档就是走个形式，具体的需求有业务人员和开发人员面对面沟通。但是如果人员流动比较大的情况下，没有文档的话很难把一项工作持续下去。但是写一份详细的文档要花费很长的时间，而且后期文档的更新工作也很烦琐，这方面我一直没有找到一个平衡点，一方面能有个文档能让业务人员、开发人员都开发的需求有个比较清楚的认识，又不花费过多的时间。不知道大家这文档方面是怎样的情况？
<<7 开发与支持，相信绝大多数人都没有意识到ABAP开发和ABAP支持的区别，举一个简单的例子：业务顾问认为一个报表的数据有问题，跟另外一张报表数据对不上，于是业务顾问发送邮件给一个开发人员，希望他能帮忙看看这是怎么回事，那么这名开发人员要做的事情是查看报表、程序逻辑，分析运行结果、差异，答复顾问，这是一个支持过程，而非开发过程；而当业务顾问提出一个报表开发的需求，开发人员需要创建程序，这才是开发过程。当ABAP开发与支持混在一起的时候，两者的效率和质量都大大降低了，遗憾的是，我们的项目中没有区分这两项工作，因此应当明确定义团队成员的职责（可以轮换），而不应该工作内容混杂。
楼主说的开发和支持工作确实内容上面不太一致，不过我不建议将这两项工作分开，与楼主的意见相反，我觉得如果将两项工作完全分开，工作效率会大打折扣。因为支持工作是需要有一定基础的，业务顾问说一个报表的数据有问题，支持的人如果不了解这个报表的目的和逻辑，他怎么去核查？那么谁最清楚这个报表的现状呢？当然就是这个程序的开发人员了。
而且我觉得开发人员有义务取做支持工作，你做的程序，出了问题不负责，反而交给别人去维护，说的过去吗？
<<8 管理工具，我认为不使用工具与使用工具之间的差距，直接反映在成本上应在30%以上，因此花费一个项目的开发经费20%以下是完全值得的，而且越早越好。例如我们的开发团队：每年的成本在50万左右，我认为投入10万元购买开发工具用于提高效率是很合适的，况且开发工具的购买往往第二年以后费用会低不少的。开发工具可以帮我们解决很多很多的问题，最主要的是实现信息管理及检索，减少沟通成本以及沟通不畅造成的损失。
不知道楼主所说的开发工具是不是泛指，包括需求管理工具，BUG跟踪工具等等，狭义的开发工具，在ABAP开发方面我不知道除了ABAP WORKBENCH是否还有更好的选择。
你们的这个流程中有一个重要的角色是设计经理，他做具体的开发工作么？他的时间中被coding 和 解答顾问问题占用多少时间？
还有一个重要的环节是三方会议文档复核，这个环节消耗很大的时间，如果这三方在不同的地方，你们如何开展？需要多高的沟通成本？主要指时间上
开发人员水平影响到开发效率和质量，效率和质量高低可能相差10倍甚至更多（现实问题）。
功能顾问测试，对于综合性报表，你们的功能顾问能否真正测试准确？比如销售结算数据，某一段时间内，某一类销售的结算数据，总量、平均量等，按照产品类别累加之后，很难想想顾问如何测试。
每个项目都有弱点，我的这些思考都是来自于我们的弱点，希望能和你多多交流
其实这10点体会，每一个都能拿出来让大家辩论上几天几夜的。
在你的批判之下，我再次重新仔细审视每一点，提炼思想，继续讨论。
1 【开发团队的输入严格界定】
我们的想法其实基本上是一致的，并无太大差异，只是仔细考究下来，跟我可能再犯同样的错误。
你说的“合规性检查”，是需要“规”的，“规”在人们心中肯定是不行的，“规”也就是我说道的量化、硬性的指标。“经过流程的需求”的确经常不合理，应该说是因为没人为后果承担责任。对一个15列数据的报表“看细节”，需要很多的时间。我觉得这个工作应该由直接开发人员完成，而控制的人则需要得到这个顾问、开发人员的确认：在文档细节上达成了一致。“合规性检查”若由较多人，如50%的开发人员参与完成，尺度可能不同，也可能由于失去了沟通结构导致流程失效。最后一点“拒绝进行开发”，对业务顾问说“不”，普通开发人员好难做到。
我觉得语言描述不够准确，有点混淆视听的意思了。如果这样表述可能更清晰：【开发团队只接受合格的功能说明书，拒绝低质量文档的开发要求，这一过程需要专人严格审核与控制】
以上文字中包括几个关键点：
1 功能说明书
2 合格的功能说明书
3 开发要求
4 低质量
5 专人
6 审核与控制
无论是从质量管理、流程管理还是内控的角度，【功能说明书】都是非常重要的，后续的一切开发皆源于此，重要性不言而喻。理想状态下，功能说明书的内容不一定细致，但要准确，即没有二义性。开发人员最怕的是理解错了顾问的意思。
【合格】的功能说明书是指达到一定的要求。我认为这个基本的要求是：首先符合“文档”的基本要求：格式；如果不遵循格式，或者只是胡乱填写，文档内容的威信就无从存在，存档的价值也就荡然无存了。其次，要简练准确，不同的项目开发过程有不同的要求，虽说开发人员充分理解业务后对功能说明书的要求会降低，但是从ERP实施过程看，再简单明确的功能、代码，经过几个月之后，也会被网的一干二净。“合格”的事实依据可以是这样：顾问提交的文档开发人员阅读之后，不会产生歧义理解，经过简单的电话、邮件、MSN等沟通之后，即可进行开发，而文档或修改之后达到不需再改的状态，开发人员据此开发程序能够满足90%的业务顾问设想，这份文档就算合格了。后续变更也需要更新文档，否则功能说明书也就不再合格了，说的更简练一些，文档与程序相符的时候，功能说明书是合格的。
【开发要求】是很不规范的开发需求提出方式，项目进度紧张，或有某些压力的时候，业务顾问可能口头提出开发要求，如编写一个例程、修改一个字段的取数逻辑。这种要求很容易成为下落不明的开发，这是害群之马，是堕落之源，大多数文档都是在1~2次【开发要求】之后变得没有意义。
【低质量】有时很难鉴别的，业务顾问写下sql伪代码，也不能说明就是高质量，有时繁荣拖沓的表述或说明文字远不如一个简单的截屏能说明问题，低质量的文档往往具有以下基本特征：从别的文档复制过来，标题甚至都忘记修改，乱七八糟的基本信息、大小不一的字体，仅有简单的截图排列下来，显然不符合项目中一般开发习惯的选择屏幕、字段文字描述等。简单来说，【低质量】判断的直接依据就是，开发人员在开发过程中，与顾问沟通了多少次，因为理解失误造成了多少的返工。
【专人】是说要有人承担责任，对于【低质量】文档流入开发团队负责，对于【开发要求】负责，要能顶得住来自顾问团队的压力，要能熟悉大部分的业务流程、系统配置数据等。对这个【专人】的要求是很高的，压力也很大。
最后说说最让人头痛的【审核与控制】，负责这项工作的人常常会由于各种原因导致审核与控制的尺度把握不好，而这种偏差，确总是会给开发团队造成伤害。原文中多处提出：量化、硬性指标，在这里也适用。最常见的办法是使用CHECK LIST，例如：
1 业务顾问信息是否填写？
2 选择屏幕是否定义？
3 权限控制方式是否填写？
等可以用简单 是/否 的回答的问题，除此之外，还有一些需要沟通的问题，如：
1 程序可行性是否与开发经理讨论过达成一致？
2 程序类型是否与开发人员讨论过达成一致？
3 功能文档是否经过业务顾问、开发人员沟通确认无误？
等等，以上几个例子我没有仔细推敲，但基本上可以说明问题了，就是用于提醒审核与控制者执行这个角色功能时的基本尺度以及控制点，只有这样，才能保证【审核与控制】的有效以及尺度一致。
往往只有在很完美状态下的才能实现这些要求，如业务顾问能够写出合格的文档、开发人员经验比较丰富，能够准确理解文档内容，进度允许我们花费1天甚至2天的时间完成这些工作以达到标准……
事情确往往不是这样简单，每个项目都有自己的痛楚和无奈，我想一套可执行的方案就已经很好了。
其它的观点继续研究中，陆续发帖，欢迎继续批判
浙公网安备 33010602011771号