likes
comments
collection
share

敏捷开发

作者站长头像
站长
· 阅读数 4

最近公司降本增效，提倡敏捷开发

相对于瀑布模式，敏捷开发会提高产品的交付效率。市场变化太快，我们可以先做MVP，交付出来，看看市场反应。或许才是我们技术人员对于业务的赋能。其实，敏捷开发不一定要加班，要 996； 诚然，以前我对它是有误解的。

下面，我写一下这几年自己的工作实践中，对于敏捷开发 新的理解

敏捷理论体系解读

敏捷软件开发宣言：

agilemanifesto.org/iso/zhchs/m…

敏捷软件开发宣言

个体和互动 高于 流程和工具

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

左右都很重要

敏捷开发

什么又是有必要的文档呢？

在敏捷开发中，虽然强调"个体和交互胜过过程和工具"，"可工作的软件胜过面面俱到的文档"，但并不意味着完全不需要文档。在实际项目中，仍然会有一些必要的文档，尤其是在项目复杂度较高、团队规模较大或跨团队合作时，文档的作用尤为重要。

以下是一些在敏捷开发中可能会保留的必要文档：

  1. 需求文档或用户故事：虽然强调口头交流，但为了确保共同理解和记录需求细节，编写简明的用户故事或需求文档是有必要的。
  2. 设计文档：重要的设计方案、系统架构、数据库设计等，可以在文档中记录，方便团队成员回顾和理解系统结构。
  3. 测试文档：测试用例、测试计划等文档可以帮助确保软件质量，并为后续的维护提供依据。
  4. API文档：若项目涉及对外接口，编写API文档有助于其他团队或开发者理解如何与系统进行交互。
  5. 运维文档：记录系统部署和运维的细节，方便后续维护和故障排查。
  6. 代码注释和文档：虽然代码本身应尽量自注释，但在特定复杂场景或特殊处理时，添加适当的注释是有帮助的。

虽然敏捷开发强调实际交付的软件，但适当的文档在项目的不同阶段和不同情况下，仍然是有价值的。重要的是保持文档的简洁、明确和易于维护，不要过度依赖文档而忽略沟通和合作。在敏捷团队中，持续改进和不断优化工作方式是关键，包括对文档的使用和管理方式。

这些是敏捷开发的12条原则，它们为团队提供了指导方针，帮助团队在项目开发过程中保持灵活、高效和客户导向。以下是对这些原则的简要解释：

  1. 满足客户需求：优先考虑交付有价值的软件，使客户满意。
  2. 适应需求变化：即使在开发后期，也欢迎对需求进行改变，以适应变化的市场和客户需求。
  3. 频繁交付可工作的软件：经常性地交付可工作的软件，增加客户反馈和改进的机会，持续提供价值。
  4. 业务人员与开发人员紧密合作：业务人员和开发人员之间天天紧密合作，增进相互理解和团队协作。
  5. 信任和支持个体：团队应围绕被激励起来的个体构建，给予他们所需的支持和信任，相信他们能完成工作。
  6. 面对面交流是最有效的：在团队内部，面对面交流是最有效和高效的信息传递方式，促进更好的理解和沟通。
  7. 工作的软件是进度度量标准：实际工作的软件是衡量进度的主要标准，重视软件的实际交付。
  8. 保持可持续开发速度：敏捷过程倡导可持续的开发速度，确保团队能够保持长期恒定的开发进度。
  9. 关注技术和设计：不断关注技术的发展和优秀的设计，提升团队的能力和敏捷性。
  10. 保持简单：将复杂问题拆分为简单的任务，最大化未完成工作的价值，保持开发的高效性。
  11. 自组织的团队产生最佳结果：最好的构架、需求和设计往往由自组织的团队决定，激发团队的创造力和责任心。
  12. 定期反省和调整：团队定期反省工作方式，寻求提升效率的方法，并相应地调整工作方式和行为。

