Scrum初體驗(1) - Sprint Planing Meeting

2015/3/28 20:08-20:28

我們的Scrum Team共有六個人，
一個Product Owner、一個不懂Scrum的Scrum Master兼Developer、其餘4位都是Developer，在Spint Planning Meeting中有遇到2個問題：

1. Story在估點數的時候，如果每個人點數差異性一直過大，該怎麼辦？

2. PO怎麼知道這個Sprint要拿幾個Story

目前使用的估點數方法：

我們最後所採用的方法，首先看大家所估的點數是不是差不多，只要有一個人出的點數過大，會請他說明原因，再由PO或點數出很低的人解釋Story達成的複雜度，通常解釋完之後，第二回合點數的差異性會變低，但是我們最後估出來的點數是採用多數所出的點數，而不是全部點數加起來平均，剛開始還不覺得奇怪，但估到後面發現大家點數不一定會一樣，多少都會有差異，但目前還是遵照一開始的方法將Story估完，待下一個Sprint再改進。

目前估算這個Sprint要做幾個Story的方法：

第二個問題，點數估完了，開發人員將Story切成若干個Task，將每個Task估算時間。
我們團隊共有五位開發人員，這個Sprint共有三週，假設每個人每天工作一小時，所以一個Sprint，共有

5(人) * 1(小時) * 5(天) * 3(週) = 75 小時

這個Sprint就選入75小時的Story量。


整個Meeting耗時3小時，中間休息十分鐘，以Team的角度來看，發現要完成每個功能很簡單，跟著一群神一般的隊友。


結果會如何呢？讓我們繼續看下去

什麼是設計？

2015/3/21 15:59-16:32

這星期上北科大軟體生命週期，有點像在上哲學課，一上課Teddy照慣例問題轟炸。


Teddy：「什麼是設計？」

學生A：「確定要解決的問題。」

Teddy：「什麼是問題？」

學生A：「...」


經過一番苦戰，還是說不過Teddy。

什麼是定義？定義就是在所有情況下皆適用，而Teddy隨時都能把我們所認為的【定義】輕易用一個不適用的例子擊垮。

Teddy引用Alexander的想法：

這張圖有錯，圖中的Force不可能超出Context (2015/06/06 11:21)

設計就是決定Form在Context中的範圍。

Form
= Problem
= Solution

依時間性來看Form在設計的開始，通常是一個Problem，而在設計的最後，就會變為Solution。

------

什麼是好的設計？

在宇宙中，充滿了各式各樣的Force(作用力)，因為有這些Force的存在，才有Problem的產生。

Force就是這些Problem的特徵，無法抵消，只能平衡。

一個好的設計，就是將你的Form代入Problem，看這個Problem的Force有沒有被平衡，越平衡就代表這個設計越好。


這個定義好像到哪都適用耶，不愧是可以行騙天下的哲學！

------

解決問題時，要先找到問題。找到問題後，在開始研究作用力。

一個星期換一個晚上

2015/03/14 22:25-22:51

最近的Waterfall專案眼看就要到驗收時間了，但距離驗收合格的功能標準還差了一半左右，所以呢我們團隊必須利用一星期的時間完成為期一年的專案，這個專案牽涉到硬體到整個軟體的整合，我們團隊只負責開發軟體，但我們直到最後不到一個月的時間，才拿到完整的硬體可以開發，而且在每個專案成員都壓很緊的情況下，還必須負責維護舊有專案問題，就在一連串的阻礙之下，終於到了捷案的前一天...

這天還有許多工項沒有做完，大家似乎做好了熬夜的準備，今晚準備一起在公司奮鬥一晚，自己覺得即使奮鬥一晚，也不可能來的及將全部的工項完成，但也不敢和上司說，應該想想該怎麼跟客戶溝通延期，於是在上個星期四的夜晚和許多團隊成員們開夜車，功能最後一樣沒有完成，而且效率還很差，還把自己的身體搞得疲累不堪。

秉著敏捷的精神，撐到驗收時間後，和團隊成員們討論我們這次的瓶頸在哪裡，結論是承接的案子太多了，且每個專案都採用Waterfall的形式，所以大家一個瀑布沖完之後，接著又要趕場沖下一個瀑布。每次專案都急得要命，主管所給的時間都很短，完全沒有商量的空間，即使每個星期都有回報該星期的進度客戶，但對客戶來說，其實是我們創造出<有做完>的假象，實際上沒有完成整合，只有完成該功能的元件，但對上司來說，完成元件功能就等於完成該項功能。

但我想說，開發程式最難的地方其實不是完成某個小功能，而是把功能全部整合在一起

這些話最後我只講在心裡。

其實自己有很多內心戲應該要更勇敢地爭取，表達出來給上司聽，講在心裡也沒人知道你在想什麼。

那一夜之後，睡一覺起床就得了嚴重感冒，失聲一星期，喉嚨痛得要命。

看來已經不是新鮮的肝了 Orz

有問題就要說出來，會吵的孩子有糖吃

敏捷式思考訓練

2015/3/7 15:30-16:07

這學期繼續選修台北科大的軟體生命週期，授課老師就是Teddy沒錯，上課第二週，由這門課的助教Erica，這週主題是敏捷體驗設計工作坊。

在體驗這個活動的過程中，藉由遊戲來發現一些問題，然後持續改善，這個遊戲有數個回合，每一個回合都會有得分值，想辦法在限制時間之內把得分衝到最高，每一回合結束，Erica會在旁邊提醒：「瓶頸出在哪裡？」，但由於參與人員過多，在遊戲開始之前的討論時間有也限制，每個人都有他自己想到的方法，但要表達出來給每個人都遵循你的想法，又是另一回事，當自己講出想法之後，就會有其他人提出各種質疑，然後你就要盡你所能地說服別人，我就在心中會偷偷想說：「可以不要這麼白目一提出質疑嗎？試試看就知道了阿！」。


總共玩了五個回合

第一回合  20  分
第二回合  28  分
第三回合  25  分
第四回合   0   分
第五回合  80  分

第四回合因為大家還沒達成共識到底要用哪一種方法執行遊戲，所以當遊戲開始的時候，大家還是持續討論，討論不出個結果。

第五回合，大家呈現一個半放棄狀態，有一位同學，他提出了一個好像還不錯的辦法，但是他講了三次，在場的各位還是沒人聽得懂(包括我在內)，後來建議他直接執行一次他提出的方法，雖然還是有一很多別人質疑的地方，但眼看討論時間也已經來不及，大家就繼續使用該同學的方法進行遊戲，最後竟然爆衝到80分。

活動結束之後稍微反省了一下自己剛剛在遊戲中的想法，遊戲進行時，自己提出的方法被質疑就會有很多OOXX，反過來想，當別人提出他的方法的時候，我好像也會質疑他，繼續想著怎麼會質疑別人呢？

想了一下下～突然靈光乍現，好像是因為自己不懂對方到底在講什麼，所以提出很多質疑，然後對方就要想辦法說服你，表面象看起來是說服，實際上好像是要把你教懂，你懂了之後自然就不會有質疑。

會有質疑通常是因為還不懂，這個靈光乍要感謝一下＜打問號＞


人已經養成的習慣很難改，要把自己的不敏捷改變成敏捷，找泰迪軟體就對了。

說實話，Teddy所教的課是我上過最棒的課了！ (很貴是真的)

敏捷式的思考，不是述說一件事情完成的很快。


個人覺得敏捷思考的主旨，是要你發現問題的瓶頸，然後持續改善。
做事的方式靈活，能趕得上變化。

持續練功打問號