敏捷软件开发(Agile )介绍

敏捷软件开发介绍Davin2009年06月N.001目录•敏捷理念•敏捷优秀实践•敏捷应用建议2020/2/11Page3软件作坊软件过程控制重型过程2001~今敏捷正在流行软件规模小，以作坊式开发为主；硬件飞速发展，软件规模和复杂度激增，引发软件危机；引入成熟生产制造管理方法，以“过程为中心”分阶段来控制软件开发（瀑布模型），一定程度上缓解了软件危机；软件失败的经验促使过程被不断增加约束和限制，软件开发过程日益“重型化”，开发效率降低、响应速度变慢；随着信息时代到来，需求变化更快，交付周期成为企业核心竞争力，轻量级的，更能适应变化的敏捷软件开发方法被普遍认可并迅速流行。软件危机20世纪60年代80年代90年代软件开发顺应时代变化，从重型过程转向轻量型敏捷70年代敏捷诞生的历史背景Page4•Hw敏捷的发展：•2006年之前：IPD（集成产品开发）•2006~2008年：从咨询公司ThoughtWorks引入敏捷软件开发，开展软件项目试点•2008后：产品试点，全部软件项目使用，硬件项目使用优秀实践•腾讯敏捷的发展：•2006年之前：IPD（集成产品开发）•2006年之后：从咨询公司ThoughtWorks引入敏捷软件开发，正式命名为TAPD（TencentAgileProductDevelopment）HW敏捷和腾讯敏捷的发展Page5敏捷宣言揭示更好的软件开发方法敏捷宣言（2001年）是敏捷起源的基础，由上述4个简单的价值观组成，敏捷宣言的签署推动了敏捷运动敏捷宣言本质是揭示一种更好的软件开发方式，启迪人们重新思考软件开发中的价值和如何更好的工作敏捷宣言Page6•软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长•敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品传统开发敏捷开发敏捷更符合软件开发规律Page7对敏捷的常见误解误解一：敏捷开发意味着可以不需要文档、设计和计划误解二：敏捷只是一些优秀实践，或者是优秀实践的结合误解三：敏捷只适用于小项目开发误解四：敏捷只会对研发产生改变误解五：管理者不需要亲自了解敏捷，只需要管理上支持就可以了误解六：引入敏捷只需要按照既定的步骤去做就可以了误解七：敏捷是CMM的替代品，是另一种流程误解八：敏捷只注重特性的快速交付，在敏捷下架构不重要了Page8统一认识：敏捷=理念+优秀实践+具体应用理念（敏捷核心思想）敏捷包括3个层次优秀实践（敏捷的经验积累）具体应用（能够结合自身灵活应用才是真正敏捷）理念优秀实践具体应用Page9敏捷理念不断调整以适应(Adapting)变化激发团队(Team)潜能，加强协作聚焦客户价值(Value)，消除浪费Page10优秀实践:业界敏捷优秀实践概览结对编程测试驱动开发客户参与验收计划游戏代码集体所有每日站立会议产品backlog（带优先级的需求清单）燃烧图迭代计划会议回顾会议ScrumMasterProductOwnerAnatomy（系统解剖）OneTrackSystemakut（缺陷管理和决策）重构完整团队稳定开发节奏Lagomising（需求决策）隐喻电信业偏重大规模产品实践、Scrum偏重项目管理，XP偏重编程实践电信业ScrumXP持续集成迭代交付敏捷软件开发典型场景Page11①PO和开发团队对产品业务目标形成共识②PO建立和维护产品需求列表（需求会不断新增和改变）,并进行优先级排序③PO每轮迭代前，Review需求列表，并筛选高优先级需求进入本轮迭代开发④开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成⑤开发团队每日站立会议、特性开发、持续集成，使开发进度真正透明⑥PO对每轮迭代（2－4周）交付的可工作软件进行现场验收和反馈⑦回到第3步，开始下一轮迭代迭代每日工作交付可以工作的软件迭代计划回顾确定一个迭代的工作内容产品和利益相关人①②③、⑦④⑤⑥Page12什么是完整团队敏捷开发中，以Story为单位的持续交付要求系统组、开发和测试等跨功能团队进行密切协同，相互独立的功能团队难以应对。完整团队是跨功能领域（需求分析师、设计师、开发人员、测试人员、资料人员等）的人员组成一个团队，坐在一起工作，团队成员遵循同一份计划，服从于同一个项目经理。完整团队的好处有助于团队成员形成共同目标和全局意识，促进各功能领域的拉通和融合；通过面对面沟通提升沟通效率。实现团队成员的高度协同，支撑高密度地、持续地、短周期的交付。完整团队的关键要点成员来自多功能领域：团队拥有完成目标所需的各职能成员；坐在一起办公：团队成员无障碍地沟通；团队保持相对稳定：临时组建的团队生产效率较低，团队稳定非常关键。完整团队聚焦客户需求交付，提高协作效率敏捷团队实践：完整团队Page13产品Backlog关键要点清楚表述列表中每个需求任务对用户带来的价值，做为优先级排序的重要参考；动态的需求管理而非“冻结”方式，PO持续地管理和及时刷新需求清单，在每轮迭代前，都要重新筛选出高优先级需求进入本轮迭代；迭代的需求分析过程，而非一次性分析清楚所有需求（只对近期迭代要做的需求进行详细分析，其它需求停留在粗粒度）。敏捷工作件：产品Backlog什么是产品Backlog经过优先级排序的动态刷新的产品需求清单，用来制定发布计划和迭代计划。产品Backlog的好处通过需求的动态管理应对变化，避免浪费；易于优先交付对用户价值高的需求。产品Backlog是需求动态管理的载体Page14什么是迭代Backlog迭代Backlog是团队在一轮迭代中的“任务”（Task）清单，是团队的详细迭代开发计划；当团队接收从产品Backlog挑选出要在本轮迭代实现的需求时，召开团队迭代计划会议，将需求转化为具体的“任务”；每项任务信息包括当前剩余工作量和责任人。敏捷工作件：迭代Backlog迭代Backlog的好处将需求分解成更细小的任务，利于对迭代内进度进行精确控制；剩余工作量可用来实时跟踪团队当前进展。迭代Backlog关键要点“任务”由团队成员自己分解和定义，而不是上级指派，支撑需求完成的所有工作都可以列为任务；任务要落实到具体的责任人；任务粒度要小，工作量大于两天的任务要进一步分解；用小时做为任务剩余工作量的估计单位，并每日重估计和刷新。迭代Backlog提供精细的迭代开发计划任务责任人状态剩余工时日期Page15敏捷工作件：完成标准（DefinitionofDone）什么是完成标准基于“随时可向用户发布”的目标制定衡量团队工作是否已完成的标准，由团队和PO形成共识；完成标准的好处共同协商的完成标准是团队的自我承诺，团队会更认真；用于准确评估团队工作进展；清晰和明确的完成标准保证了每次迭代是高质量的。完成标准的关键要点团队自协商：团队根据项目实际情况来定义完成标准，并严格遵守；有层次：一般分为三个层次：Story级别，迭代级和发布级，每个级别都有各自的完成标准。Story完成标准样例迭代完成标准样例发布完成标准样例代码合入主干代码符合规范代码100%检视通过验收测试通过迭代验收系统测试用例100%通过通过性能测试所有Story完成通过回归测试所有缺陷解决更新配套资料完成标准的样例代码100%通过单元测试持续集成无错误完成标准确保团队每一步前进都奠定在坚实的质量基础之上Page16敏捷管理实践：迭代计划会议什么是迭代计划会议每轮迭代启动前，团队共同讨论本轮迭代详细开发计划的过程，输入是产品Backlog，输出是团队迭代Backlog；多团队迭代计划会议要分层召开版本迭代计划会议：将产品Backlog（需求）分配给团队；团队迭代计划会议：将选取的产品Backlog需求转换成迭代Backlog（任务），分配给团队成员；迭代计划会议内容：澄清需求、对“完成标准”达成一致工作量估计、根据团队能力确定本轮迭代交付内容；细化、分配迭代任务和初始工作计划。迭代计划会议的好处通过充分讨论，使团队成员对任务和完成标准理解一致；团队共同参与，促进团队成员更认真对待自己的承偌。迭代计划会议的关键要点充分参与：ScrumMaster确保PO和Team充分参与讨论，达成理解一致；相互承诺：Team承诺完成迭代Backlog中的需求并达到”完成标准“，PO承诺在短迭代周期不增加需求（2-4周）；确定内部任务：Team和PO协商把一些内部任务放入迭代中（例如重构、持续集成环境搭建等），由PO考虑并与其他外部需求一起排序。迭代计划会议由团队共同确定迭代交付内容和完成标准Page17敏捷管理实践：每日站立会议什么是每日站立会议每日工作前，团队成员的例行沟通机制，由ScrumMaster组织，Team成员全体站立参加聚焦在下面的三个主题：我昨天为本项目做了什么？我计划今天为本项目做什么？我需要什么帮助以更高效的工作？每日站立会议的关键要点准时开始：按计划会议制定的时间地点开会，形成团队成员的自然习惯；高效会议：会议限时15分钟，每个人都保持站立，依次发言，不讨论与会议三个主题无关的事情（如技术解决方案等）；问题跟踪：ScrumMaster应该记录下所有的问题并跟踪解决；每日站立会议的好处增加团队凝聚力，产生积极的工作氛围及时暴露风险和问题；促进团队内成员的沟通和协调。每日站立会议促进团队沟通协调，及时暴露问题Page18敏捷管理实践：可视化管理可视化管理的好处简单，一目了然，降低管理成本；实时状态显示，及时暴露问题；信息同源使团队理解一致，提升团队凝聚力；激励先进，鞭策后进，增强团队进取心。什么是可视化管理将项目状态(进度、质量等)通过物理实体（如白板，大屏幕）实时展示，让团队所有成员直观地获取当前项目进展信息。可视化管理的关键要点物理实体：可视化一定要做到物理上的实体化，大家在公开场所都容易看到，触摸到，（存在电脑中的文件不是可视化的）；内容精简，易懂：信息展示一目了然，切实对团队有帮助，切忌贪多求全，难以分辨；实时刷新：延迟的信息拖延问题暴露，降低运作效率。可视化管理及时暴露问题，激励团队Story墙（展示Story进度）缺陷走势图（展示缺陷解决进展）Anatomy视图（展示系统集成进展）Page19敏捷管理实践：迭代验收什么是迭代验收每次迭代开发结束时举行，通过演示可工作的软件检查需求是否满足客户要求；由ScrumMaster组织，PO和用户代表（外部或内部利益相关人）负责验收、Team负责演示可工作软件。迭代验收的好处通过演示可工作的软件来确认项目的进度，具有真实性；能尽早的获得用户对产品的反馈，使产品更加贴近客户需求。迭代验收的关键要点展示“真实”的产品：Team应在真实环境中展示可运行的软件，判断是否达到“完成”标准；收集反馈：PO根据验收情况及客户反馈意见，及时调整产品Backlog。迭代验收尽早演示可工作的软件，收集反馈意见Page20敏捷管理实践：迭代回顾会议迭代回顾会议的好处激励团队成员；帮助团队挖掘优秀经验并继承；避免团队犯重复的错误；营造团队自主改进的氛围。什么是迭代回顾会议在每轮迭代结束后举行的会议，目的是分享好的经验和发现改进点，促进团队不断进步；围绕如下三个问题：本次迭代有哪些做得好本次迭代我们在哪些方面还能做得更好我们在下次迭代准备在哪些方面改进？迭代回顾会议的关键要点会议气氛：Team全员参加，气氛宽松自由，畅所欲言，头脑风暴发现问题，共同分析根因；关注重点：Team共同讨论优先级，将精力放在最需要的地方（关注几个改进就够了）；会议结论要跟踪闭环：可以放入迭代backlog中。迭代回顾会议是促进团队持续改进的最有效手段好的能做得更好的将来改进的Page21敏捷工程实践：用户故事（userstory）什么是用户故事用户故事是站在用户角度描述需求的一种方式；每个用户故事须有对应的验收测试用例；用户故事是分层分级的，在使用过程中逐步分解细化；典型的描述句式为：作