敏捷导入实施的常见问题实战解答-CSM/ACP培训FAQ知识管理看板

常见问题A

A：公司: 文化、风气、高阶主管支持

A1: Scrum PO要怎么跟管理阶层沟通计划进展？

因为上层都会说要订WBS，先将时程安排下来，但Scrum比较都属于短期目标，很难订长期的规划时间 。当项目急的时候，主管就会开始进入”有追有进度”的模式，甚至细到每一个人把时间花在哪，认为这就是精益(Lean)！要如何管理以便符合Scrum和主管的需要？

优普丰敏捷顾问回答: 

任何的项目管理手法，最好是高层、中层及低层人员大家要一起先建立共识，是要采用纯PMP瀑布手法？纯敏捷开发？还是双模混合模式？

近期：就这问题的情境，目前应该是混合模式，产出的工作蓝图沿用WBS，而每个工作包可依照时间优先排序后，视为产品待办清单，搭配Scrum的迭代规划会议，进行两周工作的规划，每日Scrum站会来分享进度，并进行评审及回顾会议

远期：跟高层举办共识会议，未来仍要用混合模式还是纯Scrum，但前提要先厘清该项目的客户需求是高确定性还是复杂多变！

A2:实践上，项目除了Code开发，还需要许多汇报、协调、跨Team沟通或行政事务。项目经理在敏捷导入中该如何采纳转型?

优普丰敏捷顾问回答: 

建议可令Project Manager 行使Scrum Master职责（SM不是一个职位，也不单纯是一个角色，更是一个责任），充分了解敏捷精神并实践相关实践。

在 《Scrum指南》 并未定义对公司进行汇报、协调、跨团队沟通或行政事务是由PO、SM或Dev Team谁来处理，但是我们身为CSM是否要去思考这些工作内容是否反敏捷? 如果是的话，日后我们如何让公司管理阶层投入敏捷，创建一个更支持敏捷的企业文化。

A3:如何解决依赖Dependency的问题

优普丰敏捷顾问回答: 

Dependency 问题通常来自于DT 无法单独完成客户的所要的 Feature. 有四个方法可以解决. 设原有的 Feature 需4个 Functional team A->B->C->D 方能完成:

1.完全移除: 将团队纳入 Dependency 的团队，这需要比较大的权限，需Management的投入.

2.减弱:  假设该 Dependency 由一个A 负责团队所 own, 而这团队正在忙其它的事务。此时可以由其它团队来修改 Code, 但实际上线前仍由owner 团队来派驻评审和把关质量

3.透明和持续曝露: 善用自动化的CI/ CD

4.管理力量的介入: 联合 Sprint 会议, Task board 管理, Review Meeting

常见问题B

Ba： 敏捷运作:  敏捷运作原理不熟悉、 敏捷会议操作不顺畅

Ba1：成员的能力差异大，无法如时交付产出或是质量不一。

优普丰敏捷顾问回答: 

每个人的个性和能力本来就是差异很大，特别是脑力型的工作环境中。

个人能力要予以投入培养和刻意练习，管理者的责任是成为园丁，给团队要创造一个互相Polish(打磨碰撞)的环境，取长补短，形成跨职能团队。另外，师傅带徒弟、结对编程(Pair Programming) 也是很好培养能力的方式。

时间是主观、靠经验值预估的，即使再资深的PM也难以给出准确的估算，除非之前有做过类似的项目经验。因此，在敏捷的每一个Sprint 过程中，也会让估算越来越符合实际产出。

Ba2:评估工作项的所需工时的时候，如何避免短时间可完成的项目，成员预估过高?

(例如修改表单可能实际做3小时，但预估需要大改所以要21小时)

优普丰敏捷顾问回答: 

敏捷不是避免犯错，害怕犯错，惩罚犯错。而是从过程中求取宝贵的经验，估算不准确没有关系，迭代回顾会Retrospective 可以提出讨论，以及找出未来类似状况下，要如何因应的机制。发生错误是可预期且OK的。但能不能保持持续改善，才是重点。也就是说一个3小时可以完成的任务被团队估成21小时，于Retrospective 时，担任PO/SM的主管可以给予修正的建议。于下一个Iteration时，再观察是否类似任务工时估算膨胀的情形发生。

