当前位置：首页 > 范文大全 > 实用文>项目管理沙龙第二次聚会纪要

项目管理沙龙第二次聚会纪要

2024-04-25 07:49:16 收藏本文下载本文

“park”通过精心收集，向本站投稿了8篇项目管理沙龙第二次聚会纪要，下面小编给大家整理后的项目管理沙龙第二次聚会纪要，欢迎阅读!

项目管理沙龙第二次聚会纪要

篇1：项目管理沙龙第二次聚会纪要

本次话题依然集中在敏捷方法和传统项目管理的问题上，在两次聚会之后，一些概念正在渐渐地清晰，

有人提出，如果传统项目管理方法将敏捷的一些做法接受过来，是不是也会变得敏捷起来呢？在讨论中大家发现敏捷的一些做法原本就是早已存在的一些通用的做法，例如头脑风暴、集体评估story的点数、定期的回顾总结、团队工作等，这些做法传统项目管理方法也在做，但是为什么效果不如敏捷呢？关键还是在于敏捷和传统方法的本质区别：后者认为人是需要监管的，需要一个项目经理去监督他们，不让他们偷懒，并需要别人指导项目组成员如何去工作；敏捷的理念正好相反，它认为人是可以激励的，项目组成员天然就有一种保质保量完成任务的愿望，管理者只需要引导他们。从实践来看，用传统方法管理项目，始终无法做好项目规模的评估和进度预测，但是在使用敏捷方法的两个迭代内就可以轻松得到，这个也是我们敏捷实践中得到的最让人惊讶的成果。

传统的项目经理需要很高的能力，他们首先需要能够准确评估每个任务的规模，其次需要及时跟踪项目的进度，还需要收集项目过程中的数据，以便进行评估和预测。另外，他还需要和客户沟通，确保需求的稳定或及时提出需求变更请求，然后定期填写一大堆的报告和表格，向不同的人报告 ... 。有人认为敏捷方法对项目经理的需求比传统的方法还要高，而且这么“高”的项目经理几乎是不存在的。可是只要去回顾实际的敏捷实践过程之后，我们就会发现情况恰恰相反，敏捷方法对项目经理的要求是降低了。实践中我们一个之前没有项目管理经验的人，在敏捷团队的项目经理位置上做得很好。如果我们深入地思考敏捷管理方法，就会发现敏捷团队的管理任务其实是分散到了每一个成员的身上，敏捷和传统管理方法相比，就像是拿“分布式计算”和传统的“单机运算”相比，结果也当然是一样了。敏捷的项目管理力度其实比传统的指令式项目管理方法要高，但是平均到每个人身上的管理任务却比传统的项目经理一个人要低很多，

这不正是我们经常谈论的“负载均衡”吗？

与会的嘉宾们一致同意敏捷的一个缺点，就是容易“只见树木不见森林”，认为敏捷团队中依然需要有设计师这样的角色去关注整体架构的实现和演进。

在谈到人员能力问题的时候，我们提到了“检查表”。大部分人都没有关注检查表这个东西，而事实上，检查表是一个公司管理能力的直接体现。一个管理稳定的公司，必定有很多“检查表”在支撑整个公司的运作。简单地通过“检查表”的形成过程，我们就可以了解到这个“检查表”的价值所在。首先公司在实践中得到的经验，会以检查表的形式沉淀下来，并且在实际使用过程中，会逐渐地改进，所以一个公司的检查表肯定是最贴合这个公司实际运作的（因此检查表拿到其他公司去也用处不大，这个也是检查表不为人所知的原因之一了），随后，检查表的使用者只需要直接对照表格内容进行实施和检查，最终就可以把事情做完，或者得到一个评估结果。而且，我们可以看到，检查表的使用者其实并不需要是专家，只要不是文盲就可以了。专家在设计完检查表之后，可以去做别的事情。

最后，我来谈一点沙龙本身的问题。

