21天敏捷打卡--敏捷方法实现

Posted atun

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了21天敏捷打卡--敏捷方法实现相关的知识,希望对你有一定的参考价值。

常用的敏捷实践包含:精益、看板、Scrum、XP极限编程、水晶、DSDM动态系统开发、FDD功能驱动开发、AUP敏捷统一过程、OpenUP。

《敏捷实践指南》将敏捷方法和看板方法是为精益方法的子集。因为他们都符合精益思想的具体实例,都反映了“关注价值”、“小批量”、“消除浪费”。

技术图片

  • 精益软件开发LSD
TPS
面对场景 解说 原则 解说
过度 对员工和生产/研发过程施加不必要的额外压力 消除浪费 无法带来价值的事务就是浪费
违规 不切实际的需求导致过生产/研发程中的不均匀 尽快交付 短期迭代或小批量提供有价值的反馈,促进有效的决策
浪费 非增值活动或过程 增强学习 通过短迭代周期、重构、继承测试和频繁客户反馈会议增强学习
    团队授权 精益专注于团队,因为决策制定和管理的来源让团队了解最佳选择和成本。
    较迟决定

管理不确定性的最佳方法是收集信息,最后的责任时刻给予承诺,打破部件 

间的依赖关系。 

    建立整体 确保质量是嵌入在整个系统的,系统需要构建自动化测试,安装和持续集成。 
    目光长远 脚踏实地,快速试错,快速学习。
  • Scrum 参见我的另一篇文章,ACP--Scrum
  • 极限编程

技术图片

极限编程 (XP)是一种基于频繁交付周期的软件开发方法。该名称基于这样一个理念:将特定最佳实践提炼到最纯粹和最简单的形式,然后在整个项目周期内持续运用该实践。

核心思想:鼓励从最简单的解决方式入手再通过不断重构达到更好的结果,主张“不对将来可能的需求上投入精力”,这么做的好处,设计与代码上的简化可以提高交流的质量。

价值:沟通、简单、反馈、勇气、尊重

  1. 沟通:追求有效的沟通而非无意义的会议。强调项目组成员、客户之间有效地、及时沟通,打破信息孤岛,确保信息的畅通。
  2. 简单/简洁:实现最贱的可行方案。应该尽快保持代码的简单,只要能满足工作需要即可,有利于代码的重构和优化,确保频发的发布功能。
  3. 反馈:通过对当前系统状态进行不断的反馈,达到迅速沟通、编码、测试、发布的目的。
  4. 勇气:勇于放弃和重构,这点太难了。
  5. 尊重:尊重每一位成员,从人性的角度为项目组成员考虑,确保项目的质量和交期。

敏捷编程的开发过程核心活动:“需求→测试→编码→设计过程中,因此对工作环境、需求分析、设计、编程、测试、发布等提出了新的思路、要求和挑战。

敏捷编程开发过程核心活动
动作 解说
工作环境

项目开发人员都需担任角色,并履行相应的权力和义务

开放式的工作环境,方便面对面交流

强调每周工作40小时,不加班

需求分析

开发人员和客户一起编写Story,并根据经验经将user stroy组合或分解,最终记录在stroy card;

根据记录的stroy card,按照商业价值、开发风险有限顺序逐个开发

设计 强调简单设计,即用最简单的方法实现每个小需求,满足系统客户在当前的需求即可
编程 提倡结对编程,共同完成一段程序的编码,可以提高纪律性等等
测试 开始编程之前,先写好测试,提高软件的可测试性。通用方法:单元测试、整合测试、功能测试、系统测试
发布 按照开发计划/时间盒,没完成一个时间盒,发布一次。通过敏捷的迭代和增量交付实现客户利益最大化
  •  看板方法

技术图片

  • 水晶方法

  水晶是一种方法论家族。水晶方法论旨在根据项目规模(项目中涉及的人员数量)以及项目的关键性来量化并提供方法严格程度选择。

 技术图片

  • FDD(特征驱动开发)

