2015年3月28日 星期六

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日 星期六

什麼是設計?

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年3月14日 星期六

一個星期換一個晚上

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

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

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

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

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

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

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

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

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

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


2015年3月7日 星期六

敏捷式思考訓練

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

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

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


總共玩了五個回合

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

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

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

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

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

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


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

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

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


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

持續練功打問號