[最佳实践]在Scrum敏捷软件开发模式中，我们是如何开Sprint 计划会议的

在Scrum敏捷开发框架下，最重要的一环就是 Sprint计划会议，这个会议开不好，整个Sprint会让Scrum Team痛苦不堪，也很难完成最初的Sprint目标。经过多次尝试后，我们终于找到了我们自己的模式。这些方法和原则对我们来讲是最好的，这基于我们自 己的知识，我们自己的项目情景，对于其他团队不一定试用。

---敏捷精灵

• 跟任何其他会议一样，确定好会议日程

sprint计划会议一定是要基于Time-Boxed, 在规定的时间内，一定要结束，就像一个Sprint一样。

我们的日程一般是这样的

Agenda:

Part I : Product Backlog Review [Product Owner, Scrum Team]

Time: 2 Hours

1) Enrich Product Backlog (60 Minutes)

2) Re-Prioritize Product Backlog Items (10 Minutes)

Break(10 Minutes)

3) Set Sprint Goal (20 Minutes)

4) Select Product Backlogs to Sprint (20 Minutes)

Part II: Sprint Planning [Scrum Team]

Time : 3-4 Hours

1) Work Breakdown by Two groups. (60 Minutes)

Break(10 Minutes)

2) Agree with the definition of "DONE" for each task with estimation (20 Minutes)

3) Critical Path Analysis (20 Minutes)

4) Resource Plan (20 Minutes)

Break(10 Minutes)

5) Find owner for each task. (40 Minutes)

6) Risk/Dependecy Analysis (20 Minutes)

7) AOB

• Sprint计划会议必须在一个完整天内开完

Sprint计划会议开始的那一天，也就是Sprint开始的一天。如果Sprint计划会议要跨越两天，可不是什么好玩的事情，你的Burndown Char就会象我们的这样很难看。因为我们是在前一天的下午开了4小时，第二天上午又开了3小时，对任务进行细化。。。

• 采用Delphi方法进行任务工作量的估算

当进行任务细化的时候，每个人的估算是不一样的，当出现分歧的时候，采用Dephi估算方法，如果最高估算值跟最低估算值相差一半以上，而者就要进行沟通一下，看看为什么二者的理解相差这么多。沟通明白后，再重新估算

• PM必须在Sprint计划会议前给出Sprint参与人员的预期工作时间

根据我们的历史统计，我们的投入率基本在75%左右，譬如按一个人上班8小时计算的话，他用在项目上时间大概在6小时左右。如果这个Sprint周期需要 15个工作日，这个员工可能要休假2天，参加培训1天，那他可以投入的预期工作时间 就是 6*（15-2-1）= 78小时。这样，在这个Sprint中，会有多少“人小时”就会事先计算出来。在Sprint计划会议中，当选择和细化Sprint任务的时候，有这个总 预期工作时间总作参考，就可以避免任务不足，或者承诺过多的问题。同时，也提醒每个人在领取任务的时候，不要过度承诺。

• 为了提高任务细化的效率，将团队分成两个小组分别进行
  

最初，我都是打开投影仪，把ScrumWorks中的东西投到屏幕上去，大家一边说，我一边敲，我是挺忙活的，但是大家却不一定都能集中注意力。。。现在 回头看看，这种方法真是有点蠢！当team成员少的时候，在最初的几个Sprint，大家在兴趣还比较高的时候，这种方法还行。

当Team成员超过6个的时候，问题出现了，首先是当讨论某一个问题的时候，总会有人问，刚才你们说什么来着？很显然，他走神了。。。另外，人多地时候，对同一个任务的细化，即使采用Delphi方法，沟通成本也很高，很费时间。

把team分成两个小组，分别对任务进行细化。细化时，不再用投影仪，而是把Sprint Backlog中的内容按大块张贴在墙上，大家站在墙前，拿着纪事帖直接进行细化和估算。 当两个小组都进行完后，互相检查对方对任务的细化，解决争议，澄清模糊的地方。这样一来，就把大家的积极性调动起来，参与程度非常高，效率也高。