技术图片

  特征驱动开发(FDD-Feature Driven Development)方法是敏捷软件开发过程中的一种,是由Jeff de Luca 、Eric Lefebvre、Peter Coad共同开发的。它强调特性驱动,快速迭代,即能保证快速开发,又能保证适当文档和质量,非常适合中小型团队开发管理。

它提出的每个功能开发时间不超过两周,为每个用例user case限定了粒度,具有良好可执行性,也可以对项目的开发进程进行精确及时地监控。它抓住了软件开发的核心问题领域,即正确和及时地构造软件。FDD还打破了传统的将领域和业务专家/分析师与设计者和实现者隔离开来的壁垒。分析师被从抽象的工作中解脱出来,直接参与到开发人员和用户所从事的系统构造工作中。

  角色:项目经理、开发经理、首席编程人员、类负责人、领域专家,由团队成员分别担任。

  FDD最佳实践

    • 持续集成Continuous Integration.
 
    • 对领域(业务)对象建模Domain Object Modeling.
 
    • 按特性开发Developing By Feature.
 
    • 类的所有者Individual Class ownership.
 
    • 按特性组织团队Feature Teams.
 
    • 源代码控制Source Control.
 
    • 汇报/结果可见性Reporting/Visibility of results

 

  • DSDM动态系统开发方法

技术图片

  一种敏捷项目交付框架,强调制约因素驱动交付而著称。DSDM的基本观点是:任何事情都不可能一次性圆满完成,应该用20%的时间完成80%的有用功能,以适合商业目的为准。

  DSDM的基本原则:

  1.活动用户必须参与。

  2.必须授权DSDM团队进行决策。

  3.注重频繁交付产品。

  4.判断产品是否可接受的一个基本标准是符合业务目的。

  5.对准确的业务解决方案需要采用循环和增量开发。

  6.开发期间的所有更改都是可逆的。

  7.基本要求是高层次的并区分优先级(以在低优先级的项目上获得一定的灵活性)。

  8.在整个生命周期集成测试。

  9.在所有参与者之间采用协作和合作方法。

  • AUP敏捷统一过程

技术图片

  捷统一过程 (AgileUP)是软件项目中统一过程 (UP)的分支。与紧前统一过程相比,该过程具有加速周期和轻量级的过程。其目的在于在七个主要因素之间执行更多迭代的周期,并在正式交付之前纳入相关反馈。

  该方法应用了敏捷技术,包括 测试驱动开发(TDD), 敏捷模型驱动开发(AMDD), 敏捷变更管理和 数据库重构,以提高生产率。

  AUP的哲学
  敏捷UP基于以下原则:
    1.员工知道他们在做什么。人们不会阅读详细的过程文档,但会不时需要一些高级指导和/或培训。
    2.简单性。使用很少的页面(而不是数千个页面)来简洁地描述所有内容。
    3.敏捷性。敏捷UP遵循敏捷联盟的价值观和原则 。
    4.专注于高价值的活动。重点是实际计数的活动,而不是项目上可能发生的所有可能事情。
    5.工具独立性。

  • OpenUP

 四项核心原则:

  1. 平衡,在竞争优先级以及最大化干系人利益之间,建立平衡 。
  2. 协作,协作以协调利益,以及保证理解一致。
  3. 关注,从开始起,就将注意力放在软件架构上,以减轻风险,并组织软件开发。
  4. 演化,持续演进并且不断获得反馈。

 生命周期:OpenUP的迭代开发流程分布并且贯穿在几个阶段中:启始(Inception)、精化(Elaboration)、构建(Construction)和移交(Transition)阶段。

  1. 启始阶段: 确保项目目标和范围已经明确。
  2. 精化阶段:开发整体架构框架,确保架构已经稳定。
  3. 构建阶段:从摸索到可部署产品的开发,转向功能模块的开发。 
  4. 移交阶段:确保软件被最终用户接受。

以上是关于21天敏捷打卡--敏捷方法实现的主要内容,如果未能解决你的问题,请参考以下文章

21天敏捷打卡-敏捷估计与规划

敏捷21天打卡-敏捷项目管理(终章)

21天敏捷打卡-用户故事地图

敏捷21天打卡-AARRR模型

21天敏捷打卡-看板

敏捷21天打卡--Scrum角色