估算就是拍脑袋(主观)，并不存在绝对正确的“预估”，即时是有做过类似任务也不能保证和昨天的结果完全一样。通过分解、持续面对面讨论，PO与Team协作编写Acceptance Criteria(验收条件)，都是有助于加深理解，从而对细节达成一致理解，估算也会更加接近实际。另外，人员的经验能力培养，允许从失败中学习，也会使估算也会更加接近实际。

Ba3:如何判断”人”不胜任 Agile 需要回到以前的 瀑布模式？

优普丰敏捷顾问回答: 

建议可观察成员是否具备Scrum价值观中的特质：Commitment、Focus、Openness、Respect、Courage。观察团队成员是否能够自组织自管理，经过多个Sprint(Iteration)后，团队成员仍无法遵从团队规范(Team Charter/Ground Rule)或完成Retrospective中改善要求。建议让该成员离开团队。

身为好CSM思维不应只有 0 与1，如何把一不胜任 Agile 的团队成员引领为自我组织的成员也是很好的挑战，如乔布斯的Parable of Stone视频，石头和石头互相敲击, 团队才能往前成长。怎样培养团队的开放性，也是SM存在的价值。

Ba4:请问每个 Sprint 的结束跟开始时间是否需要隔一段时间准备下个 Sprint 的计划会议，还是这个sprint就可以召开下个 Sprint 的计划会议？

优普丰敏捷顾问回答: 

依照 Scrum Guide, Sprint 与 Sprint 之间是无缝接轨的, 若隔周周一是每个 Sprint 的开始, 就维持固定这一天开 Sprint Planning. Sprint 不宜时大时小, 会乱了团队的步调. 故, 若 Sprint 尚在进行中, 已经没有Feature可以做, 可请PO和DT增加能做到DoD的User story, 最好不改变Sprint goal. 不用为此而提前召开Sprint Planning.

Ba5:如果 Agile 是可以接受不断改变，那 release date 需要订出来吗?还是需要每个 Sprint 调整?

优普丰敏捷顾问回答: 

Release date/上市时间固定或可调，要因开发的产品或服务而不同。有时上市时间很死, 需倒推要做什么工作。有时Release date 无法达成，就采最高价值舍弃低价值的features。如果该产品或服务是可能有对手竞争的。团队在开发前便已一起参与Release date的制定，通常会因为已达到目的而提前，不会延后。开发的目标本就是一个预订的方向与上线时间。用敏捷方式来开发产品或服务依开发的目标进行不断的调整(改变)。

Ba6:遇到完成不了 task的状况，是直接放入下一个 Sprint 吗? 重新估时(or 累积估时)

优普丰敏捷顾问回答: 

PO 在 Sprint planning 把该 Sprint 要开发的  User story 说明给团队听. 团队再依自我组织方式将这些User story拆成 tasks. 依 Scrum Guide, 未完成的 task 应放回 Product backlog, 由PO重排优先顺序在未来的 Sprint planning 重新发包给 DT 来开发. 若是未来再拆成新 Tasks, 理应由接球的成员重新估算时间. Task的估算不像User story一般需由团队一起估算, 而是执行的人估算即可. 估算单位为工时.

Ba7:遇到大型且流程相关复杂的项目(MVP很大)在MVP部署(Deploy)之前，可有项目方法检查需求是否要调整

优普丰敏捷顾问回答: 

MVP是指以最小的投资取得最大化对客户需求的学习。这是一个正常的项目，每个Sprint 皆依该 Sprint 应完成的DoD即可, 怕的是会有些技术债及Undone features可能无法在该Sprint 内完成. 

以下为一个IT系统较完整的DoD. 一开始团队能力不足, 可能没有办法一次全部执行, 可以先完成Green的部分. 后续团队能力会起来, 团队默契会越来越好, 自动化工具会越来越多, 可以再多实施Yellow的部分. 如果达到Red的部分, 几乎所有系统部分问题都可以卡下来了, 只是在于团队能力是否可以做到而已.

MVP Agile Alliance 定义： http://bit.ly/2QtTin8

A minimum viable product (MVP) is a concept from Lean Startup that stresses the impact of learning in new product development. Eric Ries, defined an MVP as that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

Ba8:如果晚期需求变更跟原先方向差异过大，会造成项目无法准时交付该如何处理?