• 对任务"DONE"的定义一定要做好，做细！
  

这个问题不言而喻，就不多说了。

• 虽然我们采用了Scrum，但是传统的Risk/Dependency分析还是不要丢弃。

即使不再采用Gatt图，但在Sprint计划会议结束前，进行Risk/Dependency的分析，还是帮助我们发现了一些问题，通过重新调整任务的优先级，顺利保证了Sprint的成功。

• 产品负责人(Product Owner)一定要参加。

实在不能参加的话，也要指定一个人授权代理。否则，就不要开Sprint 计划会议。

• Sprint Goal一定要定义的简洁、突出，选择的Sprint Backlog Item一定要强内聚，松耦合

这样大家才能不受或者少受外界的干扰，目标明确。

• 要给Sprint起一个好的名字
  

关于这个问题，就不多说了，详见 前文 “在Scrum开发模式下，为Sprint起名字的艺术”


阅读详细......

国外敏捷软件开发相关网站资源大全

Agile Alliance
敏捷联盟
敏捷方法发源地，有许多最新的研究文章和发展动态。

Cetus-Links
历史悠久的对象技术资源网站。在“OO Project Management - OOA/D Methods”条目下提供了大量迭代与敏捷方法资源链接。

Brad Appleton
大量软件工程、迭代方法资源链接

C2 Wiki
XP、敏捷方法、设计模式等重要思想的发源地
Ward Cunningham

极限编程
Don Wells
不错的 XP 介绍

极限编程
Ron Jeffries
XP 大师介绍 XP

Agile Modeling
敏捷建模
Scott Ambler



美国南加州大学（USC）软件工程中心（CSE）
软件工程大师 Barry Boehm 多年来有关迭代方法（如螺旋模型）的研究成果。

Cutter Consortium
著名的软件工程咨询机构，有一个“敏捷项目管理”专题。

XP 敏捷大师 Martin Fowler

ASD（Adaptive Software Development）方法创始人 Jim Highsmith

Crystal 方法创始人 Alistair Cockburn

Scrum 方法创始人 Ken Schwaber

Scrum 方法创始人 Jeff Sutherland

Evo 创始人 Tom Gilb 大师
历史最悠久的迭代演进式方法之一

敏捷方法大师 Craig Larman
我向全国每一位软件项目经理推荐 Larman 的著作 Agile & Iterative Development: A Manager's Guide。

Object Mentor
敏捷大师 Robert C. Martin 的咨询公司

Nebulon
FDD 方法发明人 Jeff De Luca 的公司网站

DSDM 方法官方网站

Rational Unified Process
IBM RUP 产品，如今叫 RMC（Rational Method Composer）

Network for Agile Methodologies Experience (NAME)
一个介绍敏捷方法研究及相关资源的欧洲网站

Agile Metrics
Robin Gibson
ThoughtWorks 的咨询顾问 Robin Gibson 创建的个人网站，其中 Agile Tool 栏目下的 Estimates/Risk Spreadsheet 很不错。

XP San Diego Wiki
美国圣地亚哥地区的一个 XP 社团 Wiki，其中的 Agile Tools、Book Reviews 以及当地采用敏捷方法的企业名单值得一看。



阅读详细......

[scrum工具]用excel表格工具实现Scrum

这是最初用Scrum的时候，搜集到的一个工具，感觉还是挺不错的。虽然现在我们改用ScrumWorks, 但我还是喜欢用这个工具生成一个初始的Burndown Chart,再把他打印出来，贴到看板上，每日开Standup meeting的时候，手工更新一下，生成实际的Burndown chart.。

----敏捷精灵

需要的朋友点这里下载。

这里还有一个实际模拟使用示例，不妨也看看。


以后再添加其它的工具

阅读详细......

Scrum敏捷项目管理的 ppt

很久以前总结的Scrum敏捷项目管理资料，给Team内部做Scrum Training用的，拿到这里，希望对大家又帮助，不过是E文的啊！