本次沙龙的缺席率比较高，没有通知就缺席的人数有两位，也许是国庆长假即将到来的缘故吧。但是还是引出两个问题，一个是共同话题如何提炼，第二个是如何让这个聚会对大家产生实际的作用。但是归根到底有一个问题需要首先解决，那就是需要激情和耐心。沙龙不会承诺给大家什么东西，“师傅领进门”，“修行”都要靠“自身”，何况一个小小的沙龙呢，它只是一个交流场所而已。

对于共同话题的提炼问题，我认为还是需要沙龙参与者之间的频繁交流，要么是BBS，要么是即时通讯会议，或者干脆碰头几分钟也可以，实践中使用邮件讨论的方式证明效率太差，达不到双向沟通的效果。其次对于沙龙产生实际作用的问题，目前来看有如下几种：集体阅读，实际案例分析，提问。目前候选的图书有《项目百态：深入理解软件项目行为模式》，如果可以找到电子版，我们可以从中选择几个典型案例来讨论一下实际的应对方式。

篇2：项目管理沙龙第九次聚会纪要

前不久在腾讯举行了敏捷大会，但是因为加班或者报名的原因，沙龙里只有一个人参加了敏捷大会，所以本次聚会由夏勇分享参加大会的心得，

对大家印象比较深刻的首先是雅各布森给出的一系列敏捷卡片，我们拿到的这一系列卡片有四组，基本覆盖了敏捷过程的方方面面，对于敏捷过程的指导作用还是比较强的。所以我们决定接下来将这个卡片电子化一下，让每个人都可以看到。

QZone的产品经理的演讲还是挺让人感兴趣的，他号称是QZone每周五天可做到约二十次发布。在这种情况下，如何保证项目成果的质量稳定，是需要一定的水平的。QZone前台使用php，后台使用C++，所有模块集中发布。他们有一个专门的发布系统，可以做到“一键式发布”。他们在发布之前做的测试，只测试一些关键逻辑，小的地方就不测试了。QZone自己把这种发布形式叫做“灰度发布”。结合从会议上听到的消息，我们分析他的测试方法大致有如下几个：产品关键部分要做专门的测试；修改所牵涉的部分做简单的测试；使用招募的内测用户对系统进行在线测试；将用户群拆分，比如把某个二线城市的用户都切换到新版去用，跟踪他们的使用状态等。有人举了一个淘宝为世纪光棍节做系统压力测试的例子，因为要产生一个访问的峰值，所以淘宝发了一个优惠券让大家去抢，结果峰值自然就出来了。不过像QZone这样的测试，最小测试颗粒度都应该是User Story级别的，再小可能就太细太多了。

QZone在划分Backlog的时候，先定2～3个月的目标，颗粒比较粗，然后定每个sprint的目标，

我认为这种形式比较适合于那些开始时候需求不明确，需要在过程中不断挖掘需求的项目。在制定Backlog的时候，采用颜色将Backlog分类，比如数据界面的Backlog标为绿色，属于Bug的标志为红色等。这个办法值得学习。

敏捷会议上的另外有人提出了“轻敏捷”的概念，和与之相对应的“传统敏捷”相比，他抛弃了过程数据的收集，只看结果。其他经验的包括流程可视化，流程梳理，以及交流一定要面对面。

雅各布森讲了“如何做有效的Backlog”。大致就是说从项目干系人、蓝图、用户的变更申请等处得到Idea，然后把Idea整理成Use Case。Use Case要包含范围、场景描述等。再基于Use Case整理出可以Telling的Story。最后把Story拆分成一个个可以交付的Backlog。经过优先级排序、价值评估、风险评估之后，就可以将这些Backlog纳入到Sprint中去。