优普丰敏捷顾问回答: 

每个Sprint都与PO讨论并细化需求、每个Sprint都将成果展示给需求者，并取得需求者的回馈，取得需求的变化走向，需求晚期是可能与原方向差异大，这是正常的现象。但敏捷的精神本来就是拥抱变更来发现使用者的真正需求。若是因为变更需求太大，导致无法准时交付，其实不会在最后才发现，而是过程中就会发现。PO需谅解团队无法准时交付，SM也需努力保护团队，使PO不会予取予求。

Ba9:成果(产出物)之质量如何确保?

优普丰敏捷顾问回答: 

敏捷团队以DoD 来确保每个Sprint的质量。一开始团队能力不足可以实施少量的质量把关机制，后续能力起来了可以再增加更多的质量测试。请参考B9。

Ba10:Scrum 如何运用在测试/验证? (有限时间/人力) 

优普丰敏捷顾问回答: 

是否应用Scrum，先决条件仍是判断开发的商品或服务，甚或是公司文化是否适合使用Scrum。比如用一把小刀转开螺丝或是挖土，应该做得到，但是否合适？容易上手？或有效率？

如果测试/检验的内容所需技术都不是太确定，是可以考虑套用Scrum架构。成员们讨论并估计测试/检验的大小，PO排序优先顺序，计划本Spring完成哪些，邀请Stakeholder参与验证”测试/检验”、并给予团队回馈意见，然后进行下一轮的Sprint。最重要的是对PO有价值，团队有成就感&拿到钱，双赢。

Ba11:Task 在 Task Board 的 Done 和 DoD 是不同的, 对吗？

优普丰敏捷顾问回答:

在Scrum的Task Board有US (User Story) 及Task之分, US要放在Done的话要满足DoD, 但是Task则不用. 一个US可能被拆解成10个Task, 这10个Task要满足什么样的条件需DT讨论出规则即可, 但若US要放在Done 栏位则需满足DoD.

Ba12:task done是否要更新燃尽图？

优普丰敏捷顾问回答:

Task 本身并没有故事点数, 有点数的只有US, 所以task完成后不用更新燃尽图，US才需要.每个US完成后, 可以即时给PO验收, 验收OK再更新燃尽图.

Ba13:燃烧图是依工时或故事点？

优普丰敏捷顾问回答:

要看管理者最关心的是什么。时间轴单位是release还是sprint。

敏捷的burndown没有规定一定要用什么单位。

Bb：敏捷运作实践_五个事件及项目

Bb1: 要不要中断进行中的Sprint？

如果上级有ㄧ个紧急任务要团队的人去执行，而这时也才开完 Planning 会议开始一个 Sprinit，SM 说要等 Sprinit 结束后下一个 Sprinit 执行，这时是要怎么做呢？  谢谢！

优普丰敏捷顾问回答: 

通识专才是敏捷团队培养成型后的组织特性，所以这个不会是大问题，同样的工作会有别人可以胜任。但是在整体工作量上，可能会有资源短缺不足的状态，SM要与PO同步，并且要团队的成员一起取舍，若是这个人力损耗无法避免，看看Sprint goal会不会被这个影响到。若是不会，看看什么work item可以牺牲，若是会，只能Sprint砍掉重来。

同时，SM身为change agent，要教育好上级主管敏捷的好处与精神，让组织了解敏捷的本意与思维，最后再分析团队成员任意变更的潜在负面效应。（切勿倒因为果去先讲坏处；对于不懂敏捷的人来说，会被误认为『找理由搪塞』）

紧急任务真的很紧急吗？或许可以等一等。紧急任务容易使大家忽略了真正“重要”的任务。假如真的是紧急，可以采用置换原则，从Sprint换出一个优先顺序最低的任务，从而维护节奏。注意，任何紧急任务都要通过PO才能交予Team。

Bb2:若无法在每个  Sprint 内将问题解决，导致无法顺利 release 交付物时，应如何处理?如何避免发生?

优普丰敏捷顾问回答: 

在回顾会议中，讨论问题的情境，操作方式：

1.团队要能具体描述问题

2.用5Why法探索原因

3.提出3~5个解决方案

4.一同选出一个最佳解决方案

5.获得大家的认同

