近，在Agile Leaders邮件列表中，Dan Mezick发起了一场关于敏捷教练是否该有职业道德规范的讨论。Dan写道：

　　当潜在的客户致电谈论有关敏捷教练的事情时，他们通常只有很少敏捷方面的经验，对敏捷的理解程度也比较低。甚至几乎不了解敏捷，要寻求高度专业的指导。

　　同时，敏捷教练又必须创造效益来谋生，这样他们可能有意或无意地造成客户对教练的依赖。这样极有可能产生机能障碍（dysfunction）??他们会很快陷入严重的互相依赖的机能障碍中。客户寻求专家来告诉他们“应该”做什么，可实际上却把招募的教练置于更高权威的角色和地位上去。而教练在一些重要事项上会左右为难。

　　对此James Schiel回复说：

　　我倾向于相信因果报应。换句话说，别惹你的客户，因为不管你赚了多少钱，终都会失去他们的信任。

　　James O. Coplien并不赞同此观点：

　　我觉得制定职业道德规范??比如像美国银行业协会（ABA）所做的??基本没有效果。我认为良好的职业道德规范终将会成为大家常识中的基本要求，如消除障碍并转向透明的态度，以及可以进行开放、富有成效的对话的环境。即，如果你已经在实践敏捷的价值观，那么在某方面，人以及人们彼此之间的互动应该是占据主导地位的，却会发现有一套道德体系处在流程和工具中。它也会加入一些不变的东西，导致在某些方面，本应该是敏捷教练能灵活处理的事，却变得非常僵硬和不灵活。

　　Dan Mezic对敏捷教练和设立了从业道德标准的其他形式的教练作了比较：

　　对通常所说的教练，已经建立了从业道德标准，而且形成了稳定的基础。它们来自于国际教练联盟（ICF，International Coach Federation），而且被其他组织所使用，比如美国教练培训学院（CTI，Coaches Training Institute）。我们可以把“ICGCodeOfEthics”（译者注：指The Institute of Career Guidance Code of Ethical Principles，职业道德规范准则指导学院）当作基类来继承，用来给我们创造出新的精细详尽的道德规范类……我们可以调用使用了国际教练联盟（ICF）标准的“AgileCoachingEthics（敏捷教练职业道德规范）”类作为基类。在ICF标准中没有说明：采用权威的立场（或者不是）并没有考虑到“客户想要的”是什么。

　　客户经常对真正的需求毫无头绪，他们通常寻求的只是“止痛药”。我们的工作是要千方百计地为他们服务。

　　James指出，结构化的道德体系可能违背敏捷的原因：

　　记住，职业道德规范目的在于：当情况太过复杂或你被搅乱头绪时，用它来帮助你采取行动，以做出“正确的”（无论那意味着什么）决定。它完全未顾及敏捷本身的特性，因为敏捷所有的一切都是关于透明地支持开放性对话的，而不是依照从业道德体系采取专断的行为。

　　我并不是说它没有意义，只是……基本没有通用的道德，更别说通用的道德规范了。我认为你完成发布敏捷教练职业道德规范列表的方法是使用命令，而那是违背敏捷原则的。

　　所以我认为费劲做这件事很可能是自欺其人，这样说并不是因为我缺乏意愿或需求，而是由于它的这种结构化的方式。

　　Peter Stevens补充说：

　　敏捷联盟有职业道德规范。我认为应该要求敏捷认证教练CSC签署这份规范，不过我也不确定（而且我更不确定Scrum认证教练CST的情况）。

　　Dan总结说：

　　我相信关于敏捷教练是否该有专门的职业道德规范的讨论很有用。敏捷教练是独特的行业，他们至少有可能极大地帮助或者伤害客户组织。还有一些关于敏捷是如何被视为整体的推论，说是因为敏捷教练（理论上）参与建立了敏捷的道德和原则。

Gene进一步阐述了该讨论：

　　我觉得详细讨论这个话题非常重要。因为敏捷教练这个角色相对来说仍然还很年轻（起码它不会比敏捷/Scrum本身存在的时间还长，对吧？）我们得承认它仍然有需要改进的地方，而职业道德规范可能正是这些改进点中很好的一个方面。

　　显然，作为教练，我们被给予了改变行业状况的巨大力量，重建组织、影响人际关系，而且有可能引起业市场的变化。我们必须确保，当我们给客户提出建议和提供指导时，我们能时刻牢记他们的基本利益，并且不会操纵他们来为我们、教练或是我们所代表的人服务，而是更多地关注客户的利益。

　　关于这个话题，Dan Mezick在他的博客里写了更深层的想法。你可以在独立的敏捷和敏捷教练职业道德规范的用户故事查看他的文章。

　　你的看法呢？敏捷教练应该有职业道德规范吗？

　　1、敏捷过程中测试人员如何参与？具体如何配合

　　敏捷中的sprint backlog详细标注了每个迭代过程中的任务和目标，开发人员负责代码编写，测试人员准备测试用例。迭代中，开发人员不断集成以进行开发测试。在sprint结束时开发人员为测试人员集成一个完成了所有sprint目标的可测试版本。

　　2、敏捷过程中的质量如何衡量，一个story开发完成后，或者说一个迭代完成后，如何知道这个story（迭代）的质量是好的？统计用例的通过率？ut的覆盖率？还有没有其他的衡量标准？

　　同上，story的质量是有测试人员进行保证的，用例通过是每个sprint的基本目标。ut是用来保证代码质量，ut覆盖率高不代表没有问题，覆盖率低也不一定有问题，同样的100行代码其逻辑复杂度有很大差距，需区别对待，不可一棒打死。需要指出的是测试人员在迭代过程中只需验证sprint的目标达到即可，至于store对系统可能产生的连带影响可以在User acceptance test中验证。

　　在我们团队的实践里，代码质量主要还是开发人员自己负责，测试人员主要工作是编写自动化的功能测试和进行一些无法自动化的手工测试，还可以做做可用性测试，再闲得慌还可以做做没有测试用例脚本的随机测试， 有些项目还需要每个迭代持续的进行性能测试与稳定性测试。嗯，还有发布/安装测试。

　　无论什么样的过程，对质量的标准应该是没有区别的吧，所谓的质量无非当前实现的正确性与日后的可扩展可维护性。

　　Agile应该没有特别的统计方式吧。

　　关于如何提高项目的质量，除了常见的UT+CI外，还推荐一个比较好的活动---Definition of done（DoD），在每一个story宣布完成后都要进行Checklist的检查（注意，是随时，不要放在迭代后才执行）， 比如：

　　1）Story Owner Approved（重要的一项）

　　2）Code Guideline（保证通过Sonar等的自动化检测工具的检查）

　　3）Code Review（保证通过了Team内的Review）

　　4）Test Review（保证有足够的Unit Test 与 Functional Test，并且在持续集成服务器上通过）

　　5）No Bug（保证Bugzliia中没有相关的Bug）

　　6）Document Update（保证足够的JavaDoc注释， 保证用户文档/交付文档需要改变的部分已与技术文档编写人员沟通）

　　7）Configuration Update（保证涉及系统配置的变更已与集成人员沟通，涉及数据的变更已与DBA沟通）