敏捷开发的个人实践

搬运工

敏捷（Agile）开发

是一种以人为核心、迭代、循序渐进的开发方法。

是一种快速响应变化需求的一种软件开发能力。

是一种持续根据用户反馈和需求优先级发布新版本，不断迭代、增量的理念。

前言

敏捷开发的痛点在于，团队开发过程中，单一的开发模式并不适用于一个团队之中，往往会融合团队leader与manager的理念。敏捷的目的是在团队内积极的交流，有效的沟通，统一的价值观，目标是交付可感知的功能。但是随之而来的是需求的混乱（需求与变更的入口包括所有参与人员）、冲刺的疲惫、缺失的文档、稀碎的质量。对外不但要有快速的响应和多元化的输出。对内要有严格的质量控制，宽松积极的环境。团队需要服务者去激励，而不是一个敏捷教练去控制。这种激励包括变化使用游戏、思维风暴等类型的敏捷方法，关注开发个人状态调整他的工作量技术栈和工作方向，给予信任、个人成长环境、团建和金钱奖励。疏于一个环节的跟进都会导致项目的不可控。

敏捷开发的优势在于，早期交付可感知的迭代版本，及时反馈需求，降低风险。

敏捷开发的难点在于，如何将大项目切分梳理成多个可执行敏捷开发方法论的可交付的子项目。将子项目需求分析成具有检查点的迭代需求任务，进而工作分解成成为用户故事和工作任务。跟进责任人的燃尽图，尽量平滑任务完成的曲线。在敏捷会议中的评审阶段消化开发盲区。

比较流行的敏捷（Agile）的管理和工程实践有精益（Lean）、Scrum、极限编程（XP）和看板方法（Kanban）等。DevOps的核心内容是敏捷方法（Disciplined Agile）、持续交付（Continuous Delivery）和轻量化的IT服务管理（ITSM）。其中敏捷方法的开发部分内容继承了敏捷开发方法论（Scrum）和极限编程（XP）的良好实践。

1 敏捷开发

---

1.1 敏捷（Agile）

在2001年，17位研发人员共同探讨出了《敏捷宣言》，定义了四项价值观：

左项	右项	描述
个体和互动	流程和工具	以人为本，重视互动
工作的软件	详尽的文档	目标导向，持续交付
客户合作	合同谈判	客户为先，参与反馈
响应变化	遵循计划	拥抱变化，快速响应

尽管右项有其价值，我们更重视左项的价值。

以及指导执行的敏捷开发十二项原则，尽早的以及连续的高价值交付、自组织团队、小批量交付、团队节奏、可改善可持续的流程、保持沟通等。

敏捷开发的核心是目标的迭代开发、功能的增量开发。

1.2 应用范围

stacey矩阵描述了不同需求、技术的项目应该用什么类型的开发模式。

敏捷开发属于迭代式增量，同样适用。对于混乱的项目，这种混乱可能是组织管理结构、并行管理、需求偏差、背景复杂、不可行等等，此时大部分的压力都在研发团队，同样可以使用敏捷开发实现可预见的最小快速失败。可能会在新的沟通过程中打开窗口，缓冲冲突。

1.3 scrum

流行的敏捷（Agile）开发方法有精益（Lean）、Scrum、极限编程（XP）和看板方法（Kanban）等。侧重点各不相同。

描述：Scrum是一种灵活的敏捷软件开发管理过程。

理解：跨职能团队在一个sprint冲刺中，把球传来传去，好像橄榄球争球列阵。

结构：

• 一个承诺：承诺目标，专注工作，开放检查，履行承诺，接受尊重
• 三个角色：product owner，master，team
• 三个工件：Product Backlog、Sprint Backlog、Burn Down、（QA List自己加的）
• 四个会议：Planning meeting、Daily Scrum meeting、Review meeting、Retrospective meeting

1.3.1 scrum 流程

1.3.2 产品需求列表 Product Backlog

需求列表是产品的的功能总纲，对于开发团队而言，期望应有清晰的检查点和优先级，并大致估算时间。检查点可以便于理清需求脉络、估算较大需求的时间、任务分解、将分解出的小任务分离出去，继续分解。需求列表中较稳定、清晰的任务可用于编写模板代码和由新手培训。有价值的、恰如其分的、清晰的、可变性小的任务分解，可以放入Sprint Backlog