6.用便利贴写成一个行动方案

7.放入Product backlog

8.作为下一个Sprint要执行的方案

Bb3:如何执行一个好的回顾会Retro ? ( 毕竟华人比较不勇于开口)

优普丰敏捷顾问回答: 

Retro 有很多开会的方式. 有两种方式: 

第一种方式是Retrospective Process：

1.Set the stage

2.Gather data

3.Generate insights

4.Decide what to do

5.Close the retrospective

第二种是WWW及EBI 都可以用便利贴方式来写出意见. 为求听到真声音, 卡片可匿名. 

WWW: What went well

EBI: Even Better If

第三种是LS释放性结构共创工具箱（Liberating Structures）。

在一些 Retro 作法,可以在一开始让大家先 Check in, 用简单的问题让大家在一开场都能有发言, 如此先开了话匣子, 后续更容易带动讨论.

常见问题C

C. 团队管理: 一人多工 (同时多个项目) 、团队成熟度不足、责任心不够

C1:客户或PO对产品需求本身也不是很清楚，如此可以跑Agile？会不会造成予取予求或不符成本之现象？

优普丰敏捷顾问回答: 

Agile 敏捷管理正是为了应对变化和不确定性而生，产品需求也是在不断的回馈中慢慢清晰和调整的。解决业务问题，符合市场需要才是企业生存的根本，而不仅仅是为了符合预定计划中的成本时间要求。要完成的工作量是PO 和 Team 达成一致，才不会有PO予取予求的现象发生。

敏捷没有予取予求、任意索取而不考虑成本的问题，因为以每一个Sprint为单位，只做当下高价值的items，做到没有价值时结束。如果怕有成本的控制问题，可以把故事点数转换成单位成本，团队用掉多少工时就向客户/PO 收取多少费用。PO、SM及团队要尽量谨守稳定的步调规则，别有工作峰期忽高忽低的情况，即可持续产出高绩效。

敏捷强调团队swarming effect(蜂拥而上)，群策群力，互助提出援手，责任是共同的。敏捷要培育通识专才，藉由工作的pairing(结对)，cross-training(跨职能训练)，让每个人至少成为π型人才。

PO不是一个client relationship manager (客户关系经理)而已，这个角色要能够对于市场走势洞烛先机，对于产品未来嗅觉强烈。敏捷没有予取予求，不符成本的问题，因为以每一个Sprint为单位，只做当下高价值的items，做到没有价值时结束。

C2: Scrum Master可以同时兼任Dev Team成员或PO代表？

优普丰敏捷顾问回答: 

在人力不足的情况下，SM是可以兼Dev Team的角色。但全职的SM，自然可以专注在敏捷团队的带领。

在SM 身兼 Dev Team时，在任何场合或时刻，这个人若是要发言，或是要与项目成员互动时，当下自己头上戴的是哪一顶帽子（也就是角色为何），不能同时两个角色交叉浮现（双重人格）。

SM可兼职，但尽量避免与PO重叠，因为一个是守护团队福祉，传达敏捷思维的人，一个是商业利益导向，客户价值优先的人，在利益冲突的考量下，把这两个角色摆在同一个人身上，到最后团队成员被牺牲的机率非常大，敏捷平衡一旦打破，稳定的步调无法维持，客户拿不到最佳产出，团队也创造不出来可能的好价值。

C3:目前PO多是由主管担任，但似乎应由产品或业务部门担任，请问何种方式较为合理? 若应由产品或业务部门担任，TL主管适合担任何种角色?

优普丰敏捷顾问回答: 

谁对于产品路线发展，以及最后成败负全责，就是PO（他绝对不是任何人的棋子，也不是任何的传声筒，他对于产品的方向有绝对的自主权，并且能够与团队成员每日互动至少三小时以上）重点是同时要把PO当作是团队成员的一份子。

PO适合由产品或业务部门派有决策权的人担任之，须能与团队共同工作，随时厘清团队的需求。但当产品或业务部门无法派适当的人选担任PO，则主管出任PO是一个选择（同时也要清楚地知道这样做的弊端），因为PO负项目成败之责。注意，授权要足够充分情况下才能这样做，否则PO无法决策，实际的决策权还是在产品或业务部门手上。

