项目管理沙龙第十一次聚会纪要--当敏捷没有共识的时候
“深宪琪中”通过精心收集，向本站投稿了3篇项目管理沙龙第十一次聚会纪要--当敏捷没有共识的时候，今天小编在这给大家整理后的项目管理沙龙第十一次聚会纪要--当敏捷没有共识的时候，我们一起来阅读吧!
篇1：项目管理沙龙第十一次聚会纪要--当敏捷没有共识的时候
本来这次聚会要讲一下项目管理的流程概貌，同时对第一个阶段进行一次试探性的深入探讨，可惜这次缺席人数太多，变成了“锵锵三人行”，原定想要谈的内容，也就弱化了。其实每周一次的沙龙，并不需要太多的负担，就当是每周一次的茶会吧，大家紧张了一整周，放松个90分钟，也是应该的。
不过“三人行必有我师焉”，只要有意愿，肯定能够谈出新话题来。
今天分享的知识是“Dreyfus模型”，全称是“Dreyfus技能获取模型(Dreyfus Model of Skills Acquisition)”，是两兄弟研究人工智能时候得到的成果。这个模型把人对知识的学习过程分为几个阶段：新手(Novice)、高级初学者(Advanced Beginner)、胜任(Competent)、精通(Proficient)、专家(Expert)、大师(Master)。这六个学习过程中，新手到胜任的过程基本是线性的过程，但是之后的过程就是非线性的了，每一个过程的进阶都是一个质的飞跃。这个也就能解释为什么小孩子通过“幼小初高中大学”的学习就可以学到和大人差不多的知识。
Dreyfus的六个阶段的主要特点如下：
1.新手（Novice）： 需要详细的指导，要手把手地教，并且新手分不清重点。
2.高级初学者（Advanced Beginner）： 熟悉基本步骤，能够单独完成任务，且觉得自己学得不少了。简历上的“精通”就是从这个阶段开始出现的。但是一旦任务遇到难点，他们就搞不定了。
3.在胜任（competent）： 他们可以分解目标和组合一系列任务以达成某个目标，但是通常这些组合不是最佳的。他们也能初步做一些指导工作，并很讨厌被人指手画脚地指挥。大部分人都处在这个阶段，他们大多不想再投入精力改进，而只想完成工作而已。
4.在精通（Proficient）： 能够给出成型的并覆盖主要细节的解决方案。已经能够将知识和经验结合，开始喜欢谈“哲学”和“方法论”。并且在继续学习中领悟更多。
5.专家(Expert) ：有自己解决问题的方法论。依靠直觉和自发工作，在他自己的领域中很少犯错误。喜欢和其他专家交流来提高自己的能力，更加谦虚和低调。
有趣的是，处于初级阶段的人们倾向于过高估计自己的能力，而在较高阶段的人则更加谦逊。
模型特别指出，大部分人都很难超越“胜任”这个级别，
由此可见，那些满天飞的简历里边的“精通”两字是多么幼稚和可笑。
我们的话题谈到了一个没有共识的团队如何逐渐推行敏捷方法的问题。这个是非常普遍的需求，如果需要用另一种方式来描述这个问题的话，就是“如何让敏捷快速见效”？初步的意见就是一些常用的敏捷实践需要立刻实施，因为他们能够解决实际的问题。
1. 最容易开始的就是“每日例会”，它可以即刻解决项目组沟通不畅的问题，让项目经理不再需要询问任务的进度，团队其他成员也不再需要每天填写工作日志。
2. 其次就是backlog的编写和评估，初期可以让项目组自由评估，等到出现问题之后，逐渐改进到用point评估和计算投入时间。
不过这个话题没有深入，但是我们约定下一个聚会就将此作为讨论话题，并且为某个项目组量身定做一个实施计划。
目前到了年底，项目组要么很忙，要么很闲。忙还好办，但是闲就不好办了，所以这个时候需要项目经理更多地去安排一些轻松的任务，最常见的就是安排一些共同学习。而且架构师要去深入地思考一下架构的问题。对于定制交付类型的项目，架构问题还不是很突出，而且很多都已经有了成熟的架构方案，借鉴一下就可以。但是对于产品型的项目，架构就很重要了，而且基本是从无到有的搭建，所以设计就非常重要。就拿EAS来说，简单的CRUD操作定制起来会爽的不得了，但是一旦有了特别的定制，结果就会很难受，有人举例说客户拍着桌子骂人：“你们修改一个标题要10天吗？”
一个不当的设计，很快就会成为生产力的阻碍。很多老板重商务轻产品，无可厚非，毕竟商务会带来现金流，可是有没有人想过，一个没落的产品能够带来什么？有人说一个好的产品能够创造一个新的市场，真的是这样，比如第一个做MQ产品的，第一个做ESB产品的，第一个做数据库产品的，无一例外都生成了一个新市场新领域。
因为话题比较自由，我们谈到了年龄和时间。有人谈到了他一贯的观点：女朋友的年龄=自己的年龄/2+7，然后如果交往顺利的话，就在第18个月的时候结婚，因为这个时候互相的了解已经足够，并且新鲜感没有褪去，一旦时间过长，互相依赖成了一种习惯之后，比如那些在一起5、6年的情侣，越往后结婚的概率越低。从项目管理的角度去看，不仅浪费时间，而且明显风险过大。
浪费时间是可耻的！
（部分关于人生、时间点的内容不想写了）
参考文献：
1. 更好的最佳实践 www.infoq.com/cn/articles/better-best-practices
2. 如何从小工到专家——Dreyfus模型应用 gurudk.iteye.com/blog/324204
3. Dreyfus模型和最佳实践 blog.sina.com.cn/s/blog_493a84550100c8vz.html
篇2：项目管理沙龙第十二次会议纪要--为没有共识的项目组定制敏捷方法
本次会议的主题是为没有敏捷共识的项目组定制一个敏捷的实施方法，这是一种普遍存在的情况，和其他的新事物一样，总会有一些人对“敏捷”这两个字比较敏感，究其原因，无外乎偏见、误解和不了解（无知），部分人则是恐惧或自大。当然，不了解是绝大多数人的原因。
但是，面对“没有共识”的人们，到底是说服之后再实施敏捷呢，还是先实施敏捷再用实际效果展示给他们？这是一个问题。我们倾向于后者，即先实施让人们看到效果。理由很简单，因为人与人之间的知识和经历的差异很大，要全部说服的时间成本太高，甚至于不可能，如果面对是一个有一定经验的人，要想说服他抛弃原先的经验来接受一个新事物，难度恐怕会更高。所以，“暗渡陈仓”或“偷梁换柱”地实施敏捷，是一种切实存在的需求。如果要给这种方法安装一个冠冕堂皇的名字，那就是“传统的项目管理方法到敏捷管理方法之间转换与过渡”。
之所以我们要探讨这种情况，因为我们坚信“敏捷不会把事情变得更糟”，既然敏捷肯定不会“砸场子”，肯定“效果>=现状”，所以“暗渡陈仓”就是有价值的，也是可行的一种推广方法。
我们的目标项目组情况是这样的：团队成员之间技术水平差异较大，但是工作热情高涨，气氛较好，而且项目组感觉“陷入泥潭”已经很久了，看着一堆难以维护的代码，大家都有一种想要改进和突破的渴望。但是团队的关键领导之一对敏捷的态度比较暧昧，不支持也不反对，但对敏捷始终保持着足够的距离，既不拒绝，也不欢迎，更不去深入了解。在管理方法上，项目组采用月计划和周计划相结合的管理方法，即每月定一个计划，本周的计划细化到可执行。但是可想而知，管理比较混乱，计划也经常不准确。
面对这样的项目现状，我们首先讨论的是实施策略：
1. 绝口不谈敏捷两个字，也不谈敏捷相关的什么术语，避免反弹。
2. 选取敏捷方法中最有价值的几个行为，改良项目组的管理现状。
3. 在达到效果，取得大家的认同之后，全面实施敏捷方法。
经过讨论，我们总结出的敏捷成功的要素有如下几个：
1. 管理上的PDCA循环。通过Plan-Do-Check-Adjust形成一个不断改进的循环。
2. 工作的可视化。通过将工作以可视的形式展示出来，让团队对进度有切身的感受。
3. 任务的定量化。所有的任务在阶段开始前就已经定好，一般不再改变。
4. 沟通，
定期、按需沟通，保持信息流转的顺畅。信息包括：任务，进度，问题等。
5. 团队工作。团队的每个人都知道所有的事情，了解一致，当然就没有歧义。
事实上，敏捷的这几个要素纳入到任何一种管理方法中，这种方法也就立刻符合了“敏捷”的规范，因为“敏捷”本身就是一种“价值观”，在同一个价值观下，可以有N中不同的方法。“老酒”兑“新水”自然也是可以的。
讨论之后的具体实施方法如下：
1. 沿用原来的“月度计划”和“周计划”结合的管理方式。 用敏捷术语就是一个“迭代”长度为1月， 但是考虑到一个月时间太长， 不容易出效果， 所以在每个月的15日加入一个局部总结会议。 实际上把一个月分为上下两个半月，即2周一个迭代。这个也是目前公司敏捷经验中推荐的初期迭代长度。
a) 每月月初开“每月例会”，内容就是规划本月的工作， 并且将工作细分为可分配的任务， 颗粒度粗一点没关系， 但是要保证一个月够用， 不需要中途再加。 例会上所有的工作都要进行讨论， 保证大家都对工作没有分歧， 其次要对每个工作进行评估，评估的单位采用传统的“工作日”。 只有所有工作都进行了评估， 才能评估任务的进度。
b) 每月15日左右开“月中总结会”，负责总结一下上半月的工作情况， 讨论改进措施， 并根据进度，酌情调整下半月的任务进度安排。
c) 每月月末召开“月度总结会”， 负责总结整月的工作情况，并讨论改进。 月末总结会议一般不要和月初的例会合在一起开。
2. 开始实行每日例会。会议上监控如下的几个问题：
a) 每个人当天的工作状况是否都已经更新
b) 对停滞超过2天的工作要询问原因，可考虑进一步细化和分解。
c) 鼓励在例会上交流，慢慢形成交流的气氛。
3. 所有的工作和进度，在白板或者wiki上展示，统一管理。
a) 初期的工作任务描述可以简单，但是要在计划和总结会议上形成口头共识，防止歧义。 在实施过程中逐步精细化，慢慢达到敏捷对Backlog的要求。
b) 暂时不考虑使用敏捷工具，避免反弹。
在实施过程中，还有一些技巧需要酌情使用：
1. 任务评估由具体执行人给出评估时间，然后乘以相应的系数，作为实际的任务期限。
2. 某些需要形成共识的地方，可以故意引导对方出错，然后给出相应的正确方法。 比如代码难看难维护， 可以先采用“每周代码show”的方式， 逐渐形成集体对代码质量的重视， 达成共识之后，进而引入“代码评审”的方法。
接下来的沙龙时间里，我们会持续跟踪这个方法的实施效果。
考虑到目标项目是真实的项目，为了保证实施的隐蔽性，本次沙龙会议纪要仅在沙龙成员和特邀嘉宾内部发布，请勿外传！
篇3：项目管理沙龙的第一次聚会纪要：项目管理和敏捷
会议的主题是项目管理和敏捷，敏捷是近几年的热门话题，也是最让人误解的名词了。
有人在会上提了这样的例子：
两个人A和B爬山，B不管三七二十一，直接上山朝目的地行进，结果半路遇到没路，就折回来再重新走一条路，这个就叫“敏捷”。而A呢，先绕山走了三圈，制定出一个完美的计划，并且进行风险评估，设计应对方案，然后还划出几个里程碑，最后开始实施，到了山顶，人们叫这个为“瀑布式项目管理”。并且现在都认为B会先到目的地。
这个例子引起了大家的反对。并认为最早写这个例子的人肯定不懂敏捷。相比而言，其实敏捷更重视计划和阶段的划分，而且在过程跟踪上的力度也比传统方法要紧密。
这就提出了“什么是敏捷”的话题。
有人首先强调了敏捷方法和传统的指令式项目管理方法在目的上的一致性，就是以达成项目目标（进度、成本、质量、团队等）为目的。但是他们是两种完全不同的解决思想的产物。
传统的项目管理方法首先普遍认为员工是一种需要用严格约束来驱动他们工作的，而监管他们的人就是项目经理。几乎所有关键的项目工作压力都集中在项目经理身上，由PM进行任务的分解、评估、工作分配和任务跟踪，还需要对过程数据的收集和评估等，当PM出现差错、懈怠或者不胜任的时候，项目就会陷入混乱和停滞。在团队氛围上，普遍士气不高，没有明确的团队激励机制。
但是敏捷方法采用的是相反的思想，他们首先强调的人的因素。希望通过充分调动人的积极性，将项目管理的职责分摊到每一个人，每一个人在履行自己的工作承诺的同时，也参与项目组的所有管理工作。通过持续的“计划-实施-检查-改进(PDCA)”工作循环，保证团队和参与的每一个人都得到提高。敏捷方法的主要激励机制是“成就感”，所以团队氛围普遍较高昂。在BPM和AOM的SCRUM实践中，有明显的感受。
另外有人举了例子：
一个人A在早上八点准备从深圳出差到北京，但是到机场的时候误点了，于是他就上了一辆taxi，让司机B开车去北京，并且要求中午就要开到。
很明显这是一个很过分的要求，深圳到北京这么远，很明显不可能4个小时到达。用数学公式来解释，就是“速度×时间”远远小于了“距离”。所以这个是一个不可能完成的任务。
但是把同样的场景放到软件开发项目中，却有不同的结果：客户A要求在某个期限内完成项目，作为项目经理的B很可能就答应下来，但是结果要么是无法完成，要么就是完成质量不高，导致后期返工。
目前最常见的问题是项目组无法评估项目的规模，也不知道项目组的实施能力，从公式“距离=速度×时间”来看，项目组当然也就无法评估项目结束所需要的时间了。面对客户的无理要求，这样的乱答应也就毫不奇怪。
通过过程数据收集和评估，来获取项目的实施能力、规模、质量、进度数据，是项目经理的一项重要工作。但是在传统的项目管理方法中，实施起来并不容易。一般要达到CMMI3或4的企业才能达到这样的能力，但是通过SCRUM方法的实施，在前两个迭代之后，就基本可以获得这些数据了。
为什么实施SCRUM之后就可以短时间内做到？这个是沙龙中提出的又一个问题。实际上敏捷采用的管理策略是一种“人民战争”的策略，通过发动“群众”，提高大家的主动性，平等和积极地参与项目的日常管理，
有这么多人，通过每日例会和其他的频繁沟通，来平等获取项目的各种信息和状态。这样当然比传统的一个项目经理单打独斗要有精力，而且更细致，更全面。更重要的是项目组员获取的“任务”，基本都是自己感兴趣的甚至就是自己发现的，工作干劲上是传统项目管理手段所不能达到的。
所以“敏捷”的管理力度更强、更深入、全面和细致。而且从实际来看，敏捷的项目管理者并不需要拥有比传统方法的项目管理者更高的能力，相反还更轻松一点。
讨论中并不是所有人都认可敏捷。实际上SCRUM中的做法不是什么新发明的，都是传统项目管理中已经大量应用的技术，比如需求的功能点评估，项目过程数据收集和评估，设计方法等，项目管理过程中只需要坚定地朝项目目标前进，只要是好的方法都可以拿过来实践，我们就可以在SCRUM的基础上来发展出一套符合自身特点的敏捷过程。传统的项目管理方法也可以采用敏捷的一套做法，慢慢把自身敏捷起来。
不过有人立刻就此观点提出了异议。从公司目前两个项目组的SCRUM实践经验可以看到，敏捷过程（至少是SCRUM方法）中充满了一些隐喻的做法，比如评估point和评估hours并行进行，相互印证；比如backlog打分过程的知识传递和博弈；比如每个迭代的“计划会议-每日例会-回顾会议”这个PDCA的循环过程；比如Team Work的团队责任原则，等等。缺少这些基础的价值观，“敏捷”就不再是敏捷了，而不纳入这些价值观，传统的项目管理方式也永远不能“敏捷”起来。
当然，敏捷方法也有自身的缺点。首先一个就是缺少一个人去关注全局，关注架构。但是很快有人提出，敏捷只是一种项目管理方法而已，把这个缺点说是敏捷的缺点也有点牵强。继续讨论之后，我们发现在实施敏捷的时候，还是不能忘记每个角色的分工和侧重点，虽然号称是“平等”，但是架构师依然要多关注架构，测试工程师也依然不能忘记产品的“可测试性”。
敏捷的初衷就是要抛弃各种条条框框，所以敏捷实施过程中，也并不存在什么“必须”去做的方法，哪怕是敏捷的核心价值观，也没有什么固定的做法。灵活是敏捷的表现，但是“灵活”并不等于“粗糙”，事实上敏捷就是拒绝“粗糙”的，我们要看到敏捷的“灵活”背后所蕴含的“细腻”的各种实践。我们在去看《敏捷宣言》：
敏捷软件开发宣言
agilemanifesto.org/iso/zhchs/
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，
我们更重视左项的价值。
可以看到，所谓的“敏捷”方法，就是秉持敏捷理念的项目管理方法。
但是在敏捷的实施过程中，并不都是一帆风顺的。一个流畅的敏捷管理过程，机器的辅助是相当重要的，比如关键的“持续集成”。
总结
虽然这次讨论的主题是“项目管理和敏捷”，但是话题涉及到了项目管理的很多方面。会议气氛热烈，有很多精彩之处，个人比较满意。但是因为是初次沙龙，所以会议话题有些分散，有些同学希望主题能够更加明确一些。
期待下次更好。
【项目管理沙龙第十一次聚会纪要--当敏捷没有共识的时候】相关文章：
文档为doc格式