----敏捷精灵

想下载这个 Scrum敏捷项目管理.ppt 的可以直接点击这里

对于Scrum敏捷项目管理，每个人都会有自己不同的理解， 欢迎大家提出意见。

阅读详细......

在Scrum开发模式下，为Sprint起名字的艺术

在过去的几个月中，我们在每个Sprint 计划会议上，都会花上几分钟的时间，一起为当前的Sprint起名字，现在回顾一下，还是非常有意思的。

---敏捷精灵

看一下我们为项目A起的Sprint名字：

• Sprint1---"The Big Con"
• Sprint2---"Breakout"
• Sprint3---"Hours to doom day"
• Sprint4---"The Big End"
• Sprint5---"The Dragon Warrior"

熟悉加里森敢死队的同学一定会很兴奋的，因为我们这里面用了《加里森敢死队》好几集的名字，之所以选择《加里森敢死队》，是因为我觉得这个团队里面有一个很好的team leader-----
上尉加里森，以及各有所长的成员：小偷、酋长、戏子、强盗。。。他们各自发挥自己所长，完成了很多难以想象的任务，这样的团队，对于软件开发团队来讲，太需要了！

• “队长”（绰号：“头儿”）加里森中尉（Lt. Craig Garrison）由罗·哈珀（Ron Harper）饰演，西点军校毕业生，美国陆军情报部中尉，敢死队队长。童自荣配音。
• “戏子”（Actor）由塞萨·多诺万（Cesare Danova）饰演，一名诈骗犯，精通多种语言。他的特长是化妆与扮演。乔榛配音。
• “卡西诺”（Casino）由鲁迪·索拉里（Rudy Solari）饰演，一名惯盗，精通保险柜锁，对爆炸物也有一些了解。杨成纯配音。
• “酋长”（Chief）由布兰登·波恩（Brendon Boone）饰演，一名杀人犯，他的特长是飞刀、机械修理和驾驶。施融配音。
• “高尼夫”（一译“高涅夫”、“哥里弗”）（Goniff）由克里斯托弗·卡里（Christopher Cary）饰演，一名扒手神偷。尚华配音。
• “准成员”，一名杀人犯，因贪财在第一集中就丧命了。

下面具体讲解一下每个名字对于我们自己的含义:

• Sprint1---"兵不厌诈（the Big Con）"

因为大家第一次采用Scrum, 对这个Agile流程都很期待，同时呢，对于怎么做，如何用，还很模糊

• Sprint2---"越狱记（Breakout）

经过了第一个Sprint后，大家干劲十足，士气高涨，认为我们可以在第二个Sprint取得重大突破（breakout）

• Sprint3---"虎口余生（Hours to doom day）"

这个Sprint里面有很多技术难点需要破解，如果解决不了，那么后面的工作就无法进行，将是非常关键的一次攻坚战。

• Sprint4---"The Big End(大结局)"

这次计划会议，作为Scrum Master，因为有事没有参加，汗！大家认为我们的工作基本差不多可以做完了，起了个结局的名字。

• Sprint5---"The Dragon Warrior（神龙大侠）"

事实证明，我们上一个Sprint4过于乐观了，我们还需要一个Sprint才能完成所有的工作，包括Bug Fixing，文档等等。。。。正好那期间播放《功夫熊猫》，在sprint4结束后，大家提议这次的Team Building就去看电影吧（嘿嘿，我们一直坚持每个Sprint结束，就搞一次Team Building,羡慕吧！ ）。。。。。电影归来，就把 "The Dragon Warrior（神龙大侠）"颁给了Sprint5

经过半年多的时间，项目A终于顺利结束了！


其实，在项目A开展的同时，我们随后又Kick Off了另外一个项目B，我还是Scrum Master，但成员有所变化。基于项目A中对Sprint起名字得良好实践，我们为项目B中的Sprint也起了名字，看到名字，大家自然就会联想到007、奥运等等。。。：）