若PO由产品或业务部门有决策权的人担任之，主管适合担任SM角色，给予适当的协助。

所需要注意的是，PO也是需要经由足够的敏捷训练，方能成为称职的PO(CSPO是不错的任职认证要求)。要不然只会一味地打乱成员的步调，对团队予取予求，造成团队疲于奔命。或者，要求不当，造成将帅无能，累死士兵的情况发生。

若是PO神龙见首不见尾，只有出现在Scrum Planning 及Review Meeting的话，这个不是敏捷的思维与做法，也不会得到敏捷可能带来的好处。

C4: 课堂上说Sprint与Sprint中间不可改变Sprint Goal，但实践上几乎不可能

(E.g.主管临时交办、线上系统有紧急bug…etc.)，请问有无合适的处理方式?  开发人员预留紧急交付项目处理人力或加班处理非Sprint项目议题?

优普丰敏捷顾问回答: 

所谓的敏捷Sprint 开始后不变是指Sprint Goal 尽量不要变动，Sprint Goal是指PO在此Sprint 所要完成的功能，但是这些功能底下的工作任务则掌握在Dev Team身上，是可以因应需求调整修改或是删除的。若是真的有新的需求(User Story)，则是先摆在Product Backlog，待下一个Sprint 再开发 。或预留一些工作量的buffer，以应对可能的变化。

如果真的有需要插单，可以检查一下在这个Sprint 有没有尚未开始的User story, 用交换的方式，但可能的风险是大小不一定相等，也可能要花时间拆解任务。但至少交换的方式比新做一个User story 好。 另，如插单情况常常发生，每次选定任务时，保留一定的缓冲，作为突发状况的处理。同时，也可以评估Scrum 手法是否适合团队。救急不是办法，可以回到源头找出根本解决之道。

一个好的敏捷实施PO、Dev Team 需要有共同的共识，如果PO一味地忍不住在已经开始的Sprint 提出新的需求，自然会打乱 Dev Team 稳定的步调。但，敏捷精神是Customer Collaboration 及 Responding to change，客户有紧急需求的变更，还是需要配合。

C5:执行的项目类型是自主研发，客户并没有强烈的需求而是由主管每周group meeting方式追踪进度，请问这样的形态要如何逐步导入Agile?

优普丰敏捷顾问回答: 

有没有市场时间表的压力并且传达给研发单位？

有没有产品路线图的方向？

有没有一个好的PO？

可否在一个Sprint 内产出客户能验收的Increment(产品增量)? 

上线交付的目的和市场价值在哪里？

这几个条件缺一，建议不要硬导入敏捷，不用为导入敏捷而敏捷。若是以前的方式可以做得很好，为何不维持?  

敏捷有其适用条件，就是符合快速变动环境、需求不确定性的项目。如果，一个规格或是目标明确，已经有具体作法、反复执行过多次的项目，用瀑布式的方式，反而成功机率高并且单纯。

瀑布式项目的优点是规划充分考量，包含十大知识领域，如整合、范畴、时程、成本、质量、资源、沟通、风险、采购及利益干系人管理。这些预先规划皆可摆在敏捷项目之前，可以有效提高敏捷项目成功机率。

当我们把瀑布式及敏捷手法混合使用，称为Hybrid双模手法。可以有效地提高项目的成功机率，也可以大幅降低一家习惯导入瀑布式项目公司推动敏捷的阻力。

C6:可否分享如何”有效”引导团队形成自组织”Self organized”?

优普丰敏捷顾问回答: 

让团队能形成自组织的关键是授权、不干扰、观察支持、创造环境。先要不管！（Leading, not Managing), 以下方法可以有效激发起团队的自组织.

1.把问题带给团队

2.忍受错误及阵痛学习期

3.培养积极主动的行动文化. 问一下每一位员工你为什么来这里工作？(Motivation)

4.从招聘开始, 寻找Open-minded的人, 愿意不断地学习. 对本公司及技术充满热情, 充满好奇心及愿意做不同事情的人. 

5.打造全栈或一专多能, 实现任务分配的拉动系统 (按优先顺序别)

6.团队共同对目标作出承诺, 从实现目标获得成就感

7.没有个人的失败, 只有团队的失败

8.简单的、可视化、 即时更新的工具