这些原则强调灵活性、团队合作、持续改进和客户导向，帮助团队在不断变化的项目环境中取得成功。在实践敏捷开发时，团队可以根据这些原则进行思考和决策，以确保项目的顺利进行和交付高质量的软件。

敏捷软件开发--计划

  • 2-4周 详细计划
  • 1-3个月 粗略计划
  • 1年 大致想法

每年3-4 茶话会，写纸条，写出自己的未来的一年的计划，投票，内部开会，产品线。

敏捷软件开发宣言的原则

  1. 及早交付有价值的软件
  2. 传递信息效果的最好，效率最高的方式： 面对面的交谈

敏捷开发框架 Scrum

三个角色

第一个角色 1. 产品负责人

负责建立和维护产品特性

  1. 和客户不断沟通和协作确定产品应该做什么，定义用户需求，确定需求的优先级
  2. 必须拥有决策权
  3. 要对团队内部的工作流程 和 技术水平有所了解

第二个角色 2. scrum教练

确保团队能够实现更快的交付

  1. 要能激励团队士气，促进团队合作，确保团队有效率
  2. 要能帮助团队排除干扰，确定冲刺目标的顺利进行
  3. 教练不是事无巨细的管理者，而更像是服务团队的仆人

第三个角色 scrum团队

5-9人 团队

  1. 自You组织，平等
  2. 在一个 Sprint(冲刺) 里面，成员应该尽量保持稳定

4个活动

4个活动-Sprint冲刺规划会议

标识着冲刺的开始（时长一般不超过4个小时）

  1. scrum团队选择并理解要完成的工作

  2. 议程1：由产品负责人介绍产品，确定sprint 将要完成什么任务；明确产品待办列表中优先级最高的任务；明确冲刺目标；确定本轮冲刺中要完成的任务数量；

  3. 议程2： scrum 团队研究本轮冲刺 如何完成要交付的任务； 团队对冲刺要完成的 任务数量 和复杂度达成共识； 对需求充分理解并 进行估算； 将 产品代办列表 中的内容 转化成 软件开发过程中 的具体任务

4个活动-每日站立会议

团队成员在会上轮流发言，回答：

  1. 昨天我做了什么
  2. 今天我准备做什么
  3. 我在工作中遇到了什么苦难，是否阻碍了工作进展
  4. 不建议超过15分钟
  5. 汇报预计今天能完成的进度

4个活动-冲刺复审会议

用来演示在这轮冲刺中开发的产品功能，并由产品负责人验收

4个活动-冲刺回顾会议

  1. 用来给团队定期自我审视
  2. 建议控制在30分钟以内

三个工件-产品待办列表

一份有序的待办事项列表

涵盖产品开发中已知的每一项需求，并且应该是产品需求变动的唯一来源

产品负责人是唯一的产品待办列表的负责人

其他人可以提出意见，但只有产品负责人有权做决定

产品待办列表

  1. 功能性需求 或者 非功能性需求
  2. 缺陷
  3. 技术债务

产品待办列表--评判标准- DEEP原则

  1. 粗细得当： 产品待办列表 应当 远粗近细， 越远的需求应该越粗；越近期要开发的需求应该越细致
  2. 估算过的：对每一个事项有一个工作量估算 和 技术风险 估算
  3. 涌现的：产品待办列表不是一成不变的，而是涌现的
  4. 排好优先级别的

冲刺待办列表

开发团队估算工作量，识别冲刺待办列表优先级等等

敏捷 vs DevOps

DevOps教程：DevOps vs 敏捷

www.cnblogs.com/icodewalker…

DevOps 与敏捷

azure.microsoft.com/zh-cn/overv…

DevOps知识图谱

DevOps知识图谱

roadmap.sh/devops

案例分享：阿里是如何DevOps的

阿里云 云效

www.aliyun.com/product/yun…

Jenkins BlueOcean插件

zhuanlan.zhihu.com/p/70355846

案例分享：Amazon是如何DevOps的

亚马逊 基于AWS的DevOps实践指南

AWS视频中心

aws.amazon.bokecc.com/searchresul…

一站式DevOps平台-Hygieia

