系统分析与设计复习-敏捷项目管理和实践

敏捷较传统模式更符合软件开发规律

敏捷宣言：

个体和交互胜过过程和工具

可以工作的软件胜过面面俱到的文件

客户合作胜过合同谈判

响应变化胜过遵循计划

敏捷开发原则：

客户满意，拥抱变化，短迭代交付，业务参与，以人为本，面对面沟通

结果导向，保持节奏，追求卓越，简单务实，团队自组织，持续改进

敏捷的三个层次

敏捷=理念+优秀实践+具体应用

理念（敏捷核心思想）

优秀实践（敏捷的经验积累）

具体应用（能够结合自身灵活应用才是真正的敏捷）

敏捷理念：

聚焦客户价值

标识和消除软件开发中的浪费（浪费：部分完成的工作 未应用特性 过度作业 传递  任务切换  等待  缺陷）

交付刚刚好的系统

随时构建质量，不容忍缺陷（缺陷遗留会带来高额成本）

及时消除技术债务，持续保持快速响应（技术债务：日趋不稳定的架构，圈复杂度搞的代码，低的测试自动化率，不及时清楚地静态检查告警等）

（精益七大浪费：缺陷，过度生产，运输，等待，库存，移动，过度作业）

深入理解“激发团队”

认清团队的基本事实

敏捷方式下管理者的转变（控制--->激发）

敏捷方式下团队成员的转变

深入理解“适应变化”

认清“客户是逐步发现真正需求”

小批量是快速交付的关键（缩短交付周期，提高质量，促进创新，降低管理成本，更高的效率等等，答复提高商业价值）

通过迭代计划不断调整以适应需求变化

应保持良好的软件架构（良好软件架构是适应变化的基石，软件架构需要尽早验证和持续维护）

利用多层次反馈不断调整以逼近目标

（对客户需求的反馈，对团队运作的反馈，对系统功能的反馈，对单元功能的反馈，对代码质量的反馈）

（利用多层次反馈手段，在变化的环境中让团队准确的了解与目标的差距，不断调整自身行为，并逐步逼近靶心）

 

敏捷实践

团队：

敏捷团队角色： Product Owner（PO）   Scrum Master   Team

 完整团队实践      

工作件：

产品Backlog（需求清单）

迭代Backlog

完成标准

管理实践

迭代计划会议

每日站立回忆

可视化管理

迭代验收

迭代回顾会议

技术实践

用户故事

结对编程

TDD（测试驱动开发）

持续集成

Anatomy系统解剖

敏捷软件开发是以短周期迭代为核心，包含团队，工作件，管理和技术优秀实践的集合

角色负责

Product Owner（产品负责人）

角色定义：确保Team做正确的事

角色职责：

代表利益相关人（如用户，Marketing，用服，管理者等），对产品投资回报负责

确定产品发布计划

定义产品需求并确定优先级

验收迭代结果，并根据验收结果和需求变化刷新需求清单和优先级

Scrum Master

角色定义：确保Team正确地做事

角色职责：

辅导团队正确应用敏捷实践

引导团队简历并遵守规则

保护团队不受打扰

推动解决团队遇到的障碍

激励团队

Team（开发团队）（5-9人）

角色定义：负责产品需求实现

角色职责：

负责估计工作量并根据自身能力找出最佳方案去完成任务且保证交付质量

向PO和利益相关人演示工作成果（可运行的软件）

团队自我管理，持续改进

完整团队：

敏捷开发中，以Story为单位的持续交付要求系统组，开发和测试等跨功能团队进行密切协同，相互独立的功能软对难以应对。

完整团队是跨功能领域（是需求分析师，设计师，开发人员，测试人员，资料人员等）的人员组成一个团队，做在一起工作，团队成员遵循同一份计划，服从同一个项目经理

完整团队的关键要点：

成员来自多功能领域：团队拥有完成目标所需的各职能人员

坐在一起办公：团队成员无障碍地沟通

团队保持相对稳定：临时组建的团队生产效率较低，团队稳定非常关键

完整团队的好处：

有助于团队成员形成共同目标和全局意识，促进个功能领域的拉通和融合

通过面对面沟通提升沟通效率

实现团队成员的高度协同，支撑高密度地，持续地，短周期的交付

聚焦客户需求交付，提高协作效率

迭代开发

将整个软件生命周期分成多个小的迭代，每一次迭代都由需求分析，设计，实现和测试在内的多个活动组成，每一次迭代都可以生成一个稳定和被验证过的软件版本

迭代式开发的关键要点

每一次迭代都建立在稳定的质量基础上，并作为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善

每次迭代要邀请用户代表（外部或内部）验收，提供需求是否满足的反馈

迭代推荐采用固定的周期（2~4周），迭代内工作不能完成，应当缩减交付范围而不是延长周期

迭代式开发的好处

通过将高技术风险的需求在早期迭代里实现，有助于尽早暴露问题和及时消除风险

