个人自己带过SCRUM，也跟过其他人带的，
只能说不管是被带(凹工时)、还是带人(自己要事先准备很多东西)，
都是很辛苦的@@
(谜之音：好像也有不辛苦就能带SCRUM的人，那我保证辛苦的就是被你带的人...)
(谜之音：好像也有不辛苦就能带SCRUM的人，那我保证辛苦的就是被你带的人...)
(谜之音：好像也有不辛苦就能带SCRUM的人，那我保证辛苦的就是被你带的人...)
但因为公司文化，我必须调整SCRUM框架默认的运作模式，求融入既有制度，
以下分享个人带SCRUM(九人团队)看到的一些现况
原文传送门：http://sean666666.blogspot.tw/2015/05/scrum-mythos.html
[前言]
敏捷式开发不是软工方法，敏捷只是一种心理状态的描述、一种工作环境的意
念，如果公司文化没有敏捷的意图或是想法存在，导入任何方法都没有用。
那SCRUM又是什么，假如敏捷开发是个数学的应用问题，那SCRUM就是一套或许可以解
决问题的公式，SCRUM只是一套方法、一种作业方式、一种运作模式、一种流程，SCRUM不
是万灵丹、SCRUM不是万灵丹、SCRUM不是万灵丹，因为很重要，所以要讲三次。
[迷思一：有了SCRUM就不用写文件]
一言以蔽之：SCRUM是利用大量的沟通、许多的定期会议取代文件撰写，所以在时程上并
不会大量减少耗费人时，因为这是一种挖东墙补西墙的概念。但好处是因为沟通频率高，
各角色间的思考误解会有效减少，避免各说各话。
CMMI最令人诟病的就是那一拖拉库的文件，从肥滋滋的客户拿着钱需求来找你开始，
一直到开发完成、测试完成，全部都是一连串的交付文件，包含每个月研发团队开的会也
要记录，所以CMMI常常被骂到臭头的都是这件事情。但用了SCRUM之后，难道就真的可以
避开这些阿杂的事情吗？
CMMI设定的SA、SD、PG、Tester便缺少了文字依循，所以SCRUM放入了几项元素：会
议(快速、经常性的)、User Story。
因应软件开发这种脑力高度集中的产业，资讯需要快速交流、有效沟通，SCRUM的模
型里面针对沟通部分导入大量的会议，包含Daily standing meeting、Sprint
retrospective meeting、DEMO meeting...
所有的SCRUM教科书都说Daily standing meeting是一种每天要所有团队成员以站立
的方式开一个10 - 15分钟的会，那这个会要干什么，一言以蔽之就是要资讯通透，会议
中要求每个人只要说明前一天做了什么、今天要做什么、遇到什么问题需要协助...
你真的以为会议都会在15分钟内就结束吗？
除非你真是个非常有经验Scrum Master相当会掌握会议仅度 or 技术能力很强可以理
解每个成员想要表达的事情，一个理想的Daily standing meeting执行上其实不简单，提
供个人经验分享。
此外Retrospective meeting一定要把会议讨论的重点跟调整方向记录下来，口说无
凭、时过境迁，很多事情不写下来或是当下没有决议，进度检讨流于空谈。这种会议文件
也不需要长篇大论，基本上就是一张A4就绰绰有余，纪载会议时间、与会人员、决议事项
、待办事项(包含人、事、时)即可。
[迷思二：SCRUM可以节省开发时程]
一言以蔽之：SCRUM无法减少研发时程，但有其它很棒的效益。
SCRUM在每个Sprint会订立这次的冲刺的目标，团队成员将PO写User story根据优先
权认领工作，然后开始执行，反复冲刺。问题来了，如果User story规划的不好，可能一
个冲刺做不完、或是开发完根本无法整测、或是问题根本无解，这就跟导不导入SCRUM一
点关系都没有了，而是需求规划、程式架构有问题，导致所有的工作根本没有办法系统性
规划在一次次的SCRUM时程冲刺完毕。
以上的问题可能会发生在一个运作好几年的大型研发团队，因为专案研发常常delay
所以想诉诸新的软件工程方法来解决。
那你会问："为什么我要导入SCRUM？这样我到底哪里敏捷了？"
SCRUM能带给你的是一个自主型团队，一个拥有独立思考、无痛抽换成员、增加成员
后人时可以是线性成长，不用浪费在一堆无效沟通且没有固定release的产出，快速且定
期给客户检视成果，快速走向市场验证你的商业模式。
[迷思三：SCRUM的角色不能变动或重叠]
一言以蔽之：请依照组织与文化调整你的SCRUM团队。
依个人带领团队的经验，人不多但事情又多又杂，加上核心程式码算是捡尸继承来的
，所以我没有办法很干净导入梦想中的敏捷方法，例如code review、continuous
integration、pair programming、auto testing...
SCRUM也有提到PO、SM必须是不同角色，老实说这在我的团队根本不可能达成，因为
人力完全不足。考量开发人力、测试人力、程式码版控、PM、写报告...多样角色，我思
考很久，就是忍痛把PM/PO/SM/写报告全部往身上扛，把测试依据功能性来界定范围尽量
平均分分到各成员身上，再来就是把开发工作用SCRUM每两周一次方式来定期追踪。
初期团队每天都执行Daily standing meeting，直到个人觉得团队上了轨道(差不多
半年)，我就只定期两周开retrospective + DEMO meeting。当团队可以在把事情说清楚
、指定好负责人、著名限办期限，事情能自动完成，代表已经上了轨道。
[结语]
看法也许有误，欢迎提出指教讨论。