• Sprint1---"Golden Eye" 《黄金眼》

没啥特别意义，大家觉得项目A用了《加里森敢死队》，这个就用007系列好了

• Sprint2---"Live and let Die" 《生死关头》

因为需求太不明确了，大家也不知道能不能做下去，表达了一种不甚乐观的情绪。。。。事实证明大家的感觉是对的，我在Sprint进行一般的时候，终结了这个Sprint，因为真的做不下去了：）

• Sprint3---"You only live twice" 《择日而亡》

继续的不乐观，但我们最终还是Live下来，大家想表达的是：我们不能再Fail掉这个Sprint了！

• Sprint4---"The Matrix Revolution" 〈矩阵革命〉

情形不错起来，大家心气又高了！决心做一次大的改变！

• Sprint5---"One World One Dream"

奥运月，没什么可说的，与时俱进！

这个项目B还会持续到明年才能结束，我们会一直坚持下去这个实践的！

总结一下，在Scrum开发模式下，为Sprint起名字还是挺有艺术的，也是很有好处的：

1. 增加软件开发的乐趣（不是一直说，软件开发就是协作游戏嘛！）
2. 提高大家的参与程度
3. 记录Scrum Team当时的心情

阅读详细......

[修改于Pipin版]从美式Scrum说起 (一家美国公司的Scrum敏捷项目记要与思考)

朋友Pipin发表于《程序员》08年8月刊杂志上的文章，写的非常好，这里做了些许的修改，共享给大家！

---------------------------------------------------------

从美式Scrum说起

一家美国公司的Scrum敏捷项目记要与思考

许舟平

2008年7月16日

引子 敏捷是一个过程

从计算机诞生的那一天起，如何编写最符合用户要求的代码就一直是每一个软件开发者所追求的目标。随着计算机应用领域的不断扩大，人们对软件的需求量和功能性要求不断增加，并且迫切需要缩短软件开发的周期。软件危机的到来孕育了软件工程学在1968年的诞生，计算机软件从原来面向的科学计算走到了人民大众的日常生活中。当软件产业已经向服务业靠拢的时候，软件工程也在向着需求工程倾斜着。当客户需求的变化和软件开发模式的固有矛盾相遇时，敏捷开发就从软件工程学中诞生了。

敏捷是一个过程，敏捷开发实际上是根据软件特性和用户需要的敏捷价值观，通过遵循敏捷的原则来进行软件开发的一系列过程的集合。笔者前些日子接触了一个国外运用敏捷开发的项目实例，现在拿来和读者分享，希望能对中国的敏捷开发者有所帮助。

项目背景

美国公司A是一个典型的在硅谷诞生的软件公司，以技术为导向，产品很新，更新速度很快，销售渠道稳健、高效，在销售产品的同时可以有效的把握好客户需求，并能将客户需求趋势反馈给开发团队。项目背景是在通过公司前几个产品将市场打开之后，公司急需推出一个全新版本V，能够将早期的几个产品integration到一个平台之上，并通过客户的需求反馈做产品功能的增删和Bug Fix。开发团队分为二个Team，Team1负责构建一个全新平台，用来integration原有产品；Team2负责进行原有产品的bug修复和根据客户需求变更所做的程序模块改动；Team人数分别在8至10人，项目周期以月而记，分为3个周期，采用Scrum模式来做敏捷开发（Scrum是一种寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进）。项目的风险在于：1.项目开发时间紧，要求在3个月内完成开发阶段工作；2.team1和team2在各自的Scrum开发周期内要完成功能联调和集成，需要并行工作；3.产品测试部门采用外包方式，测试人员在国外，而产品质量必须得到保障。

之所以采用Scrum，是因为Scrum方法将传统开发中的分析、设计、实施视为一个黑箱，认为应加强黑箱内部的混沌性，使项目组工作在混沌的边沿，从而充分发挥每一个程序员的创造力。下面就让我们通过Scrum的方法论来深入解析Team1和Team2的开发过程。

项目组织

