在很多場合, 會聽到很多人在討論 waterfall 和 agile 方法的比較, 不少人還是堅持 waterfall 或是 CMMI 不錯, 但是也有人覺得這些都是過時的做法.
不管這些方法是新是舊, 過時或是最新流行, 我想重要的是要問自己, 所遭遇的環境是否合適. 如果一切用的很順利, 準時交付, 並且品質很好, 那確實沒有還的必要. 個人覺得一切都是需求導向, 要真的有病痛才能吃藥.
目前分類：Agile Concept (204)
- Jan 10 Fri 2014 00:18
waterfall 開發方法的困境
- Jan 08 Wed 2014 06:44
為什麼要實例化需求
有人問說為什麼要使用實例化需求? 他跟之前的做法有什麼不同? 讓我利用 spec by example 書中的例子來解釋一下.
首先先問大家一個問題, 大家在這個圖形中, 可以找出多少個頂點?
- Jan 06 Mon 2014 07:23
實施 agile 一定要多技能團隊嗎?
在上次的聚會中, 有人提到在專案進行時, 會發生有人沒事做的現象, 原因並不是那位員工不認真, 而可能是以下幾種
- 不會那項工作所需要的技能
- 因為架構切割的關係, 導致大多數的人只會某些系統或是元件
我想這些是很常見的因素. 可是你的老闆並不會體諒這種狀況, 他會覺得你明明有 10 個人,(可是只有 2 個會寫 UI), 為什麼整體開發這麼慢. (因為會 UI 的人太少寫不快)
- Jan 03 Fri 2014 06:21
沒有銀製子彈, 只有嚴密防護網
有人問我在實施例化需求時, 為什麼一開始不在乎自動化? 如果能自動化, 不就一直可以確認開發人員, 是否照著當初所確認的需求去做, 並且也可以及時檢查. 為什麼呢? 我一開始認為有以下的理由:
1. 專案背景: 目前我的專案一開始需求很不確定, 老闆也不知道要做什麼, 所以重點不是在於自動化, 而是在於確認範圍是什麼.
- Jan 02 Thu 2014 07:02
實例化需求到底是什麼?
歷史背景
起初, 是在 Ward Cunningham 在 A Pattern Language of Competitive Development (http://c2.com/ppr/episodes.html) 一文中提到這個概念. 然後由Martin Fowler 把它命名為 spec by example (http://martinfowler.com/bliki/SpecificationByExample.html). XP 團隊利用這種方法來進行客戶的驗收測試.
後來 Ward Cunningham 還發展出 FIT 來進行自動化. 同一時期, Brian Marick, 在 Agile testing decisions: tests and examples (http://www.exampler.com/old-blog/2003/08/22/#agile-testing-project-2) 也有提到這件事情.
- Sep 03 Tue 2013 14:59
Scrum 為何推不動
最近在和別人討論 Scrum 時, 他們會覺得非常難推, 其中有些論點蠻有趣的
1. 必須要不斷衝刺
以前 waterfall只要衝一次, 從分析, 設計, 編碼到測試, 一次可能要半年或一年.
- Aug 13 Tue 2013 20:59
常見對敏捷開發方法的誤解
- Jul 22 Mon 2013 15:56
死亡行軍圖
死亡行軍圖
很多時候專案在忙或是壓力很大的時候, 人們常常會做出很多錯誤, 或者是說很蠢的決定, 可是大家卻不一定會說出來, 只是默默地繼續做事, 直到失敗那一刻來臨. 這就是所謂的死亡行軍.
在 agile 社群中, 有一個好玩的方式, 可以讓大家知道, 或者是讓大家宣洩一下內心的感想, 作法如下:
- Jul 16 Tue 2013 10:43
Agile 團隊的特徵
Agile 團隊的特徵
很多人問說 agile 團隊看起來是甚麼樣子, 或者問說這個團隊是否已經是 agile 化了? 這個問題可以用些簡單的方法來觀察:
(來源: Agile Experience Design)
1. 團隊會很吵
- May 13 Mon 2013 15:21
早釐清早處理
以前在瀑布式開發時, 是屬於大批次處理, 要分析做完, 再進行設計,一關完畢再處理下一關.
因此, 往往發現問題時, 大多是在測試末期, 或者是專案後期, 才知道專案的品質和時程, 都不如預期理想. 主要是因為大批次, 要道後面做完或是快做完, 才知道問題在哪. 此外也因為學生症候群效應, 大家都是在交作業前, 才會很緊張沒有做完.
- Feb 13 Wed 2013 09:34
文件真的很重要嗎?
文件真的很重要嗎?
當初開始教 scrum 時, 很多人問我敏捷宣言說不用寫文件, 這是真的嗎? 讓我們來看看原文吧
Individuals and interactions over processes and tools
當初開始教 scrum 時, 很多人問我敏捷宣言說不用寫文件, 這是真的嗎? 讓我們來看看原文吧
Individuals and interactions over processes and tools
- Jul 17 Tue 2012 14:14
如何進行user story map
如何進行user story map
How to create a User Story Map
http://winnipegagilist.blogspot.tw/2012/03/how-to-create-user-story-map.html
最近對於要如何處理複雜需求有興趣, 因此想知道user story map是否有幫助. 目前在網路上有不少文章討論,
但是還沒有相關書籍出版, 所以只能藉由一些文章來了解. 所以第一步, 先至少了解他是怎麼進行的
步驟
1. 成立一個3-5人的團隊, 這些人是了解產品的目的是甚麼.
- 若是少於這些人數, 可能會遺漏某些想法
- 若是超過這些人數, 可能會讓整個過程變慢, 導致無法產生足夠的好的想法
2. 在大家都不出聲的狀況下, 開始收集這個產品或是應用系統主要的user tasks.
- 這個user task是指使用者會做的事情
- 每個人使用相同顏色的便利貼來撰寫user task
- 每張便利貼只寫一件user task
- 一旦大家都寫完自己的user task, 便請每個人唸出他自己所寫的東西, 並且把它貼到白板上面
- 如果有發現重複的話, 便把這張便利貼移除
- 每個usere task的描述, 通常是動詞開始. 例如: compose e-mail, create contact 或是 Add user 等等
- 這些user task 是high level的user stories, 它組成了map的walking skeleton
3. 同樣在不出聲的情況下, 請大家把這些便利貼分組
- 把類似的task放在同一組裡面
- 如果發現重複的task, 要把它移除
4. 利用不同顏色的便利貼, 對每個群組命名, 並且把它貼在每個群組的上面
5. 根據使用者完成這些工作的順序, 由左至右來排列這些群組
- 這些群組叫做user activities, 它組成了map的backbone
A1 A2 A3 (user activities = backbone)
T1 T2 T3 T4 T5 T6 T7 T8 T9 (user tasks = skeleton & timeline)
6. 現在逐一檢視skeleton, 以確保我們沒有遺漏任何主要的user tasks 或是activities.
- 你可以利用user scenarios 或是利用使用者, 來檢視每件事情都被包含進去
7. 當你完成以上步驟時, 你可以增加detailed user stories 在user task下面. 並且把它們拆解幾部分, 以分不同時間發行
- 一開始可以先用silent brainstorming的技巧, 來產生每個user tasks最重要或是最初始的user stories.
- 然後再利用user scenarios and persona來增加user stories的內容
- 這樣你就可以請使用者來排出要發行的優先順序
How to create a User Story Map
http://winnipegagilist.blogspot.tw/2012/03/how-to-create-user-story-map.html
最近對於要如何處理複雜需求有興趣, 因此想知道user story map是否有幫助. 目前在網路上有不少文章討論,
但是還沒有相關書籍出版, 所以只能藉由一些文章來了解. 所以第一步, 先至少了解他是怎麼進行的
步驟
1. 成立一個3-5人的團隊, 這些人是了解產品的目的是甚麼.
- 若是少於這些人數, 可能會遺漏某些想法
- 若是超過這些人數, 可能會讓整個過程變慢, 導致無法產生足夠的好的想法
2. 在大家都不出聲的狀況下, 開始收集這個產品或是應用系統主要的user tasks.
- 這個user task是指使用者會做的事情
- 每個人使用相同顏色的便利貼來撰寫user task
- 每張便利貼只寫一件user task
- 一旦大家都寫完自己的user task, 便請每個人唸出他自己所寫的東西, 並且把它貼到白板上面
- 如果有發現重複的話, 便把這張便利貼移除
- 每個usere task的描述, 通常是動詞開始. 例如: compose e-mail, create contact 或是 Add user 等等
- 這些user task 是high level的user stories, 它組成了map的walking skeleton
3. 同樣在不出聲的情況下, 請大家把這些便利貼分組
- 把類似的task放在同一組裡面
- 如果發現重複的task, 要把它移除
4. 利用不同顏色的便利貼, 對每個群組命名, 並且把它貼在每個群組的上面
5. 根據使用者完成這些工作的順序, 由左至右來排列這些群組
- 這些群組叫做user activities, 它組成了map的backbone
A1 A2 A3 (user activities = backbone)
T1 T2 T3 T4 T5 T6 T7 T8 T9 (user tasks = skeleton & timeline)
6. 現在逐一檢視skeleton, 以確保我們沒有遺漏任何主要的user tasks 或是activities.
- 你可以利用user scenarios 或是利用使用者, 來檢視每件事情都被包含進去
7. 當你完成以上步驟時, 你可以增加detailed user stories 在user task下面. 並且把它們拆解幾部分, 以分不同時間發行
- 一開始可以先用silent brainstorming的技巧, 來產生每個user tasks最重要或是最初始的user stories.
- 然後再利用user scenarios and persona來增加user stories的內容
- 這樣你就可以請使用者來排出要發行的優先順序
- Nov 29 Tue 2011 09:31
改進團隊效率的方法 (上)
改進團隊效率的方法 (上)
16 ideas about what a Scrum Master can do to improve team performance, Urs Enzler
http://www.planetgeek.ch/2011/06/24/16-ideas-about-what-a-scrum-master-can-do-to-improve-team-performance/
1. 作一些非擅長的事
有時候開發人員不一定每次都做他們擅長的事情, 讓他們有機會嘗試一些不同的事情.
- Nov 27 Sun 2011 09:50
Adopting XP - 讀書摘要
- Sep 20 Tue 2011 07:19
2011 100本最暢銷的agile書籍
2011 100本最暢銷的agile書籍
Top 100 Agile Books (Edition 2011)
http://www.noop.nl/2011/08/top-100-agile-books-edition-2011.html
作者又整理出今年最暢銷的100本agile書籍. 其中前十本如下:
TY LY Title
1 5 The Art of Unit Testing: With Examples in .Net
- Aug 29 Mon 2011 22:25
Agile是否能一步到位
Agile是否能一步到位
有些問我, 很多團隊執行agile, 都不像書上講的那樣, 大多數是mini -waterfall 或是 scrumfall.
其實, 在一開始的時候, 大家無法做到書上講的境界這件事情是很正常的, 很少人是一開始學東西, 就能夠做到完美的境界. 這樣的要求是不切實際的.
可是那要怎麼辦呢?
個人認為重點是要continuous improvement.
- Aug 28 Sun 2011 19:27
那些project適合使用agile的方法來開發
那些project適合使用agile的方法來開發
Deciding What Kind of Projects are Most Suited for Agile
http://blog.mountaingoatsoftware.com/deciding-what-kind-of-projects-are-most-suited-for-agile
最近team member問我, 甚麼樣的專案適合執行agile. 這裡剛好有篇文章在探討.
- Apr 05 Tue 2011 16:33
如何建立Persona
如何建立Persona
A day in life of an AgileUX Practitioner: Personas
http://www.agile-ux.com/2011/03/08/a-day-in-life-of-an-agileux-practitioner-personas/
這系列的文章是在介紹agil UX的實踐, 在這篇文章內則是在介紹如何建立persona.
甚麼是persona呢?
Persona是某種典型, 或是虛構的使用者, 用來代表我們想找的目標用戶. 在處理產品, 功能, 視覺設計時, 你可以用它來輔助制定一些決策.
- Mar 07 Mon 2011 14:54
2010 Agile 開發方法的調查結果
2010 Agile 開發方法的調查結果
source: 5th Annual State of Agile Development Survey Final summary report, VersionOne
http://www.infoq.com/vendorcontent/show.action?vcr=1276
這分調查報告內容還蠻豐富的, 有些地方還超出我的想像. 我列出了一些我有興趣的項目
1. 使用哪種agile 方法論
Scrum (31%)
- Jan 21 Fri 2011 10:34
Salesforce 導入 agile 的經驗談
Salesforce.com 這家公司, 是目前聽到導入agile最成功的公司, 他不但持續了好幾年, 並且在一些研討會上都有發表相關的report. 若是你要導入agile, 他是很值得你研究的公司
1. Slides
Salesforce.com Agile Transformation - Agile 2007 Conference
http://www.slideshare.net/sgreene/salesforcecom-agile-transformation-agile-2007-conference
