个人自己带过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。当团队可以在把事情说清楚 、指定好负责人、着名限办期限，事情能自动完成，代表已经上了轨道。 [结语] 看法也许有误，欢迎提出指教讨论。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.136.249.37 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1464147305.A.047.html ※ 编辑: cactus1021 (114.136.249.37), 05/25/2016 11:45:57