早在 1995 年被提出的 Scrum 就提出了三大支柱：透明、检视、调整，Scrum 3355 中的提到了5项价值观：承诺、勇气、开放、专注、尊重。早在1999年发布的极限编程也提到了 5 项价值观：简单、沟通、反馈、勇气、尊重。
理解这些词的人深知它们意味着什么，不理解的人也很难去思考这些对于团队的价值。每当谈起价值观，难免会觉的空无，总有人挑战：
- 不是说要有勇气么，挑战高难度的Scope来彰显一下勇气可好！
- 经常会有很多人跟我提谁谁谁的反馈，我觉得大家还挺乐意提反馈的啊！
- 我们可爱自省了，Retro会议也从不落下，每次Retro完会有一些行动项下发下去！
- ……
有人说，做敏捷开发容易啊，不就是开几个会、搞一些实践嘛！但我想告诉你，做敏捷开发也有点难，难在那些不容易被意识到但又经常在你眼前晃来晃去的东西 – 团队里的日常行为点滴以及这些点滴背后的价值主张。
本文我尝试通过极短的篇幅列举一些在交付过程中团队中展现出来的违反敏捷价值理念的行为模式，不求全面，但源于现实。
关于透明、检视和调整
- 团队成员经常突然被告知谁谁谁要 roll off，经常突然接收到某个决策通知。
- 信息不透明会失去团队的信任
- 团队的管理成员公布决策时忽略了解释 Why，只宣告 What 和 How。
- 不透明的决策难以得到认同
- 团队成员的日常交付工作优先级经常被临时切来切去，没有提前被同步计划安排。
- 生产力呗消耗，专注也受到了破坏
- 团队连续多次 Retro 中出现相同或类似的问题和行动项。
- 行动项不能闭环，反复消耗团队的信任和信心
- Retro 行动项没有具体Owner以及不知如何衡量是否完成。
- 这样的行动项很难被负责
- Retro 提出关于解决团队资源和支持的行动项多次没有得到落实。
- 管理团队会失去信任
关于反馈和沟通
- 团队成员提反馈的主要途径是私下1对1找PM或者TL（吐槽居多）。
- TL或PM千万别得意自己跟大家关系处的好，这可能意味着团队的反馈机制失效了
- 某人向你吐槽另外一个人，只有主观评价却给不出具体Fact。
- 这种无效反馈不仅无法帮助他人做出改进
- 你向某人直接请求反馈时收到的是一些不痛不痒的反馈，而你却从其他人那里听到他关于你的负面吐槽。
- 不但无法帮助你做改进，还让你想远离某人
- 团队的管理成员长时间收不到团队直接的反馈，却经常通过小道消息听到一些成员的抱怨和吐槽。
- 管理成员失去了信任，团队不愿意正面沟通和反馈
- 你要给TL或PM提出建议性的反馈时有较大的心里压力，或者你提过几次反馈，却发现几乎没有任何变化，不再想提。
- 团队已经不安全，反馈机制不凑效了
- 团队成员经常表现出的 Bad Apple 的行为得不到明确有效的指导，而是其他人在背后的议论吐槽。
- 营造了只会抱怨却纵容 Bad Apple 的团队氛围
- 团队新人在询问一些老人问题，经常得到类似的回复：“我昨天不是刚刚才讲了么！”、“这个我不是在群里通知过了么！”
- 这种回复隐藏着责怪：“你不该再浪费时间问！”
关于尊重和勇气
- 团队有人给你提反馈，却不愿意听你澄清。
- 封闭型心态的反馈，自居上帝给别人贴标签，丢掉了尊重。
- Retro的时候，经常听到针对某一种角色或者某些具体成员的负面评价。
- 对人不对事，被针对的人感受到不被尊重
- 当 Senior 成员无法就某个方案有效说服 Junior 成员时，采取这样的回应：“等你成为Senior之后你就会懂了！”
- 职权影响力打压，失去了基本的尊重
- 当 Junior 成员询问 Senior成员为什么要这么做时，得到的回应：“你别问那么多，照着做就行了！”
- 职权影响力打压，失去了基本的尊重
- PM 长期使用高于团队实际的速率做交付计划，并“激励”团队鼓起勇气挑战更大难度。
- 勇气不是不切实际的鲁莽，保持持续且健康的状态需要勇气
- 你不敢尝试一些新的想法，因为担心一旦犯错后会被贴上不胜任的标签。
- 不尊重新想法，不包容犯错，难以有效成长
- 团队成员因为被盯着个人的开发速率，不得不倾向选择坐视代码库变坏而不去重构优化。
- 因为花时间改进会拖慢自己的速率，有被扣上不胜任帽子的风险
- Team Code Review 的时候谁Senior谁一言堂或者TL经常一言堂。
- 这样会扼杀很多好的想法，大家逐渐也失去了表达的欲望
小结
团队在磨合的过程出现这些问题其实是很正常的现象，但如果团队的核心成员意识不到这些行为的危害性，不真正想办法纠正这些行为，可能会导致团队中越来越多的人开始装睡，或者越来越多的人没勇气清醒。
另外，有时土壤太贫瘠或者外部约束不可破，也不用难为自己，非把自己套在敏捷开发框架里做事，正如 2018年，《敏捷宣言》签署人、XP 联合创始人 Ron Jeffries 发表文章《开发人员应该放弃敏捷》并表示开发者应该放弃敏捷：
如果不恰当地运用“敏捷”，会导致对开发人员的干扰更大，完成工作的时间更少，压力更大，并被要求 “进行得更快”。这对开发人员是不利的，最终对企业也是不利的，因为“敏捷” 做得不好往往会导致更多的缺陷，以及更慢的进度。通常，优秀的开发人员会离开这样的组织，进而导致企业的效率不如实施 “敏捷” 之前。
而一个体内流着“敏捷”血液的团队，即便不按照敏捷开发框架去做事，他们照样会在过程中不断地检视和调整，努力营造安全信任的氛围，建立有效透明的反馈机制，真正在做持续改进。有了这些，敏捷开发中提倡的会议和实践只是水到渠成的事情。
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 350394277@qq.com
