敏捷就是微观管理
“崔胜澈”通过精心收集，向本站投稿了5篇敏捷就是微观管理，下面是小编给大家整理后的敏捷就是微观管理，欢迎大家借鉴与参考，希望对大家有所帮助。
篇1：敏捷就是微观管理
微观管理是指管理人密切监视或控制下属工作的管理方式，通常给人不好的印象，敏捷开发和微观管理看起来可能一点也不搭边，但实际上它们是紧密相联的。
Mike Cohn认为敏捷最大的秘密是敏捷实际上就是微观管理。Mike提到敏捷的所有实践都支持微观管理。他认为：
Daily scrum是对团队每天工作计划的微观管理，确保每个人都会做他们所承诺的事。
持续集成是为了当某些人破坏构建时，能够被大家知道。
结对编程是为了防止开发人员分心、镀金（做的太多，超出了所需要做的事）、只做有趣的工作，并把事情做好。
对于上述观点，Artem Marchenko补充道：
对于很多人来说，敏捷看起来就是大量的微观管理：开发人员需要每天汇报他们的工作，管理细化到每个特性，团队最好能够每二到四周就提交demo，有了问题可以思考几个月并构建良好的架构。听起来像微观管理，不是么？
那么，谁在实施微观管理？
很明显，是项目团队。团队实施微观管理是为了他们自己的利益。团队用微观管理来管理每天的工作和每个迭代的内容。当团队讨论每天的任务时，他们就是为了团队和组织的利益，作为一个整体在实施微观管理，
管理资料
然而，有些时候团队的成员会感觉被微观管理了。
Scrum master可能会过于关注团队的进度。这包括在团队中走来走去，询问任务的进度，质疑团队的估算。有时团队成员也会因为缺乏技术方面的技能或短处而害怕让事情变得透明。其他因素包括：
除了长长的报告、电邮和会议，管理人员还不停的询问进度。
管理人员企图和你讨论技术细节，而实际上他们却不懂。
管理人员根据心情随意改变你正在做的事或打断你。
这种微观管理确实存在于某些试图从传统软件开发向敏捷开发过渡的组织中。就像
Jurgen Appelo所说：一些管理人员对于让团队一起做决定感到很不舒服，当团队离开他们自己做决定时，他们会感觉对发生的事失去了控制。管理人员认为决策必须是强制性的或至少不是混乱的。但正是这种混乱本身造就了整个宇宙，因此它不可能太坏。
微观管理人员必须认识到，他们应该“负责”而不是“控制”。试图“控制和抑制”通常都不奏效，有时甚至会对生产力产生反作用。
因此，虽然敏捷中充满着微观管理，但不同的是，团队会做这些管理。管理人员必须将权利交给团队，为了项目和团队的利益，每天由团队进行微观管理。
查看英文原文：Agile is Micromanagement本文来自：www.infoq.com/cn/news//11/agile-micromanagement
篇2：敏捷风险管理
风险管理包括风险评估、舒缓风险影响以及监控风险，很多敏捷用家相信敏捷开发项目风险管理过程跟传统项目差不多，虽然这过程在敏捷的内容中较为轻盈，但是在找寻、过滤、优先化以及制造解决方案上的步骤跟传统项目中很接近。
Mike Cottmeyer提出以敏捷开发去识别和舒缓风险影响更为有效，他指出：
敏捷开发方式之所以能有效管理风险因为风险管理过程建立在我们执行项目的结构上，这隐含的意思就是风险在项目中无处不在，风险清单不能包括所有风险，也不能透过团队会议和定期的风险评估来减轻风险，风险处理必须是不能抽离的思想，我们减轻风险的策略不是处于项目以外，而是影响着如何规划和安排工作的本质。他把风险分成三类：
业务风险– 涉及项目付运能否带来它所预期的价值
技术风险– 涉及技术方案在若干时间及资金下的可行性
后勤风险– 涉及人与其他基建之间的假设
根据Mike所说，敏捷开发的本质就是要求频密的付运、定时的检察和调整，这本身已经是风险管理。
但是也有人认为敏捷开发不是固有地处理风险。
Jurgen Appelo认为敏捷项目经常缺乏风险的关注。
他认为，
Prince2、PMBOK、CMMI都有包含风险管理的部份，但敏捷方法的书本上就很少明确地看到风险管理的内容，对此我感到莫名其妙。他同r指出，项目经理经常埋头在项目里，而忽略了整体宏观形势，这导致严重缺乏对风险管理的关注。
另外，James Shore认为有效的风险管理能帮助团队作出更实在的承诺，他建议使用风险倍数（risk multiplier）和Burn-up图来管理项目有关的风险。
风险倍数包括常见的风险，例如人事变动、要求改变、工作上的障碍之类，这些风险倍数让你更准确地于设定日期和估计需要多少故事点数（story potints）。James建议在团队使用较为精确的开发过程（相对于风险较高的开发过程，可参考James网站上这例子），而且速度（velocity）固定、每个故事都在迭代完结时做到“Done Done”（不仅完成客户需要的功能，而且没留下支持团队的工作，原文出至于James的网站，亦可参考“The Power of Done”一文）的情况下使用以下的风险倍数。
风险倍数
机会率精确的开发过程所使用的倍数热10%1几乎没可能50%1.4伸延目标--只得一半机会，有机会再去完成90%1.8几乎可以成事的承诺（这些倍数来至DeMarco和Tim Lister的RISKOLOGY模拟器（详文可参考「与熊共舞」一书）以及Todd Little的分析数据）
这风险倍数使用方式如下：
（假设团队的速度为14，十个迭代后发布的话，那么当前可运用的故事点数有140点）
机会率能完成的故事点数热10%140 (140 ÷ 1)几乎没可能50%100 (140 ÷ 1.4)伸延目标--只得一半机会，有机会再去完成90%78 (140 ÷ 1.8)几乎可以成事的承诺从以上例子中：
让你可以跟项目有关人士和管理人员说：「我们几乎肯定会在发布前完成当中的78点，所以我们先承诺完成功能A、B和C，我们有一半机会能完成总共100点，所以我们安排功能X、Y和Z作为伸延目标，完成好A、B和C之后再去完成他们的，管理资料
」所以风险管理在敏捷项目中就如传统项目一样，都是核心部份，重点在于适当的重视、有效地处理而基于这里作出承诺。
查看英文原文：Agile Risk Management
译者附注：
James的网站有更多关于其风险倍数的内容，亦可参考他所写的“The Art of Agile Development”一书，特别是此文没有包括的Burn-up图。此外，风险倍数的使用还有其他注意的地方：
「承诺」背后的意义，值得思考的就是「承诺」到底是什么、管理人员如何理解和使用这里作出的「承诺」。要知道，这些还是机会率，如果最后变成合约，又或者客户拿来争议的「论点」，那么也是没有意思的。
风险倍数的由来，这里的1、1.4和1.8是如何得出呢？到底又有多适合您的项目情况呢？就连James自己的网页上 也有这样一句 “I”m guessing somewhat at how accurately they apply to XP. The most accurate approach is to calculate your own risk multipliers from past project history, but most companies don“t track that data” （我在猜这些数字对极限编程的情况有多准确，最准确的方式还是根据过往项目纪录来计算您的风险倍数，但很多公司根本不会记下这些数据），所以千万不要把这 些数字看成什么魔幻数字。
延续上面这点，如果公司为了提供「承诺」而去收集项目相关数据，这是否对容户有所得益呢？容户为什么要投资金钱给开发公司去收集数据？客户又如何可以知道投资金钱让公司收集这些数据可以有所回报呢？
其他方法如Prince2、PMBOK或CMMI等对风险管理都有值得参考之处，而跟敏捷有关的独特观点则是减少开发上浪费而没必要的过程和活动，之前在「Scrum的风险管理」也有相关的讨论。
还有，要好好管理风险，评估形势的能力很重要，甚至比其方法更重要，例如如何猜量我们是否在“风险较高进行开发”呢？这里其实可以套用Stacey模型和Cynefin模型来辅助
本文出自：www.infoq.com/cn/news/2009/02/agile-risk-management
篇3：如何发现和改变微观管理
微观管理是技术驱动的工作场合中的瘟疫，下面是如何发现它以及如何改变它的建议。
每个人都觉得微观管理是一件坏事，但是不是每个人都知道如何识别并且纠正它。
根据我的经验，微观管理体现在以下五个可以避免的行为之中：
1.测量太多的事情。
技术的好处在于你能够更精确地测量你的业务。技术的缺点在于它让测量过多的事情变得太过容易。测量过多的事情，但是又并不清楚这些数据的含义，这种做法就是典型的微观管理。
该如何做：对于每项工作，选择一个或者两个能够定义这份工作成功的指标。忽略其他的事情。
2.监控过于严密。
监控有时候会和测量相混淆，但是两者是不同的。你测量数据；你监控行为。如果你总是严密监视员工的话，那就是在微观管理了。
该如何做：让员工在自己觉得有必要提高绩效的时候主动要求监控和指导，
3.达成了太多共识。
在决策之前收集大家的意见是一个好主意，特别是从那些会受到这个决策影响的人那里收集意见更是如此。但是，如果你在做出决定之前非要将所有的一切都讨论清楚，那么你就是在进行微观管理了。
该如何做：为决定设置一个最后期限。安排有限次数的会议，让大家集中起来讨论。然后在最后期限之前做出决定。
4.干预太多。
直升机式的经理和直升机式的父母一样糟糕——他们让那些他们试图帮助的人满心无奈。人们成长的唯一途径就是通过犯错误，这就意味着管理者不应该随时跳出来解决问题。
该如何做：在员工要求的时候提供指导，但是让你的员工自己去犯错误。如果他们不能或者没有从自己的错误中汲取教训，那么他们就不是值得保留的员工。
5.设定了太多的重点。
如果管理者给出的任务列表上的内容或多或少都是同样重要的话，就会让员工感到混乱。这就会引发微观管理，因为唯一的方法就是“让所有的盘子都转起来”。
该如何做：为每个员工、每一个团队、每一个小组和每一个部门都设定一个压倒一切的优先事项。让他们弄清楚如何达成这个目标或者实现它。
篇4：SCRUM敏捷项目管理
Scrum这个词是来自于英式橄榄球，是指两个前锋互相争球的情况，我想Scrum的创始人Ken Schwaber肯定是一个橄榄球迷，呵呵….，这是题外话。先简单介绍一下，Scrum一种敏捷项目管理的框架，它的核心是迭代和增量。Scrum中有三种角色：产品经理(Product Owner)，ScrumMaster(相当于项目经理)，团队(Team)。具体流程如图：
产品经理整理出按优先级排序的产品Backlog(产品需求列表)，然后召开Sprint(开发周期)计划会议确定当前要进入的一个Sprint的Sprint Backlog(选中产品Backlog的需求)，进入Sprint开发，每日需要进行Scrum例会已检查项目当前进度和遇到的问题，Sprint完成之后是Sprint评审会议，已检查Sprint产出的功能增量，最后是Sprint总结会议，总结Sprint中的经验和问题，已改善流程提高效率，把待改进的高优先级的事项加入到下一个Sprint Backlog中，
我觉得Scrum很好的诠释了戴明的PDCA(plan-do-check-adjust)循环，就整个迭代来讲，Sprint计划会议对应Plan，Sprint对应Do，Sprint评审会议和Sprint总结里面做了check和adjust。那么在Sprint里面，每日的Scrum简会处理三个问题：1、前一天做了什么？2、今天将要做什么？3、遇到了什么障碍？那么在这里面做了plan今天的事情，check前一天做的事情和遇到的障碍，do今天的事情，如果有障碍那么就需要adjust。
另外Scrum的三大特点也让我比较振奋，也是它和传统瀑布式的项目管理的最大区别。
一、“可能性的”艺术
强调想事情的时候不应该把注意力集中在“不能做的事情”上，而是关注当下“什么事情可以做或者可能做”，不要被诸多的不确定性因素所困扰，先做可以做的，然后看有什么新的发现，有什么新的思维出现。
二、团队自组织，自管理
强调“放权”，让团队自己寻找解决问题的最佳方案。可以激发团队创造力，增强团队责任感，显著提高生产力。
三、面对面沟通
强调面对面的沟通，以有效减少沟通障碍。
如果你公司的项目在原来的管理方式下无法运行了，请试试Scrum吧！
本文来自：www.kdued.com//02/scrum/
篇5：敏捷供应链过程管理的过程描述
敏捷供应链过程管理的过程描述
利用对象Petri网(OPN)重点通过对活动和连接两个因素的`描述来对敏捷供应链过程进行定义.通过进一步对其进行数学描述,以便利用数学工具对该过程进行分析,目的是将现实世界中的业务流程转化成计算机可处理的形式.
作 者：曹昌军 覃正 刘大光 邹辉 作者单位：西安交通大学管理学院,西安,710049 刊 名：商品储运与养护 英文刊名：STORAGE, TRANSPORTATION & PRESERVATION OF COMMODITIES 年，卷(期)：2003 25(4) 分类号：F723 关键词：敏捷供应链 过程管理 对象Petri网【敏捷就是微观管理】相关文章：
1.敏捷的反义词
2.敏捷的爷爷作文
10.我就是我，
文档为doc格式
