当前很多时候是自己去领需求来开发，Scrum团队将由owner来接受需求，配合master来分析具体开发任务直至具体开发人，Owner精神是需要的，但是一个东西还没有分配到你的时候如何去owner？松散管理对于团队成型未必总是有效，ProductOwner必须充当需求认领人角色。

　　上面是一个团队改造的设想，几周前有这个构想了，或者说遐想。接下来开始演进笔者的看法。

　　Scumn在具体实施层面都给出了很好的实践，大师们勾画的蓝图确实很让人向往，然而脱离实际也是举步维艰的，笔者尝试将该方法论和现状结合，但还是出了问题。

　　显著问题之一，QA测试的介入，一般测试思想认为一个迭代周期后交付的部分功能测试往往会导致后产品完整完成需要重新测试，将浪费这期间的测试工作。笔者如下反驳：

　　QA用于保障产品质量，参与的测试以黑盒，功能性，验收性测试为主。作为终保障，更多的价值在于终产品质量保障，对于产品代码状况，设计质量无法涉及，而代码作为终产出，其质量直接关系产品质量，性能等，应该有充分的测试保障，核心代码的白盒/单元测试，系统集成测试，以及重要的对于业务设计的测试都不可或缺，测试驱动是一个可参考的实践，业界对于TDD评价颇高，可惜笔者目前未有实践机会。若转型为敏捷团队提供测试支持，更多的测试目的在于帮助验证产品设计，监督和提高产出质量，而不仅仅是为测试而测试。

　　回过头来，一个现实问题需要考量，QA部门往往独立于项目部门，编制不在一处，服务于此，现实利益相关的考核等约束使得测试人员不得不考量实际工作量和效益问题。凡事涉及利益，多半是无果…

　　问题之二，当前并无明确的项目概念，通常以零散需求为单位进行开发，多半是单个开发人员独立开发，从SVN不强制加锁即可窥见协作程度并不高，零散需求工作量长短不一，暂无一致的分配者来调剂，由开发人员自行安排，缺乏统筹和资源安排合理性，且人员技能组成不够理想，强行合并人员组建团队，磨合期恐怕较长，新scrum团队内的分工较难定义。

　　问题之三，基础系统以及相关积累的成熟度不够高，拆分多个团队必然容易导致团队按各自风格积累，统一标准为定义前，将产生多个版本的局部标准。

　　综上，论述了可用实践和相关的考虑，然而实际状态并非理想环境，一蹴而显然不可取，循序渐进为佳，如DDD全面实施成本较高，项目主体架构已基本成型，切换不易，笔者认为可取的架构目标应该是健壮底层和基础服务，提高自动化和规范化开发，降低开发和维护成本，应用层面的编码要求可适当放宽，以较可行原则来做合理约束即可，根据当前的技术能力组成，规避应用层面开发的技术风险或繁琐程度，企业应用求稳定之后再求体验和性能，稳定的响应在可接受范围即可，重点系统和项目实施DDD，TDD等，敏捷团队还是需要有意识的磨合和组建，思想转变后相信会带来不一样的成效。

　　这篇博文提笔之前，笔者认为写出来的想必是XX卫道者的思维去扯方法论，写完后，发现其实是希望记录下观点的转化过程。

　　鲜明观点到后被模糊了，不过文尾还是想提一些关于产品方面的东西，毕竟本文标题里也忽悠了产品的字眼，

　　本人虽自称已经UE疲劳，不过这玩意即使疲了也得做。

　　用户体验不可能只靠UED的，况且他们并非我们的直接资源，哪天没排上计划了不做体验了？ 部门通常需要制定一系列产品标准来引导和规范其产品的质量走向，这些标准落实到实际执行者，遵循优先，而不应只从具体人员角度去度量它是否有价值（往往是由于其实现成本而导致这个思想），如品牌形象一样，任何产品或部门必然需要树立起产品/职业形象，标准是帮助你在没有该意识的情况下达到这个树立形象目的。而标准也如双刃剑，若当前整体产品状况或阶段并不适合一个庞大而复杂的标准的时候，尽管标准很，也需要考量它是否合适于在当下实施，或者它的实施成本与实际价值的比例是否足够诱人，如果在稳定性和可用性都还未完美保障的时候大谈UE，结局惨淡笔者已见了不下少数。合适的阶段做合适的事。

　　近脑子一直有很多需要记下的东西，可能是过多过乱而又忙的无暇静下思考，故而酝酿了这篇杂烩式作品，希望观点杂糅在一起也能碰出一点火花吧。

　　本文转载自：http://www.cnblogs.com/wsky/archive/2010/05/28/1746013.html