2016年3月28日 星期一

PO或老闆:軟體甚麼時候能夠上線?甚麼時候可以給客戶用?

PO或老闆:軟體甚麼時候能夠上線?甚麼時候可以給客戶用?
1. 列出必要開發的功能(PBI)
2. 並依重要性排出優先順序(Priority)
3. 必要功能粒度相對大小評估(T-Shirt Size)S, M, L, XL
4. 使用sprint0進行穿刺實驗(Spkie)
(1) PBI中挑選SML各一個項目放入sprint0,開始開發
(2) 開發過程中,紀錄SML各需要多少Story Point(開發時間)
(因為是估算,其實精確在幾點幾分完成不是重點,真正耗費的總時數才重要,為了統計平均用)
(3) 推算一個sprint的產出速率 (每個sprint可以產出多少story point)
注意PBI size 是否有大到超出 sprint 的範圍,也就是一個 sprint 做不完某一種 size PBI 。若有此情況,則需考慮拆細 PBI 並調校 size 的定義。
5. 所有的PBI進行 story point加總
6. 初估團隊速率與專案完成時間
7. 每次sprint結束後,持續修正團隊速率與PBI size的估算,看看是否還是能夠如期完工。(Yesterday weather)
8. 重新檢視與評估需要的完成時間
(1) 按照目前速率,是否能如期完成所有功能
(2) 如果無法如期完成,有甚麼選項可以選:
        1) 延期 (團隊工作速率(工時)不變):需要延多久
        2) 調整功能重要性順序,刪減較不重要的功能 (團隊工作速率(工時)不變):刪哪些就可如期完成、只刪去AB功能,要延期多久可以交付軟體
        3) 加班(增加工時):每天要加班多久,才能如期完成

舉例:若SLM分別用了51320 Hr,這三個PBI共用了1週的時間完成,則:
* 團隊的Velocity(5 Hr + 13 Hr + 20 Hr) / 0.5sprint = 76 Hr / sprint
(通常一個完整的sprint為期兩週,所以1週就是0.5sprint)
* SLM size 對應的 story point 基準為5 Hr13 Hr20 Hr
* 專案總共有SML2PBI完整的product backlog76 Hr。目前已經完成SML各一,剩下的 product backlog 大小為 38,只需要38 Hr / 76 Hr/sprint = 0.5 sprint就可以完成,也就是1週。


{Reference} 

Why are software development task estimations regularly off by a factor of 2-3?
[英文]
https://www.quora.com/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe?srid=kw
[中文]
http://www.inside.com.tw/2013/10/24/why-the-last-20-of-work-takes-the-same-amount-of-time-as-the-first-80

Why Software Development Estimations Are Regularly Off
https://diegobasch.com/why-software-development-estimations-are-regu

Scrum EstimationStory Points and Planning Poker

https://dotblogs.com.tw/hatelove/2015/11/23/scrum-estimation-story-points-and-planning-poker

Scrum Estimation-如何估算專案時程

https://dotblogs.com.tw/hatelove/2015/12/19/scrum-project-schedule-estimation

Scrum Estimation-Dog Point Game

https://dotblogs.com.tw/hatelove/2015/12/01/scrum-estimation-dog-point-game

2015年7月15日 星期三

[C#] 停止Thread的運作

一個可能的做法是,使用Join方法,並結合while,讓Thread充分地完成工作後再停止。
工作到一半緊急地停止,也容易讓資料變得不完全,難以除錯。
但如果真的停不下來怎麼辦?? 設定Retry次數??

while (thread.ThreadState ==  ThreadState.Running)

{
   thread.Join(10);
}

2015年7月10日 星期五

Loops 的 OOP 奇幻之旅 (1) - by Loops

[楔子]

上了Bill的課程,不,應該是更早之前,一個莫名的悸動,促成了我與Bill這微妙的緣分。

時空拉回到,那個佇立在風雨交加夜晚中的小咖啡館... ... ...

OOP,近乎禪」
坐在我面前的Bill,不疾不徐地說出了這句話。或許我不應該稱呼他為Bill叔,比爾禪師也許更為恰當!?

Bill接著說:「其實我們大腦看待世界的方式,本來就是物件導向式的。而物件導向很重要的一個核心概念,就是抽象化。我問你,甚麼是抽象化?」

在這一瞬間,我驚呆了。對於抽象二字,我除了畢卡索其他甚麼都想不起來啊!
我甚至開始懷疑,今晚我與禪師邂逅的公案,會不會超過10個人按讚... ...TAT

正當我還在煩惱的當下,接下來Bill說的話,讓我一輩子也忘不了。


[第一章:被神化的模式(Pattern)]

「在回答抽象化這個問題之前,先岔題一下。你信裡面有提到看過設計模式的書籍。很多學習寫程式的人,常常會想要『套用某個模式到某個專案中』,這反過來了。」


咦!?


「你要想的是...    你 。 想 。 解 。 決 。 什 。 麼 。 問 。 題     




「解決問題的過程中,你會發現,這些你想出來解決問題的『方法』,就是書上面說的『模式』」


咦 咦 咦!?


從後背尾椎一股竄流而上直衝腦門的十萬伏特電流,讓我不禁夾了個冷筍。

這單純、簡單、樸實卻又直搗核心的觀念,輕易地摧毀了那被我神化了的設計模式宮殿,炸裂出一株擁有23個末節分枝的大樹。

我彷彿聽到Erich Gamma一派輕鬆地坐在枝頭上哼著必昂濕的I am Singleton~ I am Singleton~


如果這不是美,那甚麼才是美?




 (未完待續... ...)

2015年7月2日 星期四

軟體設計:像地圖一樣縮放

古語云:「大處著眼,小處著手」 這句話應用在Coding也是一樣 1. 把視角放大,描述需求 2. 將需求中的關鍵步驟做出流程

2015年6月29日 星期一

Interface 中的 屬性 get & set

如果希望Class實作Interface中的property,但是只希望該property具有下列特性:

{get; private set;}  封裝set的方法


這時候的Interface中宣告該property時,只能包含get


interface IPerson
{

    double Height { get; }


}

Class Person : IPerson
{
    public double Height {get; private set;}

}
interface中的屬性不能宣告為private set,否則會出現下列錯誤訊息:"Height.set': accessibility modifiers may not be used on accessors in an interface" 但如果宣告成set,Class的實作interface時,該屬性一定要一併宣告成set,否則會出現下列錯誤: "Name.set' is not public."