需求列表是不断增量的，参照设计人员的需求分析，是研发团队所理解的需求的功能描述和项目的技术组件的待办事项。

在敏捷开发流程中，需求列表的入口很复杂，

1.3.3 迭代任务列表 Sprint Backlog

sprint是一个迭代（iteration），一个开发周期。制Sprint Backlog，要聚焦有价值的结果和指定恰到好处和清晰的Sprint Backlog。

设计恰如其分的sprint计划，而不是面面俱到。sprint会议分析较粗粒度的用户故事，分发负责人。根据用户故事的粒度设定故事点。由研发人员自己设计细粒度的用户故事呼应sprint backlog并上看板。根据负责人的估计时间，乘以开发系数，计算工时。（高级别研发人员的开发系数少，如1.2。低级别研发人员开发系数多，如1.5）。这里需要明确负责人，工时缓冲，同时需要跟踪任务的开始时间、结束时间与进度，开始绘制燃尽图，调度主线任务的畅通执行。同时，需要根据情况明确交付标准，比如单元测试代码、demo、详细设计文档等。当开发过程中出现需求变更，或理解需求偏差导致的时间变动，都需要反馈到迭代日志中。

1.3.4 燃尽图 Burn Down

燃尽图是一条显示剩余工作量的计划曲线。明确了需要完成的剩余任务的总和，直观展示，统一进度。在项目进度执行过程中，快速发现任务变更、任务分解等情况，尽量使燃尽曲线贴合计划曲线。燃尽图依赖于精准的预估，同时也需要有在小范围内的变化调整的能力。在开发过程中直观展示进度曲线，在开发回顾总结中描述项目进度。

1.3.5 问题QA表 QA List

有时公司组织架构的不同，导致需求和研发、测试和研发在不同版本上的工作进度有偏差。此时积极沟通可能没有作用，回复的内容会因为时间偏差和工作内容偏差导致结果描述的偏差。这时需要提前的提供QAList进行交互。同样可以使用邮件、jira交互。但是也会出现回复不谨慎而导致的增加工作量的情况。为了明确责任链还是最好有明确的QA记录。同样，测试根据测试版本的不同与开发、需求人员也有一定的信息代沟。

不明确的BUG和需求答复，会急剧打乱backlog计划，减少不必要的工作量浪费和扯皮热情。

1.3.6 交付

持续集成在代码提交后触发单元测试和自动化部署。

单体应用的送测单参照如下，之后由测试人员进行冒烟测试，功能测试，集成测试等。

1.3.7 每日站立会议 Dally meeting

每日成员间的承诺，了解工作内容。Master需要安排相关人员扫除问题。成员需要更新看板与燃尽图

• 昨天我完成了什么工作（2-3个细粒度的任务）
• 今天我打算做什么
• 我（可能）遇到了什么障碍，需要与谁交互

1.3.8 评审会议 Review meeting

虽然一般意义上评审完成Demo，所有涉及该功能的人员都可以参加。但是一般情况下，属于开发内部的代码review会议，不但查看User Story的完成度，也要对开发团队的内部问题，人员调度，代码审查，重构设计等环节日益求精。“每日解决1个小问题”。对于可能使用的新技术预研讨论等。

1.3.9 用户故事 User Story

As a Role, I want to Activity, so that Business Value.

用户故事不是想当然自嗨的，是需要与需求设计人员或其他相关人员确认的，通常写成 Card 形式，最好有交付目标和工时。

1.3.10 其他

结对编程、持续集成等。

2 DevOps

2.1 区别与联系

敏捷是为了解决业务与开发间的沟通和响应的gap，DevOps是为了解决运维与开发间的敏捷与安全稳定菜的gap。

敏捷从内核来说，是客户、需求、研发、测试不同角色组合不同模子间的有效沟通，DevOps不但引入了自动化运维和持续交付等D2O，更拓展到E2E（端到端）。

2.2 驱动力

• 业务敏捷
• 虚拟化和云计算基础设施
• 运维数据中心自动化
• 敏捷开发

2.3 docker实践

本文作者： Sapphire
本文链接： https:rensifei.site/2016/10/sprint/
版权声明： 转载请注明出处！