敏捷管理有一个原则就是:拥抱变化

敏捷管理有一个原则就是:拥抱变化。

这是它和传统性项目管理的一个最大的区别,传统的项目管理为了防止需求变更才开始从需求调研和分析开始并把它文档话,在这块做了大量的工作,但问题是需求变更时避免不了的,只能通过这些方式做到相对降低。所以需求和需求变更更管理是瀑布式或者流程式的项目管理最头疼的地方,大家都用很多招来应对。

需求变更在敏捷管理里都是新的需求,产品关注的重点是这个变更对用户是不是有价值的,有价值的就会最优先的去做。

所以不同的项目管理方式,大家关注或者沟通的出发点不一样。当然前提是什么样的项目适合怎样的项目或者产品研发方式,需要开始时沟通清楚,没有谁对谁错,只是看怎样更合适,否则后期大家在这个最根本的基础点上会存在很大偏差。

大家可以跟更多的项目经理项目管理社区一起探讨分享项目管理案例

原文地址:https://www.cnblogs.com/iwangjun/p/11649914.html

时间: 2024-11-06 07:30:11

敏捷管理有一个原则就是:拥抱变化的相关文章

敏捷软件开发:原则、模式与实践——第20章 咖啡的启示

第20章 咖啡的启示 这个例子对于教学有很多好处.它短小.易于理解并且展示了如何应用面向对象设计原则去管理依赖和分类关注点.但从另一方面来说,它的短小也意味着这种分离带来的好处可能抵不过其成本.就当做一个设计思路来看吧. 20.1 Mark IV型专用咖啡机20.1.1 规格说明书 Mark IV型专用咖啡机一次可以产出12杯咖啡.使用者把过滤器放置在支架上,在其中装入研磨好的咖啡,然后把支架推入其容器中.接着,使用者向滤水器中倒入12杯水并按下冲煮(Brew)按钮.水一直加热到沸腾.不断产生的

敏捷软件开发:原则、模式与实践——第11章 DIP:依赖倒置原则

第11章 DIP:依赖倒置原则 DIP:依赖倒置原则: a.高层模块不应该依赖于低层模块.二者都应该依赖于抽象. b.抽象不应该依赖于细节.细节应该依赖于抽象. 11.1 层次化 下图展示了一个简单的层次化方案: 高层的Policy层使用了低层的Mechanism层,而Mechanism层又使用了更细节的Utility层.它存在一个隐伏的错误特征,那就是:Policy层对于其下一直到Utility层的改动都是敏感的.依赖关系是传递的. 下图展示了一个更为合适的模型: 每个较高层次都为它所需要的服

敏捷软件开发:原则、模式与实践——第5章 重构

第5章 重构 在Martin Fowler的名著<重构>一书中,他把重构定义为:“在不改变代码外在行为的前提下对对代码做出修改,以改进代码内部结构的过程.”可是我们为什么要改进已经能够工作的代码结构呢?我们不是都知道“如果它没有坏,就不要去修理它!”吗? 每一个软件模块都有3项职责.第一个职责是它运行起来所完成的功能.这也是该模块得以存在的原因.第二个职责是它要应对的变化.几乎所有的模块在它们的生命周期中都要变化,开发者有责任保证这种变化应尽可能地简单.一个难以改变的模块是有问题的,即使能够工

敏捷软件开发:原则、模式与实践——第15章 状态图

第15章 状态图 在描述有限状态机(FSM)方面,UML提供个丰富的符合. 15.1 基础知识 下图是一个简单的状态迁移图(STD),该图描述了控制用户登录到系统的FSM.圆角矩形表状态.上层格间放置每个状态的名字.下层格间中放置的是一些特定动作,表示当进入或退出该状态时要做什么. 图中左上角的实心圆称为初始伪状态.FSM从这个伪状态开始,根据变迁规则进行转移. 15.1.1 特定事件 状态图的下层格间含有事件/动作对. 15.1.2 超状态 当许多状态以同样的方式响应某些同样的事件时,使用超状

敏捷软件开发:原则、模式与实践——第9章 OCP:开放-封闭原则

第9章 OCP:开放-封闭原则 软件实体(类.模块.函数等)应该是可以扩展的,但是不可修改. 9.1 OCP概述 遵循开放-封闭原则设计出的模块具有两个主要特征: (1)对于扩展是开放的(open for extension).这意味着模块的行为是可以扩展的.当应用的需求改变时,我们可以对模块进行扩展,使其具有满足那些改变的新行为. (2)对于修改是封闭的(closed for modification).对模块进行扩展时,不必改动模块的源代码或者二进制代码.模块的二进制可执行版本,无论是可链接

敏捷软件开发之原则篇

1.我们最优化先要做的是通过尽早的.持续的交付有减脂的软件来使客户满意. 2.即使到了开发的后期,也欢迎改变需求.敏捷过程利用变化来为客户创造竞争优势. 3.经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好. 4.在整个项目开发期间,业务人员和开发人员必须天天都在一起工作. 5.围绕被激励起来的个人构建项目.给他们踢空所需的环境和支持,并且信任他们能够完成工作. 6.在团队内部,最距有效果并且富有效率的传递信息的方法,就是面对面的交谈. 7.工作的软件是首要的进度

敏捷软件开发:原则、模式与实践——第13章 写给C#程序员的UML概述

第13章 写给C#程序员的UML概述 UML包含3类主要的图示.静态图(static diagram)描述了类.对象.数据结构以及它们之间的关系,藉此表现出了软件元素间那些不变的逻辑结构.动态图(dynamic diagram)展示了软件实体在运行过程中是如何变化的,其中描述了运行流程或者实体改变状态的方式.物理图(physical diagram)展示了软件实体不变的物理结构,其中描述了诸如源文件.库.二进制文件.数据文件等物理实体以及它们之间的关系. 查看如下代码,这段程序实现了一个基于简单

敏捷软件开发:原则、模式与实践——第3章 计划

第3章 计划 3.1 初始探索 在项目开始时,开发人员会和客户商讨一下关于新系统的情况,以确定出所有真正重要的信息.然而,他们不会试图去确定所有的特性.随着项目的进展,客户会不断的发现新的特性.特性发现的过程会一直持续到项目完成. 当识别出一个特性时,会把它分解成一个或者多个用户故事,并把这些用户故事写在索引卡片之类的东西上面.除了用户故事的 名字之外,无需记录其他任何内容(比如Login,Add User,Delete User 或者Change Password).此时,我们不会试图记录细节

敏捷软件开发:原则、模式与实践——第10章 LSP:Liskov替换原则

第10章 LSP:Liskov替换原则    Liskov替换原则:子类型(subtype)必须能够替换掉它们的基类型(base type). 10.1 违反LSP的情形 10.1.1 简单例子 对LSP的违反导致了OCP的违反: struct Point { double x, y;} public enum ShapeType { square, circle }; public class Shape { private ShapeType type; public Shape(Shape