在公司A中，分别由二个资深的项目经理来担当每个小组的Scrum Master角色，每个Scrum Master来负责本小组中的人员协调和项目组织工作，他们的真正工作职责并不仅仅是传统意义上的Project Manager或Team Leader，其最主要的工作是使各自所在小组内的工程师有充分的交流。每个小组都是由不同专业的人员组成，其中包括了程序开发人员，UI设计人员，文档人员等。Team1小组人员的划分是按系统层次导向（按体系结构中的分层），Team2的划分则是按功能导向（即按所分配的问题包或Backlog）。

图一：Scrum流程示意图

在项目的初始阶段，Team1和Team2的Scrum Master分别将各自负责的产品功能要求（注意：那时的产品功能并没有得到细化）、用户改进建议、技术升级等任务安装优先级排序形成一个Backlog列表，而后将Backlog列表中的各项按照其耦合性的高低分解称为不同的问题包Packets，并根据不同的问题包Packets来划分相应负责的开发人员，并由他们建立开发运行环境。在这个阶段笔者注意到了一个有趣的地方，那就是在项目设计阶段并没有一个传统意义上的架构师Architect角色。这省却了在传统的开发模型中概要设计和详细设计的时间，但并不意味着没有系统设计和文档，稍后会做介绍。而没有Architect的另一个好处是team中的每一个程序员都分担的Architect的作用，对于中国做敏捷开发的团队，由于传统的Architect存在着固有的领导思维意识，并且经常是由Team Leader或者PM来兼任，所以尽管运用了敏捷开发的方法，但却不能起到真正调动每一个程序员创造力的作用。而在美国，这种情况基本不会发生。

项目进程

经过了项目初始阶段的确定性过程后，项目进入了经验性过程的Sprint阶段。顾名思义，Sprint即为冲刺，运用在Scrum敏捷开发中的Sprint阶段就是在项目初始阶段确定了系统体系结构之后，在一段的限定时间内所完成的一系列开发活动，其中包括在前一个阶段可能没有做完的产品功能细化、设计、编码、单元测试等工作。在项目V中，Team1和Team2分别分解了3个Sprint周期，每个周期为4周，在第3个Sprint周期开始时要保证Team1和Team2完全可以并行工作和可以进行联调。一个Sprint周期结束之后即要完成在该Sprint周期中所规定需完成的Backlog项，并产生可执行的版本。对于开发人员来说，在每个Sprint周期中，他们都需要完成对所分配的Backlog工作进行分析、设计、开发、实施、测试和文档化等工作（在项目V中Team1和Team2的开发人员采用Wiki代替传统软件工程的文档管理）；在完成这些后，通过打包来封装Packets，从而产生满足各自Backlog需求的可执行版本，然后通过评审（Review）和回顾(Retrospective)，提出和解决开发中遇到的问题，并增加新的Backlog项，进行项目风险评估和相应对策，从而确定下一个Sprint的Backlog内容和完成时间。在每个Sprint进行过程中，每个Scrum Team都会通过Daily standup meeting进行沟通，交流遇到的问题，互相帮助。

当项目V进入到最后一个Sprint周期时，Team1和Team2中负责Integration接口模块设计的开发工程师将与QA人员一起进行系统联调，并由二个小组的Scrum Master在每个礼拜一下午召开Scrum Meeting（如图2中所示），来讨论系统需求变化和Bug修复情况。由此根据这个跨Scrum Team的Meeting的情况实时做出Backlog项的调整和从新分配。然后再进行打包封装交给QA人员进行测试。这个周期非常短，可能二、三天甚至一天就会有一个新的版本出现。