Hygieia搭建

手动搭建：

基于Docker搭建：

敏捷开发

记得那是 2007 年~2008 年，我们有一个项目是负责某大型通信公司印度尼西亚工厂的 SAP 实施。在简单了解需求之后，我们制定了项目初步计划，包括预算、人员和进度计划等等；目标是用 10 个月完成项目，包括需求调研、开发、测试、上线以及用户培训。

我们的项目经理很资深，公司也有一套成熟的项目管理模式，于是我们就按照公司规定的项目管理规范来开展工作。

我们花了 1 个月的时间来进行项目的前期筹备，包括组建团队。之后，我们花了 2 个半月的时间做完了需求调研，又花了 3 个月做开发，开发完成后交给测试，测试花了 2 个月完成，然后交付给客户来验收。验收之前，我们仿佛看到了胜利的曙光，就等着庆功宴了。

没想到，噩梦才刚刚开始。当客户看到系统并真正试用时，开始觉得这也不行、那也不可，提了大大小小 50 多条修改意见。记得当时验收会议结束时，客户方相当不满意，就差拍桌子了。

经验：

  1. 软件研发和传统的生产管理不同，它的产出物具有强烈的不确定性。
  2. 从大的组织结构来讲，我们的团队应该组成一个个小的特性团队，团队是固定的，成员也基本是固定的，这样项目来的时候我不需要花费那么长的时间去组建团队，磨合团队。
  3. 从需求梳理的过程来看，我不会一次花 2 个半月去梳理并在最后才给客户看我们梳理的结果，我会边梳理边跟客户交流。
  4. 我会把需求按优先级排序形成需求池，迭代地进行研发。
  5. 我会让客户积极地参与我们的研发过程，包括前期的需求调研梳理和后面的开发测试上线，在做的过程中迭代有产出时就让客户来验收，让他们提意见和建议，以便我们在后面的迭代随时调整。

比方说，有的公司会考虑加快反馈循环来提升流转效率；有的公司会把自己所有事情按照价值和优先级来排序，定期整理自己的工作列表，就像管理产品待办事项列表一样来管理工作，让员工把精力放在更有价值的工作上；还有的公司引进了很多在线协作管理工具来加强协作等等。

一定要早点把客户拉下水。让客户早点确认各种细节。这样就不会后期唧唧歪歪了。

敏捷开发

以下是评估诊断的方法步骤，帮助你更好地了解团队的状况和制定相应的改进计划：

  1. 挑选代表性项目：选择代表性的项目，涵盖业务和研发模式上的不同类型。这样能确保评估结果更全面真实。

  2. 访谈评估：对选定的项目成员进行深度访谈，从流程、组织、人员技能、度量和技术等维度评估项目。重点探讨项目中存在的问题和痛点。

  3. 制定转型计划：根据访谈评估的结果，制定推进敏捷的计划。计划应针对性解决项目中具体的问题和痛点，如跨团队协作不畅、DevOps 流水线建设等。

  4. 沟通：将评估结果和转型计划与相关干系人进行沟通，包括团队成员、主管和内部负责人等。确保整个团队对现状和改进计划有一致的理解，避免互相配合出现偏差和拆台。

通过以上评估方法，你可以更加全面地了解团队在敏捷实践方面的问题，制定针对性的改进计划，并推动敏捷转型取得成功。

新的认识：

最后，团队在跨团队交流方面有很大的障碍，这表现在业务人员与开发测试团队隔离，目标

不统一，且参与敏捷的投入度不够。 对于已经采纳敏捷的团队而言，他们只是在开发测试团

队上做了一些敏捷实践，而并未将业务人员拉进来；团队也没有相应的制度，所以业务人员

在敏捷活动中想来就来、想走就走，毫无纪律性可言。另外，业务人员还是像过去一样，认

为提完需求，自己的工作就结束了，至于做不做得出来，是开发测试团队的事情，而不是想

着大家一起把产品做出来，一起去为它的最终上线及推广效果负责。

你的认识很准确，团队之间的交流和协作是敏捷开发中的关键因素。团队应该形成一个紧密的合作体，而不是业务人员和开发测试团队之间的隔离。以下是解决这些问题的方法：

  1. 业务人员的参与和责任意识：敏捷开发强调业务人员和开发测试团队的合作。业务人员应该积极参与敏捷活动，如需求梳理会议、迭代评审等。他们应该对提出的需求负责，并在开发过程中与团队紧密合作，提供反馈和指导。

  2. 建立跨团队的沟通机制：为了解决团队之间的交流障碍，建立跨团队的沟通机制非常重要。可以定期组织跨团队的会议，让业务人员和开发测试团队在一起交流、分享经验和解决问题。

  3. 制定明确的目标和责任：团队应该共同确定项目的目标和优先级，并建立统一的工作计划。业务人员和开发测试团队都应该对项目的成功负责，共同努力实现项目的目标。

  4. 敏捷实践的推广和培训：为了提高敏捷实践的投入度，团队应该对敏捷方法进行推广和培训。业务人员应该了解敏捷开发的原则和实践，以便更好地参与其中。

  5. 建立适应性强的团队文化：团队应该建立适应性强的文化，鼓励开放的沟通和合作。业务人员和开发测试团队应该相互信任，共同努力实现项目的成功。

通过以上方法，团队可以解决跨团队交流障碍，增强团队的合作意识和纪律性，实现敏捷开发的顺利推进，为产品的最终上线及推广效果负责。

此外，我建议你选两个或两个以上团队来进行试点。如果只选一个团队，孤品风险太大，也 没有竞争效果；而两个或两个以上团队容易产生竞争性，对比效果明显，大家都会争着把事 情做到最好。当然，这也要看敏捷教练的数量，一般一个教练一次只能带 2～3 个团队，否 则一个教练的精力是没有办法照顾到每个团队的。

例如 B 公司，他们希望通过导入敏捷提高研发效能。在试点时，我们选择了两个试点团 队，手机银行产品团队和直销银行产品团队。对于 B 公司这样的银行来说，这两个产品都 是公司的核心产品，在互联网的冲击下，业务压力很大，所以他们要求研发团队能够快速响 应，因此团队有相对强烈的敏捷实践意愿。

高内聚，低耦合组织

引申用在组织结构中，高内聚指的是日常工作中，全功能小团队内、小团队内部成员之间的 沟通合作更紧密；低耦合则指的是，团队之间的沟通协作要远比团队内部的少。这样的组织 结构才更适合推进敏捷。

Spotify框架的组织结构确实是一个典范的敏捷实践，可以提高团队的协作效率和响应能力。重组团队和培训是试点成功的重要步骤，下面进一步展开这些内容：

团队重组

  1. Squad分解和组建： 将原有的大团队分解成小团队，每个Squad都由跨职能成员组成，包括业务分析师、开发人员、测试人员和迭代经理。团队规模限制在5~9人，保持高内聚、低耦合的特性。
  2. Tribe划分： 当Squad数量超过一定限制时（如5个），将Squad划分到不同的Tribe中。Tribe是一个逻辑组织单元，可以包含多个Squad，负责类似业务或领域的项目。
  3. 产品负责人角色： 设立产品负责人的角色，负责整个产品的把握和协调。

敏捷培训

  1. 基础课程培训： 进行敏捷思想和实践基础的培训，确保团队成员对敏捷的理念和方法有一定的了解。
  2. 拆书会： 选择敏捷基础书籍，每个人分别阅读一部分，并在团队内分享，促进团队共同学习和进步。
  3. 干系人宣讲： 对项目的干系人进行宣讲，介绍敏捷的实践和成效，以获得支持和理解。

试点运行

  1. 随时讲解和解答： 在试点运行过程中，根据团队的实践情况，及时解答团队成员对敏捷的疑问和模糊认知，帮助团队更好地应用敏捷方法。
  2. 深入讲解需求管理： 针对需求管理的重要性，深入讲解需求条目化、用户故事拆分等技术，帮助团队更好地理解并应用敏捷的需求管理实践。

