顯示具有 Agile 標籤的文章。 顯示所有文章
顯示具有 Agile 標籤的文章。 顯示所有文章

星期六, 5月 14, 2022

[課程] 谷歌創新寶劍: 設計衝刺體驗營

課程資訊 


心得

自己有看書來運用,不過沒被人引導過Design Sprint,既然三叔公都要開課了,就快來學習一下,也來比較自己跟專業的落差(羞)。

先比較了Design thinking及Design Sprint差異,這也是課前我想問了
更清楚瞭解兩者不同,就能掌握應用情境


p.s. 原本是實體課程,但因為疫情創變嚴重,所以改線上課程,原本覺得可惜沒能學習實體引導技巧,但反而可以學習沒做過的線上引導技巧,上完課果然腦補了不少實用技巧,賺翻了。

筆記

  • DS介紹
    • 啟源
      • 做了沒人用
      • Brain Storming不可行 
        • 通常不會有出色的想法,出色的想法通常是討論後,獨立想出來的方案
        • 而且常會挑出不可行的方案
    • DS是framework
      • 給框架,但各自實做,所以都會不太一樣
    • DS步驟
      • 理解(收斂), 速寫(發散), 決策(收斂), 打模(發散), 驗證
    • 應用時機
      • 適合快速驗證想法;不適合需事先大量研究
  • 實做
    • Monday(理解)
      • 訪談調查
        • 事實,不是感受意見(會迎合訪問者)
          • 不方便,麻煩的點,要進一步問why
          • 目前怎麼做
        • 過程中記HMW(機會及挑戰)
          • 量比值重要
          • 邊說明邊grouping比較省時間
        • 投票
          • 大家認為最有問題及機會的點
      • Map
        • 目的:瞭解現在用戶的經驗,挑出焦點的部份(其中一個步驟)
        • 做法
          1. 列出actor  為了達到 goal的步驟
          2.  再把剛HMW投票最高的幾張貼到對應的步驟,即為焦點區域
    • Tuesday(速寫)
      • 用意
        • 團隊迷思(Group think)
          • 不敢講真話,做出錯誤的決定
        • Work alone together
          • 先看現況解決產生idea(lightening demo)
          • 再各自獨立思考(4 step sketch)
          • 再腦力激盪
      • lightening demo
        • 用意:抄idea, 不會是第一個遇到的,看目前有什麼解,供大家參考
      • 4 step sketch
        • 用意:表達每個人的想法,找出可行方案
        • 步驟
          • note
            • 摘要重要資訊及衝刺問題
            • e.g. 知道工作說明影響應徵意願,如何協助填寫
          • idea
            • 連結資訊,思考想法
            • e.g.參考缺乏未寫的工作說明,思考如何協助面試官填寫
          • crazy 8
            • 把一個想法,畫出8個變型
              • 有點難,二個想法,4個變型也可啦
            • 想法品質重於圖案美醜
          • Solution sketch
            • 針對最好的想法繪製
              • 遭遇的問題,體驗過程,美好結果
              • 善用文字說明
            • 重點
              • 比想法,非實做
              • 為每個解法給別名,避免用作者名,免被影響
              • 聚焦在問題是否有解決,不要因有新想法加新功能
    • Wednesday(決策)


      • 黏貼決策(Sticky decision)
        • 用意: No design by committee
          • 很多人設計,沒有統一看法,反而決定出不用好的東西
          • 先沈默投票避免爭辨、推銷
          • 稻草投票讓每個人有機會表達(給老板聽)
        • 步驟
          • 羅浮宮
          • 沈默投票
            • 投票及貼疑問
          • 快速評論
            • 由主持人帶領,避免爭辨、推銷
            • 整理突出構想、賣點
          • 稻草投票
            • 決定方案,及投感興趣的feature
            • 投票時,說明投票的理由
          • 超投票
            • 老板決定,避免做出老板不要的
      • 分鏡腳本
        • 重點
          • 讓人想買單
            • 把客戶,痛點, 解法畫出來講清楚
          • 表達想法
            • 想法示意非細節(e.g. app細節),重點在是否有解痛點
        • 步驟
          • 六個步驟
            • 各自用六個步驟簡述故事
          • 分享腳本
          • 投票
          • 繪製分鏡腳本
    • Thursday(打模)
    • Friday(驗證)
  • Design Sprint 2.0的差異
    • 5天=>4天
    • 先調察再訂Sprint Question
      • 先訂是猜問題,非真正的問題
      • 所以2.0建議先問user 