通过提供功能渐增的产品，持续从客户获得反馈，根据反馈及时调整，使最终产品更加符合客户的需要

通过小批量减少排队，提供更灵活，快速的交付能力

平滑人力资源的使用，避免出现瓶颈

迭代开发是有节奏的小步快跑，但建立在坚实的质量基础上

产品Backlog

经过优先级排序的动态刷新的产品需求清单，用来指定发布计划和迭代计划

产品Backlog关键要点

清楚表述列表中每个需求任务对用户带来的价值，作为优先级排序的重要参考

动态的需求管理，而非“冻结”方式

迭代的需求分析过程，而非一次性分析清楚所有需求（只对近期迭代要做到需求进行详细分析，其他需求停留在粗粒度）

好处

通过需求的动态管理应对变化，避免浪费

易于有限交付对用户价值高的需求

迭代Backlog

迭代backlog是团队在一轮迭代中的“任务”（Task）清单，是团队的详细迭代开发计划

当团队接收从产品Backlog挑选出要在本轮迭代实现的需求时，召开团队迭代计划会议，将需求转化为具体的“任务”

每项任务信息包括当前剩余工作量和责任人

迭代Backlog关键要点

“任务”由团队成员自己分解和定义，而不是上级指派，支撑需求完成的所有工作都可以列为任务

任务要落实到具体的责任人

任务力度要小，工作量大于两天的任务要进一步分解

用小时作为任务剩余工作量的估计单位，并每日重新估计和刷新

迭代Backlog的好处

讲需求分解成更细小的任务，利于对迭代内进度进行精确控制

剩余工作量可用来跟踪实践团队当前进展

完成标准

基于“随时可以向用户发布”的目标制定衡量团队工作是否已完成的标准，由团队和PO形成共识

关键要点

团队自协商：团队根据项目实际情况来定义完成标准，并严格遵守

有层次：一般分为三个层次：Story级别，迭代级和发布级，每个级别都有各自的完成标准

完成标准的好处

共同协商的完成标准是团队的自我承诺，团队会更认真

用于评估团队工作进展

清晰和明确的完成标准保证了每次迭代是高质量的

迭代计划会议

什么是迭代计划会议

每轮迭代启动前，团队共同讨论本轮迭代详细开发计划的过程，输入是产品Backlog，输出是团队迭代Backlog

多团队迭代计划会议要分层召开

       版本迭代计划会议：将产品Backlog（需求）分配给团队

       团队迭代计划会议：将选取的产品Backlog（需求）转换成迭代Backlog（任务），分配给团队成员

迭代计划会议内容：

       澄清需求，对“完成标准”达成一致

       工作量估计，根据团队能力确定本轮迭代交付内容

       细化，分配迭代任务和初始工作计划

迭代计划会议的好处

通过充分讨论，使团队成员对任务和完成标准理解一致

团队共同参与，促进团队成员更认真对待自己的承诺

迭代计划会议的关键要点

充分参与：Scrum Master要确保PO和Team充分参与讨论，达成李姐一直

相互承诺：Team承诺完成迭代Backlog中的需求并达到“完成标准”，PO承诺在短迭代周期不增加需求（2-4周）

确定内部任务：Team和PO协商把一些内部任务放入迭代中（例如重构，持续集成环境搭建等），由PO考虑并与其他外部需求一起排序

迭代计划会议是由团队共同确定迭代交付内容和完成标准

每日站立会议

每日工作前，团队成员的例行沟通机制，由Scrum Master组织，Team成员全员站立参加

三个主题

我昨天为本项目做了什么？

我计划今天为本项目做什么？

我需要什么帮助以更高效的工作？

关键要点：

准时开始   

高效会议（限时15分钟，保持站立，依次发言，不讨论无关的事情）

问题跟踪（Scrum Master应该记录下所有的问题并跟踪解决）

好处

增加团队凝聚力

及时暴露风险和问题

促进团队内成员的沟通和协调

 

可视化管理

将项目状态（进度，质量等）通过物理试题（如白板，大屏幕）实时展示，让团队所有成员直观地获取当前项目进展信息

要点

物理实体（白板/大屏幕，在公开场所能看到）（电脑文件不是可视化的）

内容精简 易懂

实时刷新

可视化管理的好处

简单，一目了然，降低管理成本

实时状态显示，及时暴露问题

信息同源使得团队理解一致，提升团队凝聚力

激励先进，鞭策后进，增强团队凝聚力

 

迭代验收

每次迭代开发结束时举行，通过演示可工作的软件，检查需求是否满足客户要求

由Scrum Master组织，PO和用户代表（外部或内部利益相关人）负责验收，Team负责演示可工作软件

迭代验收的关键要点

展示“真实”的产品：Team应在真实环境中展示可运行的软件，判断是否达到“完成”标准

搜集反馈：PO根据验收情况及客户反馈意见，及时调整产品Backlog

迭代验收的好处

通过演示可工作的软件来确认项目的进度，具有真实性

能尽早的获得用户对产品的反馈，使产品更加贴近客户需求

尽早演示可工作的软件，收集反馈意见

 

迭代回顾会议

在每轮迭代结束后举行的会议，目的是分享好的经验和发现改进点，促进团队不断进步

围绕三个问题

本次迭代有哪些做得好

每次迭代在哪些方面还能做的更好

下次迭代准备在哪些方面改进

关键要点

会议气氛：Team全员参加，气氛狂送自由，畅所欲言，头脑风暴，共同分析

关注重点：Team共同讨论优先级，将精力放在最需要的地方

会议结论要跟踪闭环：可以放在迭代backlog中

好处：

激励团队成员

帮助团队挖掘优秀经验并继承

避免团队犯重复的错误

赢在团队自主改进的氛围

迭代回顾会议是促进团队持续改进的最有效手段

 

用户故事

用户故事是站在用户角度描述需求的一种方式

每个用户故事须有对应的验收测试用例

用户故事是分层分级的，在使用过程中逐步分解细化

典型的描述句式为：作为一个XXX客户角色，我需要XXX功能，带来XXX好处

关键要点

I --可独立交付给用户

N -- 便于与客户交流

V -- 对客户有价值

E -- 能估计出工作量

S -- 分解到最底层的用户故事力度尽量小，至少在一个迭代中能完成

T -- 可测试

好处

用户故事是站在用户视角便于与客户交流，准确描述客户需求

用户故事可独立交付单元，规模小，适于迭代开发以获得用户快速反馈

用户故事强调编写验收测试用例作为验收标准，能促使需求分析人员准确把握需求，牵引开发人员避免过度设计

 

结对编程

两个程序员在一台电脑前工作，一个负责敲代码，一个实时检视每一行敲入的代码。

“驾驶员”“领航员”

领航员检视的同时还要负责考虑下一步的工作方向

关键要点：

角色经常互换

开始一个新的Story开发的时候可以变换搭档

培养团队成员积极，主动，开放，写作的心态能够增进结对编程效果

实施初期需要精心辅导

好处

有助于提升代码设计质量

总体效率更高（编程慢了，但是缺陷少了）

结对编程能够大幅促进团队能力提升和知识传播

结对编程提高代码质量和工作效率

 

测试驱动开发TDD

以测试作为编程的中心，他要求在编写任何代码之前，首先编写定义代码功能的测试用例，编写的代码要通过用例，并不断进行重构优化

关键要点

测试代码和源代码一样都需要简洁，可读性好

测试用例的设计要保证完备，覆盖被测试单元的所有功能

每个测试用例尽量保持独立，减少依赖，提高用例的可维护性

当功能单元较大时，为降低难度，可分解为多个更小的功能单元，并逐一用TDD实现

好处

和代码同步增长的自动化测试用例，能为代码构筑安全网，保证代码重构的质量，有助于开发人员优化代码设计，提高代码的可测试性

测试驱动开发保证代码整洁可用

 

持续集成（CI）

一项软件的开发时间，团队的成员经常集成他们的工作，通常每人每天至少集成一次，每次集成通过自动化构建完成

持续集成的好处

大幅缩短反馈周期，试试反应产品真实质量状态

缺陷在引入的当天就被发现了并解决，降低缺陷修改成本

将集成工作分散在平时，通过每天生成可部署的软件避免产品最终集成时爆发大量问题

关键要点

持续集成强调“快速”和“反馈”，要求完成一次系统集成的时间尽量短，并提供完备且有效的反馈信息

自动化测试用例的完备性和有效性是持续集成质量保障

修复失败的构建是团队最高优先级的任务

开发人员必须现在本地构建成功，才可提交代码到配置库

持续集成的状态必须实施可视化显示给所有人

大系统持续集成需分级分层，建立各层次统一的测试策略

持续集成提供产品质量的快速反馈，保证随时拥有可工作的软件

 

Anatomy系统解剖

从用户视角全面展示复杂产品系统的功能依赖关系，让整个系统的功能自底向上逐步有序的开发和集成

关键要点：

Anatomy不是系统架构视图，图中的Block是表示系统给用户使用的一个功能，是站在纯用户视角的，不包含设计信息

Anatomy中的依赖关系是用户使用系统功能的依赖关系，而不是设计或架构上的依赖关系

Anatomy是系统全视图，由最了解系统的工程师绘制出基线，在增量开发时需要不断刷新

好处

Anatomy是迭代计划制定的重要依据，保证系统按照类似生物自然生长的顺序自底向上有序的开发和集成

可作为可视化工具，通过表示图中每一个功能的状态，使系统整体进展一目了然，极大增强团队的信心

有助于团队从增量交付向交付全系统的四位转变

是很好的培训教材，帮助工程师了解全系统

Anatomy帮助团队理解系统全局，只能合理的迭代计划