敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

　　在Scrum领域里，Scrum M aster到底是full time job or part time job，一直是大家很关注的问题。在学习了PMP之后，我的答案更偏向于前者。

　　首先，介绍一下我的情况，我们是一家大型的软件公司，根据公司政策的需要，我们从2006年左后开始实践Scrum，在公司实践敏捷已经6年多了，我们从经典的白板到现在的电子模拟白板，从Excel画burn down到漫天的Scrum 在线工具。一路走来，感触颇深，中间大大小小的经历让我对敏捷和之前的瀑布理解充实很多。当我进入很多大型论坛里面的时候，发现大家都遇见一样的问题，而且这种问题一直在重复重复着。

　　一个企业如果刚开始学习使用Scrum，那么我是非常推荐SM担当一个执行教练的角色。帮助团队如何使实施敏捷，如何规范化工作方式和制定流程，如果寻找一个适合我们自己企业的敏捷路线，这个是非常重要的。敏捷是理念，规章制度是标尺，项目成员是一大群羊，但是如何让羊群以最有效率的方式前进，牧羊犬的领队是非常重要的。training.mypm.net

　　这个时候，就可以按照大家都用的模式，将一个大的release的概念，每次项目管理计划的时候，就按照3个月一个大迭代，安排好一个大release的工作量和安排在一个3个月大的release里面，再可以根据队伍的不同性质切分很多小的sprint。每个队伍不要过大，5~10个人是最推荐的规格。我们公司是4个Dev配2个QA，然后2个星期10个working day是一个sprint。每个sprint必须开的会是Sprint Planning Meeting, Daily Stand Up Meeitng, Review Meeting,如果从一个刚计入Scrum领域的工资，肯定每个sprint会保留各种各样的问题，我们就召开sprint Retrospective Meeting。回顾会议室非常重要的，因为我们会整理当前遇见的问题并且和组员一起分析和整理出如何应对他们。当下一个迭代开始的时候，我们会选择如何避免同样的问题，和跟踪他们。

　　举个例子，很多sprint，前2天QA工作清闲一点，他们会准备test cases，准备环境，DEV会持续产出。等到了3~7天的时候，陆续有代码check in，QA会忙起来，Dev会放在重构和代码质量审核的过程，最后3天，是QA和DEV矛盾最激化的时候，大大小小的bug被发现，DEV也会脾气特别大。而且QA会经常报告说QA Resource不够。 相信很多执行Scrum的队伍都遇见过这样的问题。

　　怎么去应对这样的问题，相信八仙过海各显神通，根据不同的切割方式，不同的迭代方式，会有不同的方法和流程去避免这个。我们公司很简单的就按照“串行改并行”，“协作加监督”，“报告加质疑”的方式，解决了这样的问题。转自项目管理者联盟

　　当羊群超过2年多的敏捷实践，我相信那些羊们出了羊棚该往哪儿跑，等太阳快下山了，该自己怎么回羊棚也应该知道了差不离。相信这个时候少几只牧羊犬，大多数羊任然会学会如何做好本职工作，做出非常professional的判断。这个时候我们就可以说这样的Scrum队伍已经成熟了。

　　难道成熟的团队就不要Scrum M aster了么?是不是part time就可以了?我的理解是并非如此。

　　因为，这个时候也许队伍不需要牧羊犬来对着你大吼大叫，但是需要一个强有力的监督和审查机制。队伍需要的不只是一个单单的执行教练，而是一个鞭策者，监督者，审计角色和一个“敏捷的转播者”。PMP的作用就起到了，如何计划队伍的大方向，如果拿捏项目资源的分配，如何分析预估项目面临的risk，如何根据企业的特色和以往这么多年执行敏捷而积累的宝贵经验来制定风险应对策略，如何弹性地将项目切片切块，增加或者减少迭代来适应当前的项目的不同阶段。理论引导实践，学习了PMP理论之后，你才能将这种管理理念和实际工作相结合，让队伍更有效的紧密结合起来。不以规矩不成方圆，一个成熟的，有监督的，按规矩办事的，能自我管理实现自我价值的团队，才是任何企业都希望的队伍。

　　如果成熟的敏捷实践公司，后期Scrum Mster只是一个part time job的话，那么就会遇见如下鲜为人知的问题：

　　1. 预估需求大小，队伍已经“协作”非常默契，点数只大不小，队伍整个心态懒散，每个迭代产出下降，但是很“稳定”项目管理论坛

　　2. 觉得Daily stand up meeting 可开可不开，变成了汇报日常工作的地方，把“有什么问题和间接share”这个部分直接忽略，会上交流会越来越生硬，越来越无趣，越来越失去原有的意义

　　3. 队员和SM矛盾加剧，认为SM是一个监工，老是负责push的黑脸，又是part time，爱理不理。觉得和PO交流即可，流程已经太熟悉了，不需要这样的角色，甚至会质疑SM的存在是否合理

　　4. burn down作假，只报喜不报忧，从一开始就给自己留下大量的capacity，工作团队开始疲软，毫无斗志，企业活力下降，变成敬老院，大家开心才是真的开心。

　　5. 老员工很难被管理，因为他掌握了大量的企业知识和资源，又不能得罪他还怕他跳槽，但是喜欢这样的懒散的工作氛围，工作压力小，劳动强度可以自己控制，对自己敏捷起来，不是团队敏捷起来，应此资源储备进度也慢慢放下，企业知识共享库也放下了，如病入膏肓的老人。
 
等等这些问题，我相信超过3年Scrum的企业都会遇见。以为Scrum重在“manage yourself to fulfill biggest value"，这些答案和解决方法都在PMP里面，当然在执行上也会遇见很多 政策的问题。这方面我感触颇深，我们是一个弱矩阵的管理架构，resource上面有line manager,需求方面有专门的PO，当队伍成长成如上的老人的时候，左没resource右没requirement的时候，同时又想根除这些根深蒂固的病根时，真是使不出来力来。

　　PMP让我学到很多，看到很多，它是一种思想一种理念一种追求，不是一个特定的工作方式或者流程。我们在工作和生活中药处处分析和利用起来。我们的PMP老师说的好，生活就是一个PMP，如果更好的管理好自己的生活，才能真正体验其中的乐趣，我说的可不是”怕马屁“哟，呵呵。就写到这里，望高手们多交流。