Ruddy Lee 分享空間

Emergent Design 演化設計

在竹科上SCRUM的課程: reading SCRUM

with 5 comments

與第二組可愛的隊員合照

在竹科上SCRUM的課程

第一次試著運用讀書會的方式,把原本應該是程式開發的一次Sprint的迭代過程改成運用閱讀來進行(好棒! 我稱他為 Reading SCRUM),在為期三天的敏捷開發法 SCRUM課程中實際的run了一次 Sprint, 真是有趣,效果也比我預期的好太多了,看到很多人性的可取面,第一次上SCRUM課程感覺得這麼累,但卻這麼過癮~~~真是教學相長!

讀書會的專案設計

下面是讀書會的專案設計文案,有興趣的人請參考,過程挺精彩的,或許是這群學員的求知慾望旺盛吧! 我總覺得自己好像一下子年輕了好多好多~~

Listing 出來的書都真的買來了,其中(2) Succeeding with Agile ,by Mike Cohn依照組數買了許多本,花了不少精力把這些書扛過去,但看著學員們閱讀時的專注表情,真是太值得了! (雖然成本增加了許多,但我一定會繼續做下去的,因為太值得了,SCRUM的講師們有興趣的話,不妨試試看,這也證實了 SCRUM 的多方面運用性)。

為了這個課程把清明掃墓祭祖的家庭活動延了下來,夜深了…讓人倍感思念已經過世多年的老爸老媽,好想念您們!

專案文檔

專案文檔


有一點要特別提醒講師的,那就是不要輕估了學員們閱讀的能力,千萬別把範圍訂得太小了~

總是會有一二個團隊把閱讀的範圍定在只挑選單獨的一本書及裡面的一個章節上頭,說得好聽是集中精髓–精讀,但基本上是見樹不見林。一般的老闆最討厭這種情形發生了,他總希望專案能做到的功能越多越好,這一點講師們可以把專案鐵三角拿來作機會教育,「範圍 – 資源 – 時間」的調整練習,但千萬別犧牲了中間的品質。這是最值得強調的了。

Written by ruddyllee

2011 年 04 月 16 日 於 18:07:47

張貼於未分類

Tagged with ,

5 回應

Subscribe to comments with RSS.

  1. 李老師你好~
    因為我們實驗室本身也有在跑 Scrum 的流程
    我看到3.3的地方
    其實這個地方我一直很困惑,就我所知所謂的Definition of Done
    可以包括以下的項目

    1.做到某些功能才能符合Done
    2.測試涵蓋率超過某個程度、測試全過才能符合Done
    3.靜態分析的check list全都通過後才能符合Done
    4.code review的check list全通過後才能符合Done

    但在整個Scrum跑下來的流程中似乎已經沒有什麼時間能夠將這些項目涵蓋進去了,但如果捨棄掉某些項目相對的程式碼的品質也會相對低落
    這樣的衡量下DoD的做法在Scrum應該怎樣才是最恰當的呢?

    還有第二個小問題~哈
    是我個人對於Scrum的一個小問題
    因為研究生難免都會接學長姐的專案
    如果有一天有學生接到的是一個有黑洞(問題有點的多)的專案
    在Scrum這種有 Time Box 的壓力之下到底應該要怎麼樣解決這種問題呢?

    希望老師不會嫌我問題很多…🙂

    ninja31312

    2011 年 04 月 17 日 at 01:15:33

    • 都是很實際的問題(你客氣了),值得釐清一下… 提問出來,雖然不見得能夠得到正確的解答,但至少可以紓解一下心情。
      (這是SCRUM在團隊開發上要求減少成員數目,多做溝通的價值所在,“提問"是最重要的開始,唯一要注意的是發問的技巧)

      先回答第二個問題,Ken Schwaber說: 「開發團隊首先瀏覽整個開發需求,考慮可用的技術,並對自身技術及能力做出評估。然後共同確定構建功能的方案,並每日調整方法,以應對新的複雜問題、困難和出乎意料的情況。團隊找出並選擇最佳方案去完成任務。」
      SCRUM 開始運行的前提: 考慮可用的技術,並對自身技術及能力做出評估。如果團隊沒做出正確的評估(由技術的觀點來看)就出手接案子,那不論是運用哪一種開發法來做都會失敗的。
      適當的把學習的時間也評估進去,才不會做得人仰馬翻,千萬不要做到吐血為止,那就是Sprint 的回顧會議開得太草率了些,沒能真正正視到團隊的狀態!
      但話說回來,老闆接案子沒讓團隊先進行評估,這是所有團隊都會碰到的問題! 記得把這篇回覆轉給他參考,適當的吐一下苦水是好的! 下次可以先考慮來一下POC,或許會好上許多,但也不一定,很快的你會覺得要做就做,POC 太多很累人的。

      ruddyllee

      2011 年 04 月 17 日 at 08:18:46

      • 至於第一個問題就不用回答了,只要客戶點頭就對了。若是小功能沒法讓客戶參與,那扮演客戶的傢伙(product owner)說對就好了。

        常常有工程師把只會被執行個幾回就一輩子不會再被執行到的程式;寫得完美的一蹋糊塗,真是太愛乾淨了。真是愛做白工… 還不如早一點睡來得有價值,其碼會活的健康些,程式只要在他被需要的生命週期內活得好好的,就ok了! 這就是done了。

        ruddyllee

        2011 年 04 月 17 日 at 17:12:19

  2. 其實第一個問題是我幫學長問的,因為他目前的論文就是想如何將code review這個活動引進Scrum中DoD的一部份,所以我想要多方的聽取一下意見
    看看能不能多些幫助,其實我也覺得設一堆綁手綁腳的規定和標準雖然能夠提升程式碼品質但有時候也常常會逼死程式設計師

    至於第二個問題,哈~
    我還不太清楚POC是什麼勒,我會好好去找找方法融合老師給的意見
    期待能夠縮小黑洞 = =

    btw
    老師,說好的長髮勒,我滿想看看老師目前留長頭髮的樣子~

    ninja31312

    2011 年 04 月 17 日 at 19:40:51

    • POC 就是 Proof of concept 的意思,是用來驗證想法或架構是否正確,試著運用較短的時間來開發功能較不完整的而可工作的儲型,僅供證明某些觀點而開發來驗證用的東東,做多了是相當勞民傷財的。

      哈!頭髮嘛;二邊長長了些,中間則依然如故~

      ruddyllee

      2011 年 04 月 17 日 at 20:05:56


發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: