ACP敏捷实践指南
2022-05-05 21:05:01 0 举报AI智能生成
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
作者其他创作
大纲/内容
‘个体以及互动’而不是‘过程和工具’
‘可用的软件’而不是‘完整的文档’
‘客户合作’而不是‘合同谈判’
‘应对变更’而不是‘遵循计划’
敏捷宣言
我们的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求
欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势。
要经常交付可用的软件，周期从几周到几个月不等，且越短越好。
项目实施过程中，业务人员与开发人员必须始终通力协作。
要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务
无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面的交谈
可用的软件是衡量进度的首要衡量标准
敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该都能够始终保持步调稳定。
对技术的精益求精以及对设计的不断完善将提高敏捷性。
简洁，即尽最大可能减少不必要的工作，这是一门艺术。
最佳的架构、需求和设计将出自于自组织团队。
团队要定期反省怎样做才能更有效，并相应地调整团队的行为。
十二大原则
敏捷概述
仆人式领导是一种为团队赋权的方法。仆人式领导是通过对团队服务来领导团队的实践，他注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。
定义
与团队一起定义“为什么”或目的，以便他们能围绕项目目标进行合作互动。整个团队在项目层面而不是在人员层面优化。
目的
目标确立后，鼓励团队创造一个人人都能成功的环境。要求每个团队成员在项目工作中做出贡献。
人员
不要计划遵循“完美”的敏捷过程，而是要注重结果。如果跨职能团队能够常常交付完成的价值并反思产品和过程，团队就是敏捷的。团队将其过程称作什么都不重要。
过程
提升自我意识
倾听
为团队服务
帮助他人成长
引导与控制
促进安全、尊重与信任
促进他人精力和才智提升
优点
教育相关方，使其了解为什么要敏捷以及如何敏捷。根据优先级说明商业价值的好处，对被赋权团队加强问责，提高工作效率，并通过更频繁的评审改进质量
通过指导、鼓励和帮助为团队提供支持。倡导团队成员的培训和职业发展。“我们通过支持的方式领导团队”，这句话说的是领导在发展其团队成员时所扮演的角色。通过支持、鼓励和专业发展，团队成员将获得信心，承担更多的职责，并在组织中做出了更大的贡献。仆人式领导的一个关键作用是，培训和发展团队成员，帮助他们超越自身当前的角色，即使团队将失去他们也在所不惜。
通过技术项目管理活动，如量化风险分析来帮助团队。有时团队成员可能并不具备在某些角色或功能方面的知识或经验。对相关技能有更多接触、或者接受过相关培训的仆人式领导可以通过培训或开展这些活动为团队你提供支持。
庆祝团队的成功，为团队与外部团队合作提供支持，并起到桥梁作用。创造相互欣赏的积极氛围，建立加强合作的良好意愿。
职责
仆人式领导
实施敏捷：创建敏捷环境
我们为什么要做这个项目？这是项目愿景。
谁会从中受益？如何收益？这可能是项目愿景和/或项目目标的一部分。
对此项目而言，达到哪些条件才意味着项目完成？这些是项目的发布标准。
我们将怎么合作？这说明预期的工作流。
敏捷项目章程
当团队完成一个发布或加入一些功能时。这不一定是一个巨大的增量。它可以是任何发布，无论他有多小。
自上次回顾以来，又过了几周时间
当团队出现问题时，以及团队协作完成工作不顺畅时。
当团队达到任何其他里程碑时
回顾时间
回顾不是责备；回顾是让团队从以前的工作中学习并做出很小的改进。
回顾针对定性的（人的感觉）和定量的（衡量指标）数据，然后利用这些数据找到根源，涉及对策，并制定行动计划。项目团队可以采取许多行动事项来消除障碍。
回顾
待办事项列表是所有工作的有序列表，它以故事的形式呈现给团队。
待办事项列表编制
在基于迭代的敏捷中，产品负责人往往在迭代中期的一次或多次会议中与团队合作，为即将进行的迭代准备一些故事。这些会议的目的是细化足够的故事，让团队了解故事的内容，以及股市之间的相互关系。
基于流程的敏捷的及时细化。团队将下一张卡片从待办事项列表中拿出来讨论。
许多给予迭代的敏捷团队在两周的迭代中用一小时的时间盒讨论。（团队选择一个迭代持续时间，为他们提供足够频繁的反馈。）
基于迭代的敏捷团队的多次细化讨论。团队可以在陌生的产品、产品领域或问题领域使用这一技巧。
待办事项列表的细化
团队成员利用站会对彼此做出小的承诺，发现问题，并确保团队工作顺利进行。
为每日站会规定时间盒，不超过15分钟。团队以某种方式‘过一下’看板或任务版，而团队中的任何人都可以主持站会
上次站会以来我都完成了什么
我现在到下次站会，我计划完成什么？
我的障碍（或风险或问题）是什么？
基于迭代的敏捷，每个人需回答问题
我们还需要做些什么来推进这一工作？
有人在做看板上所没有的事情吗？
作为一个团队，我们需要完成什么？
工作流程是否存在瓶颈或阻碍？
基于流程的敏捷，团队从右到左对看板进行评估。
站会是为了发现存在问题，而不是解决他们。将问题添加到停车场区，然后创建另一次会议，他可以在站会之后立即召开，并在会上解决问题。
每日站会
团队在迭代结束时展示所有已完成的工作项
基于迭代的敏捷中
团队在需要时展示完成的工作
基于流程的敏捷中
展示/评审
团队应考虑自身故事大小，避免提交更多的故事，而超出团队在一个迭代中所能完成工作的能力。
规划基于迭代的敏捷
无论产品如何，都要频繁地将工作集成到整体中，然后再进行重新测试，以确定整个产品仍然按照预期工作。
持续集成
对端到端信息使用系统级测试，对构建快使用单元测试。在两者之间了解是否需要进行集成测试，以及在何处进行测试。
团队发现冒烟测试有助于测试工作产品是否良好。
团队发现，决定何时以及对哪些产品进行回归测试，可以帮助他们在维护产品质量的同时，良好地构建性能。
敏捷团队非常偏爱自动化测试，因此他们可以借此构建和保持交付的势头。
在不同层面测试
在ATDD中，整个团队聚集一堂讨论产品验收标准。然后，团队创建测试，这让团队能够编写足够的代码，进行自动化测试，满足标准要求。对于非软件项目，要考虑怎样在团队完成大量价值时对工作进行测试。
验收测试驱动开发（ATDD）
在编写/创建产品之前编写自动化测试，实际上可以帮助人员设计产品，防范产品错误。对于非软件项目，要考虑如何通过“测试驱动”团队的设计。硬件和机械类项目经常使用模拟进行设计的中间测试。
测试驱动开发（TDD）和行为驱动开发（BDD）
刺探对学习很有用，可以在诸如评估、验收标准定义以及通过产品了解用户行为的流程中使用。在团队需要学习一些关键技术或功能要素时，刺探会很有帮助。
刺探（时间盒研究或实验）
帮助团队交付价值的执行实践
迭代可以帮助团队为交付和多种反馈创建一个节奏。团队会为交付和反馈创建增量。交付的第一部分是一次演示。团队会收到关于产品的外观和运作方式的反馈。团队成员回顾如何检查和调整有关过程以取得成功。
演示或评审是敏捷项目流程的必要组成部分。为团队的交付节奏安排适当的演示。
迭代和增量如何帮助交付工作产品
常见敏捷实践
解决敏捷项目的挑战
敏捷倾向于使用基于经验和价值的衡量指标，而不是预测型衡量指标。敏捷衡量团队所交付的成果，而不是团队预测将交付的成果。
基准通常是尝试预测的产物。在敏捷中，团队的估算是多限于未来几周时间。在敏捷中，如果团队工作的可变性不高，如果团队成员没有从事多任务，则团队的能力就会变得稳定。这样才能对未来几周做出更好的预测。
基于流程的敏捷团队使用不同的衡量指标，交付周期（交付一个工作项目花费的总时间，从项目添加到看板直至项目完成）、周期时间（处理一个工作项目所需的时间）和响应时间（一个工作项目等待工作开始的时间）。
敏捷项目的衡量指标
实施敏捷：在敏捷环境中交付
Scrum是用于管理产品开发的单个团队过程框架。采用迭代方法来交付工作产品，Scrum是运行在1个月或更少时间的时间盒上的，其中包含持续时间一致的多个冲刺，在这些冲刺中会产生潜在可发布的产品增量。
负责实现产品价值的最大化
产品负责人
是一个跨职能自组织团队，其开发成员拥有所需的一切资源，可在不依赖团队外部其他资源的情况下交付工作产品。
开发团队
负责确保Scrum过程获得相应支持且Scrum团队遵从实践和规则，并指导团队消除障碍。
Scrum 主管
冲刺、冲刺计划、每日例会、冲刺评审、冲刺回顾
Scrum事件
产品待办事项列表、冲刺待办事项列表、增量
Scrum工件
SCRUM
极限编程（XP）是一种基于频繁交付周期的软件开发方法。
将特定最佳实践提炼到最纯粹和最简单的形式，然后在整个项目周期内持续运用该实践
主要：集中办公；整个团队；信息灵通的工作场所
次要：真实客户参与；团队连续性；可持续节奏
组织
主要：结对编程；测试优先编程；增量设计
次要：共用代码/集体所有制；代码和测试文档；重构
技术
主要：用户故事；每周周期；每季周期；时差
次要：根本原因分析；裁剪团队；按适用情况支付；协商范围合同；每日站会
规划
主要：10分钟构建；持续集成；测试优先
次要：单代码库；增量部署；每日部署
整合
XP实践领域
该演变是通过筛选核心价值观（沟通、简洁、反馈、用气、尊重）并根据主要原则（人性化、经济、互惠互利、自相似、改进、多样性、反思、流程、机会、冗余、失败、质量、循序渐进、承担的责任）信息来设计和采用技术的结果
极限编程
看板在精益制造中是一种用于规划库存控制和补给的系统
看板方法应用并适合于多种场合，可以确保工作流和价值交付的持续性。
与大多数敏捷方法不同，看板方法未规定使用时间盒迭代。在看板方法中可以使用迭代，但应是始终遵循在整个过程中持续拉去单个条目并限制在制品以优化流程的原则。
团队通常不受时间盒的限制，将执行待办事项列表中优先级最高的工作。
灵活性
团队专注于完成整个系统工作流，直至在制品完成才会开始新工作
专注于持续交付
通过限制在制品将可以提高工作效率和质量
提高工作效率和质量
检查每个任务，了解增值或非增值活动，然后清除非增值活动
提高效率
限制在制品，使团队能够专注于当前工作
团队成员专注力
如果即将开展的工作存在不可预测性，团队将无法做出可预测的承诺，即使对于短期工作也不例外
工作负载的可变性
透明将会使浪费可视化，因而能够消除浪费
减少浪费
看板方法适用团队
从当前状态开始
同意采用增量演变性变更
尊重当前过程、角色、职责和头衔
鼓励所有层级领导行为
定义原则
工作流可视化
限制在制品
管理流程
明确过程政策
实时反馈循环
提高协作性
核心属性
看板方法
水晶方法是一种方法论家族。水晶方法论旨在根据项目规模（项目中涉及的人员数量）以及项目的关键性来量化并提供方法严格程度选择。
人员；交互；社区；技能；人才；沟通
核心价值观
频繁交付；反思式改进；密切或渗透型沟通；个人安全；专注；容易接触专家用户；具有自动化测试、配置管理和频繁整合的技术环境
常见属性
水晶方法
Scrumban是一种敏捷方法，最初设计为Scrum到看板之间的过渡方法。它是通过其自身衍生演变而成的另一种混合敏捷框架和方法，其中团队将Scrum作为框架，而将看板作为过程改进方法。
工作被分解到许多小的‘冲刺’，并利用看板面板来可视化和监督工作。
将故事列在看板面板上，团队通过使用在制品限制来管理其工作。
通过召开每日例会来维持团队之间的协作并消除阻碍。
团队通过设置规划触发因素来了解何时规划下一步工作，通常发生于在制品级别低于预设限制时。
Scrumban看板中没有预定义角色-团队保留其当前角色。
SCRUMBAN
开发整个模型
构建功能列表
依据功能规划
根据功能设计
依据功能构建
功能驱动开发项目分为五个过程
领域对象建模
依据功能开发
个体代码所有制
功能团队
检查
配置管理
定期构建
进度和结果可视化
功能驱动开发活动由一组核心软件工程最佳实践提供支持
开发高层级模型--开发功能列表--依据功能规划--依据功能设计--依据功能构建
功能驱动开发项目生命周期
功能驱动开发
DSDM因强制约因素驱动交付而著称
该框架从一开始便可设置成本、质量和时间，然后利用正式的范围优先级来满足这些制约因素的要求
专注于业务需求
准时交付
协作
在质量上永不妥协
在坚实的基础上进行增量式构建
迭代开发
保持持续和明晰的沟通
演示控制（使用适当的技术）
八个原则
动态系统开发方法
敏捷统一过程（AgileUP）是软件项目中统一过程（UP）的分支
与紧前统一过程相比，该过程具有加速周期和轻量级的过程。其目的在于在七个主要元素之间执行更多迭代的周期，并在正式交付之前纳入相关反馈。
模型、实施、测试、部署、配置管理、项目管理、环境
发布中的因素
团队了解当前工作，简洁性，敏捷性，专注于高价值活动，工具依赖性，量身定制，特定情境
指导因素的原则
敏捷统一过程
也称作‘Mate Scrum’，是由两个或多个Scrum团队而不是一个大型Scrum团队所使用的一种技术，其中一个团队包含三到九名成员来协调其工作。
每个团队的代表会与其他团队代表定期召开会议，可能是每日例会，但通常是一周两次或三次。
每日例会的执行方式类似于Scrum的每日站会，其中代表将报告已完成的工作、下一步工作设置、任何当前障碍以及可能会阻碍其他团队的潜在未来障碍。
SCRUM OF SCRUMS
拓展框架
采用经济视角；应用系统思维；假设可变性；预留方案；以快速整合的学习周期进行增量式构建；根据对工作系统的客观评估设定里程碑；直观显示并限制在制品，减小批次规模并管理队列长度；应用节奏；与跨域规划同步；解锁知识员工的内在动力；决策分散化
大规模敏捷框架（SASFe）
以拓展Scrum方法为共同目标来组织多个开发团队的框架，核心组织原则是尽可能保留传统单个团队Scrum模型的元素
一个产品待办事项列表；一个所有项目完成的定义；一个可在每个冲刺结束时潜在交付的产品增量；一名产品负责人；全面的跨职能团队；一个冲刺
Less与Scrum相似性
冲刺计划分为两个正式部分：冲刺内容和方式；有机跨团队协作；整体跨团队优化；专注于跨团队改进的整体回顾。
在Scrum中添加Less技术
大规模敏捷开发（LeSS）
企业Scrum是一种旨在通过更整体性组织层而不是单个产品开发层来应用Scrum方法的框架
将所有Scrum应用拓展到所有组织方面
普及Scrum技术以便在这些不同方面轻松应用
根据需要使用补充技术拓展Scrum方法
该框架尤其建议领导
企业Scrum
规范敏捷是一种在综合模型中整合多种敏捷最佳实践的过程决策框架。DA旨在平衡专注范围过于狭窄（如Scrum）或细节过于规范（如AgileUP）的流行方法。为实现这种平衡，该方法根据以下原则混合了多种敏捷技术：
以人为先。枚举不同层级的角色和组织元素。
面相学习。鼓励协作改进
完全交付生命周期。提倡多个符合目的的生命周期
目标驱动。定制过程以实现特定结果
企业意识。提供跨部门治理方面的指导。
可拓展。涵盖多种项目复杂性维度。
规范敏捷（DA）
常见敏捷方法
必须首先积累经验并能够成功利用一种敏捷方法才能尝试剪裁
将大项目重建为多个小项目。首先尝试技术实验项目，然后再执行实施项目；考虑频繁发布较少的功能，以创建较小的项目团队；考虑将团队裁剪到仅包含关键核心成员。通常人员过多会阻碍过程而不会有所助益；所限团队规模可减少内部动荡和成本；将大型团队分解为多个小团队，并利用项目管理进行同步和协调；利用敏捷和精益项目管理来组织大型项目。
大型项目团队
许多项目都会包含（一些）分散团队成员。即时信息、视频会议和团队电子板都有助于确保通讯流畅。如果团队保存稳定，请尽快构建面对会议以提高未来远程交流的效率。面对面交流时更容易建立信任感，提高对话质量；如果在远程会议过程中参与者缺乏面部表情和身体语言交流，请考虑循环提问以确认他们的参与程度以及对决策是否认可。此外，请考虑使用基于迭代的敏捷方法。如果团队成员所在时区差比较大，请避免使用整个项目迭代方式，而是鼓励开展更多更频繁的私人会议（每次两到三人）。
分散团队
在这些环境中仍可使用敏捷方法，但还需要该领域所要求的其他相应的合规性审查、文档和认证。在这种情况下，文档可能需要随已完成的功能一起交付。只有文档完成后功能才算完成。
考虑使用混合方法（多种敏捷方法），按照产品环境所要求的更高严格程度，从敏捷所带来的协作和沟通改善中获得益处。航空飞行系统开发商和药物公司采用敏捷方法并结合自己的其他过程，充分利用这些优势并保留了相应的控制权。
某些安全关键型产品可能需要当前敏捷过程所建议的其他文档及合规性检查。
是否真正需要敏捷方法？如果需求不确定性较低、变更速度缓慢、或者执行风险很小，则可能不需要整套敏捷方法。尽管协作和透明程度提高对任何项目都有益处，但某些迭代构建和审查周期可能会是多余的。
如果构建/反馈周期无法定期发现或优化需求，请考虑延长其持续时间以减少审查时间对成本的影响。
如果项目在设计和开发期间的变更速度极快，但向客户交付是一个确定性的可重复的过程，在每个项目阶段采用相应生命周期模型的混合方法可能更有意义。
稳定需求和执行过程
敏捷是基于跨职能团队的理念。考虑让这些员工自行创建跨职能团队，而不采取管理干预手段，并了解其后果。
如果能够通过组织报酬系统认可职能领域并给予奖励，请考虑首先变更该系统。除非对自己的报酬有一定影响，员工才会为产品或团队的利益行事。
团队位于职能型组织内的职能孤岛中
敏捷将创建透明文化：员工会在整个开发期间展示和分享其成果。这种分享中间可交付成果的方式以及对成败得失和当前状态的开诚布公的态度即反映了透明化。透明需要勇气。通过使用状态版或白板，示范引导并在决策过程中展示透明化。
透明会产生恐惧
敏捷方法将会提高团队的主动性并发挥其优势，作出工作内容相关的本地决策，例如任务安排顺序以及在解决问题时采用哪种方法。如果大多数团队成员经验不足，基于共识的方法可能会产生问题并导致返工。因此，对于这些团队来说，在获取必要技能之前，一些‘分配’和‘指导’方面的额外帮助可能是必需的。换言之，不要盲目地采用敏捷方法，授权经验不足的自指导团队尝试解决一切问题。考虑构建能力中心以帮助提供指导并积累领域知识。
许多团队成员缺乏技术领域知识
如果缺乏管理层支持，团队将会在敏捷思维模式和方法与更具预测型的思维模式和方法之间遇到冲突。
根据组织需求找到共同点和改进之处，然后利用实验和回顾取得进展。
考虑管理层教育/培训。考虑从精益思维方面揭示敏捷：周期短、规模小、频繁审查、回顾与小幅改进。
缺乏管理层支持
如果不是敏捷语言，就修改术语，让员工了解并同意这些活动。说明每个术语的特定含义。
敏捷术语和语言不适合组织文化
影响剪裁的属性
文化：是否具有支持该方法并已建立信任的团队环境？
团队：适当规模的团队是否能在采取敏捷后获得成功？成员是否能够获得成功所需的技术以及业务代表联系渠道？
项目：变更速度极快？增量交付可行？项目关键性如何？
敏捷适用性筛选工具
ACP敏捷实践指南
0 条评论
回复 删除
下一页
