谈敏捷不能离开谈人，敏捷宣言第一句：个体和互动高于流程和工具，而谈人就不能离开谈组织建设。

  • 每一次 pull request 的 merge 就是一次 release，因此在 code review 的时候就要检查：

    • Release version 是否增加了？
    • Release note 是否写清楚了？ 与相应的 JIRA ticket 是否对应？
    • 相应的 JIRA ticket 是否更改了状态？
    • 单元测试是否都通过？
    • 代码是否符合习惯和规范？
    • 是否有可以重构和改进的可能？

  • ‘No Estimates’ in Action: 5 Ways to Rethink Software Projects

如果不能改善业务成果，持续交付和DevOps就毫无意义。仅仅让开发和IT运营更好地合作，并不能改善业务成果。

做好每个职能是必要的，但还不够。唯有改善各职能之间的互动，才能提高组织的敏捷性。当单个职能的优化收益已经开始递减时，注重跨职能的互动就会带来较大的收益。

许多敏捷实施是被那些好心却不专业的人给搞坏的，他们首先将专有名词"敏捷"（是指一种方法论）与日常用的形容词"敏捷"混淆，然后错误地用形容词"灵活"替换"敏捷"。他们总把"灵活应对"挂在嘴边，实际上就是处处打折扣。大多数时候，他们的出发点是为了避免教条式坚持敏捷原则或实践。但是，坚持并不意味着教条，也可能坚持敏捷原则和实践才是深谋远虑的做法。但认识到这一点需要理性的讨论，而不是打着"灵活应对"的旗号轻易让步。