142 积分 Toronto Ahmad 是所有开源事物的倡导者和开发者工具爱好者。目前在 Mashape 领导才华横溢的工程团队，构建世界一流的 API 工具和市场。业余时间，Ahmad 在 Technology & Leadership 上写博客，指导早期创业公司，并构建被全球数千名开发者使用的开源项目。 思想开放 作者
撰写评论
嗨 Rico，
希望这篇文章出现在你的新闻推送中，帮助我们共同改进每个人的流程和软件 :)
是的，这篇文章确实非常侧重于“代码质量”和广义的“代码”，这是我的失误，我倾向于使用开发术语，但我指的是整个产品。
我所说的关于“代码”的一切也适用于“设计”+“用户体验”+“商业价值”。
以我在质量下列出的关键问题为例，产品所有方面的更广泛范围仍然适用
这段代码/设计/体验/业务是否清晰易懂？
这段代码/设计/体验/业务是否可测试？
这段代码/设计/体验/业务是否模块化？
这段代码/设计/体验/业务是否经济？
文章可能需要更长篇幅才能列出产品的所有方面，请放心，我会在以后的文章中澄清这一点。
至于敏捷教练，是的，我们有很多，遍布不同的团队和公司。有些很好，有些很棒，实际上很少有差的。我想说，我合作过的敏捷教练通常是对我们团队的工作流程和生产力的巨大投资。实际上，他们是我合作过的最有活力的人之一。
话虽如此，虽然教练很棒，并提供了巨大的价值，但他们仍然在宣扬一种过时的流程，这种流程是为过去的软件开发而设计的。我们的世界已经发展，我们的技术也是如此，团队分散在多个时区、语言和文化中。软件不再是单一的定义，而是多种多样的，而从事产品开发的团队必须接触到不断扩展的技术领域，这些技术领域无法轻易地归入具有重叠交付计划和需求的小型 Scrum 团队中。
我完全同意没有所谓的“银弹”，我也不是在暗示开放式开发方法就是银弹。我建议的是，我们通过持续的演进周期来发展我们的流程和方法，以适应我们的时代和需求，而不是固守 20 多年前的方法论。
毕竟，敏捷不是提倡迭代、增量和演进式的开发风格吗？为什么不将其应用于 Scrum 本身呢？
嗨 Joseph，
感谢您的评论！国际团队确实提出了超越传统项目管理方法的挑战！我过去经历过这种情况，今天仍然如此，我的团队分布在 7 个城市、6 个时区、8 个国家，说着 8 种不同的语言 :)
这就是我对替代方案的追求将我引向开源世界和开放式开发方法论的原因。
正如我在下面留下的较长评论中所述：https://open-source.net.cn/business/15/11/open-development-method#comment-8…
我不认为敏捷宣言与开放式开发方法论相矛盾，事实上，我认为它在原则上是 - 大部分 - 兼容的，但它在本质上是不同的，因为它是一个“宣言”，而不是一个“方法论”。两者都需要一个“流程”来实现日常活动。
虽然敏捷有 Scrum / Kanban / XP 等... 但开放式开发方法论还没有。目前还没有。
这是故意的，因为我不想将我们使用的流程定义为神圣不可侵犯的，或者作为所有人都应该遵循的专家答案，我希望这是一个开放的倡议，由社区来决定什么是合理的，什么是不合理的，甚至可能有不止一个流程！
我邀请您帮助塑造这项技术的未来，以造福所有人 :)