小弟在資策會有開班, 教授 Scrum 和 extreme program. 如果有需求的人, 歡迎來參加.
時間: 101年 10/13(六)、10/14(日)與10/20(六) ( 週六、日白天 9:30 ~ 16:30 )，共3天、計18小時。
網址: http://www.iiiedu.org.tw/ites/AgileXP.htm
目前分類：Scrum (126)
- Sep 06 Thu 2012 14:24
敏捷式開發實作班
小弟在資策會有開班, 教授 Scrum 和 extreme program. 如果有需求的人, 歡迎來參加.
時間: 101年 10/13(六)、10/14(日)與10/20(六) ( 週六、日白天 9:30 ~ 16:30 )，共3天、計18小時。
網址: http://www.iiiedu.org.tw/ites/AgileXP.htm
- Jun 21 Thu 2012 09:33
站立會議的時間?
站立會議的時間?
在 SCRUM 中站立會議是, 每天同步資訊和及時解決問題不可或缺的元素. 因此你需要固定好開會時間, 開會的地點, 以方便會議的進行, 和讓大家養成習慣.
通常書上或是blog上, 會說這會議的時間最後在早上, 也就是一天開始的時候. 這時候大家來談昨天做了甚麼, 今天要做甚麼, 以及遭遇了什麼問題, 會是有意義的, 因為時機點和這三個問題是相配合的. 因此我也對此不成文的規定, 堅定不移.
可是隨著所帶領的專案越多, 或者說遭遇更多不同的團隊後, 覺得一早開站立會議似乎不見得都適用.
在台灣很多高科技公司是責任制, 也就是可能上班不用打卡, 可是可能要做到半夜. 對於這樣的團隊, 若是你還規定 9 點或是 9 點半開站立會議, 似乎對於團隊士氣是種打擊. 也許站在專案經理的角度, 你想要求團隊成員有較長的工作時間, 並且加上Scrum 站立會議問題和時間的搭配性, 因此你可能會堅持在這個時候開會.
隨著時間的轉移, 越來越體會到士氣高昂的團隊, 和有品質的工作時間, 是遠遠比一早開會還重要.
- Jun 17 Sun 2012 16:05
回顧會議的重要性 (The importance of retrospectve meeting)
回顧會議的重要性 (The importance of retrospectve meeting)
上週五, 我們團隊招開了第一次回顧會議, 個人覺得效果很好, 把平時沒說的話都說了出來, 或許不見得沒有保留, 但至少跨出了第一步.
你可能會很驚訝, 為何會是第一次? Scrum不是每次sprint完後都要舉行一次回顧會議?
是的. 這是目前我們的困境. 我們專案是由兩個小組所組成, 平時溝通並不是很密切, 兩個小組在不同樓層, 不同的軟體開發流程(一個waterfall like, 一個scrum like), 不完全相同的老闆, 因此彼此累積了不少問題.
很多時候我們都急著想要去交付東西, 急著趕上進度, 可是卻沒有時間思考. 沒時間問問自己, 做這些事情有幫助我們的產品大賣嗎? 那些是顧客要的嗎? 或者如何驗證那些是客戶要的?
- Mar 01 Thu 2012 18:01
Scrum Team Structure
看了Succeeding with Agile第十章, 整理了一些重點, Enjoy it.
http://www.slideshare.net/ssusere62027/team-structure-11754492
http://www.slideshare.net/ssusere62027/team-structure-11754492
- Dec 01 Thu 2011 06:54
Ch 14 Sprint - Succeeding with Agile: Software Development with Scrum
Ch 14 Sprint - Succeeding with Agile: Software Development with Scrum
這是我整理Succeeding with Agile一書中14章的內容.
這是我整理Succeeding with Agile一書中14章的內容.
- Nov 01 Tue 2011 15:27
甚麼時候不適合使用scrum
甚麼時候不適合使用scrum
When Not to Use Scrum
http://www.scrumcrazy.com/When+Not+to+Use+Scrum
author: Charles Bradley
很多人常常問我, 甚麼狀況下不適合使用scrum. 因為很多人認為他們的project, 適不適合使用scrum的.
- Oct 03 Mon 2011 21:50
組織影響學習結果
組織影響學習結果
最近在看蕭老師所寫的"讓脈絡思考創新"一書, 其中有一段話讓我感觸深刻.
他提到在分析脈絡時, 要考量組織的作為. 因為組織的所發展出來的運行原則, 會影響創新運行的有效性.
就像武俠小說中的屠龍刀, 一般人拿到只能耍耍花槍, 只是一把鈍兵器. 當武林高手拿到後, 應用他原先的內功或招式, 才能變成一把真正的寶刀.
拿到推行 scrum 這件事情上面, 也有同樣的結果.
- Sep 26 Mon 2011 14:23
目前台灣有那些Scrum的教育訓練課程
目前台灣有那些Scrum的教育訓練課程
小弟特地上網查了一下, 發現目前在台灣, 對於Scrum or Agile的相關訓練, 還真是少的可憐.
1.XP/Agile敏捷式開發實作班
小弟開的課程.
http://www.iiiedu.org.tw/ites/AgileXP.htm
- Sep 23 Fri 2011 16:30
Ken Schwaber 和 Jeff Sutherland對Scrum Guide的修正
Ken Schwaber 和 Jeff Sutherland對Scrum Guide的修正
Ken Schwaber and Jeff Sutherland Release Updated Scrum Guide
http://www.infoq.com/news/2011/07/UpdatedScrumGuide
Ken Schwaber 和 Jeff Sutherland 在2010二月時, 對Scrum Guide 做了一些更新, 它是一份獨立的檔案, 並沒有整合到原先的 Scrum Guide.
在這分文件中, 提到有些改變很有趣:
- Jul 12 Tue 2011 10:11
常見Agile不容易實施的緣因
常見Agile不容易實施的緣因
1. 用waterfall的方式來run sprint
雖然名稱叫agile,但是所有工作都是循序進行，要等前一項做完，下一項才能接著做. 需求分析完,才能架構設計。架構設計完才能寫程式，程式寫完才能做測試。自然永遠都無法如期完成, 測試永遠被壓縮或是放在下一個sprint.
2. 不知道如何拆解user story
每次都是一個很大的功能,要放進兩週的iteration. 不知道可以拆解成小的user story.或者拆解完後不知道架構設計要怎麼做。因此往往一個sprint要一個月或一個半月，才能完全開發完畢，但是測試還是要下個iteration才能做完，並且也沒有時間修改上個iteration的bug.
- Jul 08 Fri 2011 17:12
Succeeding With Agile讀書會
Succeeding With Agile讀書會
目前在Facebook的Scrum in Taiwan的community, 發起一個讀書會.
是針對Succeeding with Agile" Software Development using Scrum這本書. Schedule規劃如下:
7/9 Ch14(David),
7/16 Ch15 (David),
7/23 Ch11 (Sam Ku)
- Mar 21 Mon 2011 16:02
產品擁有人的十個主要工作
產品擁有人的十個主要工作
Top 10 Activities of the Product Owner
http://agilesoftwaredevelopment.com/blog/jackmilunsky/top-10-activities-product-owner
1. 建立和維護產品的 backlog
2. 根據商業價值和投資報酬率, 排定 backlog 的優先順序
3. 持續把 epic, theme, 和 feature 展開成使用者故事, 好讓其詳細程度可以足夠在一個 sprint 內完成.
- Feb 19 Sat 2011 21:41
執行 Scrum 時常見的錯誤
之前和朋友討論, 發現在實施 Scrum 時, 一旦執行不順的時候, 團隊成員或是經理們, 常常認為是 Scrum 的問題, 以下是早期常見的現象:
1. 想把 Scrum 用在所有的地方
- Dec 15 Wed 2010 21:44
實施Scrum可以帶來時麼好處?
實施Scrum可以帶來時麼好處?
有人問到, 採用Scrum會帶來甚麼好處? 會不會縮短時程, 或者品質更好, 或是做多功能?
答案當然是不能, 這些東西目前我都沒有遇到. 我不認為Scrum是銀製子彈, 事實上也沒有銀製子彈.
就個人經驗而言, 我覺得在採用後, 我們的團隊得到以下好處
1. 建立一個自我組織, 自我管理的團隊
- 有甚麼比一個團隊願意自動自發去做事, 還能讓你更高興呢?
- Dec 08 Wed 2010 21:12
剛開始要導入Scrum的團隊要注意甚麼?
- Dec 06 Mon 2010 07:07
Command and Control是Scrum的大敵?
Command and Control是Scrum的大敵?
最近看了幾個團隊在執行Scrum, 發現了一個有趣的現象.
若是團隊的主管比較是屬於command and control型的, 團隊成員會比較被動, 也就是一口令一個動作, 比較不會自動自發.
習慣Command and control的團隊, 在daily scrum時, 團隊成員通常都是面向經理報告, 比較不會對其他有關的成員講述他的進度.
和其他成員之間不會有眼神的交流, 不會彼此用眼神互相示意.
- Dec 05 Sun 2010 17:40
進度的追蹤 - ScrumBut的實例分享
進度的追蹤 - ScrumBut的實例分享
在使用task board追蹤成員的工作進度時, 通常我們會搭配一些方法來追蹤進度
一般常見的方式, 是查看task board上的task, 這樣我們就可以知道團隊的狀況.
也就是每天在daily standup前, 對於task board的工作先以檢視, 看看是否有哪些工作已經落後. 若是有落後的工作, 在daily standup進行時, 便仔細加以聆聽, 已知道他的狀況或是遭遇的問題是甚麼. 在daily standup結束之後, 視狀況來給於幫助.
雖然這個專案想用scrum的task board來追蹤進度, 可是因為對MS Project比較熟悉的關係, 所以使用了MS Project來取代了task board.
用MS Project會讓我們有以下的好處和壞處:
- Nov 23 Tue 2010 08:21
沒做Release Planning Meeting會產生甚麼問題
沒做Release Planning Meeting會產生甚麼問題
Relase planning是要讓大家了解, 在下一次的release中有那些事情要完成, 並且大約花多少時間來完成. 以及在每個iteration中, 會完成哪些功能. 它要的只是一個預測, 而不是要一個承諾. 重點是要讓每個人都知道相同的訊息.
對於agile, 大家只知道agile就是要有iteration, 因此會做iteration planning. 可是對於release planing, 通常大家很容易忽略掉.
可是經過幾個專案之後, 我發現若是沒有release planning會有以下問題:
1. 無法對長官交代時程
因為沒有整體的時程的評估, 長官不知道你是否會準時交付, 以及會有那些milestones可供他做風險評估或檢驗
- Oct 11 Mon 2010 09:13
Task Board二三事
Task Board二三事
最近觀察了一下新團隊在run task board時, 有以下的問題
1. Task的內容
- 常常每個人寫的都不相同, 通常這是manager沒有要求, 所以導致每個員工做法都不相同
- 每個task至少要包含task name, owner, 以及預估的日期時間.
- 若是有要用burn down chart, 每個task 的story point要標上去, 以方便計算
- Aug 01 Sun 2010 21:04
Scrum 的八項缺點
Scrum 的八項缺點
Scrum/Agile Failings or the Theses of Uncle Bob Martin
http://www.infoq.com/news/2010/02/scrum-failings
Uncle Bob在二月時提出對Scrum的批判, 每點都直擊要害, 我自己是十分認同. 不過令人興慰的, 到目前為止, 有不少先知對這些缺點, 提出不少解法.
http://groups.yahoo.com/group/scrumdevelopment/message/44851
1. No technical practices
