城下秋草‘s Blog

现代项目管理中，敏捷研发越来越流行；言必称敏捷，似乎不敏捷就是跟不上时代。敏捷真的就是现代软件项目的灵丹妙药吗？它是否真的是一个普适的研发方法？

综合以上几个方面，快速完成测试，归根到底就是能不能尽快建立交付的信心，跟个人能力、产品属性、研发流程都有关。其实是个认知问题最后，还是要说，任何事物都无法背离内在规律，一个运行稳定，健壮，耐造的系统，必然是会要经过各种磨合、内外部各种问题锤炼才可能达成的。你以为的快速交付、一战功成，哪有什么岁月静好，不过是有人替你负重前行罢了。只是这个负重的可能是前期的开发人员、也可能是测试人员、或者运维人员，抑或最后，靠用户扛下所有！

关于Sprint 回顾会的一些梳理。实际运作中，千万不要把回顾会开成抱怨、诉苦会或互相指责，不管运作过程中发现的问题多么严重，大家最终还是要立足团队发展，成员和团队共同得到提升才是目的。

那么总结下复盘会的关键事项：首先这个会议是一个迭代结束后，获取迭代产出反馈的一个会议。是敏捷小步快跑思想的主要体现。但实际运作中，并不是一个必定会每个Sprint都会召开的一个会议。只是应尽可能不要间隔时间太长，给团队来根据干系人的反馈进行及时调整有灵活性。这个会议并不是一个验收会，它并不是用于向PO确认Sprint Goal有没有达成的一个会。沟通反馈才是主要目的会议的过程和产出，是敏捷迭代，产品演进的重要一环，是确定PBI，及时纠偏的重要过程，可以确保团队的工作和用户的期望是匹配的。

站会是 Sprint 进行过程中，全体成员都会参加的一个例行的信息同步仪式。所以效率很重要，是团队自组织和高效协同的重要体现。掌握站会的目的和各个角色参与的要点和注意事项，可以帮助我们更好地把站会开好，真正发扬出敏捷精神。

sprint planning会议在敏捷运作中非常关键，是确定团队在当前Sprint的工作内容和工作方向，形成Sprint的待办列表 SBI的一个会议。

Scrum是敏捷中应用最多的框架，其中定义了三大主要角色。PO、SM、Dev Team

在上一篇介绍中，我们主要分享了团队级别的一些敏捷实践模型，但是现代软件规模其实越来越庞大，仅仅依赖一个小型团队，并不能完成软件产品的系统级研发。所以为了整合多个通过的小型团队，敏捷组织又提出了多种不同的大规模敏捷模型。

在本系列上一篇博文《敏捷Agile概述，何为敏捷？中，我们初步介绍了何为敏捷，敏捷提出的背景和为什么目前得到了广泛的应用。但敏捷本身，更多只是一种价值观，是一个思想层面的指引。在组织中实际应用，还是需要借助一些具体的实践模型来进行落地。随着敏捷的发展，其实涌现出非常多不同的实践模型，基于这些模型来组织我们的研发过程，都可以称之为敏捷研发。下面，我们将重点梳理下，在敏捷研发实践中，比较常见的一些模型以及它们的优缺点。

Agile 敏捷研发可能是现今 IT行业最为流行，也是被广为应用的研发模型。但实际运作中，似乎和预期总有不少的偏差。所以开一个系列来详细梳理下和 Agile 敏捷研发相关的知识并谈一谈自己的 Agile 的理解。

Rails 大神、创始人 David Heinemeier Hansson 曾发文抨击TDD。此后, Kent Beck、Martin Fowler、David Hansson 三人就这个观点还举行了系列对话（辩论）笔者作为一个多年在软件测试领域摸索的人，其实更多是跟同行们澄清 "TDD并不是测试活动"，“TDD是开发活动”， TDD这里的“测试”和我们正常理解的软件测试并不是一个东西。倒是很少认真思考过 TDD 本身的价值在哪？是不是真的有用。

敏捷Agile是现今被广泛应用的一种研发理念和思想。著名的敏捷宣言也广为流传，被翻译为了60多种语言。这个宣言其实更多是提出了在软件研发中，被这些先驱者们认为更重要的价值观，传递的是一种不同于传统研发的新理念。但思考提出这些理念背后的逻辑，又是什么呢？我们还是应该搞清楚为什么有这样的一个宣言，否则大家虽然都号称在施行敏捷，但又有点似是而非，甚至因为敏捷又搞出很多流程、仪式和各种敏捷工具，兜兜转转又回到原点。这里笔者尝试理解下敏捷宣言的背后逻辑和真正作用，抓住这个核心，其实就理解了敏捷的本质。