在这个过程中，公司A开发工程师的单兵作战能力给笔者留下了很深刻的印象。比如Team1中UI设计师具有10多年的专业设计经验，仅凭一己之力就完成了Team1中所有的界面模块设计和调用接口工作。项目中的每一个工程师都在系统建模、设计、开发环境部署、程序打包上拥有丰富经验，实际上他们已经分别完成了在传统软件工程中系统架构师、Coder、Tester和Build Manager等工作。与他们相比，国内软件公司处于的一线软件工程师大多属于拥有2-5年工作经验这一经验积累阶段，在个人技术的确存在差距，这种差距在某一方面导致我们国内的软件厂商在相似的开发项目上，同样运用敏捷开发方法，却不能充分达到一个良好的效果。这也与我们的国情有关，想想10年前老一辈的程序员，有多少现在还战斗在开发的第一线呢？不过没有关系，中国的软件产业正在慢慢成熟，一个充分良好的开发环境会让越来越多的程序员迅速成长起来，毕竟我们从事软件开发人员的基数是不可小视的。

图二：处在Sprint冲刺阶段的项目示意图

项目成果

在Scrum过程中会认为软件产品的开发是一个持续性过程，除非该软件产品经风险评估后认为可以停止。通过一系列的Sprint阶段，项目V会产生一个稳定可靠的版本交给公司的Release Manager。而处于Scrum过程中的最后阶段――软件产品交付后的巩固活动则近似于传统软件工程中的系统维护和改善工作，其目的在于整理Sprint阶段中由于压力而忽略的工作，为下一个Sprint阶段的开发做准备，以便轻装上阵。

思考：敏捷，不仅仅是敏捷

在中国软件公司的敏捷开发项目里，对比于国外，有着许多影响敏捷开发但又在敏捷开发理论以外的东西。比如开发者经验的不同，开发环境的不同，软件开发公司的管理状态等等。笔者接触过国内的很多软件企业的开发团队和项目管理者，不可否认的是，中国的软件开发在很大程度上一直处于长期借鉴国外软件开发的模式。而在借鉴的过程中，形似而神不似的情况屡屡出现，很多时候，我们只是将国外的开发模式照搬过来，并没有根据中国软件业特有的国情和我们的开发者实际情况作出合理的调整。比如当年CMM火热之时，国内的很多公司都投入巨大的人力物力来做评估，来搞文档管理和过程控制，可是到头来除了取得一纸证书以外并没有给软件产品带来本质性的提高，软件开发效率和质量依旧一塌糊涂，Maintenance team每天还是要不断的应付客户反馈回来的bug和投诉。而对于敏捷开发来说，希望国内的项目管理者能够抓住敏捷开发的精髓，让我们的软件能够真正的敏捷起来。

阅读详细......

[Scrum工具]推荐一本好书---《硝烟中的Scrum和XP》

这是小刀同学的力作，翻译的真好！希望能很快正式出版！

作者 Henrik Kniberg译者 李剑 发布于 2008年7月7日 上午4时45分

在本书中，作者Henrik Kniberg讲 述了他在一年的时间里，带领40人的团队实施Scrum的过程。他们试过了多种团队尺寸（3～12人）、sprint长度（2～6星期），定义“完成”的 不同方式，不同的backlog格式，各种测试策略，在多个Scrum团队之间进行同步的多种方式。他们还尝试过XP实践——持续集成、结对编程、测试驱 动开发等等，还试过了把XP跟Scrum组合。

本书描述的是一个成功敏捷团队的工作过程，没有理论、没有引用、没有脚注、没有废话。读者可以把它当作一些基础实践的入门指南，帮助团队进行正确实施——但不能模仿，你需要了解自己所处的环境，进而对具体实践做出取舍，创造出属于自己的过程。

本书目录

1. 简介
2. 我们怎样编写产品backlog
3. 我们怎样准备sprint计划
4. 我们怎样制定sprint计划
5. 我们怎样让别人了解我们的sprint
6. 我们怎样编写sprint backlog
7. 我们怎样进行每日例会
8. 我们怎样进行sprint演示
9. 我们怎样做sprint回顾
10. Sprint之间的休整时刻
11. 怎样制定发布计划，处理固定价格的合同
12. 我们怎样组合使用Scrum和XP
13. 我们怎样做测试
14. 我们怎样管理多个Scrum团队
15. 我们怎样管理地理位置上分布的团队
16. Scrum master检查列表
17. 额外的话
18. 有关作者

