• 一文搞懂敏捷开发


    本文为博主原创,未经允许不得转载:

      本篇目录结构如下:

                                          

    1.什么是敏捷

      敏捷是一种思维模式,敏捷是指能够让团队思考更加有效,工作更为高效,并且做出更好决策的一组方法和相关理念

    2.敏捷宣言的四大价值观

      四大价值观意在通过亲自开发和帮助他人开发,发现开发软件的更好方法

        1.个体以及互动   而不是  过程和工具

        2.可用的软件       而不是   完整的文档

        3.客户合作          而不是合同谈判

        4.应对变更          而不是遵循计划

      右侧的项目固然有价值,但敏捷更重视左栏中的项目。《敏捷宣言》的价值观和原则的一个核心宗旨是强调个人和交互的重要性。敏捷优化了价值流, 强调了向客户快速交付功能,而不是怎样“用”人。

      

    3.敏捷宣言的十二大原则

      1.我们的最高目标是,通过今早的持续交付有价值的软件来满足客户的需求

      2.欢迎对需求提出变更,即使在项目开发后期也不例外,敏捷过程要善于利用需求变更,帮助客户获得竞争优势

      3.要经常交付可用的软件,周期从几周到几个月不等,且越短越好

      4.项目实施过程中,业务人员与开发人员必须始终通力协作

      5.要善于激励项目人员,给予他们所需的环境和支持,并相信他们能够完成任务

      6.无论是对开发团队还是团队内部,信息传达最有效的方法都是面对面的交谈

      7.可用的软件是衡量进度的首要衡量标准

      8.敏捷过程提倡可持续的开发。项目发起人,开发人员和用户应该能够始终保持步调稳定

      9.对技术的精益求精以及对设计的不断完善将提高敏捷性

      10.简洁,即尽最大可能减少不必要的工作,这是一门艺术

      11.最佳的架构,需求和设计将出自于自组织团队

      12.团队要定期反省怎样做才能更有效,并相应的调整团队的行为。

    4. 敏捷解带来的好处

      1.敏捷项目可以按时完成,为那些苦恼于交付期限和预算的团队带去了福音

      2.敏捷项目交付高质量的软件,那些受困于bug和低效软件的团队会迎来巨大的变革

      3.敏捷团队构建的代码结构优良且易于维护,那些常常维护负责又混乱的代码的团队会得到解脱

      4.敏捷团队会让用户满意,不再交付无法为用户带来价值的软件

      5.最重要的是,在出色的敏捷团队中,开发人员不用加班,可以与亲朋好友共度晚间时光和周末

    5.敏捷项目的生命周期类型

      1.预测型生命周期:这是一种更为传统的方法,提前进行大量的计划工作,然后一次性执行;执行是一个连续的过程

      2.迭代型生命周期:这种方法允许对未完成的工作进行反馈,从而改进和修改该工作

      3.增量型生命周期:这种方法向客户提供各个已完成的,可能立即使用的可交付成果

      4.敏捷生命周期:这种方法既有迭代,也有增量,便于完善工作,频繁交付,其特点是它同时利用迭代属性和增量特征。团队使用敏捷方法时,他们会对产品进行 迭代,创建完成的可交付成果。团队将获得早期的反馈,并能提供客户可见性、信心和对产 品的控制。由于团队可以提前发布产品,而团队将率先交付价值最高的工作,所以项目可以 更早产生投资回报。

      

    6.项目经理应用仆人式领导

      从事敏捷项目工作时,项目经理的角色会从团队的中心转变成为团队和管理人员提供服务。在 敏捷环境中,项目经理充当仆人式领导,其工作重点转变为引导需要帮助的人,促进团队的合作, 保持与相关方的需要一致。作为仆人式领导,项目经理要鼓励将责任分配给团队成员,分配给那些 掌握完成任务所需知识的人。

      仆人式领导的特征:

       1.提升自我意识; 2. 倾听; 3. 为团队服务; 4. 帮助他人成长; 5. 引导与控制; 6. 促进安全、尊重与信任;7. 促进他人精力和才智提升。8.消除组织障碍

      项目经理要善于激励项目人员,为他们提供所需的环境和支持,信任他们能够完成工作。

    7.项目章程

      具备的特点:

        1.我们为什么要做这个项目?这是项目愿景。

        2.谁会从中受益?如何受益?这可能是项目愿景和/或项目目标的一部分。

        3. 对此项目而言,达到哪些条件才意味着项目完成?这些是项目的发布标准。

        4. 我们将怎样合作?这说明预期的工作流。

      制定项目章程是一 种很好的开始工作的的方式。此外,团队成员可能希望通过协作了解他们将如何一起工作。

    8.团队章程

      1. 团队价值观,例如可持续的开发速度和核心工作时间;

      2. 工作协议,例如“就绪”如何定义,这是团队可以接受工作的前提;“完成”如何定义,这样 团队才能一致地判断完整性;考虑时间盒;或使用工作过程限制;

      3. 基本规则,例如有关一个人在会议上发言的规定;

      4. 团队规范,例如团队如何对待会议时间。

    9.常见敏捷实践

       9.1 回顾

      回顾是最重要的一个实践,原因是它能让团队学习、改进和调整其过程。

      回顾可以帮助团队从之前的产品开发工作及其过程中学习。《敏捷宣言》背后的原则之一是:“团队 要定期反省如何能够做到更加有效,并相应地调整团队的行为。

      团队可以通过分配足够的时间学习受益,无论是在项目中间回顾,还是在项目结束时回顾。团队 需要了解他们的工作产品和工作过程。例如,有些团队在完成工作时遇到困难。团队可以计划用充 足的时间组织回顾,以此收集数据、处理数据、再决定之后要尝试的实验做法。

         首要的是,回顾并不是责备;回顾是让团队从以前的工作中学习并做出小的改进。

       回顾针对定性的(人的感觉)和定量的(衡量指标)数据,然后利用这些数据找到根源,设计 对策,并制定行动计划。项目团队可以采取许多行动事项来消除障碍。

       9.2 待办事项列表编制

      待办事项列表是所有工作的有序列表,它以故事形式呈现给团队。工作开始之前,不需要为整个 项目创建所有的故事,只需要了解第一个发布的主要内容正确即可,然后就可以为下一个迭代开发 足够的项目。

      产品负责人(或产品负责人价值团队,包括产品经理和产品领域的所有相关产品负责人)可能 会制作一个产品路线图,以显示预期的可交付成果序列。产品负责人根据团队的实际成果重新规 划路线图。(关于路线图的示例请参见附件 X3“敏捷适用性筛选工具”。)

      9.3 待办事项列表的细化

      在基于迭代的敏捷中,产品负责人往往在迭代中期的一次或多次会议中与团队合作,为即将进行 的迭代准备一些故事。这些会议的目的是细化足够的故事,让团队了解故事的内容,以及故事之间 的相互关系。

      9.4 每日站会

      团队成员利用每日站会对彼此做出小的承诺,发现问题,并确保团队工作顺利进行。 为每日站会规定时间盒,不超出 15 分钟。团队以某种方式“过一下”看板或任务板,而团队中的 任何人都可以主持站会。

      在基于迭代的敏捷中,每个人都轮流回答下列三个问题:   

        a. 上次站会以来我都完成了什么? b. 从现在到下一次站会,我计划完成什么? c. 我的障碍(或风险或问题)是什么?

       9.5 展示/评审

      一般的指导方针是,每两周至少展示一次团队的工作产品。这种频率对于大多数团队来说是足够 的,这样,团队成员就可以得到反馈,防止他们朝着错误的方向前进。这种频率也足够频繁,让团 队可以保持产品开发足够清晰,按照自己希望或需要的频率构建一个完整的产品。

      9.6 规划基于迭代的敏捷

      敏捷团队在一个工作块中不会只计划一次。相反,敏捷团队会开始计划一点,交付、学习,然后 在一个持续的循环中重新规划更多的东西。

      9.7 帮助团队交付价值的执行实践

        以下帮助团队以最快的速度交付:

        1.持续集成。无论产品如何,都要频繁地将工作集成到整体中,然后再进行重新测试,以确定整 个产品仍然按照预期工作。 

        2. 在不同层面测试。对端到端信息使用系统级测试,对构建块使用单元测试。在两者之间,了解是 否需要进行集成测试,以及在何处进行测试。团队发现冒烟测试有助于测试工作产品是否良好。 团队发现,决定何时以及对哪些产品运行回归测试,可以帮助他们在维护产品质量的同时,良好 地构建性能。敏捷团队非常偏爱自动化测试,因此他们可以借此构建和保持交付的势头。 

        3. 验收测试驱动开发 (ATDD)。在 ATDD 中,整个团队聚集一堂讨论工作产品的验收标准。然后, 团队创建测试,这让团队能够编写足够的代码,进行自动化测试,满足标准要求。对于非软件 项目,要考虑怎样在团队完成大量价值时对工作进行测试。

        4. 测试驱动开发 (TDD) 和行为驱动开发 (BDD)。在编写/创建产品之前编写自动化测试,实际上可 以帮助人员设计产品,防范产品错误。对于非软件项目,要考虑如何通过“测试驱动”团队 的设计。硬件和机械类项目经常使用模拟进行设计的中间测试。

        5. 刺探(时间盒研究或实验)。刺探对学习很有用,可以在诸如评估、验收标准定义以及通过产品 了解用户行为的流程中使用。在团队需要学习一些关键技术或功能要素时,刺探会很有帮助。

     10. SCRUM 迭代式增量软件开发过程

      Scrum 是用于管理产品开发的单个团队过程框架。该框架包含 Scrum 角色、事件、工件和规则,采 用迭代方法来交付工作产品。Scrum 是运行在 1 个月或更少时间的时间盒上的,其中包含持续时间 一致的多个冲刺,在这些冲刺中会产生潜在可发布的产品增量。表 A3-1 列出了项目执行中所利用的 Scrum 事件和工件。

      Scrum 团队包含产品负责人、开发团队和 Scrum 主管

      产品负责人负责实现产品价值的最大化。   

       开发团队是一个跨职能自组织团队,其开发成员拥有所需的一切资源,可在不依赖团队外部其 他资源的情况下交付工作产品。

       Scrum 主管负责确保 Scrum 过程获得相应支持且 Scrum 团队遵从实践和规则,并指导团队消除 障碍。 

                                        

    11.极限编程

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

       XP 最受关注的地方在于推广旨在改进软件项目成果的整套实践。该方法最初包含十二种主要实践, 随后逐渐演变,采用了一些其他推论实践。

                                                       

       该演变是通过筛选核心价值观(沟通、简洁、反馈、勇气、尊重)并根据主要原则(人性化、经 济、互惠互利、自相似、改进、多样性、反思、流程、机会、冗余、失败、质量、循序渐进、承担 的责任)信息来设计和采用技术的结果。

    12. 敏捷的其他关键词

      生命周期/阶段:愿景-----------产品路线图-----------发布计划-----------迭代

      SM/PM角色:服务型/仆人式领导,维护敏捷方法/流程/团队

      整合:敏捷方法框架(IPECC)

      变更:加到产品待办事项列表 Backlog

      需求/范围/功能:产品待办项,用户故事,MoSCoW等优先级排序

      进度:故事点估算,迭代燃尽图,产品燃起图

      成本:S曲线

      质量/bug/漏洞:DoD。验收时又重大缺陷-----持续集成来避免

      资源/团队:自组织团队,虚拟团队(太阳原则,鱼缸窗口)

      沟通:信息发射源,四个会议/仪式

      干系人:审查会/演示会

      风险:信息发射源,风险燃尽图

     13.敏捷转型步骤

      可分为以下步骤:

        1.制定实施策略

        2.建立转型团队

        3.构建仪式和培养热情

        4.确定一个试点项目

        5.确定成功的度量标准

        6.充分培训

        7.制定产品策略

        8.制定产品路线图,产品待办列表和估算

        9.运行你的第一个冲刺

        10.犯错,收集反馈,加以改进

        11.成熟

        12.推广

       如果对你有帮助,希望走过路过的,高抬贵手点个赞          

  • 相关阅读:
    条形码分类
    ubuntu下配置j2ee开发环境——sunjdk1.6的安装
    折腾的这几天
    Windows Phone 8 开发环境搭建
    Windows Phone SDK 8.0的安装软硬件配置要求
    ubuntu连接无线网遇到的错误和解决思路总结(无具体过程)
    解析html标签并转化成图片
    javaIO的类备忘
    ubuntu下配置j2ee开发环境——sunjdk1.7的配置
    Jmeter之JDBC Request及参数化
  • 原文地址:https://www.cnblogs.com/zjdxr-up/p/15473553.html
Copyright © 2020-2023  润新知