以上措施有助于推动敏捷实践在B公司的团队中落地，让团队成员更好地适应和应用敏捷的理念和方法，从而提高团队的研发效能和竞争力。同时，组织结构的优化和培训的持续推进是一个持续改进的过程，团队可以不断总结经验，不断优化和完善敏捷实践。

在 B 公司，起初我们在管理实践上选择了 Scrum 方法，在技术实践上则选择了单元测试、 自动化回归测试，还有搭建 DevOps 流水线。然而在实际推进敏捷试点的过程中，我们发 现在当时的情况下，由于团队的老旧代码过多，做单元测试的收益不大，所以我们及时调 整，优先推进了自动化接口测试、自动化回归测试和搭建 DevOps 流水线，而选择在试点 后再尝试单元测试。

经验：老旧代码过多的团队

做单元测试的收益不大 优先推进了自动化接口测试、自动化回归测试和搭建 DevOps 流水线

如何做好准备工作呢？

调整好结构、组织好人员、划定好需求、搭建好架构、选择好方法和工具、布置好办公环境

所谓“凡事预则立，不预则废”，在推进团队敏捷试点之前，你要挑选好试点团队，并做好 试点工作前的充分准备。如何做好准备工作呢？一句话：调整好结构、组织好人员、划定好 需求、搭建好架构、选择好方法和工具、布置好办公环境。

新的认识：

最后，团队在跨团队交流方面有很大的障碍，这表现在业务人员与开发测试团队隔离，目标 不统一，且参与敏捷的投入度不够。 对于已经采纳敏捷的团队而言，他们只是在开发测试团 队上做了一些敏捷实践，而并未将业务人员拉进来；团队也没有相应的制度，所以业务人员 在敏捷活动中想来就来、想走就走，毫无纪律性可言。另外，业务人员还是像过去一样，认 为提完需求，自己的工作就结束了，至于做不做得出来，是开发测试团队的事情，而不是想 着大家一起把产品做出来，一起去为它的最终上线及推广效果负责。一般而言，作为敏捷教练，我们自己会有一个自认为“正确”的推进顺序。但敏捷实践方法是团队来用的，行为和习惯转变也是团队要做的，而且我们也要打造自组织团队，所以相比你自己单纯地做口头宣讲，按自己的想法推进敏捷，引导团队自行选择和决定推进顺序会比较好，这更容易让团队认可和接受。所以重要的不是“你想”而是“团队想”，回顾会议正好可以完美地做到这一点。以我带过的一个手机银行团队为例。在第一次回顾会议时，团队针对做得不好的地方提 出“项目透明度差，只了解自己的工作而不了解其他团队成员的工作”，我就这个问题引导团队思考其背后的原因，之后团队一致认为主要原因是“没有地方和机会了解别人的工作”。我就势引导团队说：“大家觉得可以做些什么事情来改善这个问题呢？”最后大家讨论认为，不如约一个时间，每天定时定点地开个短会来共享一下彼此的工作内容和状态，这不就是“站立会议”吗？我们又一起给这件事情定了一个时间段：下个迭代。我领取了这个改进任务，在下一个迭代中为团队导入“站立会议”。

此外，试点涉及的主要是团队内部的敏捷，而规模化推广还要涉及团队间的敏捷。 规模化推广实例分析

这个案例来自一家银行，我们姑且叫它 D 公司，D 公司的研发团队有接近 2000 人，在比 较顺利地做了团队敏捷试点后，希望做规模化推广，让敏捷为整个公司的研发赋能。 我先分析了 D 公司的痛点，总结来说是研发效率比较低，无法满足业务发展的要求。 他们的问题也很突出，主要有 3 点：

  1. 研发中各个环节的效率有待提升，各个角色的等待时间过长；
  2. 敏捷走到业务那里就卡壳，业务人员参与度低；
  3. 跨团队沟通不畅，协作效率低。