9.充分利用团队内部互相汇报机制, 如计划会议及每日例会全体参与

10.成员面对面坐在一起

11.多做结对工作

12.简单的团队约定规则, 包括DoD等

13.不断的审视团队有没有功能障碍

14.引导团队充分利用回顾会议来做持续改进

15.避免人员经常更换

C7:  “IT” 传统角色定位 “PM,SA,SD,PG” 如何转换成 agile “PO, TL, Developer” 过渡期如何减低阵痛?

优普丰敏捷顾问回答: 

传统角色直接转换为敏捷三角色肯定会有阵痛和排异反应, 实施敏捷的单位需要有强烈的导入动机, 自然可以克服. 建议过渡转换流程如下: 

1.先确定三角色（PM中个性适合的人过渡为Scrum Master, SA过渡为PO  剩下的人皆是Developer）

2.大家熟悉三角色的职责

3.彼此说出: 喜爱的沟通方式、脾气的接受区间、彼此的雷区

4.一同订出团队的工作协定

5.先试行2个Sprint

6.每一个Sprint都要都要一同回顾检讨及修正

C8:如果在资源上的考量，有人同时在Sprint以及新项目中该分开管理或合并 (eg:晨会)

优普丰敏捷顾问回答: 

Scrum会议每个都有其目的，通常是要发会团队的自我组织。而公司的管理会议是管理的机制监控，员工是否达到其绩效。如果目的相冲突，就不建议合并一起开，要不然就会形成表面是敏捷会议，内里是管理监控机制. 那就是伪敏捷了。

C9:Scrum如何组成跨公司团队? (外部伙伴/委外厂商)

优普丰敏捷顾问回答: 

外部伙伴/外包厂商的人员要成为三角色的一员（开发团队），初期2~3个Sprint要积极参与面对面会议，项目的有时候可以接受用视频会议方式＆电子任务板等来进行沟通.

C10:Scrum团队的组成是由谁来组织?

优普丰敏捷顾问回答: 

SM或DT没有负责召募及裁撤成员的权力, 这是属于管理阶层的权力, 有时可以从内部召募适任的人来形成 SM+DT, 若内部无人力可再外部召募. 在此, PO我们假设是外部客户, 不会管理公司内部的员工. 

C11:Scrum Master 应该同时接住 Dev 工作吗?

优普丰敏捷顾问回答: 

如果人力不足时, SM也可以接DT的工作. 就是角色扮演要清楚. 例: 他在 Daily Scrum 也是要报告三个问题. 同时若发现有人在 Daily Scrum 讨论三个问题以外的问题, 也要随时纠正.

SM唯一不能兼的角色是PO, 因为PO是要求团队绩效, SM则是保护团队避免被PO予取予求. 两者由同一人角色扮演, 会形成角色失衡.

C12:Scrum Dev Team 应该同时承接2个以上的项目吗?

优普丰敏捷顾问回答: 

就公司的商业利益及成本来看，开发团队只做一个项目是很难的，故可能同时承接2~3个项目，但要做好自己的时间管理和PO间的协调（轻重缓急）

敏捷的精神是期望团队可以做到Co-location与Delicated. 做两个项目是没有符合后者, 但是公司的成本考量一人做多个项目只能折衷. 故, 仅能让成员做最少的项目及一次只做一件事情 (不 Multi-tasking)

C13:团队如何证明自己在错综复杂的工作中越来越有效?

优普丰敏捷顾问回答: 

个人的部分可以用用户故事完成及被允收的情况来评估, 团队可以用交付产品让客户允收及满意度来评量, 团队可以用每个Sprint的速度来评估, 团队可以用共好的情感来评估.

常见问题D

D.PO问题:PO需求无限上纲，导致许多重工、成本激增、PO被过度授权、团队不合理频繁交付、疲于奔命

D1:Project Manager 可以当 Scrum Master吗?

优普丰敏捷顾问回答: 

