敏捷CSM/ACP培训常见FAQ知识管理看板

敏捷需求分析学习心得 | 穿过这片云雾,前方一片广阔
2021年4月25日
Certified Scrum Master-CSM Certification Course in English-January 2022-Online-Agile Project Management Core Training
2021年5月8日

常见问题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: 如果上级有ㄧ个紧急任务要团队的人去执行,而这时也才开完 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:项目

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

评论关闭了。

拨打免费咨询电话 021-63809913