Post by "WilliamLuo", 10-30-2006, 14:11
-----------------------------------------------------
From: Liu Shibin
FYI
网上看到的一篇文章，不知是哪里的了，有的经验我们已经知道，有的可能还比较新，也许对我们有所帮助。
------------------------------
救火沉思录--关于项目最后阶段的思考
这几个月来，大部分业余时间，都花在阅读软件工程和编译原理方面的书籍上了。软件工程方面的书，包括软件需求、风险管理、敏捷建模，系统设计，软件项目管理，还有一些类似于的沉思录书籍等。
在这些书中，都只是讲了如何让项目健康发展，最后成功的提交一个产品。尽管它们都是从不同的角度，用不同的方法去完成同样的事。但它们几乎都支持这样的观点：计划+修正计划（不但设计是迭代的，计划也是迭代的）。用其中一个作者的话说，伤害你的，不是那些你没有考虑完整的，而是你根本没去考虑的事情。
然而，几乎没有一本书里，讲到关于消防队的事，唉，真是奇怪，老外声称有超过50%的项目是失败的，那么在他们的项目中，失火也是常事，为什么就不谈谈救火的招数呢？难道他们也相信，不叫出魔鬼的名字，魔鬼就不会找上门来吗？
唯一的解释就是，救火太难了，可能老外的救火能力远不如我们，他们干脆就不谈了。我在上一个项目中牺牲惨重，巨大的压力之下，和女友分手，精神上和身体上都受到极大的伤害，当然，我不是那个项目唯一的牺牲品，很多同事，他们很优秀，也一样的无助。之后，我一直在想，既然有50%的项目会失火，那么救火能力和计划能力至少是等同重要了。我苦苦的思索，回忆上次的经历，查找相关资料，然而收获甚微。
救火的银弹也许永远不会出现，我把自己一些经验写出来，或许对大家有点帮助，如果能达到抛砖引玉的效果那是更好了：
1. 在FIX BUG过程中，持续进行重构。在设计时没有做好，重做是不太可能的了，但绝望也是没有意义的，我们只能想法去改进它。利用前人一些经验，持续进行重构，每 FIX一个BUG，我们让代码更好一点，而不是更坏一点，FIX了一个BUG，代码中就少了一个BUG，而不是引更多的BUG。在实际上，重构最大的困难是没有完整的自动测试程序和测试用例，这使得我们根本不敢去改动代码，或者为了让改动最小，采取一些折中的方法，这都使得代码不断的变臭。在这种情况下，建议是建立自动测试，然后不断完善测试用例，我觉得建立自动测试任何时候都不晚。如果建立自动测试确实比较困难，那就列出所有的测试用例，然后手工测试。这时候，工程师的工作就是：重构à测试àFIX BUGà测试。有人说，我没有时间去重构，没有时间去测试。呵，这会使我想到，一个人围绕着一个小圆圈拼命的奔跑，累得半死的时候，发现在原地，他还在说，我没有时间去看清方向。
2. 关注常用功能。在项目的最后阶段，千万不要被QA牵着走，他们发现一个BUG，我们就FIX它。FIX一个BUG当然好，但是FIX BUG不是免费的，要不但要成本，还有潜在的风险。编译的优化原理是基于：20%的代码花了80%的时间。如果这个原理成立，可以推出：80%的用户实际上只使用20%的功能。QA并不是最终用户，QA和最终用户的不同在于：QA尽力去发现不常见的问题，而最终用户经常使用最常用的功能。这时候我们可以把自己想成最终用户，列出最常用的测试用例，如果不在这些测试用例中的情况，即使BUG的现象很严重，我们也要考虑一下再决定是否修改它。
3. 确定哪些BUG不改同样重要。这一点与2有一定的重复，为了强调有必要单独提出来。在软件需求分析时，分析师们都认为，要确定什么不在系统内和什么在系统内一样重要。程序员对于BUG态度，有时往往走两个极端：一种是老子就不改。一种QA怎么说我就怎么改。前者往往被看着工作态度不端正。而后者呢，却被视为好孩子。其实，在项目的最后阶段，后者未必正确，正如前面所说，FIX BUG不是免费的。这时候建立一个仲裁委员会有必要的，确定哪些BUG不改是他们的职责之一。
4. BUG分类，明确责任。以前接手别人一个模块，处于Pending状态的BUG已经有110多个了。要把每一个BUG都看一遍就要花几个小时，不看吧，每次改一个BUG时，总有只见树木不见森林的感觉。最初，我很努力的去修改BUG，进展还是甚微。后来我花了几天时间，仔细分析了所有BUG，把它们归纳几类：其它模块引起的BUG; 和其它模块的接口引起的BUG; 超出需求之外的BUG; 完全是本模块内部的BUG。然后把其它模块引起的BUG提交给相关人员，和相关人员确认因接口不统一引起的BUG，把超出需求之外的BUG提交给需求控制委员会，最后剩下本模块的BUG又根据引起BUG的原因分为几类。这样，这些BUG很快被FIX了。
5. 工程师应该积极寻求帮助。有什么自己解决不了问题，应该向知道的人请教，或者向上司寻求帮助，不要出于面子或者其它原因，而花费大量的时间。在项目的最后阶段，每一分钟都很宝贵，不要重新发明轮子，对于有共性的难题也应该由专人解决。
6. 项目经理应该把眼光放在全局上。项目经理应该更多的关注于全局的事务，不要学只想拿大红花的小学生。别只顾修改自己的BUG，你的BUG少，并不能说明你是个好项目经理，在项目失败时，你个人的BUG少，并不能真正减轻你的罪恶感。据说软件团队遵循水桶原则，最低的那块木板才是决定装多少水要素，而不是最高的那块。项目经理应该随时关注哪块是最低的，然后把它补起来，自己成为最高的那块是没有意义的。
7. Person Review以提高士气。呵，不知道有没有Person Review这个术语，反正我觉得挺好的，在项目的最后阶段，士气是非常宝贵的东西，可以说得士气者得天下。在前一个公司，每周一，老板会把每个工程师叫到他的办公室，一起聊会儿，聊天内容不限，多半是问问你这边工作上存在什么问题，有什么看法，非常坦白的谈一会儿，最后会得到他的鼓励和赞扬，自己感觉这对提高士气很有帮助的，当然老板最好是个好的煽动者。
8. Bug Review。建立一个Bug Review小组，他们的主要责任是：发现一些具有共性的BUG，确认哪些BUG需要FIX，哪个BUG不用FIX。有共性的BUG，让专人解决或者督促。不管一个BUG是要FIX还是不用 FIX，都要注明足够的理由。
9. 加强QA和RD之间的合作。呵，根据遗传学和适者生存原理可以知道，在最后阶段，BUG的生命力极强，往往花费很长时间才能重现。加上自然语言本身具有的二义性和个人看问题的侧重点不同，QA可能忽略了RD让认为很重要的重现步骤，QA的BUG描述在RD眼中也可能迥然不同。在这个阶段，直接到现场和QA 交流一下，可能会节省很多时间。同时也要尊重QA的劳动成果，这样他们才会更积极的配合。
10. 经验积累。每遇到一个BUG，想一想，它为什么会出现，为什么才出现，修改它后会有什么后果。把重要的记录下来，可能对自己和别人都有所启发，以减少犯同样错误的机会。
Reply by "St.Valentine", 10-31-2006, 18:18
-----------------------------------------------------
有点说不上什么感觉。对于Bug，倒是有点话说：
不管是因为对需求的理解在随着测试过程逐步深入还是程序在引导着测试人员，测试用例总是在不停的被补充——也许是件好事——致命的是最后补充的用例往往能发现更深层次的致命问题。于是，在普遍延期开发交付日期和卡死的交付日期之间，矛盾和紧张会一直在测试人员心中，很不爽的。
Reply by "morris", 11-01-2006, 9:36
-----------------------------------------------------
关于“更深层次的致命问题”的发现时机，我有些想法。
目前的现状可能是这样的：
首先、开发人员由于时间紧张或者个人的疏忽大意，没有认真细致地做单元测试，或者没有好好地对照设计书检查，就草草提交了自己的程序。
然后、测试人员刚开始测试的时候，都是发现大量的本应由程序员在单元测试中发现和解决的一些低级的甚至极其弱智的BUG。这些低级BUG花费和占用了很多的时间，去写报告和验证。
而后、到了测试的最后阶段，测试人员才开始接触到深层次的致命问题，而这个时候，往往已经接近项目的交付期限了，矛盾和紧张就在所难免了。
最后、为了赶上交付期限，匆匆忙忙Release了，结果到了用户那边，更多的深层次的致命为题暴露了出来......用户开始骂娘了......测试人员受到了指责......可究竟谁该挨板子呢？？？
所以，我始终认为，高质量的程序，是开发出来的，不是测试出来的。所以要求我们的开发人员提高责任感和质量意识，同时项目安排上要给出单元测试的时间，把属于自己的问题，在自己担当的阶段解决好，不要老让测试人员帮你擦屁股。测试人员的主要任务是来发现“更深层次的致命问题”地，不要让他们总在一些弱质低级的BUG上面浪费宝贵的时间，我们的测试人员不是端屎端尿的下人，请不要让他们总干一些下人的活呀。
以上，都是这几年经历的项目后的一些思考，用语比较粗俗，但是道理应该算说清楚了吧，呵呵
Reply by "WilliamLuo", 11-01-2006, 9:47
-----------------------------------------------------
>高质量的程序，是开发出来的，不是测试出来的
严重同意！过去我们没有专业的测试队伍，都是通过程序员自测或对测来保证质量，好像也没有遇到过太多的客户抱怨。是不是有了测试，反而就有了“反正还有他们把关呢”的想法？不知道这样说会不会引来板砖一片？:-)
Reply by "St.Valentine", 11-01-2006, 16:12
-----------------------------------------------------
深有感触，测试始终是很被动的。说得更切实一点，有时候单纯的测试是一个边缘的工作，我们很难看到测试的“功绩”——产品质量好了，说是开发的水平高；质量差了说是测试失误。不过换一个角度，如果让每一个开发人员都有作测试的经历，都尝一下Morris提到的那种无奈，相信开发的质量在下意识中已经得到很大的提升了。也许是一个解决方案（据我所知很多对质量要求高的软件公司都是这么做的）。
//原来开发人员自测不就是这个原理吗？
Reply by "SmiletotheLife", 11-01-2006, 18:15
-----------------------------------------------------
呵呵，接着拍转。好的软件是只靠开发出来的吗？换句话说，软件做的不好都是开发一手造成的吗？
从需求到设计 ，再由开发到测试，好的软件浸透着团队每个人员的心血。
同样不好的软件，每个参与的人都有可能是问题的始作俑者。
〉〉“不要老让测试人员帮你擦屁股”
开发人员是不是在擦设计人员的屁股呢？设计人员是不是在擦需求分析人员的屁股。。。？
互相埋怨，推卸责任，是永远做不出好的产品。
只有吸取教训，分享经验，互相鼓励才是出路。
我们是项目前期的问题，没人Check， 没有报漏罢了。
而这些都是定时炸弹，埋下了总有一天会爆炸，到了测试阶段，有人检查，才逐渐发现问题，可这时已经积重难返，病入膏肓了，只有加班和延期。
这也是很多项目，无论好坏，没有开发前，状态报告都是一路绿灯的原因。
Reply by "Shrek", 11-01-2006, 20:47
-----------------------------------------------------
没有做好的原因，我认为也简单，就是我们没有做到最基本的:
单元测试-->整合测试-->系统测试
我想说的是，没有理解每个测试的真正含义
Reply by "WilliamLuo", 11-01-2006, 20:55
-----------------------------------------------------
一直不太明白：整合测试跟系统测试什么区别？
Reply by "JerryMouse", 11-01-2006, 21:57
-----------------------------------------------------
顶这个贴！
有位仁兄说的好，让开发的做作测试，就理解了测试的辛苦，无奈了！
的确，遇到了一些很基础的bug，或者粗心等带来的bug，我们也只能说抱歉，然后花3秒钟修好。系统中出那些疏忽或者算法逻辑漏洞
等带来的bug，我觉得对测试来说还是可以忍受的，顶多忍受一天，第二天就可以fix了。相对比较难忍受的是，那些使得整个模块无法进行测试的问题！放心，开发人员这时候比测试的还着急呢！
另一方面，也希望项目中每一个角色对其他角色足够的理解和宽容，大家合作来做事情！还好一直以来我在的项目组都还算不错！说开发对测试有一定的依赖性，那是实话！一般来说，这种依赖的程度和（模块难度/分配时间）成正比！相对来说，如果时间充裕，我肯定会将能想到的方方面面都想到，提交的程序自然也自信满满，但更多时候，都是schudual安排的满满，一浪接着一浪，怎么可能作的没有漏洞，怎么可能会将每一个点都照顾到！
SmiletotheLife:
呵呵，接着拍转。好的软件是只靠开发出来的吗？换句话说，软件做的不好都是开发一手造成的吗？
从需求到设计 ，再由开发到测试，好的软件浸透着团队每个人员的心血。
同样不好的软件，每个参与的人都有可能是问题的始作俑者。
Reply by "morris", 11-02-2006, 9:32
-----------------------------------------------------
〉〉呵呵，接着拍转。好的软件是只靠开发出来的吗？换句话说，软件做的不好都是开发一手造成的吗？
赫赫，这位老大狭隘的理解了我所谓的开发的意思了，呵呵，诚然，各个环节都很重要，但是，一项工作要做好，必须有好的切入点，即要现有重点地推进。对于目前的状态来讲，需求上的、设计上的问题都有，都不少，但是这些要想在短期内大幅提高，困难太大。反而是，在Coding这块儿可以立刻展开的行动会很多。一说到自己这块儿有问题了，就赶快把别人也拉出来垫背，“高举旗帜地说软件搞不好大家都有问题，不是我一手造成的”，这个态度就不正确吧，就是在推卸责任吧。其实道理大家都知道，只要每个岗位的人都尽心尽责，把自己手边的事情干好，软件就不会差到哪里去。稍微耐心5分钟，就能避免不少低级的BUG，况且这些低级的BUG可不是设计出来的哦，想推都没有地方推，只好说：“唉，时间太紧张，工作太多太忙”。计划紧张是客观事实，但是，不能作为大量低级BUG的借口，详细设计书多看1分钟，多想1分钟，多问一句，就能少犯不少错误。
〉〉互相埋怨，推卸责任，是永远做不出好的产品
这里一顿大肆批判，没有埋怨的意思，只是希望能多从自身找原因，不要老强调客观因素，否则永远不能提高和进步。
以上，说得比较极端，仅供参考。
Reply by "WantSong", 11-02-2006, 9:33
-----------------------------------------------------
由于粗心导致的BUG与设计缺陷原因相比，影响还是小了很多；而且通过测试、code review和同级互查等工作可以过滤掉大多数的bug。设计缺陷却可能要到系统测试甚至上线后才能发现，这样增加的额外工数不言而喻。
设计缺陷不仅仅可能因为需求不到位，也有可能是设计失误。一般情况下，概要设计完毕后会拿给客户确认/盖章（在国内一般都这样，虽然拉着客户上了贼船，也有后来死不承认的，所以也说国内的客户不规范，呵呵），也会由客户承担一部分需求未准确传达的责任。目前的概要设计可能都会从日本那边过来吧，所以我们也没办法判别会不会有需求的问题，就当这部分是日方的责任吧。
详细设计可能会由我们来做。在项目前期检查（VAL）和验证（VER）的质量越高，相对产品质量也会高很多，带来的返工可能越小。楼上的几位都谈到了，我们在项目前期的时候就应该注意的，而不是等到项目尾声时救火。
Reply by "morris", 11-02-2006, 10:11
-----------------------------------------------------
〉但更多时候，都是schudual安排的满满，一浪接着一浪，怎么可能作的没有漏洞，怎么可能会将每一个点都照顾到！
这种牢骚话，感觉如果经常从开发人员嘴巴里听到，就很不正常了，呵呵。
〉相对来说，如果时间充裕，我肯定会将能想到的方方面面都想到，提交的程序自然也自信满满。
这种想法也有些理想化了吧，目前我遇到过的实际情况是，就算时间充裕，程序上的单纯由Coding造成的（不是设计）问题还是很多。真以为宽松的时间里大家都会用来不断Review和改进自己的代码吗？太天真和脱离实际了吧？
虽然长期不在开发一线战斗了，但是Developer的艰辛还是能够体谅地，所以我感觉这种状况要得到好转，要从两方面入手：
1、开发人员丢掉幻想，立足现有客观条件（计划、资源等），少发牢骚多努力，尽可能少出漏洞，照顾到更多方面。“怎么可能作的没有漏洞，怎么可能会将每一个点都照顾到”这种自我开脱的话就不应该说，要说也是其他人来替你说。大家都是搞开发的，能够体谅很多事情，但是要想有提高，就不能太多指望客观条件的改善，自己的主动性要加强，要努力改善工作方法，提高工作技能等等。
2、项目管理人员在编排计划时要留出单元测试等时间，开发工数也要保有足够余量。这个实际上却是很难做到地，因为我们的用户都是很“蛮横”地，呵呵，但是不能因为困难就放弃努力，能挣取得一定要争取，给项目留出足够的时间和资源。人有多大胆地有多大产的教训是深重地，一味地服从用户的“指示”也是非常可怕地。总之斗争要做到有理有利有节，最终目的只有一个，确保提交高质量的产品。这样才是负责任的做法，最后对甲乙双方都有好处。各方面的压力大，大家都知道，但是事情摆在这里，就是需要“真的猛士”。
〉的确，遇到了一些很基础的bug，或者粗心等带来的bug，我们也只能说抱歉，然后花3秒钟修好。
现在就是这种情况太多，搞得大家脸皮都厚了，说抱歉跟说谢谢一样，没一点儿愧疚感，呵呵，当初多花1分钟就做好，不是更好么，计划中难道1分钟的buffer都没有么？错误是难免地，但是稍微少一些好不好，取得一些进步就真得很难么？
最后：
言辞激烈，原于切肤之痛，本人脸皮比较薄，被用户指着鼻子数落的感觉确不是很好......集体要成长、信誉要提高、产品要好卖、待遇要增加......这一切都要仰仗诸位的切实努力才行呀，否则以上都只能是痴梦而已.....借用一句土的掉渣的话“提高质量，从我做起”，呵呵
Reply by "morris", 11-02-2006, 10:24
-----------------------------------------------------
〉目前的概要设计可能都会从日本那边过来吧，所以我们也没办法判别会不会有需求的问题，就当这部分是日方的责任吧。
这一点，反正从LeySer这边来说，如果是日方造成的需求方面的问题，决不会推卸责任死不认账，起码我接触的这一块儿不会。
目前的情况就是这样，需求由日方提出，概要设计一起做，详细设计开发方来做....都有一个对上个环节反馈和Check的作用。开发方也不是对需求这块儿无能为力，通过概要设计和详细设计的Review，就能提早发现和解决很多需求上的问题。
项目最后如果发现是由日方需求错误造成的问题，我想日方也会自惭形愧，努力配合改善的，蛮不讲理的情况不能说没有，应该不会太多吧。日方也在不断改进中...
〉由于粗心导致的BUG与设计缺陷原因相比，影响还是小了很多
提醒一下，上面这句话是典型的开发者思维，在用户那边，根本就不是这个道理。往往界面上一个由粗心导致的日语文字错误，在用户那边就是天大的问题，紧急度都是非常高的，因为，错字用户看不懂意思，严重影响使用不说，还降低使用者对我们产品质量的信任和印象，起码会想，“这家公司怎么做事情这么粗糙不谨慎，这点儿小事情都做不好？”，这个在日本是非常可怕的事情....
Reply by "WantSong", 11-02-2006, 11:14
-----------------------------------------------------
是不是跑题了？我想我们现在讨论的目的不是为了怎样救火，而是怎样避免失火吧。
“幸福的家庭都一样，不幸的家庭各有各的不幸”。救火表现为延误进度吧，那么延误进度的成因呢，可能是多样的。需求变更频繁就不必说了；即使产品质量很高，不合理的管理及计划也可能导致失火；此外资源不到位（人/物），遇到技术难题等等。
我想，并不是某几个环节做好了就可以避免失火，而是需要每一个环节都到位。
我想就任何工作而言，责任心是首要的。这个没有讨论的必要吧。
其次，就项目而言，每一个环节是递进的，需求不准确，设计不可能好，代码质量好也不顶用，……所以在前面环节上加大 VAL和VER的力度不但会降低成本，也会使后续的环节更顺利。整个环节都顺利的话，相对项目整体也会好很多。
〉再说，详细设计做充分些，就能减少所列举的字符集等问题，呵呵
对啊，同样的bug，如果是源于设计的修改成本就会比写代码时低级错误的要高得多。
我的意见是，如果要避免失火，我们在需求及设计上的提高效果会更显著
Reply by "morris", 11-02-2006, 12:04
-----------------------------------------------------
>我的意思是，从发现问题到解决问题所花费的时间和精力。 文字错误如果仅仅是笔误这一类的，修改相对容易很多；如果是字符集的问题，再严重些是调用服务的问题（数据是由别的程序提供），那就相对麻烦很多。
怕就怕容易的东西都做不好，被别人攻击为素质问题，呵呵
再说，详细设计做充分些，就能减少所列举的字符集等问题，呵呵
> 此外我们所说的上下文环境是项目尾声，还没有到提交给用户。
不要再关起门来搞建设了，用户都已经派代表常驻了，很多问题都能看到，呵呵，今后开发过程中不用户参与都不行了，呵呵
产品是用户的，人家有权随时检查状态，呵呵
Reply by "Alfred", 11-02-2006, 12:11
-----------------------------------------------------
我更多的同意 morris 的观点，尽管我也是一名 Developer。开发者自身确实有很多问题，其实大多数这些问题都来自于态度，对工作的态度，对软件开发的态度，这些决定开发者在一开始就只是为了完成进度，而不是为了想要开发出一个好的产品。
开发人员的态度决定了开发团队的态度，每个人的问题主要是靠自己克服，但其实开发者的领导更多的可以改善这个问题，使自己的团队更有士气，更有责任心。开发团队要提高容错性，健壮性，从而使团队的战斗力更强，处理问题的能力更强。
Reply by "SmiletotheLife", 11-02-2006, 12:16
-----------------------------------------------------
我希望这个讨论就此打住，无谓的口舌之争，毫无意义。
不断的从工作中吸取经验教训，才能利人利己。
Reply by "morris", 11-02-2006, 12:30
-----------------------------------------------------
SmiletotheLife:
我希望这个讨论就此打住，无谓的口舌之争，毫无意义。
不断的从工作中吸取经验教训，才能利人利己。
这个意见和本论坛的宗旨相违背吧，应该有什么说什么，充分表达意见，不是么？Communication是什么呢，可不就是口舌之争么？哈哈，不要怕伤和气，大家的目的都是一样地，问题摆出来，一起想办法。
〉不断的从工作中吸取经验教训，才能利人利己。
这句是大实话，地球人都知道，嘿嘿，但是就是不落实，看你能把我怎么办，霍霍，以前犯的错误，这次的版本继续再来一边。
我们需要通过讨论，找到好地解决办法，不是仅仅停留在口号上，说实话喊口号我更在行，嘿嘿
Reply by "WantSong", 11-02-2006, 12:32
-----------------------------------------------------
是不是跑题了？我想我们现在讨论的目的不是为了怎样救火，而是怎样避免失火吧。
“幸福的家庭都一样，不幸的家庭各有各的不幸”。救火表现为延误进度吧，那么延误进度的成因呢，可能是多样的。需求变更频繁就不必说了；即使产品质量很高，不合理的管理及计划也可能导致失火；此外资源不到位（人/物），遇到技术难题等等。
我想，并不是某几个环节做好了就可以避免失火，而是需要每一个环节都到位。
我想就任何工作而言，责任心是首要的。这个没有讨论的必要吧。
其次，就项目而言，每一个环节是递进的，需求不准确，设计不可能好，代码质量好也不顶用，……所以在前面环节上加大 VAL和VER的力度不但会降低成本，也会使后续的环节更顺利。整个环节都顺利的话，相对项目整体也会好很多。
〉再说，详细设计做充分些，就能减少所列举的字符集等问题，呵呵
对啊，同样的bug，如果是源于设计的修改成本就会比写代码时低级错误的要高得多。
我的意见是，如果要避免失火，我们在需求及设计上的提高效果会更显著。 龙灯花鼓夜，长剑走天涯。
Reply by "morris", 11-02-2006, 12:37
-----------------------------------------------------
Alfred:
我更多的同意 morris 的观点，尽管我也是一名 Developer。开发者自身确实有很多问题，其实大多数这些问题都来自于态度，对工作的态度，对软件开发的态度，这些决定开发者在一开始就只是为了完成进度，而不是为了想要开发出一个好的产品。
开发人员的态度决定了开发团队的态度，每个人的问题主要是靠自己克服，但其实开发者的领导更多的可以改善这个问题，使自己的团队更有士气，更有责任心。开发团队要提高容错性，健壮性，从而使团队的战斗力更强，处理问题的能力更强。
这种敢于自我否定的态度俺是万分地钦佩，敢于正视自己的问题，不护短，勇气呀！猛士呀！集体中有这样的Developer，真是感动和欣慰呀。
严重同意这个观点，没错，态度决定一切....确实，比起Developer来讲，leader能做的事情更多，火车跑得快，全靠车头带，霍霍
另外抱歉，俺是发散性思维，好像和楼顶的帖子有些跑题，霍霍
Reply by "morris", 11-02-2006, 13:02
-----------------------------------------------------
WantSong:
是不是跑题了？我想我们现在讨论的目的不是为了怎样救火，而是怎样避免失火吧。
跑了跑了，呵呵，抱歉我想说的话太多了，呵呵，就一口气都说了，霍霍
WantSong:
我想就任何工作而言，责任心是首要的。这个没有讨论的必要吧。
我觉得还有必要讨论，而且要年年说月月说天天说，我们在责任心方面吃的亏还少么？为什么不能常抓不懈？往往是大家都知道的事情，反而更容易被忽略，而恰好它是最重要的东西。
WantSong:
其次，就项目而言，每一个环节是递进的，需求不准确，设计不可能好，代码质量好也不顶用，……所以在前面环节上加大 VAL和VER的力度不但会降低成本，也会使后续的环节更顺利。整个环节都顺利的话，相对项目整体也会好很多。
〉再说，详细设计做充分些，就能减少所列举的字符集等问题，呵呵
对啊，同样的bug，如果是源于设计的修改成本就会比写代码时低级错误的要高得多。
我的意见是，如果要避免失火，我们在需求及设计上的提高效果会更显著。
我又来唠叨了，呵呵，我从不脱离实际谈问题。前面已经说得很明白了，需求和概要设计，开发方目前能参与的空间很有限。我们能做的是什么呢？在概要设计和详细设计过程中，尽可能发现前面阶段的问题，尽早向用户提出，请求确认和修改。但是这个有赖于需求方，也就是日方相关人员，不是我们想做好就能做好的。但是，Coding阶段很多问题我们能解决呀，先把我们自己造出的和需求方无关的虫子搞定了，再去说别人的问题。自己搞了一堆问题都半天弄不完，哪有工夫去帮别人解决问题呀。换个角度，coding都做不好，日方敢把需求和设计交给你么？少一些好高骛远，多一些脚踏实地，做需求和设计并不比Coding高级，呵呵
自己的工作做好了，让别人没话说了，就算着火，那也是日方的问题，怪不到我们头上（有些推卸责任的意思，但实际就是这样），虽然我们还要辛苦地加班救火，但是，问题捅到哪里都好说，因为我们没有错。但是，现状是，我们自己错了不少，吵架或者找地方评理的时底气就已经先泄了，呵呵，例子粗俗了一些，意思希望诸位看官能明白，呵呵
总的观点，做能做的事，做好能做的事。
是不是又有些跑题了？管他地，懒得开新帖子，这边儿聊着挺好，霍霍
Reply by "rickey", 11-02-2006, 15:42
-----------------------------------------------------
我也跟一下贴。
首先我想讲的是，当问题出现的时候，简单地将责任归咎于某个人的责任心或者能力的话，往往会偏离解决问题这个方向；
然后，再说一下开发和测试吧，说得不好，还请见谅：
1，对于一个功能模块的提交，导致很多低级的BUG，其产生原因，往往不是测试用例的不完整，而是根本没有进行测试；
2，如果开发出来的结果，与需要相悖，或者有遗漏的话，可能缘于需求方，开发人员，测试人员对需要的理解不一致所致；
3，对于应用软件的开发，我觉得Test Case的积累很重要；例如我们的Leyser系统而言，对新手来说，单就某些功能来说就很复习，更别说要理解那些晦涩的会计逻辑了；所以当修改一个业务逻辑时，都不知道到底有哪些方面的影响；这一点，我觉得应该向控件的同事们学习；
4，有的人批评，改BUG的时候不要“头痛医头，脚痛医脚”；不过我觉得理想的代码的结果，应该只需要关注出问题的那个点就可以了；不至于，每次脚痛的时候，去医院，都得来个全身的CT检查；
5，梦想：有一天我们的应用程序开发，也能像自动Build一样，来个自动Test；那一天，就不必在更改一个涉及到有多处引用的时候，胆战心惊，心里没底:-)
Reply by "morris", 11-02-2006, 17:11
-----------------------------------------------------
rickey:
首先我想讲的是，当问题出现的时候，简单地将责任归咎于某个人的责任心或者能力的话，往往会偏离解决问题这个方向；
我们现在不是再说具体问题的解决方法吧，而是再讨论造成目前着火很多的原因，就coding部分暴露的火苗来看，我还是比较倾向于责任心和技能问题。
rickey:
1，对于一个功能模块的提交，导致很多低级的BUG，其产生原因，往往不是测试用例的不完整，而是根本没有进行测试；
那么，根本没有进行测试的原因是什么呢？做计划的时候没有安排单元测试的时间？还是程序员过于自信感觉不用测都行？还是因为加班累坏了而忘了测试？反正结果不好，自己不测测看就敢提交代码，敢这么做的只有两种人：真的猛士，或者自我感觉是猛士的人。后一种情况不能说是责任心强的表现呀，呵呵。
rickey:
2，如果开发出来的结果，与需要相悖，或者有遗漏的话，可能缘于需求方，开发人员，测试人员对需要的理解不一致所致；
对，这个问题暴露得也比较多，所以必须多做Review，多Check，没有人能一次把需求吃透，需要不断的学习理解才行。
rickey:
3，对于应用软件的开发，我觉得Test Case的积累很重要；例如我们的Leyser系统而言，对新手来说，单就某些功能来说就很复习，更别说要理解那些晦涩的会计逻辑了；所以当修改一个业务逻辑时，都不知道到底有哪些方面的影响；这一点，我觉得应该向控件的同事们学习；
这是个历史遗留问题吧，我们的系统确实是非常复杂，而且文档等储备不足，或者说有文档但是过时的不少，新手上来，不碰几次墙，是很难抓住脉搏地。向控件的同事们学习！学些什么呢？希望能有更多更详细的内容。
rickey:
5，梦想：有一天我们的应用程序开发，也能像自动Build一样，来个自动Test；那一天，就不必在更改一个涉及到有多处引用的时候，胆战心惊，心里没底:-)
我也有个梦想，有一天我们应用程序的开发，能根据需求描述，比如usercase图什么的，直接自动Coding，根本不用什么Test，因为肯定没有粗心大意造成的BUG，呵呵，发现不对劲儿了，直接该需求描述，然后再Build一遍，搞定，绝对不会提心吊胆，呵呵，担心做出来的和想要得差距太大，呵呵。
不过责任心不强，很难保证需求描述部分也没有低级BUG，呵呵，所以，工具和手段不能解决所有问题，呵呵
不过我不指望在有生之年看到梦想实现了，呵呵，手边的工作，还是需要我们一起努力来改进，呵呵
Reply by "St.Valentine", 11-03-2006, 9:35
-----------------------------------------------------
先明确一下，Rickey指的Test指在提交到测试组之前进行的测试。首先一个比较核心的问题就是，据我所知我们目前还没有一个硬性的规定对单元测试为代表的自测有充分的重视——可能主要原因来自于我们是按照人月数跟客户谈价钱（而控件不是这样的），而客户不愿为自测买单，所以。。。
关于Rickey的3，我认为应用的开发和控件的开发在测试理念上有着极大的差别，应用是基于数据驱动的测试，而控件是基于对象驱动的测试。相比而言，对象驱动更容易形成一个测试用例的穷举列表，并且维护起来相对简单。数据驱动测试在这方面就会变得很困难，成本也非常高。
关于5，hiehie，理论上自动测试可以由测试组开发，每天build后自动运行。只要自动测试的用例足够完善就可以实现Rickey的愿望了。但是目前的情况是自动测试如何开发，测试用例如何维护？经验还几乎为0。更重要的是，在测试组的测试进度因为某次失火或其他原因导致进度紧张（几乎每个项目都是这样），第一个被砍掉的就是自动测试，然后是性能测试。即便自动测试凭借着测试人员在业余时间搞出来了，谁来维护？看看手底下正在维护中的很多修改日期在去年的今天的Shisan自动测试脚本，马上就能赶到及时维护的重要性。总之，对自动测试我比较迷茫，对于一个仅仅能靠编程而不是录制的数据驱动自动测试（工具所限，录制几乎是不可能完成的任务，于是大量时间花在编程来实现输入，留给编写自动测试用例的时间。。），我很悲观。
Reply by "Shrek", 11-03-2006, 23:18
-----------------------------------------------------
Manager做好了，救火现象是可以避免的，因此好的PM是非常重要的.
回顾前面大家提到的问题，其实都可以在PM工作中体现出来
Reply by "rickey", 11-10-2006, 15:23
-----------------------------------------------------
理不辩不明。
很多误会，都是因为交流不够顺畅，不知道对方的真实想法引起的．
有个典故叫，＂乞者不食嗟来之食＂．
施舍者认为自己一片赤诚，他怎么就不接受呢？
因为乞者有自尊之心；
有句歌词叫，＂不是每颗真心，都会有人珍惜＂．
其实可能并不是她／他不懂珍惜，
可能是你就没让她／他明白这是你的真心．
听说，国外经常会有学者，因为一个问题而争的面红耳赤，
但底下又是很好的朋友．
其实就个人而言，我非常喜欢这样的工作态度，
我也很庆幸有这样一个地方，可以对某件事充分发表自己的意见．
"Impossible is nothing." --Adidas如是说．
"Anything is possible." --李宁如是说．
＂人有多大胆，地有多大产．＂－不知道谁说的．
说法不一样，目标都是想把别人认为不可能的事，
变为可能． |
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图