scrum敏捷開發團隊之旅
agile是關於軟體產品開發的一種思想、一種價值觀（[url= for agile software development（敏捷軟體開發宣言）[/url]）。強調[color=red]以人為本、迭代開發、增量交付、持續整合、積極反饋[/color]。
從廣義上講，如果能[color=red]持續地進行單元測試[/color]以及[color=red]快速響應業務變化[/color]那麼它就是敏捷。[color=blue]今天做的比昨天好那就是敏捷。[/color]
[url=敏捷宣言遵循的十二條原則[/url]
參考：[url=中文網[/url]
敏捷有很多實現。它們包括：極限程式設計（xp），scrum，精益開發（lean development），動態系統開發方法（dsdm），特徵驅動開發（feature driver development），水晶開發（cristal clear）等等。[b]所有這些方法都具有以下共同特徵，它們也是敏捷開發的原則和方法[/b]：
[list]
[*]1.[color=red]迭代式開發[/color]。即整個開發過程被分為幾個迭代週期，每個迭代週期是乙個定長或不定長的時間塊每個迭代週期持續的時間一般較短，通常為一到六周。
[*]2.[color=red]增量交付[/color]。產品是在每個迭代週期結束時被逐步交付使用，而不是在整個開發過程結束的時候一次**付使用。每次交付的都是可以被部署到使用者應用環境中被使用者使用的、能給使用者帶來即時效益和價值的產品。
[*]3.[color=red]開發團隊和使用者反饋推動產品開發[/color]。敏捷開發方法主張使用者能夠全程參與到整個開發過程中。這使需求變化和使用者反饋能被動態管理並及時整合到產品中。同時，團隊對於使用者的需求也能及時提供反饋意見。
[*]4.[color=red]持續整合[/color]。新的功能或需求變化總是盡可能頻繁地被整合到產品中。一些專案是在每個迭代週期結束的時候整合， 有些專案則每天都在這麼做。
[*]5.[color=red]開發團隊自我管理[/color]。擁有乙個積極的、自我管理的、具備自由交流風格的開發團隊，是每個敏捷專案必不可少的條件。人是敏捷開發的核心。敏捷開發總是以人為中心建立開發的過程和機制，而非把過程和機制強加給人。
[/list]
xp(extreme programming)是乙個針對某種特定環境（需求變化快的小型團隊）的具體過程實施模型和方**。xp[color=red]更多地聚焦工程實踐[/color]，如單元測試、持續整合、結對程式設計等
rup（rational unified process）是乙個風險驅動的基於uml 和構件式架構的迭代遞增型開發過程（框架）。
[url=在中國——企業實施情況調查實錄[/url]
scrum是從[color=red]專案管理角度[/color]出發，[color=red]遵從敏捷宣言指導原則[/color]，定義在軟體開發時需要遵循的一系列規則。它是乙個[color=red]敏捷過程[/color]，是一種採用[color=red]迭代式[/color]、[color=red]增量開發[/color]的開發軟體過程。
如果我們說15分鐘的standup meeting： 它並不是agile需要的，scrum需要它。
[b]敏捷社群代表張克強重申了敏捷社群的基本原則：[/b]「通過在[color=red]互相尊重（respect）[/color]的基礎上，[color=red]充滿勇氣（courage）[/color]的進行有效的[color=red]交流（communication）[/color]和積極的[color=red]反饋（feedback）[/color]，任何問題都可以用乙個盡量[color=red]簡單（******）[/color]的方式解決。
[b]只要不養成習慣，失敗是件好事情！[/b]
[b]羅馬手勢[/b]
全部人員都要表達意見： 同意、不同意
[b]透明性[/b]
八元老鼠肉漢堡故事
[b]少數服從多數？[/b]傾聽理由，是否有特殊情況、特殊理由需要照顧。盡量照顧到每個人 - [color=red][b]team[/b][/color]
scrum聯盟的certified scrum master(csm)、csp（certified scrum professional）認證： [b]認證有必要嗎[/b]？重要的是過程，得到認證的過程中付出的努力，學到的東西。
[b]「豬」和「雞」的故事:[/b]
一天，一頭豬和乙隻雞在路上散步。雞對豬說：「嗨，我們合夥開一家餐館怎麼樣？」豬回頭看了一下雞說：「好主意，那你準備給餐館起什麼名字呢？」雞想了想說：「叫『火腿和雞蛋』怎麼樣？」「那可不行」，豬說：「我把自己全搭進去了，而你只是參與而已。」
[b]乙個國外小學生做的實驗：[/b]
一群小學生通過一道簡單的題目被分成'effort'努力組，即智商不那麼高的一組，和'smart'組，即智商比較高的一組。然後讓兩組繼續做選擇題，結果奇怪的是，'effort'組更喜歡選擇難題，接受挑戰，獲得提高。但'smart'組則傾向選擇簡單的題目，迴避挑戰，結果喪失了挑戰的機會。
[b]如果你真的想做一件事，你一定會找到方法； 如果你不想做一件事，你一定會找到藉口。[/b]
[b]無計可施/消防員救人的故事：[/b]
以下是發生在丹麥首都哥本哈根的一則真實故事。
***的電話總機在[color=red]清晨三點[/color]收到乙個電話。二十二歲的年青消防員，艾利希在值班。
「喂喂！這裡是***」。
電話的那端沒人回答，可是艾利希聽到一沉重的呼吸聲。後來乙個十分激動的聲音，說：「救命，救命啊！我站不起來！我的頭血在流！」
「別慌，太太」，艾利希回答，「我們馬上就到，您在那裡？」
「我不知道。」
「不在您的家裡？」
「是的，我想是在家裡。」
「家在哪裡，哪條街？」
「我不知道，我的頭好暈，我在流血。」
「您至少要告訴我您叫什麼名字！」
「我記不得了，我想我撞到了頭。」
「請不要把電話掛掉。」
艾利希拿起第二具電話，撥到電話公司。回答他的是乙個年老的男士。
「請您幫我找一下乙個電話客戶的號碼，這客戶現在正和消防總隊通電話。」
「不，我不能，[color=red]我是守夜的警衛，我不懂這些事。而且今天是星期六，沒有任何人在。[/color]」
艾利希掛上電話。他有了另乙個主意，於是問那女人：「你怎樣找到***的電話號碼的？」
「號碼寫在電話機上，我跌倒時把它給拖下來了。」
「那您看看電話機上是否也有您家的電話號碼。」
「沒有，沒有別的任何號碼。請你們快點來啊！」那女人的聲音愈來愈弱。
「您告訴我，您能看到什麼東西？」
「我 … [color=red]我看到窗子，窗外，街上，有一盞路燈。[/color]」
好啊－艾利希想－她家面向大街，而且必定是在一層不太高的樓上，因為她看得見路燈。
「窗戶是怎樣的？」他繼續查問，「是正方形的嗎？」
「不，是長方形的。」
那麼，一定是在乙個舊區內。
「您點了燈嗎？」
「是的，燈亮著。」
艾利希還想問，但不再有聲音回答了。
需要趕快採取行動！但是做什麼？
艾利希打電話給上司，向他陳述案情。
上司說：「一點辦法也沒有。不可能找到那個女人。而且，」他幾乎生起氣來，「那女人佔了我們的一條電話線，要是哪裡發生火警？」
但是艾利希不願放棄。救命是***員的首要職責！他是這樣被教導的。
突然，他興起乙個瘋狂的念頭。上司聽了，嚇壞了：「人們會以為原子戰爭爆發了！」
他說。「在深夜，在哥本哈根這樣乙個大都會裡！ … 」
「我懇求您！」艾利希堅持，「我們必須趕快行動，否則全都徒勞無益！」
電話線的另一端靜默了片刻，而後艾利希聽到答覆：「好的，我們就這麼做。我馬上來」
十五分鐘後，[color=red]二十輛救火車[/color]在城中發出響亮的警笛聲：每輛車在乙個區域內四面八方的跑。
那女人已經不能再說話了，但艾利希仍聽到她那急促的呼吸聲。
十分鐘後艾利希喊說：「我聽到電話裡傳來警笛聲！」
隊長透過收發對講機，下令：「一號車，熄滅警笛！」而後轉問埃里希。
「我還聽到警笛聲！」他答說。
「二號車，熄滅警笛！」
「我還聽得見 … 。」
直到第十二輛車，艾利希喊說：「我現在聽不見了。」
隊長下令：「十二號車，再放警笛。」
艾利希告知：「我現在又聽到了，但越走越遠！」
「十二號車掉回頭！」隊長下令。
不久，艾利希喊道：「又逐漸地近了，現在聲音非常刺耳，應該剛好到了正確的路上。」
「十二號車，你們找乙個有燈光的窗戶！」
「有上百盞的燈在亮著，人們出現在視窗為看發生了什麼事！」
「利用擴音機！」隊長下令。
艾利希經由電話聽到擴音機的聲音：「各位女士和 [color=red]先生，我們正在尋找乙個生命有嚴重危險的婦女。我們知道她在一間有燈光的房間裡，請你們關掉你們的燈。[/color]」
所有的窗戶都變黑了，除了乙個。
過了一會兒，艾利希聽到***員闖入房間，而後乙個男音向流動電話說：「這女人已失去知覺，但脈搏仍在跳動。我們立刻把她送到醫院。我相信有救。」
海倫．索恩達－－這是那女人的名字－－真的獲救了。她甦醒了，幾個星期後，也恢復了記憶。
那天清晨，哥本哈根市的消防報警中心不斷接到市民們詢問老婦人病情的電話，還有許多市民打來電話說，那天凌晨響徹哥本哈根市的警笛聲，是他們一生當中聽到的最動聽的聲音。
（agile 使用者故事與任務之間的區別
當這個問題第一次在我的csm 培訓課堂上被問到的時候，我認為，這是個非常簡單的問題。可是當我試圖回答時，我意識到，事實上並不能簡單的釋解釋這個問題。在我的培訓課堂上，我已經用 使用者故事 和 任務 這兩種說法多年，在我頭腦中，兩種措辭是非常清晰的。使用者故事存在於產品待辦事項表中，而任務則是在做sp...
樸素的Agile觀
去年，對門部門的同事喊我一起去開scrum的研討會，分享一些他們的經驗。雖然他們確實在用scrum的流程和方法，但是我發現他們還是沒有看到問題的本質 1 關注人，別只關注專案。2 雖然流程可以阻礙生產力，但是流程不能提高生產力。提高生產力唯一的方法是請好的人 3 軟體行業中，沒有用的文件和ppt最浪...
00 B 使用者故事與敏捷方法前言筆記
00.我們貼近我們的使用者，向使用者展示我們一點一滴，這樣便在不知不覺中發現乙個不需要漂亮的需求文件就可以成功的方法。01.a.大量預先的需求收集和文件會以很多方式導致專案失敗。最常見的是需求文件程式設計軟體開發的目的。應當只在對交付軟體有用時才寫需求文件 b.大量預先的需求收集和文件導致專案失敗的...