敏捷项目管理
1、敏捷定义
敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。
敏捷开发遵循软件客观规律,不断的进行迭代增量开发,最终交付符合客户价值的产品。
2、敏捷宣言
敏捷宣言,全称是敏捷软件开发宣言,是2001年由17名软件专家共同提出的。尽管右项有其价值,我们更重视左项的价值。
-
个体和互动 高于 流程和工具
-
工作的软件 高于 详尽的文档
-
客户合作 高于 合同谈判
-
响应变化 高于 遵循计划
3、敏捷十二原则
-
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
-
即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势
-
经常性地交付可工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好
-
在整个项目开发期间,业务人员和开发人员必须天天都在一起工作
-
围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作
-
在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈
-
工作的软件是首要的进度标准
-
敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度
-
不断地关注优秀的技能和好的设计会增强敏捷能力
-
简单(尽最大可能减少不必要的工作)是一门艺术
-
最好的架构、需求和设计出自于自组织的团队
-
每隔一段时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整
4、常用敏捷方法论
敏捷方法 | 摘要说明 | 强调 | 创建者 |
---|---|---|---|
SCRUM | 提供敏捷项目管理框架 | 组成团队、安排工作 | 杰夫·萨瑟兰与肯 施瓦布 |
极限编程(XP) | 专注于敏捷工程实践 | 效率、聚焦于客户、反馈与质量 | 肯特·贝克 |
精益 | 精简与过程优化 | 减少无法创造客户价值的工作 | 玛丽与汤姆·波彭代克 |
看板 | 工作可视化与限制中的工作 | 可视化与管理工作过程,及时开发 | 大卫、安德森 |
动态系统开发(DSDM) | 强调在对的时间交付对的结果 | 以结构化的方式快速开发、综整最佳实践 | DSDM联盟 |
功能驱动开发(FDD) | 专注于产品功能的交付 | 迭代开发出用户所要的功能 | 杰夫·德卢·卡 |
水晶家族 | 列出特定情况的解决方法 | 人、沟通、产品和组织动态有机融合的严谨过程 | 阿利斯泰尔·科伯恩 |
5、成功敏捷团队的属性
下图是PMBOK中成功敏捷团队的属性
6、敏捷的角色
敏捷团队中有三种常见的角色:跨职能团队成员;产品负责人;团队促进者。
7、Scrum
Scrum是一个轻量级的软件开发方法,也是个敏捷开发框架,是一个增量的、迭代的开发过程。
-
Scrum中项目整个开发周期包括若干个小的迭代周期,每个小的迭代周期称为一个Sprint,每个Sprint的建议长度是2-4周
-
使用产品BackLog来管理产品或项目的需求,产品BackLog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事,即User Story
-
团队从产品BackLog中挑选最有商业价值的需求,需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表,即Sprint BackLog
-
在每个迭代结束时,Scrum团队将交付潜在可交付的产品增量
7.1 Scrum的核心价值观
-
承诺
-
专注
-
公开
-
尊重
-
勇气
7.2 Scrum中的角色
-
产品负责人:利益相关方的代表,重点是产品业务方面,从业务角度出发对需求并对权重排序,合理的调整产品功能和迭代顺序。
-
Scrum Master:团队的导师和组织者,负责提高团队效率。提出团队培训的计划,列出障碍。让利益相关方获得最大化的投资回报,提高团队的开发效率,开发思想得到利益相关方的理解与支持。
-
团队:尽一切可能去完成任务,充分理解产品负责人的产品愿景合作完成冲刺(Sprint)中每一个目标,更好的支持可能需要进一步开发的产品发布。
7.3 Scrum三大工件
-
产品列表(Product Backlog):列出团队正在开发或计划开发的产品需求;通常是以用户故事的形式展现;产品负责人即PO负责列表的内容、可用性和优先级;不断更新变化,根据产品和开发环境的变化而演进;按照优先级排序
-
迭代列表(Sorint Backlog):包含团队在本Sprint中需要执行的任务;对产品BackLog的进一步补充,对用户故事进行任务分解;许多任务在Sprint计划会议上已经讨论、定义;只有团队可以修改Sprint BackLog
-
产品增量:
7.4 Scrum五大会议
会议类型 | 会议目的 | 会议内容 | 会议时间 |
---|---|---|---|
产品规划会 | 建立Scrum团队以及组织内的其他部门能够理解和沟通的计划和模板;会议时间 | 确定发布目标;具有最高优先级的产品BackLog条目;重大风险;发布所包含的全部特性和功能;大致交付日期和费用 | |
迭代计划会 | 制定迭代计划 | 做什么;怎么做 | 小于等于Sprint周期的5% |
每日站会 | 增强交流沟通,确定并排除障碍 | 从上次会议到现在都完成了哪些工作;下次每日站会之前准备完成什么;工作中遇到了哪些障碍 | 小于等于15分钟 |
迭代评审会 | 评审 | 产品负责人确定完成了哪些工作和剩余哪些工作;团队讨论在Sprint中遇到的问题;团队演示完成的工作并答疑;计划出可能的完成的日期 | 小于等于Sprint周期的5% |
迭代回顾会 | 改进开发过程,提高团队生产力 | 对前一个Sprint周期的人、关系、过程和工具进行总结;上一个Sprint哪些方面做的不错;上一个Sprint哪些方面需要改进;完善障碍BackLog;完善团队BackLog | 小于等于3小时 |
版权声明:本文为博主作者:未定义的半分醒原创文章,版权归属原作者,如果侵权,请联系我们删除!
原文链接:https://blog.csdn.net/qq_34713109/article/details/127210329