一个Backlog可以分成许多个Task，一个Task分配到一个人。在状态处理上，Task可以被Block，Backlog可以被归为impediment。Task的颗粒度要细分到保证能够在一天内完成。一个Backlog的所有的Task完成之后，称为Backlog的Complete，但是Backlog要从Complete到Done，还需要经过测试和验证才行。所以要注意所有Task完成之后，到Backlog的Done还是需要有时间的。另外，上一次Sprint没有完成的Task，要作为下一个Sprint中最高优先级的工作来做。

下一次聚会，我们请AOM讲一下他们的敏捷实战经验。

篇3：项目管理沙龙第八次聚会纪要

本次沙龙依然是NSEC的敏捷经验总结，这次依然谈到了客户与需求的问题。因为客户和开发组不在同一个地区，所以客户完全没有参与到项目的开发工作，所有的沟通都通过项目经理来进行。从开发人员的角度看，需求变化最大的问题是开发人员无法确定是否真的是对客户有用的。客户首先是自己有很多的想法，变来变去，PM也因为距离的关系，无法和客户面对面沟通，所以也就只能拍脑袋和猜谜语。结果开发人员心里没底，做不出成就感，心情自然也就好不起来。引出的问题就是：开发人员到底怎么办？

面对这种情况，经过讨论，大家认为首先还是要充分信任PM，但是PM也有责任去和客户充分沟通。这个时候，我们一直强调的“原型法”就会有很大的作用。原型工具可以有很多种，比如一连串简单的html页面，或者一个ppt演示。前者的好处是可以快速地完整演示一个流程，后者的好处是可以将一些用户界面效果也同时演示出来。总之，原型工具就是那种可以快速构建，快速抛弃的东西。非常适合用在客户需求不稳定甚至不成形的情况下。

实际上，NSEC的需求问题根源并不在客户，也不在PM，而是和其他大多数项目一样，缺少了一个角色，“业务分析师”，简称BA。许多项目的BA都由PM担任，或者商务人员担任，但是他们要么身兼多职，要么没有受过专门的业务分析训练，无法充分引导客户的需求，结果就造成了需求不明确，不稳定等问题。引用沙龙成员的一句话：程序员不反对变更，但是反对浪费！

BA的作用很重要，在敏捷结对中，BA的结对对象就是客户代表。他的工作就是负责引导客户，让他们的需求变得更明确，更稳定。原型法是一种很好的需求引导方法，就像我们一直强调的，“客户不知道自己要什么，但是明确知道自己不要什么”，原型法的作用就是让客户能够不断地否定自己的想法，最终形成一个明确稳定的客户想要的东西。这个也就是项目组梦寐以求的“稳定的”需求。其实BA的工具远远不止这些，“语法分析”也是BA的工作利器。根据客户所说的语句，将其划分为名词、动词、形容词和主语、谓语、宾语。根据每一个词语的特性，我们可以整理出一系列有针对的问题。一个有经验的BA，只要客户不断地开口说话，就会将客户的所有需求都问出来，

具体的方法，我们可以在以后的沙龙中详细探讨。

NSEC的另外一个问题是客户不定期不定时地要求项目组发布成果。针对这种情况，我们觉得自动化构建和上次谈到的UAT环境就很有作用了。这种问题的出现，根源其实还是在客户需求的不稳定上。当然，定期发布成果并让客户能够感受到进度的变化，也是非常重要的。

“没有验收标准文档”是另外一个NSEC的问题。从我们的角度看，这个是中国几乎所有项目的共同问题。理论上，我们会在中标之后对客户进行需求调研，然后把形成的需求规格说明书作为合同的附件，并以此作为客户验收的标准。实际上能够做到这种程度的项目几乎没有，即使做到了，这个合同附件中的需求也会在开发过程中不断地变更，最终变得面目全非。有经验的人肯定会拿出“变更控制”的办法来，可是实际项目过程中，有多少客户愿意每次需求变更都来签字呢？又有多少客户代表因为要签字就放弃需求变更呢？答案都是“很少”甚至“没有”。很多项目就是因为限制客户变更需求，或者变更需求过程中和客户经常产生不愉快，导致客户关系恶化，最终项目失败。这个也是“传统”项目和“敏捷”项目的最大的区别。

