偶然之间，再次读到developerdotstar上转载的Robert L. Glass的文章《Success/Failure Criteria: Some Surprises》，上面罗列了最近的一些从真实软件项目中收集来的数据，总结了一些决定软件项目成功与失败的因素，其中的一些数据对习惯于传统软件工程思维或停留于纸上谈兵的人们应该具有很大刺激性，Some Surprises是肯定免不了的了。
去年差不多这时候就读过这篇文章，当时就觉得很有意思。有意思之处不在于使我surprised，恰恰相反，在于很多数据或结果佐证了我的想法。原本对自己的与众人“格格不入”的想法还心存疑虑，这下有了真实世界的数据撑腰，可以直起腰板了:)
当然，虽然我的某些想法或做法可能在Process非常严格的公司环境下显得有些格格不入，并不是因为刻意想标新立异，而是实际的情况使然，从本科做毕业设计开始参加的第一个实际软件开发项目以来，大大小小的正式项目（学校里的作业当然不算，只算最终软件要投入使用的）也有十来个了，在此过程中发现现实中的软件项目实施过程因为各种原因，往往与“传统智慧”不那么相符，或完全相反，而影响项目成功的各种因素也不是理想中的那么简单。
困惑引人思考，而思考就会有怪想法（上帝发笑），怪想法被证明为符合真理当然是令人得意的，不过得意忘形就不对了，所以还得时刻对自己的想法做检讨和检验。从最初看这篇文章到现在，一年过去了，现在就着这篇文章对软件工程作一番思考应该也是有价值的，学习老牛吃草的精神，吃的时候快速吃，吃过以后再抽空反刍。
现在反刍时间到了，以下英文为原文，中文为评：
Brisbane, Australia - At a breakfast seminar here June 6 on "Factors for IT Project Success and Failure," Prof. June Verner of NICTA (the National Information and Communication Technology institute of Australia) provided a fascinating mix of surprises and predictables related to her subject topic. The findings came from NICTA’s study of 400 projects in the U.S., Australia, and Chile, using questionnaires and interviews to discuss success and failure factors with practitioners.
What were the surprises?
- Most projects that had no schedule were successful
- 没有schedule的项目居然会成功？第一条就让很多人感到非常surprise了。
- schedule的用处何在呢？是不是说在项目开始之前定一个schedule就意味着项目会按照schedule进行？当然不是了，下面就有一条说75%的项目都会估计不足，因此延期是太正常不过了，Microsoft等软件巨头就经常宣布软件延期发布。因此schedule的存在对项目实际进行只能是辅助作用，在团队之间或内部起交流沟通之用，使大家在时间上有共同概念。如果团队成员间的沟通很好，或大家能有默契，把工作分块后放入工作池，每个人都从工作池中以最优化的分配算法选取任务，以最快的速度完成任务，再次取任务，如此循环。有什么理由需要事先制度一个详细的schedule呢？
- 详细的schedule可以项目开始时制定出来吗？当然可以，但要想准确就难了。随着项目的进行，总会有很多一开始预计不足或变化的情况出现，按照之前的schedule肯定没有办法执行。因此，schedule的制订并不是一劳永逸的，需要在项目进行中随时调整。
- 有schedule意味着最有效率吗？当然不是。上面所设想的工作池方式才是最有效率的，当然那是理想的情况下，团队成员没有个人的私心，一心为公，实际是否行的通还没有验证过。在事先制定schedule的情况下，由于大部分人都有把工作拖到最后一分钟的弱点，往往即使在工作可以提前完成的情况下也拖到最后，使效率比理想情况下低很多，往往还造成延期。为了克服这点，往往在安排schedule的时候会刻意把任务完成时间提前，将克扣的时间放入缓冲池，以待不时之需。
- schedule是如何制定的呢？当然理想情况下是根据项目从需求到任务分割，再根据关键路径排出项目的详细schedule，得出一个软件发布日期。实际情况呢？往往很多项目先有一个deadline，根据deadline往前推，这是项目时间紧张情况下的惯常做法，往往安排的schedule是“不可能完成任务”，造成不是延期的“延期”。
- 如此看来，这条并不surprising。只要对团队的管理和建设做的很好，完全可以在没有schedule的情况下更有效率地工作，成功有什么惊奇的呢？！
- Requirements are needed for project success, but not necessarily early in the project
- 做项目当然得有需求，大家总得对做什么东西有个共同想法，这是毫无疑问的。但很多人往往又对需求太过强调了，以至于非得等所有需求确定后才能开始工作。这又走火入魔了。尤其在做项目的时候，往往客户是不可能一次性给出所有要求的，我们也没有办法做出一个一百年不变的需求设计，在项目的实施过程中会很经常地改变需求，这是正常的。因此，在项目的早期可以根据一个很粗略的需求开始工作，待项目过程中和用户的不断互动逐步明确需求。
- 需求天天变，开发也时刻跟着变，还怎么往下做啊？需求的确可能天天变，但开发不需要时刻跟着变。可以对需求改变做管理，分批处理。
- 如何使软件开发更适应变化？这是很大的话题。但有个总的原则：使开发团队能力提高，反应越敏捷就越能适应变化。一些技术可以帮助项目更适应变化，如code refactoring、test driven、AOP、OOP等。
- Projects often continue successfully for some time with unclear requirements
- 项目可以在一段时间内在不清晰的需求情况下顺利进行。但接下来呢？当然需要清晰的需求了。
- 如何能获得清晰的需求呢？快速原型法当然可以。但是编写原型花费的努力就白费了，并且通过一次原型演示就让用户说出所有要求好像也难了点。近几年的Agile方法更进了一步，在开发过程中引进客户代表一起工作，用小的release让客户代表反馈，利用反馈收集需求信息，逐步明确需求。
- 客户代表的想法不错，但往往是请不到客户代表的。怎么办？只能在初步了解用户需求后，按照自己的设计开始工作。完成第一版后让用户反馈。只所以说自己设计是因为中国的客户很少有自己能说出需求来的，往往都是我们按照自己的想法去设计，引导客户。这点在国外的客户可能会好一些。
- The choice of requirements methodology does not matter; UML was "no help"
- 这对UML的“粉丝”来说是不可接受的，软件工程可以没有人，怎么可以没有UML呢？当然不否认UML在某些情况下的价值，但对UML的顶礼膜拜大可不必。UML只是一个工具而已。requirements methodology 是需求管理的工具，UML也是，工具嘛，使着顺手又有效率就可以了，管他是什么UML呢！
- Using a development methodology was a success factor, especially when it was "appropriate to the application"
- 无论采用什么方法，总得有个方法，这个方法会指导项目成员做事的方法、过程，统一团队的行动及标准。其实无论成功或失败的项目，都有其开发方法，即使完全没有所谓的methodology，那也是一种methodology
- Methodology没有好坏之分，但在具体项目中是否有效是有差别的。各种开发者论坛里经常有Methodology之争，这个说要遵守严格的瀑布模型，那个说不应该守旧，应该用Agile，其他人则有Lean、Rup等等，公说公有理，婆说婆有理，谁也不让谁，都说自己的是最好的，其他人的是错误的。其实这和瞎子摸象一个道理，大家说的都对，在自己的项目环境下，他们所坚持的methodology都是有效的。
- 每个项目应该以自身的特点选择methodology，开发一个用户社区网站和开发航天飞机系统软件当然不需要用同样的methodology，好比杀鸡不用宰牛刀，宰牛当然也不能用杀鸡刀。
- 选择methodology一定要大家公认的methodology吗？当然不需要。更有效的做法应该是在每个项目开始前和项目组成员一起根据情况自己制定一套methodology，这个methodology独一无二，也许其他人不理解不认同，但只要项目组成员一致认同就可以了。遵守自己的methodology，让别人说去吧：）
- 法无定则，随需应变。盯住目标，关注环境变化及上下文。
- Very few projects use risk management, and those that do rarely manage those risks
- Risk永远都会有的。对于可预见的risk可以未雨绸缪，甚至立下制度，而对不可预测的risk也无需那么战战兢兢。如果不能提前知道山上是否有路，又必须越过这座山，而不能绕过，那么就相信“车到山前必有路”好了。
- 可以在项目过程中把各种risk收集到一起，关注可以采取什么行动可以mitigate或者remove这些risk，追踪这些行动执行情况，及时update这些risk状态。
- Post mortem reviews are rarely held, and when they are it is almost always on successful projects
- “失败乃成功之母”，这句话从小至今作文中无数次提及，人人熟知。但“成功之父”在哪儿呢？应该是对失败的反思。如果不能对失败认真反思，何谈吸取教训走向成功呢。
- 每个项目（无论成败）过后都应该举行反思大会，根据目的不同，可以分几次举行，每次相关人员都必须出席。会议上回顾本项目做过了哪些事，哪些效果好需要继续保持，哪些效果不好需要改进，哪些无须做，哪些没有做而应该做等等。每个人畅所欲言，最后总结。作为项目介绍的一个反馈环节，可以对下一个项目很有帮助，对项目组成员也是一个学习改进的机会。
- 时间比较长的项目在项目中适当的时候也可以举行。
- In the U.S. (but not elsewhere), developers are involved in project estimation only when there are poor requirements (Verner speculated that this is because the powers that be were looking for someone to blame!)
- estimation一般由最了解项目的人来做，是否必须由developer来做倒是不一定。
- 鄙视寻找替罪羊行为！
And the predictables?
- Success comes from a culture that investigates and deals with problems
- 每个项目都会有问题，要想成功必须解决问题。解决的必要步骤就是investigation，了解清楚后根据情况提出解决方案。
- 问题解决文化是一种不畏惧问题、不躲避问题的文化。
- The vision for the project (its business goals) must be shared among all project personnel, especially the project manager
- 让团队成员都清楚项目的vision或目标，看似很明显的基本原则。
- 实际的项目中经常是：不知道项目vision的PM有之，不知道项目vision的成员也很多，这往往给项目的进行造成很多麻烦，但实际情况就是这样的。
- PM往往认为自己不需要懂技术，进而对于项目做什么、做成什么样也不去了解，或没有能力了解。最终往往变成schedule的recorder。
- 很多成员认为自己只需要知道自己的那块任务就可以了，对于整个项目无须了解，也懒得花功夫。最终很多人只知道自己的任务，而不知道自己的成果对项目的作用何在，不能从全局考虑问题，埋藏很多bug而不自知。在这样的环境中，各种review机制很难执行，因为大家对其他人的工作没有足够的了解。没有vision的成员也很难获得成就感，很难打造一个强凝聚力的团队。
- 解决这个糟糕局面只能靠一个或几个“操心”人，掌控大家的工作，粘合到一起，面面聚到。对这些“操心”人就一个字：累！
- 解决这个问题：
- 成员努力了解整个项目的vision，不仅仅有这个权力，更有这个责任。
- 创造机会让团队参与vision的设定与维护。比如重要的会议让全体成员参与，其他会议的会议记录放在公共的地方或发邮件给全体成员。
- Project managers should be involved in the estimation activity
- PM往往由于认为estimate是技术人员的事，往往只拿到最终结果。
- PM需要知道项目要做的几块事，需要了解大体情况，和相关人员一起estimate是一种必要方式。
- Project managers should be good at customer and developer communication; they need not be good at the technology
- 和用户沟通中的相关技术细节可以指定一个技术负责人和用户沟通，SE当然可以。
- 还是那句话，PM还是需要懂一点技术的，虽然不需要good at，至少要有共同语言。
There was some interesting data from the study, as well:
- 60% of organizations have no process to measure benefits
- 86% of projects had a business case, but 60% ignored it
- 结合市场可能是大家都知道的，但大部分仅仅停留在口头上，没有好的措施来在行动上也保持对市场的关注。
- 33% of projects said they had no risks, but 62% of those failed
- 身在祸中不知祸，只缘身在项目中！ 人总有一种盲目的乐观。
- 49% or organizations have had (one or more) project failures
- 可能有90%的组织或公司会否认这点。他们的确大部分项目都完成了，产生了软件。但这些软件是否在用户那里运行的很好，和客户预期相符或超出预期？问到这里估计就“顾左右而言它”了。当然这条的failure标准下面是有的。
- In one-third of the projects, the project manager had no say in schedule/budget targets
- 75% of projects were underestimated, none were overestimated
- 同样的原因，人有盲目乐观的倾向，对困难会预计不足。同时，随着项目的进行，用户的需求会逐步细化，并且越来越多，很容易失控，一开始的估计不足也就不足为怪了。
- 从本人的经验了来看，也有同样的问题，一般我的估计*2是比较符合实际的，所以有时候不得不在最初估计之后再乘一个系数:(
- 5% of projects had no project manager; 16% changed project manager at least once (and that was correlated with project failure)
- 有没有正式的PM这点不重要，关键看有没有人负起这个责任。小的项目没有必要设置一个专职的PM，可以兼任。
- 在项目过程中换PM是比较忌讳的，尤其是PM参与项目的越深入，换PM带来的影响越大。PM往往决定了这个项目的运作方式，甚至一下methodology的选择。无论对国家还是对项目，政局不稳都不是好事。
Verner also asked developers what their criteria were for project success. They said:
- They had a sense they had delivered a quality product
- They had a sense of achievement
- They had enough independence to work creatively
- The requirements were met and the system worked as intended
- 这些标准也挺有意思，来自于developer，而非商务部门，如果换成商务部门，肯定就不是这样的标准了，相信成功率也会提供很多，因为他们关心的是有没有赢利。而很多项目的确赢利了，但对于developer和客户来说，这样的项目还是失败的，因为这些项目或者没有给developer带来成就感和自信，或者没有给客户带来价值。
当然，上面的数据收集过程以及数据分析方法是否正确无从知晓。数字能说明很多问题，也有很多问题无须数字说明或数字说明不了。无论怎样，实践检验真理，在软件项目管理上，这点是没有错的。
没有评论:
发表评论