番外篇 - 線上引導工具與技巧
  • 分組討論用zoom 小組討論功能
    • 由於有不同小組,因此利用了分組討論可以避免被他組影響
    • 雖有定時間,但不強制關閉,因為每組狀況不一樣,所以coach要進入不同小組房間,旁聽提醒討論方向及時間,還有決定是否需延長或提早結束。這點也是當初在Daniel課程提到的,畢竟每次的狀況不同,coach就在邊隨時調整
  • 講義及workshop放一起
    • 通腦遠端只有一個螢幕,在討論的看板已佔用一個,要切換講義就不方便
    • miro上就可以把兩者放在一起,使用起來非常方便
    • 而且miro上看的到大家的鼠標,當某人發表言論時,可以藉由鼠標知道對方在講哪裡,連畫面也不用分享。事實上,分享了佔用畫面反而影響每個人想看的範圍
  • miro倒數計時小工具
    • 雖然分組討論是靠zoom,但畫面其實停在miro上,這時有miro有倒數計數就能提醒大家

星期四, 6月 18, 2015

Scrum是提早給feedback,但講好的需求,就是要上線啊

看到好多單位都能研究新的技術,並提出相關的應用
心裡在想為何別人能持續在技術有進步

公司最近有個顧問要離開
提到「這幾個月他工作滿開心的,因為沒有人assign工作給他,所以有時間鑽研他有興趣的議題」

也讓我回想到去年底時,因健況出了問題,在家專心養病
沒有時程壓力,便有時間大量閱讀某技術的相關資料
今年回來時,也帶顉同事使用該技術

後來在David Ko的Blog看到這張圖
要 Output 還是要 Outcome

讓我回想,回到工作崗位後,疲於趕user的feature,一直在拚output
如果省下時間只做有價值的產品
我想整個team都會有更多時間在打混開發更有價值的東西,以及技術研究上 XD

星期六, 6月 06, 2015

Kanban Board應放哪裡

因團隊是在會議室內,理所當然放會議室裡
daily meeting,討論issue等,也都在會議室內

由於自主管理,主管也不太曉得我們在做什麼
反正沒出什麼包,就放給我們自己玩
只不過都關在房間裡,有天反問我,不曉得team在做什麼
這實在很難解釋...

後來有個團隊沒有會議室,只好將看板貼在放走廊上
嘿~ 這還不錯,因旁人都看的到,感覺有在做事
所以也把看板搬出來了

幾天後主管就說感覺工作氣氛不一樣
每個team比較活絡有互動~

有時還是得表現給別人看(誤)

提早得到feedback,但調整也得花時間呀~ user老大

最近開始run scrum
每回合產出的項目,也讓user實際操作體驗
在正式上線前得到不少feedback及調整需求
感覺挺不錯的~

西嘎西!!! (日語:但是)
「需求要調整,原定的功能也得在原定時程完成,也就是上線的時程不變」
我咧...
開發單位:不是有說好需求要排優先,那優先權較低的可以拿掉呀
需求單位:所有的需求都已經砍過了,沒有辦法法再砍了,一定要全上...

怪不得的有團隊明明開發差不多了
卻說上線前幾天才能給user測試
私底下問,才得知user就不會有時間改需求
把球丟回給user...

這叫「上有需求變更,下有裝死對策」

星期四, 1月 08, 2015

導Agile可以,但品質要顧好

前陣子學Agile,懂了點皮毛,正在公司導Agile
最近主管回覆:「導Agile可以,但品質要顧好」
聽起來很不合agile的邏輯,想了好久

Agile是Rough, adaptive plan,不是No plan...

我在想主管應該是以為Agile是No Design, No Plan在開發
因此對Agile會有些品質的誤解
在 Henrik Kniberg 的 文章 What is Scrum? 裡有張圖還不錯


應該就能知道Agile是Rough, adaptive plan
而不是No plan的開發









品質應該更好... 顧吧

對主管的話特別有反應是因為....
Agile把feature size切小,不敢說小就簡單
但至少開發, Tester對該週期開發的feature掌握度高
即使出搥了,也能快速的找出問題修正

公司有個team
每個月上20多個features,要上線時都要搞半夜上線
一有問題,就得從這堆features找bug
我實在很佩服,問他們不會壓力很大嗎
還說不會哩... 真是神人....

每個release短一點,features少一點

如果改成每週上5個features,我想相對大家會容易應付些
雖然每週上線壓力有點大,不過總比一個月上20多個feature好一些
而且如同agile說的,也許剩餘的feature會因些feedback有所調整或消失...

星期四, 11月 20, 2014

Kanban: Successful Evolutionary Change for Technology Organizations

  • Continuous Improvement Culture
    • bottleneck
  • setup board
  • prioritize
  • WIP
    • preventing workers from becoming overloaded
  • Pull
  • Metrics & Management Reporting
    • Tracking WIP
    • Cycle Time
    • Due Date Performance
    • Throughput
    • Issues & Blocked Work Items
    • Flow Efficiency
    • Initial Quality
    • Failure Load