从敏捷的角度去看，项目组完全接受变更所带来的影响，但是所有的变更都不能影响当前正在进行的迭代过程，所有的变更最快也要到下一个迭代才能生效。但是真的有紧急的需求变更怎么办？事实上并不存在什么“紧急”的需求变更，因为所有的需求的实现都是需要有时间的，需求是一种未来性质的东西，项目组一定要把“需求”和“BUG”区分清楚，不能用解决BUG的方法去应对“需求变更”（这个也是大多数项目组常犯的错误，任务没有优先级的结果就是经常性的加班）。针对一个需求变更，除非它能够让当前迭代的某个任务即刻作废，我们才需要即时改变迭代的任务安排，否则本次迭代不受影响。

没有验收标准文档是一个问题，但是“依赖客户进行测试”是另外一个更严重的问题。因为之前所讲的客户不定期要求项目发布，所以项目组在发布的时候的时间都很紧张，加上平时没有充分的测试，所以项目组就希望客户能够抽出人力去做验收测试。实际上，客户几乎不会去做什么认真的测试。有与会成员认为“依赖客户进行测试”本身就是项目的一种失败。

篇4：项目管理沙龙的第一次聚会纪要：项目管理和敏捷

会议的主题是项目管理和敏捷，敏捷是近几年的热门话题，也是最让人误解的名词了。

有人在会上提了这样的例子：

两个人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/

我们一直在实践中探寻更好的软件开发方法，

身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动高于流程和工具

工作的软件高于详尽的文档

客户合作高于合同谈判

响应变化高于遵循计划

也就是说，尽管右项有其价值，

我们更重视左项的价值。

可以看到，所谓的“敏捷”方法，就是秉持敏捷理念的项目管理方法。

但是在敏捷的实施过程中，并不都是一帆风顺的。一个流畅的敏捷管理过程，机器的辅助是相当重要的，比如关键的“持续集成”。

总结

虽然这次讨论的主题是“项目管理和敏捷”，但是话题涉及到了项目管理的很多方面。会议气氛热烈，有很多精彩之处，个人比较满意。但是因为是初次沙龙，所以会议话题有些分散，有些同学希望主题能够更加明确一些。

期待下次更好。

篇5：项目管理沙龙第六次聚会纪要--模式“苹果酒屋”

《项目百态》模式36名字叫“苹果酒屋”，大意是说，苹果酒屋是工人们下班之后的聚会场所，他们经常在吃完饭之后，一起爬到房顶上去乘凉，喝啤酒。于是女主管就制订了苹果酒屋规则，基本上就是“不许爬到房顶上”，“不许喧闹”等诸如之类的规定。可想而知，这种“苹果酒屋规则”不会有人遵守的。因为规则的制定者从来不会在苹果酒屋住宿，也当然不会知道屋顶上是那里唯一凉快的地方。

这种“局外人”制定规则的情况在企业内部非常常见，最终的结局也都和“苹果酒屋规则”差不多。会上列举了几种常见的推广场景，一种是“强推法”。比如“空降”到项目组或公司的能人，经常会不顾公司的现状，强行给他的下属制定各种规则，试图将做出改变。这种强推的手法，经常会导致项目组的动荡，进而引发人员的非正常变动。但是强推并不总是坏的，当年华为从IBM引进并推行制度的时候，也是一样是强推，并且任正非还特意强调几年之内不许改。一种是“循序渐进”推进法，一点一点地让“局内人”去体验，逐步获取经验，然后加入更多的规则，最后所有的规则都生效。这种做法需要耗费很长的时间，并且还需要专人进行跟踪和分析；一种是“自制规则”，这个也是《项目百态》的作者推荐的方法，即由游戏者自己来指定规则。这样无论是规则的接受程度，还是实施的效果，都会非常的好。但是这种方法容易走弯路；另一种是“专家法”，即通过利用具有专家身份的人，来向大家推行新规则，并且在规则的实施过程中不断地解答游戏者提出的问题。专家可以让游戏者快速地形成共识，并且朝正确的方向前进，但是同样需要在实施过程中进行跟踪和监督，及时对方向调整。

