2016年3月28日 星期一

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

PO或老闆:軟體甚麼時候能夠上線?甚麼時候可以給客戶用?
1. 列出必要開發的功能(PBI)
2. 並依重要性排出優先順序(Priority)
3. 必要功能粒度相對大小評估(T-Shirt Size):S, M, L, XL
4. 使用sprint0進行穿刺實驗(Spkie):
(1) 從PBI中挑選S、M、L各一個項目放入sprint0,開始開發
(2) 開發過程中,紀錄S、M、L各需要多少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) 調整功能重要性順序,刪減較不重要的功能 (團隊工作速率(工時)不變):刪哪些就可如期完成、只刪去A或B功能,要延期多久可以交付軟體
        3) 加班(增加工時):每天要加班多久,才能如期完成

舉例:若S、L、M分別用了5、13、20 Hr,這三個PBI共用了1週的時間完成,則:
* 團隊的Velocity為(5 Hr + 13 Hr + 20 Hr) / 0.5sprint = 76 Hr / sprint
(通常一個完整的sprint為期兩週,所以1週就是0.5個sprint)
* S、L、M各 size 對應的 story point 基準為5 Hr、13 Hr、20 Hr
* 專案總共有S、M、L各2個PBI,完整的product backlog為76 Hr。目前已經完成S、M、L各一,剩下的 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 Estimation-Story 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."