有关作者

Henrik Kniberg（henrik.kniberg@crisp.se）是一名咨询师，在斯德哥尔摩的Crisp公司（www.crisp.se）工作。他的专长是Java和敏捷软 件开发。

自从第一本有关XP的书籍和敏捷宣言问世以来，Henrik就开始拥抱敏捷原则，并尝试在不同的组织中进行有效应用。在1998年至2003年间， 他作为Goyada的合作创始人和CTO，构建并管理一个技术平台和30人的开发团队，充分试验了测试驱动开发及其它敏捷实践。这个网站上有他的更多信 息：http://www.crisp.se/henrik.kniberg

免费下载此书

硝烟中的Scrum和XP（ 免费下载这本书（PDF） ） 免费下载这本书（PDF）

原文 www.infoq.com/cn/news/2008/07/scrum-xp-book

阅读详细......

敏捷精灵日记21

[敏捷精灵日记]

• 人才的流动是非常正常的事情,否则,社会也无法前进.但对于一个企业或者一个团队而言,人才的流失会是一种损失.流失人才并不可怕,最可怕的是领导人没有从中学到什么,没有搞清楚人才为什么会流失,没有采取亡羊补牢的措施.长此以往,招到的人才,还会不断的流失。

阅读详细......

敏捷精灵日记20

[敏捷精灵日记]

• 尽管一个组织必须重视管理人员成长可能性并通过提供更大的发展空间等手段来激发他们的潜能，但彼得原理可以作为一种告诫：不要轻易地进行选拔和提 拔。解决这个问题最主要的措施有三个：第一，提升的标准更需要重视潜力而不仅仅是绩效。应当以能否胜任未来的岗位为标准，而非仅仅在现在岗位上是否出色。 第二， 能上能下决不能只是一句空话，要在企业中真正形成这样的良性机制。一个不胜任经理的人，也许是一个很好的主管，只有通过这种机制找到每个人最胜任的角色， 挖掘出每个人的最大潜力，企业才能“人尽其才”。第三，为了慎重地考察一个人能否胜任更高的职位，最好采用临时性和非正式性“提拔”的方法来观察他的能力 和表现，以尽量避免降职所带来的负面影响。如设立经理助理的职位，在委员会或项目小组这类组织中赋予更大的职责，特殊情况下先让他担任代理职位等等。

• 成功企业的用人之道包括：
  • 适当引进外来人才，好处就是用现成的人才，避开“彼得原理”所涉及的后果；
  • 在企业内部逐步提升，重视潜力，重要的职位大多数由所能胜任的人。

阅读详细......

敏捷精灵日记19

[敏捷精灵日记]

• 招聘员工准则： ‘hiring for attitude，training for skills’，即‘聘之以态度，授之以技能’
• 培养员工准则：品德好、能力强的是精品；品德好、能力差的是次品；品德差、能力强的是毒品；品德差、能力差的是废品。精品要破格培养，次品要加紧培训，毒品要利用，废品要丢弃。而这些都以品德好为基本前提。
• 团队建设的生命周期准则：
  1. 选择合适的人才
  2. 设立清晰的愿景、明确的目标
  3. 合理用人。人尽其才，才尽其用，充分发挥每个人的优势。
  4. 建立良性竞争机制
  5. 建立奖惩与监督制度
  6. 建立完善的培训系统，关注员工的个人发展
  7. 评估并不断改进团队
     
• 领导力应该体现在他的影响力上，而不是依靠组织赋予的Position Power
• 用心去领导。要去了解团队每一个成员的需求与渴望，去跟他们进行心与心的沟通！按照马斯洛的需求层次理论进行针对性的激励。
• 根据情境去领导（Situational Leadership）。没有最好的领导力，只有最适合的领导风格，管理者要根据员工不同情境灵活调整自己的领导风格和领导型态。

阅读详细......