这些做法都各有利弊，归纳起来，无非就是时间、空间和效果上的折衷和平衡。谈到这里，有人从自身的经历，谈到了程序员做了一段时间的测试之后，再回去写代码的话，代码质量会变得很好，很容易测试。这种角色的互换，比推行任何一种“测试要求”/“测试标准”的效果都要好。这时，有人举出了DT网项目的例子，因为第一期已经进入了维护阶段，所以该项目的下一阶段的开发项目就明显开始注重质量了。

相比这种通过“自身实践”得到的改变，让专家对工作进行总结，得到“最佳实践”方法之后，在全公司推广并评估效果，这种效率就会高很多。其实这么做也就回到了我们刚才讲的“专家法”的推广了。

因为刚才谈到了“测试”问题，所以话题继续围绕测试展开。有人谈到了测试人员的水平问题。现在很多公司里，程序员的薪资水平要比测试人员要高很多，也就是程序员的编程水平通常比测试人员要高，

可是引出了一个问题，就是水平最高的那个程序员的代码，谁有能力测？这个问题的答案并不简单，首先要看公司处于什么样的市场地位，处于领先地位的公司更考虑质量一些，处于追赶地位的公司更偏重功能，所以前者的测试要求会比后者高一些。其次要看公司的价值导向，眼光长远的公司对质量及测试的要求就高，急躁一点的公司对测试的关注度就小一些。还有就是要看项目的类型，对于产品型的项目，质量要求就会高，而对于一次性的定制项目，质量要求就低一些。其他还有很多的因素，包括公司的大小、技术能力等，都会影响到对测试的编制、地位和安排。

虽然如此，但是测试人员的水平大于开发人员的假设也并不一定成立。因为测试所需要的并不只是个人能力，和开发相比，测试有更多的流程，更多的工具，也有更多的有成效的方法来弥补与开发人员的技术水平差异。从某种程度上来说，产品的测试并不是依赖测试人员，而是开发者自己来进行的。因为所有的测试类型中，“单元测试”是最重要的测试，而单元测试的主要编写者恰恰是程序员自己。可是我们发现大部分的中国程序员都十分痛恨单元测试。我们一位与会者给大家解释了一大堆的“单元测试”概念，比如测试覆盖率，条件测试，边界值测试等等，以及单元测试的重要性又是如何如何。这些话从公司管理人员、项目经理、测试人员、客户以及维护人员，都非常消受，可是从程序员的角度听来，则是非常刺耳。虽然从实践中来看，有适当的单元测试覆盖的产品和没有单元测试的产品相比，后期的BUG量可以减少六至八成，但是这么重要的一种编程行为，即单元测试对于程序员的意义，哪怕是TDD都没有明确地强调出来：

“单元测试可以极大地降低调试的难度，加快开发的速度！！！”

这个其实也是我们沙龙要对所有程序员发出的强调。实际上，程序员的水平越高，对于测试也就越重视。当然，除了提高人员的自觉性之外，要推广单元测试还需要流程和制度的安排，比如结对测试。另外，测试的独立性也很重要，现在的测试都是被开发牵着鼻子跑，这种情况严重降低了测试的效率。

在讨论中，有人提到了一种反面现象，就是如果片面强调单元测试覆盖率的话，会有人只写出测试“永远正确”的单元测试来（显然这是中国式应试教育的变种）。经过讨论，大家认为这种情况并不严重：通过培训，可以提高程序员们对测试的能力；通过引导，可以让程序员们意识到1到2年的开发时间和为单位的运行维护时间相比，眼光应该更多落在持续的维护和升级上，避免一些短期行为对产品质量的影响。