针对问题 1，我们在规模化敏捷前的团队敏捷试点中，改变了研发模式，让小团队使用了 Scrum，很有效地解决了这个问题。而问题 2 和问题 3 涉及的就是大型团队敏捷导入与推广最需要解决的两个问题。该团队要想做好规模化敏捷，主要就是要突破这两个问题。

那该如何解决这两个问题呢？

针对问题 2 业务人员参与度低这个问题，其实就是 D 公司在敏捷推广时忽视业务这一环。

你要注意，只做到开发、测试团队的敏捷，只算是敏捷的一小胜利，最重要的是要走向业务

敏捷。只有业务敏捷了，我们才能和 IT 团队一起真正打通研发整个过程的敏捷，才能在短

时间内快速交付业务价值。所以针对问题 2，我们主要通过两个方法来解决。

第一是定制度。确立产品负责人制度，将过去以“项目”为中心的管理改为以“产品”为中

心的管理。只有这样才能让业务战略与产品战略合二为一，让整个团队目标一致，“劲儿往

一处使”，从而方便团队做好研发全链条的敏捷。 第二定反馈机制。在整个产品研发流程中进行数据收集和处理，做到从业务创意和机会捕捉 到需求识别，到开发上线，再到业务运营的整体大反馈闭环。这样的好处是为端到端的研发 过程提供了数据支持，以便在后续工作中识别整个研发过程的瓶颈，为持续改进做支持。 针对问题 3 跨团队沟通不畅这一问题，涉及的就是团队间的敏捷实践。 我们很多团队在需要兄弟团队协助开发时，总是希望对方在我们需要时能够随叫随到，但每 个团队都有自己的优先级工作，哪里有时间随时“听喝”呢？

因此，要建立各团队间的敏捷实践，就需要提前安排支持工作。这样，你们团队需要协助的 工作就会被排入对方的工作列表，就更加易于团队间依赖关系的管理，省去了很多无效的沟 通和无谓的等待。由于管理实践是后面一切具体技术实践的基础，因此在这里我只想教你如何在管理实践上探 索团队间的敏捷，带你做好这关键的第一步。所以针对问题 3，我们主要是建立沟通机制，对齐团队目标，把“做什么”和“怎么做”这两个方面的目标对齐以后，团队间的沟通就更加有序和有高效了。 具体的措施是定义了一系列关于产品团队内及与 Scrum 团队间的沟通策略和沟通机制、定 期的产品集体计划会议以及将团队间的依赖放到看板上，通过 Scrum of Scrum 等来定期 沟通进展。其他还包括一些具体的技术实践，例如怎么进行团队间版本控制，团队间的架构解耦等。

敏捷的规模化推广不是对试点经验的简单拷贝，也不是找来几个规模化框架往企业身上套， 而是需要根据企业的研发管理痛点和需要解决的问题，根据实际情况寻找解决方案。当然在 这个过程中，成熟的规模化框架可以给予我们参考。 规模化推广敏捷的核心是大型团队的敏捷导入与推广，主要集中在业务敏捷和团队间敏捷两 点上。你可以通过定制度、定反馈机制推进业务敏捷，可以通过在管理实践上建立沟通机 制，对齐团队目标来保证团队间敏捷的高效和有序。当然除了这一点，你也需要统筹全局， 从推广策略、文化、环境等方面完成整个敏捷规模化推广的持续改进。

敏捷是个整体工程，需要从全局上来考虑怎样去推进。在前期，要做好诊断和规划，在解决 痛点的基础上导入适合自己的敏捷方法；推进过程可以分步进行，要及时排查每一步中出现 的新的阻碍；要加强协作，打通研发管理的全链条，必要时要成立高层参与的敏捷督导团 队，请高层领导帮忙推动；在整个敏捷实践过程中都需要有能力的敏捷教练陪伴，并在推进 过程中培养出适合自己团队的 Scrum Master。

真敏捷，还是“小瀑布”？

那么真正的敏捷是什么样子呢？