思考这问题前，建议先将 PM 与 Scrum Master 这两个角色定义清楚。若是你所认定的PM是指采用瀑布式生命周期来带领项目的传统式项目管理者的话，那就不建议你以同样的方式来担任Scrum Master。但是，若你是现在遇到了组织变革，组织希望你未来能以敏捷方式带领项目的话，只要你能成功转型成 Scrum Master，并教育组织及团队理解与接受 Scrum 的话，那你当然可以担任 Scrum Master职责。不过，由传统式领导型的PM 转变成仆人式领导的 Scrum Master，其功能与思维真的差异蛮大的。另外，组织若想转换成以 Scrum Master 来带领项目的话，建议要先确认组织高层对于 Scrum 的期望是什么，以免他们将 Scrum 想象得过度美好。Scrum 并不会增加产出，也不会让团队变成超人。但 Scrum 可以让产品更容易符合客户的期望，成员也可以更有自信，更愉快地工作。

常见问题E

E. 文档管理问题: 文档太少要求，无法交付业主或公司知识管理（KM）系统

优普丰敏捷顾问回答: 

敏捷不是完全不要文档，而是更加关注产品首先能跑起来，能进行验证和反馈。有价值的文档需要写，可以后补，也可以考虑用可视化需求分析工具或BDD来替代文档。

常见问题F

F. 项目

F1: Impact mapping、 DDD算是Agile的手法吗? 

优普丰敏捷顾问回答: 

不是，Impact mapping 与DDD皆是Agile的辅助工具而已，应用范围不止是敏捷。impact mapping（影响力地图）是最近很多团队会使用在敏捷项目上的技术，有时也可使用 user story mapping（用户故事地图），以协助团队关注系统的全貌。这是因为，撰写程序前，如果对于所开发的系统缺少「整体感大局观」，最后的系统设计就很容易长歪掉。另外，Domain-Driven Design；DDD（领域驱动设计）不是只专注于技术上，而是专注于与开发人员及领域专家的讨论与交流，以达成共识，并在此基础上建立一个domain model 与通用语言，有这两项的话，后续不管你想怎么设计，都可以得心应手。

F2:scrum/sprint planning 如何运用在 sales/marketing 工作上?

优普丰敏捷顾问回答: 

可以参考这本书

F3:所有项目都可以敏捷吗?系统重构该怎么拆敏捷story以及周期

优普丰敏捷顾问回答: 

不是所有的项目都适合用敏捷，主要是客户需求不明确+创新的项目( Stacey Model) 才适合, 依照适合的工作量(2~3天能完工的), 拆成一个用户故事. 这种方式对于无形产出的知识型项目很合适, 例如: 资讯系统开发

重构是属于DoD的一环, 也是User story task的一部份. 如果整个系统所有程序都完成后才来重构, 那一定是会来不及, 所以该每个Sprint都该做好自己的重构, 以满足DoD. 

像传统产业的建筑工程或是地铁工程就无法使用敏捷, 因为没有办法阶段性交付给客户, 要全部盖好, 试车OK后, 方能全部交付给客户. 如果客户不喜欢打掉的话, 就会浪费许多成本. 

F4:How to measure progress if my product is not a software, is a campaign or an event or an activity?

优普丰敏捷顾问回答: 

可正常运作的软件只适用于软件产业, 若是非IT项目, 试想每个 Sprint 能产出客户什么价值? 例: 市场营销项目分成4个Sprint, 每个 Sprint 提供客户可以使用行销方案, 文宣, 文案… 这些产出客户皆可马上使用及创造价值, 我们称之为 Working “System”. 

F5:没有自动化测试的公司可以跑 Agile ? (常常瓶颈QC) 以及质量的管理

优普丰敏捷顾问回答: 

基本上使用敏捷很重要的一点在于团队会进化，工作的方式会改善，减少浪费。如果经过多次的改善后，解决了QC瓶颈问题，那就已经解决了问题。如果开发的产品或服务需要并进行频繁的部署，减少上线后出错的负担，改善分析结果需要自动化测试，减少人力浪费，增加团队效率，那就建议增加自动化测试。一个很简单的准则是考虑运转的工作量和收益。

F6:非IT项目的DoD可否举例

优普丰敏捷顾问回答: 

DoD 指的是一套通用的检查表, 任何给客户的 Feature 都要满足这些检查表的内容. 以出菜为例, 某一星米其林餐厅每道菜皆应符合：

• 菜色好看
• 闻起来香
• 味道好吃
• 卫生
• 装盘
• 健康: 少盐、少油、少味精

本文由优普丰敏捷学院和台湾长宏共同整理，版本:2020/03/24