最后，大家总结出来了一种“代码show”的方法，就是项目组不定期地召开“代码秀”，让项目组每个成员都找出自己写的最好的代码和最差的代码，展示并解释给大家，并集体讨论和分析，甚至还可以请专家点评。会议不做记录不批评更不做考评，让与会者可以没有后顾之忧。通过这种方式，我们觉得是有助于提高大家编码能力的。

嗯，这样算是“专家推广法”么？哈哈！

篇6：项目管理沙龙第四次聚会纪要--模式“快！赶上”和“死鱼”

今天聚会讨论了两个模式“快！赶上”和“死鱼”，在 book.51cto.com/art/01/244195.htm 可以看到两个模式的内容，

模式“快！赶上”是一个正模式，也就是好的模式。这个模式里其实讲了两个极端的情况，一种积极前进的“强团队”和一种拖拖拉拉的“弱团队”。与会者对强团队的特点非常有感触，部分参加EAC的与会者认为早期的EAC团队就是一个比较典型的强团队。当时EAC团队在去北京之前，大家都不知道客户的需求是什么，但是到了北京之后封闭开发的那段时间里，形成了一个“客户沟通-分析-实现-客户验证”的一个短促而高效的迭代循环，而团队每一个人都对自己的任务非常明确，弯路很少，即使走了一些弯路，在极短的时间内就可以纠正。EAC的这一段时间，给每一个参加者留下了深刻的印象和回忆。

会中有人问如果谈EAC这段时间的贡献，领导和团队的哪一个贡献较大。有人认为可能会达到1：1的程度，因为别忘记这个是由公司研发的精英组成的团队，而这种水平的团队，即使没有管理，他们也能工作的很好。其他与会者认为组织者会更重要些，作为一个组织的推动者，关键是要先动起来，当整个团队工作形成一种节奏之后，做什么事情都会变得快起来。当“团队的能力”到“领导者的信心”到“客户的满意度”形成一种正反馈循环的时候，团队自然就渐入佳境了。

目标明确是团队能力走强的重要因素（甚至可以是最关键因素），在“明确目标”上，团队领导的重要性毫无疑问是最大的。在如何划定目标范围的问题上，有与会者提出了从微软学习到的方法，就是凡是划定范围，先划定“不做什么”，然后再定“做什么”。在我们前几次的沙龙中经常提到“客户不知道自己要什么，但是很明白自己不要什么”，从这个角度也很容易推断出，先定“不做什么”的合理性。比如我们今天沙龙的目标，首先就是不谈设计，也不谈需求分析。即使不说下去了，大家心里也觉得这个目标比说之前明显要清晰了一些。

这两个模式，都属于团队的极端情况，实践中都很难遇到，大部分团队都是介于两者之间的状态，

话题自然就转向了团队管理中如何兼顾和管理那些较弱的成员的问题上。有人回忆了他项目管理生涯早期所遇到的“个性很强”的组员，最终找个机会这个把组员“送”给了其他部门的故事。另外有人也说了一个拙于表达的成员因为不适应敏捷开发的氛围而离职的事情。这时候有人提醒大家，PM在这两种情况下一定要注意沟通，因为无论是哪一种团队成员，他都有自己的诉求和原因，在充分了解对方的诉求和原因之后，才能有针对性地采取措施。不过有人有提醒大家，作为PM，这个时候也受到资源（尤其是时间）的约束，他可能没有时间去慢慢地沟通和帮助后进生提高能力，将这种人请出项目组其实也可能是一种无奈之下的最佳选择。

不过大家一致同意的是，采取敏捷管理方法的团队，无论是团队氛围，还是成员能力培训上，情况都要比传统管理方法的团队要好的多。