以需求为例，团队会尽可能有效拆分需求，这样进入到迭代内的需求就可以是多个独立的小 需求。小到什么程度呢？小到每个需求都可以在很短的时间内，比如 2～3 天内完成开发和 测试，最长也不要超过一个迭代周期。

这样在开发人员写代码的时候，测试人员在写测试案例，或者在考虑使用自动化测试方案。 由于需求拆分得足够小，所以很可能第一个小需求在迭代后的第二天就可以交付测试了，在 测试人员测试这个需求的同时，开发人员继续开发下一个小需求，由此形成一个良好的循 环。在这种情况下，大家都在热火朝天地工作，节省了很多等待的时间。

原因：拆分的需求太大

没错，就是需求太大，这导致团队在做敏捷时不能发挥敏捷的优势，将敏捷实践做成了不折不扣的“小瀑布”。

我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意

MVP：识别核心需求，交付核心需求

你应该还记得在敏捷的原则里，有一条是“我们最优先要做的是通过尽早的、持续的交付有 价值的软件来使客户满意”，也就是说我们要先做有价值的东西。所以反应到这个项目中， 我们其实可以先把客户的需求拿来看一下，挑选好并先从有价值的、优先级最高的需求开始 做。

你有没有看到，在这里我其实是把“3 个月做完项目”这个课题转换成“3 个月做一个让客 户满意的产品”，而其实后面的那个课题才是客户最需要的。

接着再来看看 N 团队，他们的问题是需求太大。这里涉及两个层面，第一个层面是拆分方 法不当，导致大需求并没有被正确拆分成小需求；第二个层面是即使拆分方法得当，拆分后 的需求仍然很大。

第一步我先给他们讲解了需求拆分的方法。

需求拆分

需求拆分的方法有很多， 例如按照业务流程、按照业务规则的变化或按照数据的处理方式进行拆分等等。 你要注意，不管是使用哪种拆分方法，做需求拆分的目的，都是把大需求拆成一个个能够独 立开发测试的小需求。只有这样，我们才能在迭代中同时做几个小需求，而不需要等待，并 且在测试完成后，这些小需求也能独立上线。

你要注意，不管是使用哪种拆分方法，做需求拆分的目的，

都是把大需求拆成一个个能够独立开发测试的小需求。

如何拆分用户故事是敏捷开发一个很关键的部分，而评估是否是一个好的用户故事标准就 是能否独立进行上线，如果做不到独立上线，那这个还不叫用户故事，测试也没办法并行 进行，也不是真正的敏捷开发。另外敏捷开发跟现在到微服务架构是相辅相成，敏捷开发 非常适合微服务这种开发模式，微服务能够提高敏捷开发的效率。总之，敏捷开发的精髓 应该是团队至上，小步快跑，快速迭代，拥抱变化。

回复: 赞一个！优秀用户故事的标准业界有通用的认识，公认的是符合INVEST原则。在《用 户故事与敏捷方法》一书中有介绍，可以去看一下。

<用户故事与敏捷方法》

服务型领导：在敏捷环境中的挑战与应对

在我做敏捷咨询的过程中，有团队领导曾经跟我表露过对“敏捷”的担忧。他担心在这场新的变革中，强调团队的自我管理，作为团队的管理者和领导者是否会失去职位。然而，我们可以从另一个角度来看待这个问题：在工业革命时，机器取代了一些人类岗位，但同时也创造了更多的工作机会。

与工业革命一样，敏捷变革带来了新的组织方式和文化理念，对领导方式和领导能力提出了新的要求。这也是一个时刻，鼓励领导者更新他们的管理方式，在敏捷变革下不断提升管理能力。

为什么要成为服务型领导？

在不断变化的社会和敏捷实践中，我们需要不同类型的管理者和领导者。工作的复杂性不断增加，传统的管理方式在新环境中难以应对。因此，我们需要能够快速响应新市场需求的领导方式。这需要领导者具备出色的协调能力，与团队合作，共同应对复杂的工作挑战。

