敏捷Scrum培训有感

关注

原创最新推荐文章于 2026-04-18 09:25:40 发布 6.3k 阅读 AI 写同款· GEO 优化 ›

AI原生研发转型：避开六大组织反模式，构建智能研发新范式在软件工程领域，AI与大模型正从辅助工具演变为驱动研发流程的核心智能体。其核心原理在于利用大模型的通用认知与推理能力，结合领域数据与反馈闭环，重塑需求分析、系统设计、编码测试等环节。这一转型的技术价值在于构建人机协同的新型研发范式，能显著提升研发效率、创新速度与系统适应性。应用场景已从代码补全、文档生成，扩展到需求澄清、架构生成、自动化测试与预测性运维等全链路。然而，许多企业在实践中常陷入工具化思维、技能孤岛等组织级反模式，误将AI视为现有流程的简单附加。本文基于行业洞察，系统剖析了这些典型误区，并提供了从阅读详情

InfoQ网站上有两篇介绍Visual Studio产品团队敏捷实践经验的中文文章，推荐给大家！

《大型软件开发项目中的功能小组模型── Visual Studio开发团队的敏捷实践经验分享（一）》

《功能小组模型的过程与质量控制 - Visual Studio开发团队的敏捷实践经验分享（二）》

题外话：前天听说欧盟也无条件批准了Oracle对Sun公司的收购，虽然还需要等待俄罗斯和中国等国家的批准，但相信那只是时间的问题了。一个曾经在软件行业无比辉煌的公司，一个曾经缔造了众多顶级软件和硬件（Solaris、Java 、MySQL）的公司，就这样说没就没了，真是不敢相信。“江山代有人才出，各领风骚数百年”，对于IT行业可用不了数百年了，也就是数十年吧，应该改为“市场代有人才出，各领风骚数十年”。市场的选择是无情的，倒下了一个Sun，还会有更多站起来。

今天（2010/01/23）是周六，一整天都在参加InfoQ在上海闵行紫竹微软新园区举办的“京沪两地敏捷Scrum训练营”上海站的活动。活动分为上下两场：上午主要是由雅各布森公司吴穹博士的“敏捷软件开发之Scrum实践（上/下）”，介绍敏捷开发和Scrum的北京和理论方面的知识；下午是由微软钟鸣所做的“大型团队中的Agile-微软研发团队的敏捷开发实践”和北京金桥公司王然的“基于Visual Studio 2010大型敏捷项目开发”，分别介绍了微软开发工具部门上海团队所采用的Scrum流程和经验，以及如何采用Team Foundation Server 2010来进行敏捷项目开发。总体来说感觉还是不错的，理论+实践经验+工具，应该是不错的搭配。

我所在的开发团队已经成功的应用Scrum有段日子了，但通过这次培训，对以前一些模糊的概念得到了澄清，了解了一些新观点和名词，触发了我的一些新想法，还是颇有收获的。下面是些具体的收获和见闻，给大家报告如下：

不要误读敏捷宣言

下面四条就是敏捷宣言（Agile Manifesto）的内容，往往会被敏捷的“粉丝”或者激进者误读，或者用来误导领导。他们通常会把这里的over翻译为“不需要”或者“不要”等。敏捷看似是《笑傲江湖》中的“独孤九剑”，以无招胜有招，但那要看是谁来用，并不是人人都可以的。只有风清扬这样的super senior前辈，和令狐冲那样的super smart晚辈才能真正用得上“无招胜有招”，才能真正可以把over翻译为“不要”。而我等泛泛之辈，只能将其翻译为“重于”，也就是说，对于绝大多数（99.99999%）的团队而言，在敏捷开发中，方法、文档、工具合同以及计划都是必须的，区别在于要让它们的存在更合理有效，不要动辄就是几百页无人愿看的文档。

个人和交互重于方法和工具（Individuals and interactions over processes and tools）；
可工作的软件重于完备的文档（Working software over comprehensive documentation）；
与客户的协作重于合同谈判（Customer collaboration over contract negotiation）；
响应变化重于严格遵照计划（Responding to change over following a plan）；

Be Agile rather than do Agile

敏捷的本质是要找出开发流程中不合理和浪费资源的内容，并加以改进。只要所做的工作能达到这样的效果的我觉得就是一种适合你的敏捷方法。而并不一定说是必须遵循别人的已有的方法和步骤才叫敏捷。而且往往是公司、人员和项目性质等不同，别人成功的敏捷应用绝大多数情况下是不适合你的。

敏捷多起于“草根”，而终于上层和老板

采用敏捷方法的提议多是从实际的开发团队兴起，而终止于老板或者老板的老板。原因很简单，一线的技术人员（技术痴迷者、技术愤青、技术Guru）对新的开发方法更为敏感和强烈的热爱，他们经常会提出对现有流程好的改进意见。但很多敏捷方法涉及到对现有流程和人员组织结构的改变，如Scrum，没有老板的支持是绝难完成的。现在很多公司采用的是“弱项目，强职能”组织模式（不确定这是不是CMMI要求），而Scrum的Feature team/Feature crew的组织方式则正好是相反。

相对而言，采用TDD和XP要简单一些，两三个开发人员就可以实施，不需要过多的组织调整。

推广敏捷方法不是大跃进

不要把推广敏捷当成一场运动，不是要搬倒现有的一切而从头来过，那样只会招致更多人的反感和更大的阻力。存在的东西总有它合理的地方，推广敏捷是针对其中不合理的东西进行渐进式的改变。要做到“随风潜入夜，润物细无声”得推广。当然这很难，只能是个奋斗的目标和方向，做不到100%，达到个50-60%总是可以的。再说了，现在啥事不难呢，容易做就不找你了，是吧！

啥是ATDD?

这是我在这次活动中听到的一个新名词，ATDD的全称是Acceptance Test-Driven Development，也即是接受性测试驱动开发，它也是敏捷方法中的一种。

Scrum经典流程图没有指出Scrum的难点

Scrum最大的难点应该说是Product Backlog到Sprint Backlog的任务挑选和分解的过程，这需要构架师的参与。另一个难点是如何让测试能跟上敏捷的步伐，特别是在当下仍以手工测试为主的情况下。

Scrum只会让曾经爱偷懒的人感觉更累

采用了Scrum方法，会不会让团队成员感觉更累呢？确切地说：它是让那些爱偷懒的人更累了，呵呵。Scrum以项目管理实践为核心，它不同于XP和TDD。它要达到的管理效果，我用16字总结如下：分工明确、责任到人、项目透明、过程可控。在相对开发周期比较短（一个迭代周期在2-4周）的情况下，每个人的时间分配和利用都比较明确，这样就很难再有偷懒的机会了。

什么是Scrum？

Scrum一词本意是指英式橄榄球的争球，英文解释是这样的： (rugby) the method of beginning play in which the forwards of each team crouch side by side with locked arms; play starts when the ball thrown in between them and the two sides compete for possession。Scrum 将软件开发团队比拟成橄榄球的争球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。