模式“死鱼”是一个反模式，讲述了另外一种类似于“死亡行军”的团队形式。和前一个模式相比，他们有一个共同的特点，就是“项目经理”，只要项目经理尽力，“弱团队”和“死鱼团队”都是可以缓解甚至避免的。在如何防止出现死鱼团队的问题上，与会者很快达成了一致，就是“透明度”，无论对于高层的管理者还是客户，保持一定的透明度有利于他们对项目状态的充分了解。当然，如果项目正好用了敏捷管理方法那就更好了，在第一个迭代之后就可以得到工作效率的数据，和工作总量除一下，就得到时间了。只要客户是理智的，看到数据就会说服。接下来无非就是三角关系“功能-质量-时间”中砍掉哪一些的问题了。

但是针对中国特有的“献礼”工程怎么办？这是有人提出的新问题，如果你是修建某个高速铁路的项目经理，客户要求在某个特别的日子就载客运行。你怎么保证不出现事故？讨论的结果是“透明度”原则还是有效的，毕竟每个人都是希望项目往好的方向发展。实在不行，大不了通车之后实现全路闭塞，每次路上只开一辆车。

另外有人举例ZS项目，讲述了客户对项目不管不问的情况。随后总结下来，大家认为这个属于不可抗力。不过我个人觉得这个话题还有继续讨论的空间。

最后总结一下本次沙龙，按照书本的顺序依次讨论所讲的模式效果不好，下一次还是要认真选题才行。

篇7：项目管理沙龙第十一次聚会纪要--当敏捷没有共识的时候

本来这次聚会要讲一下项目管理的流程概貌，同时对第一个阶段进行一次试探性的深入探讨，可惜这次缺席人数太多，变成了“锵锵三人行”，原定想要谈的内容，也就弱化了。其实每周一次的沙龙，并不需要太多的负担，就当是每周一次的茶会吧，大家紧张了一整周，放松个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

篇8：项目管理沙龙第十二次会议纪要--为没有共识的项目组定制敏捷方法

本次会议的主题是为没有敏捷共识的项目组定制一个敏捷的实施方法，这是一种普遍存在的情况，和其他的新事物一样，总会有一些人对“敏捷”这两个字比较敏感，究其原因，无外乎偏见、误解和不了解（无知），部分人则是恐惧或自大。当然，不了解是绝大多数人的原因。

但是，面对“没有共识”的人们，到底是说服之后再实施敏捷呢，还是先实施敏捷再用实际效果展示给他们？这是一个问题。我们倾向于后者，即先实施让人们看到效果。理由很简单，因为人与人之间的知识和经历的差异很大，要全部说服的时间成本太高，甚至于不可能，如果面对是一个有一定经验的人，要想说服他抛弃原先的经验来接受一个新事物，难度恐怕会更高。所以，“暗渡陈仓”或“偷梁换柱”地实施敏捷，是一种切实存在的需求。如果要给这种方法安装一个冠冕堂皇的名字，那就是“传统的项目管理方法到敏捷管理方法之间转换与过渡”。

之所以我们要探讨这种情况，因为我们坚信“敏捷不会把事情变得更糟”，既然敏捷肯定不会“砸场子”，肯定“效果>=现状”，所以“暗渡陈仓”就是有价值的，也是可行的一种推广方法。

我们的目标项目组情况是这样的：团队成员之间技术水平差异较大，但是工作热情高涨，气氛较好，而且项目组感觉“陷入泥潭”已经很久了，看着一堆难以维护的代码，大家都有一种想要改进和突破的渴望。但是团队的关键领导之一对敏捷的态度比较暧昧，不支持也不反对，但对敏捷始终保持着足够的距离，既不拒绝，也不欢迎，更不去深入了解。在管理方法上，项目组采用月计划和周计划相结合的管理方法，即每月定一个计划，本周的计划细化到可执行。但是可想而知，管理比较混乱，计划也经常不准确。

面对这样的项目现状，我们首先讨论的是实施策略：

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”的方式，逐渐形成集体对代码质量的重视，达成共识之后，进而引入“代码评审”的方法。