这就是“服务型领导者”的概念。服务型领导者首先是服务者，与整个团队建立亲近关系，赢得团队的信任。他们的目标是与团队成员一同成长，通过为大多数人谋取利益来激励团队，最终实现整个工作的成功。

怎样成为服务型的领导？

要成为服务型领导者，首先要建立心理安全机制，与员工建立紧密联系，以更好地实现团队目标。建立心理安全机制的方法包括：

  1. 信任：支持员工的决定，在工作和生活方面关心团队成员。
  2. 健康的分歧环境：鼓励不同意见的存在，虚心听取不同的看法。
  3. 正确的失败文化：接受失败，从中吸取教训，不断改进。

除了建立心理安全机制外，还需要掌握情境领导能力。情境领导能力强调根据不同情境运用不同的领导风格，以指导和支持团队成员实现目标。

在实际工作中，领导者通常会面对四种不同的情境，每种情境需要不同的领导风格：

  1. 热情的初学者：需要指导，通过讲述和展示指导员工完成目标。
  2. 幻灭的学习者：需要教练，对员工解释任务意义，鼓励参与，持续指导。
  3. 有能力但谨慎的贡献者：需要支持，通过提出开放性问题促进问题解决，不多加干涉。
  4. 自力更生的成功者：需要授权，认可员工的专业知识，激发自主性，让他们发挥潜力。

通过上述例子，我们可以清楚地了解如何根据不同情境运用不同的领导风格，激发团队成员的能力和信心。最终，情境领导力的三个关键要点——设定目标、协同诊断、学会匹配，将帮助领导者在敏捷环境中有效地管理团队。

这里我还想再强调一下，你可以通过下面这 3 点用好情境领导力：

  1. 设定目标。要运用好目标管理，设立正确的目标，目标的设定要与需要做的事情保持一致；

  2. 协同诊断。要会评估员工在特定目标或任务上的能力和承诺，判断员工在这个目标或任务上属于哪一种情境；

  3. 学会匹配。根据员工所处的情境，匹配自己所需要运用的领导风格，帮助他们实现工作目标或完成工作任务，也为他们个人提供需要的帮助。

敏捷思想：做得多不等于价值大

在敏捷环境中，有一个重要的思想是“做得多不等于价值大”。这个思想的核心在于强调工作的价值和效果，而不仅仅是任务的数量。下面是我如何理解并将这个思想应用到我的工作中的过程：

过去的工作习惯与挑战

过去，我习惯一股脑地做所有的事情，不管它们是否真的能够创造重要的价值。这让我忙碌不堪，每天都感到压力巨大，却不一定看到显著的成果。这种方式可能会让人陷入忙碌但无效的境地。

敏捷思想的启示

在接触到敏捷思想后，我开始思考“价值”的概念。我意识到，重要的是聚焦于那些真正能够创造价值、推动目标实现的任务，而不是盲目追求数量。我采取了以下步骤来将这个思想融入我的工作：

  1. 工作池的创建：我将自己的工作列成清单，放入Jira等工具中，形成一个“工作池”。
  2. 任务评估：我开始评估每个任务的价值大小。这需要我思考任务对项目或团队目标的贡献程度。
  3. 优先级排序：基于任务的价值，我将它们按照优先级进行排序，确保先处理价值最大的任务。

应用到工作中的改变

现在，当我每天开始工作时，我不再盲目投入任务，而是先检视今天的任务，区分出哪些具有较大的价值。然后，我会优先处理这些高价值的任务，确保它们得到优先完成。

每天结束时，我会总结当天的收获和注意事项，记录在工作笔记中。虽然工作时间没有延长，但由于专注于高价值任务，我感到更有成就感，工作绩效也得到提升。

敏捷带来的变化

敏捷不仅在工作中带来了变化，也影响了我的生活。它让我保持对世界的好奇心，开放的思维以及积极的态度。作为一个职场人，我保持对新事物的学习热情，尝试学习钢琴、绘画、法语、滑冰等各种有趣的事情。

这种积极的学习态度和追求高价值任务的习惯，让我在工作和生活中都能够更加高效、有创造力地追求更大的价值。