PMI-ACP认证考试学习笔记(一)
敏捷与敏捷项目管理的含义
敏捷:是创造并相应变化,从而在动荡的商业环境中创造利润的能力。
敏捷项目管理是驾驭这种能力,针对控制与适应,组织与团队,结构与灵活,效率与效果,风险与机会进行平衡的一门艺术。
关于敏捷宣言和敏捷原则
《敏捷宣言》
《敏捷宣言十二大原则》
查看博文:[敏捷开发培训] 敏捷宣言和 Subway Map to Agile Practices
敏捷项目管理的3-3-5-5
敏捷领导力的3个核心价值观
- 价值胜过约束
- 团队胜过任务
- 适应胜过遵循
敏捷三角形的3个要点
- 价值
- 质量
- 约束
软件领域快速发展、客户要求的不断提高、用户诉求的日新月异,我们很难以保证在先期投入大量成本的项目规划是准确无误的,因为对于变化很难以去预判,也难以去管控。
组织和团队需要不断的尝试和总结来,即采用经验过程控制的方式来完成软件项目的管理,也就是敏捷项目管理三角的由来。
- 价值:将目标聚焦在客户和用户的视角,软件用来交付他们需要的价值,而非站在项目角度去完成对应的待办任务。
- 质量:软件行业发展至今,用户对软件的依赖越来越强,要求也越来越高。
- 约束:制约用户价值和软件质量的因素,由传统项目管理三角型中的范围、时间和成本构成。
对于传统三角的范围不变,敏捷三角反其道而行之,在既有的约束条件下,我们会高质量的优先完成高价值的事情。虽然约束条件中的三角和传统项目管理的三角在字面上是一样,但本质的区别在于,敏捷三角的范围是可变的而传统三角则很难。
约束点中的时间能够以敏捷项目管理中的迭代实践来进行计算,以周为单位将时间抽象成一个相对固定的基础单元;而成本最多在与人力投入,在敏捷实践中的全功能团队规模也很方便计算出整体的投入。在单位时间内的投入和产出相对稳定的情况下,可以合理的通过调整范围来灵活调配约束这个点,以满足三角形中的价值和质量要求。
敏捷三角相较于传统三角,将范围从固定演进为可变以灵活适应市场的变化,将目标聚焦于客户价值而非既定任务以满足多元化的用户需求,加强质量的权重以提升终端用户的体验。价值驱动的项目管理方式在当前的软件时代背景下显然是由于计划驱动的管理方式的。
敏捷项目管理模式的5个交付阶段
- 构想
- 推演
- 探索
- 适应
- 收尾
敏捷项目需要实现的5个关键商业目标
- 持续创新
- 产品适应性
- 缩短上市时间
- 人员和流程适应性
- 可靠的结果
敏捷领导力价值观
敏捷强调的是态度而不是流程,强调的是环境而不是方法。
在高绩效的团队中,领导者管理原则,而原则管理团队。
团队为和存在,要创造什么产品,为谁而创造,以及如何共同工作,这些组成了敏捷项目管理的核心原则。
管理和领导的区别
在《敏捷宣言》中写道“个体交互高于流程与工具”。通过这句话可以看出,敏捷认为人的价值已经超过了流程和工具的价值,所以这就需要在敏捷过程中对人进行很好的“管理”。
而在敏捷实践中,管理与领导是有很大的区别的,是两种截然不同的思维模式。
在敏捷中使用的是领导的方法,而不是指挥、命令和控制的方法。
管理的关注点 | 领导的关注点 |
---|---|
任务/事情 | 人 |
控制 | 授权 |
效果 | 效率 |
把事情做正确 | 做正确的事情 |
速度 | 指导 |
实践 | 原则 |
命令 | 沟通 |
敏捷需要创建更多的环境来激发团队成员的工作欲望。
敏捷方法论
一些主要的敏捷软件开发方法组件包括:
- Scrum
- Lean
- Kanban
- Extreme Programming
- Crystal
- DSDM
- FDD
详细参考链接(你所需要了解的Agile基本知识这里都有!!!)
https://www.atlassian.com/agile
Scrum
Scrum是一个管理框架,具有远程控制和管理所有项目类型中的迭代和增量的能力。它们是轻量级的,可以与其他敏捷方法一起用于各种工程实践。
Scrum在敏捷软件开发 区中越来越受欢迎,因为它们很简单并且具有可靠的生产率。
补充资料
It is a framework used by teams to establish a hypothesis, test it, reflect on the experience, and make adjustments. It enables teams to incorporate practices from other frameworks depending on the requirements. It is used by cross-functional teams that are working on product development, and the work is split into more than one 2-4 week iterations.
更多资料:
Download the official Scrum Guide 2020 https://scrumguides.org/download.html
精益(Lean)
精益软件开发是一种最初由Mary和Tom Poppendieck开发的迭代方法。精益软件开发中的许多原则和实践来自精益企业运动,并且首先被丰田等大公司使用。这种基于价值的方法侧重于为客户提供有效的“价值流”机制,为项目提供价值。
该方法的主要原则是:
- 消除浪费
- 扩大学习
- 尽可能晚地做出决定
- 尽快交付结果
- 赋予团队权力
- 建立诚信
- 设想整个项目
通过仅选择对系统具有实际价值的功能,小批量优先排序和交付可消除浪费。相反,精益方法强调速度和效率; 依靠客户和程序员之间快速,可靠的反馈。它侧重于客户要求“拉动”产品的想法。重点更多的是个人或小团队更快,更有效的决策能力,而不是层次控制方法。该方法集中于其团队资源的效率,确保每个人始终尽可能高效。
补充资料
It is a set of tools and principles that focuses on identifying and removing waste to speed up process development. Value is maximized, and waste is minimized. It is used in just about every industry that produces waste in some form.
看板方法 (Kanban)
组织使用看板方法来管理项目的创建,同时强调持续交付而不会使开发团队负担过重。与Scrum一样,看板流程旨在帮助团队更有效地协同工作。
有三个原则:
- 可视化您的工作:查看彼此上下文中的所有项目 – 提供更多信息
- 限制正在进行的工作量(WIP):平衡基于流的方法,以便团队不会立即做太多工作
- 增强流程:一旦完成一项任务,就从积压工作开始下一个最高优先级工作
看板方法促进了客户和团队的持续协作。它鼓励持续学习和改进,为团队提供最佳的工作流程。
补充资料
It is a method that’s used to design, manage, and improve the flow of systems. Kanban enables organizations to visualize their flow of work and limit the amount of work in progress. It is used in situations where work arrives unpredictably, and where it needs to be deployed immediately without waiting for other work items.
极限编程(XP)
极限编程(XP)最初由Kent Beck描述。它是最流行和最有争议的敏捷方法之一。XP是一种高度自律的方法,可以更快地持续提供高质量的软件。客户积极参与紧密团队,不断进行规划,测试和快速反馈,以便经常提供工作软件。该软件应每隔三到几周发送一次。
最初的XP方法基于四个简单的值:
- 简单
- 通讯
- 反馈
- 勇气
它有12个支持实践:
- 规划游戏
- 小版本
- 客户验收测试
- 设计简单
- 结对编程
- 测试驱动的开发
- 重构
- 持续集成
- 集体代码所有权
- 编码标准
- 隐喻
- 可持续发展
补充资料
Extreme Programming
It is a framework that enables teams to create high-quality software that helps improve their quality of life. It enables software development alongside appropriate engineering practices. It is applicable while handling changing software requirements risks caused due to new software, working with a small, extended development team, and technology that allows automated unit and functional tests.
水晶方法 (Crystal)
Crystal方法是开发软件中最轻量级和适应性最强的方法之一。它由几个敏捷过程组成,包括透明,水晶黄,水晶橙和其他独特的特征方法。推动这些流程的因素包括:团队规模,系统的重要性以及项目的优先级。
Crystal系列专注于实现每个项目都具有独特的特征,因此,必须定制策略和实践以适应这些功能。
Crystal方法有几个基本原则,包括:
- 团队合作
- 通讯
- 简单
- 反射
- 经常调整
- 改善流程
与其他方法一样,这种敏捷过程可以促进早期和频繁的工作软件交付。它鼓励高度的用户参与,适应性和消除干扰和官僚作风。
补充资料
It focuses on people and their interactions, rather than on tools and processes. Aimed to streamline processes and improve optimization, Crystal works on the principle that projects are unique and dynamic. It is used when the focus is on strengthening team communication, continuous integration, active user involvement, and configurable processes.
动态系统开发方法(DSDM)
动态系统开发方法(DSDM)起源于1994年,为当时称为快速应用程序开发(RAD)的项目交付提供行业标准框架。虽然它在20世纪90年代非常流行,但RAD方法以非结构化的方式发展。
自成立以来,DSDM已经发展成熟; 它为敏捷流程和迭代项目的规划,管理,执行和扩展提供了全面的基础。
DSDM使用“适合商业目的”的方法来实现交付和验收标准。它侧重于公式:80%的系统部署在20%的时间内。
补充资料
What is DSDM/strong>
Dynamic systems development method (DSDM) is an agile project delivery framework that first came about in 1994 and was, at that time, used for software development. It was meant to be an improvement on Rapid Application Development (RAD), which prioritized rapid prototyping and iteration based on user feedback. As with many agile project delivery methods, the DSDM Agile Project Framework eventually moved from being a software-specific solution to a more general project management tool.
The Eight Principles
The eight Principles of DSDM:
- Focus on the business need
- Deliver on time
- Collaborate
- Never compromise quality
- Build incrementally from firm foundations
- Develop iteratively
- Communicate continuously and clearly
- Demonstrate control
https://theqalead.com/topics/dsdm-dynamic-systems-development-method/
功能驱动开发(FDD)
Jeff De Luca,以及贡献者Am Rajashima,Lim Bak Wee,Paul Szego,Jon Kern和Stehen Palmer开发了功能驱动开发(FDD)。它是一个模型驱动的短迭代过程,首先建立敏捷模型的形状。“按功能设计,按功能构建”的迭代每两周举行一次。这些功能对客户很有吸引力,因为它们很小且很有用。
使用以下八种做法提供FDD设计和开发:
- 域对象建模
- 开发功能
- 组件和类所有权
- 特色团队
- 检查
- 配置管理
- 定期构建
- 进展和结果的可见性
补充资料
What is Feature Driven Development(FDD)
Feature Driven Development (FDD) is an agile framework that, as its name suggests, organizes software development around making progress on features. Features in the FDD context, though, are not necessarily product features in the commonly understood sense. They are, rather, more akin to user stories in Scrum. In other words, “complete the login process” might be considered a feature in the Feature Driven Development (FDD) methodology.
What’s the History of Feature Driven Development/strong>
The first real-world application of the Feature Driven Development methodology was on a 50-person software-development project for a Singapore-based financial institution, and the first public discussion of the methodology was in the 1999 book Java Modeling in Color with UML.
FDD was designed to follow a five-step development process, built largely around discrete “feature” projects. That project lifecycle looks like this:
- Develop an overall model
- Build a features list
- Plan by feature
- Design by feature
- Build by feature
The framework has since gained widespread use particularly in larger organizations, and today there is a thriving Feature Driven Development community with its own website.
Strengths and Weakness of Feature Driven Development
FDD’s strengths include:
- Simple five-step process allows for more rapid development
- Allows larger teams to move products forward with continuous success
- Leverages pre-defined development standards, so teams are able to move quickly
FDD’s weaknesses include:
- Does not work efficiently for smaller projects
- Less written documentation, which can lead to confusion
- Highly dependent on lead developers or programmers
https://www.productplan.com/glossary/feature-driven-development/
敏捷软件开发
敏捷软件开发(Agile Software Development)是一种以人为核心、迭代、循序渐进的开发方法。
补充资料
What is Agile Software Development/strong>
Agile software development is more than frameworks such as Scrum, Extreme Programming, or Feature-Driven Development (FDD).
Agile software development is more than practices such as pair programming, test-driven development, stand-ups, planning sessions, and sprints.
Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it. When you approach software development in a particular manner, it’s generally good to live by these values and principles and use them to help figure out the right things to do given your particular context.
One thing that separates Agile from other approaches to software development is the focus on the people doing the work and how they work together. Solutions evolve through collaboration between self-organizing cross-functional teams utilizing the appropriate practices for their context.
There’s a big focus in the Agile software development community on collaboration and the self-organizing team.
That doesn’t mean that there aren’t managers. It means that teams have the ability to figure out how they’re going to approach things on their own.
It means that those teams are cross-functional. Those teams don’t have to have specific roles involved so much as that when you get the team together, you make sure that you have all the right skill sets on the team.
There still is a place for managers. Managers make sure team members have, or obtain, the right skill sets. Managers provide the environment that allows the team to be successful. Managers mostly step back and let their team figure out how they are going to deliver products, but they step in when the teams try but are unable to resolve issues.
When most teams and organizations start doing Agile development, they focus on the practices that help with collaboration and organizing the work, which is great. However, another key set of practices that are not as frequently followed but should be are specific technical practices that directly deal with developing software in a way that helps your team deal with uncertainty. Those technical practices are essential and something you shouldn’t overlook.
https://www.agilealliance.org/agile101/#:~:text=Agile%20software%20development%20is%20an%20umbrella%20term%20for,Software%20Development%20and%20the%2012%20Principles%20behind%20it.
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!