再议惟独领导认同质量优先才能去搞敏捷
再议只有领导认同质量优先才能去搞敏捷
原帖 http://www.iteye.com/topic/1112913
我想强调是：
1. “正常商业环境”下，保证产品质量是最佳实践
2. 相对于产品质量，所有敏捷实践一致把严格遵守开发时间并做完用户所有想要的功能放在相对较低的位置。
3. 只有领导认为要做的产品/项目需求是质量至上，才适合搞敏捷。
关于1，这就好像达尔文进化论，适者生存。认同质量至上的公司，和那些一味强调时间啦，功能拉的公司比，更能适应市场，在市场上存活下来。业界把能较好生存发展的公司的做事方法总结出来，其中一些可以概括成-"敏捷实践"。所以敏捷实践就是保证产品质量的实践，这点不矛盾。
关于2，做“需求要求质量至上”的产品或项目时，敏捷是成功实践之一，但这点不能否认在有限资源条件下，敏捷把严格遵守开发时间并做完所有用户想要的功能放在较低的位置：scrum，每期启动会要做的工作之一，是根据开发人员认同的、能确保质量（符合用户功能需求，符合开发人员对代码质量的追求）的开发时间估计，去除相对不是那么重要的功能，保证在有限的时间内确实能出一些用户想要的东西，那么最终，要么在期限的时间内少做一些不是那么重要的功能，要么增加时间保证用户想要的功能都开发完成。XP，针对于用户没有特别清晰的需求，边做边调整。相对于scrum，xp更强调产品质量中满足用户需求的部分，短期内不对架构和代码质量有要求，而鼓励重构长期来看必然也保证了代码质量，但同时反复迭代，重构开发时间必然也不可控。敏捷如何应对客户开发时间紧，功能需求多的要求？我所了解的敏捷做法都是去说服客户，让客户认识到有质量的产品才是真正对他有价值的，而要完成真正有质量的产品客户必须要在开发时间、功能细节上作出让步。那如果客户的真正需求并不是有质量的产品，或者客户不肯在开发时间、功能细节上让步，敏捷怎么搞？！这点详细见3的说明。
关于3，可能很多人认为领导如果不同意质量至上，那说明领导不称职，说明公司没前途，没什么参考价值。但在中国，很多时候不是领导傻，不想把产品做好、把公司做大做强，而是中国的客观现实逼的！
在中国，有时某些人必须要迅速花掉某些预算，否则明年预算就少了；软件置备只是种快速花钱的手段而已。 这时客户绝对不会去关心什么产品质量，甚至都不会去关你的产品能不能真的用起来，只要能快速的把钱花了，有能让领导吹得的各类文档，有能让大领导满意的演示就行了。这类项目往往时间紧，要求的功能点巨多，文档名目巨多，但根本不要求产品真的能用！这时敏捷强调的重交互轻过程，重代码轻文档有什么用？！开发团队自管理能做出高质量的产品，对这类客户高质量的产品又有什么用？！如果有做这类项目的机会，哪个中小企业敢说拒绝？
在中国，有时客户的选择很多，竞争很激烈。如果你不是业内龙头老大能做到店大压客，那就面临客户货比三家，砍钱，砍时间，加功能。重客户协作轻合同谈判？客户很难量化产品质量，其他公司表示一个较短时间就能高质量的完成所有功能，你却要求增加时间或减少功能量以保证质量，那单子你还能签到么？销售人员拼了老命牛皮吹破终于把合同签了，钱就那么多，能为此分配的资源有限，时间很紧，做不出来违约；功能很多，做不出来违约；唯一的好消息就是合同里并没有对产品质量的明确要求。对这种项目，重个体交互轻过程，重响应变化轻遵循计划有啥用？光响应客户变化，到时候做不完违约赔死你。在你成为业内龙头前，这类利润不高的合同你敢不去争取？
以上我说的这些，领导绝不会认为要质量至上的，必然是时间点和功能量至上。你去推敏捷，这套“以保证产品质量为基准的最佳实践”，哪怕领导同意了，由于目标不同，你最多能执行一些敏捷的表象而不可能推行敏捷的精髓，敏捷必然会失败。 只有用户需求，公司条件，真的适合质量至上，领导才会认同质量至上，这时搞敏捷才有可能成功。如同类项目抽取成产品的，项目有几年后期维护合同的，客户允许你为了质量延期交付的，首先客观条件允许你质量至上，然后你再去搞敏捷
原帖 http://www.iteye.com/topic/1112913
我想强调是：
1. “正常商业环境”下，保证产品质量是最佳实践
2. 相对于产品质量，所有敏捷实践一致把严格遵守开发时间并做完用户所有想要的功能放在相对较低的位置。
3. 只有领导认为要做的产品/项目需求是质量至上，才适合搞敏捷。
关于1，这就好像达尔文进化论，适者生存。认同质量至上的公司，和那些一味强调时间啦，功能拉的公司比，更能适应市场，在市场上存活下来。业界把能较好生存发展的公司的做事方法总结出来，其中一些可以概括成-"敏捷实践"。所以敏捷实践就是保证产品质量的实践，这点不矛盾。
关于2，做“需求要求质量至上”的产品或项目时，敏捷是成功实践之一，但这点不能否认在有限资源条件下，敏捷把严格遵守开发时间并做完所有用户想要的功能放在较低的位置：scrum，每期启动会要做的工作之一，是根据开发人员认同的、能确保质量（符合用户功能需求，符合开发人员对代码质量的追求）的开发时间估计，去除相对不是那么重要的功能，保证在有限的时间内确实能出一些用户想要的东西，那么最终，要么在期限的时间内少做一些不是那么重要的功能，要么增加时间保证用户想要的功能都开发完成。XP，针对于用户没有特别清晰的需求，边做边调整。相对于scrum，xp更强调产品质量中满足用户需求的部分，短期内不对架构和代码质量有要求，而鼓励重构长期来看必然也保证了代码质量，但同时反复迭代，重构开发时间必然也不可控。敏捷如何应对客户开发时间紧，功能需求多的要求？我所了解的敏捷做法都是去说服客户，让客户认识到有质量的产品才是真正对他有价值的，而要完成真正有质量的产品客户必须要在开发时间、功能细节上作出让步。那如果客户的真正需求并不是有质量的产品，或者客户不肯在开发时间、功能细节上让步，敏捷怎么搞？！这点详细见3的说明。
关于3，可能很多人认为领导如果不同意质量至上，那说明领导不称职，说明公司没前途，没什么参考价值。但在中国，很多时候不是领导傻，不想把产品做好、把公司做大做强，而是中国的客观现实逼的！
在中国，有时某些人必须要迅速花掉某些预算，否则明年预算就少了；软件置备只是种快速花钱的手段而已。 这时客户绝对不会去关心什么产品质量，甚至都不会去关你的产品能不能真的用起来，只要能快速的把钱花了，有能让领导吹得的各类文档，有能让大领导满意的演示就行了。这类项目往往时间紧，要求的功能点巨多，文档名目巨多，但根本不要求产品真的能用！这时敏捷强调的重交互轻过程，重代码轻文档有什么用？！开发团队自管理能做出高质量的产品，对这类客户高质量的产品又有什么用？！如果有做这类项目的机会，哪个中小企业敢说拒绝？
在中国，有时客户的选择很多，竞争很激烈。如果你不是业内龙头老大能做到店大压客，那就面临客户货比三家，砍钱，砍时间，加功能。重客户协作轻合同谈判？客户很难量化产品质量，其他公司表示一个较短时间就能高质量的完成所有功能，你却要求增加时间或减少功能量以保证质量，那单子你还能签到么？销售人员拼了老命牛皮吹破终于把合同签了，钱就那么多，能为此分配的资源有限，时间很紧，做不出来违约；功能很多，做不出来违约；唯一的好消息就是合同里并没有对产品质量的明确要求。对这种项目，重个体交互轻过程，重响应变化轻遵循计划有啥用？光响应客户变化，到时候做不完违约赔死你。在你成为业内龙头前，这类利润不高的合同你敢不去争取？
以上我说的这些，领导绝不会认为要质量至上的，必然是时间点和功能量至上。你去推敏捷，这套“以保证产品质量为基准的最佳实践”，哪怕领导同意了，由于目标不同，你最多能执行一些敏捷的表象而不可能推行敏捷的精髓，敏捷必然会失败。 只有用户需求，公司条件，真的适合质量至上，领导才会认同质量至上，这时搞敏捷才有可能成功。如同类项目抽取成产品的，项目有几年后期维护合同的，客户允许你为了质量延期交付的，首先客观条件允许你质量至上，然后你再去搞敏捷