第二部分 组织挑战
3. 文化挑战
组织文化：敏捷团队最适合于允许独立思考的团队。
质量哲学：如何定义软件质量的可接受水平的角度；
整体团队负责质量
技能和适应能力
辅助因素：测试人员需要时间和培训。
合适的节奏：在团队更好的管理负载和节奏之后，加班才会消失。
客户关系：敏捷团队依赖于客户至少是客户代表的紧密参与。
组织规模：组织越大，结构中的层次越多，不适合技术和业务交流。
沟通挑战：每日例会。
组织内的文化冲突
提前计划
先行动后道歉：想办法创新。
授权团队
测试/质量保证团队成功适应敏捷的障碍
丧失身份：测试人员坚持拥有独立的质量保证团队（害怕丧失质量保证人员身份；害怕丧失支持；害怕在产品和组织中失去身份）
其他角色：思考团队缺少什么角色使我们停止不前？
缺乏培训：培训帮助测试人员适应敏捷转变。
不理解敏捷概念：团队必须就如何成功实现向敏捷的转变而达成一致。
过去的经验/观点：测试人员坐在自己的座位上，并不与程序员讨论存在的问题。
角色间的文化差异
引入变化
讨论恐惧：提供讨论恐惧和获得反馈的机会。让人们知道感到恐惧是正常的。保持开放态度。讨论每个恐惧的根源，从讨论中学习，作出决定并继续前进。
赋予团队权利
庆祝成功
管理层期望
经理的文化改变：敏捷团队的经理关于于清除障碍，让团队成员更出色地工作，而不是糟糕地管理团队的活动。
使用经理的语言：告诉经理投资回报率；图表告诉经理当前的项目进展；
改变并不容易：耐心、让他们感觉到痛苦（人们最希望在他们感觉到最痛苦的领域做出改变）、建立你的诚信、警惕质量警察思想、用离开表示拒绝
[要做一个合作者，而不要做一个强制实施者]
4. 团队构成
独立的质量保证团队：拥有独立的检查和审计角色很重要；可以对产品提出没有偏见的意见；开发关系过紧密，会确实站在客户的认识；开发leader会站在代码的角度要求你；
[如果在一个团队有什么优点呢？1. 沟通更畅通；2. 代码理解更充分，产品质量更高； 3. 测试人员成长更快]
把测试人员整合到敏捷项目：好的关系很重要
敏捷测试团队：人员职责划分不是那么的界限化；
人员分布
坐在一起很利于沟通和合作，不坐在一起需要的是大家的努力；
人力资源
测试人员/开发人员比例，依赖于应用的复杂性、测试人员的技能和使用的工具。
当程序员负责手动测试和测试自动化时，团队才真正有工作效率。
团队建设
自组织团队
在赋予团队权利自己发现并解决问题时，团队进展得最快。
引入其他团队
每个团队成员有同等的价值
业绩和奖励
你可以做什么
5. 迁移传统过程
寻找轻量级过程
度量标准
精简测算：减少测量的数量和寻找驱动正确行为的测量。
为什么我们需要度量：当度量被用作路标-为提醒团队偏离了轨道或者在正确的道路上提供反馈；不应该关注个人度量，而应着眼于目标和到达目标的趋势。
与度量无关的事情：使用度量判断个人或者团队业绩是危险的事情。
沟通度量：确保度量以正确的方式呈现给合适的人。
度量的投资回报率：应记录每一个度量标准的投资回报并决定是否跟踪或者维护它。
缺陷跟踪
为何应该使用缺陷跟踪系统(DTS)：方便；不使用DTS就没有地方记录所有缺陷的细节；知识库；大规模或分散团队；客户支持；度量标准；可跟踪性；
为何我们不需要缺陷跟踪系统：作为一种沟通工具；浪费时间和精力；
集中注意力：工具的出现是为了解决问题；
测试计划
测试策略和测试计划：注意信息使用的频率和用途，越是长的文字越是很少有人会去看；
可跟踪性
现有的过程和模型
审计
框架、模型和标准