背景
項目
我們的這個項目背景比較簡單，本質上是爲業務部門做一個類OA系統。它的功能主要是把一些線下的工作流程轉到線上處理。只不過與一般的行政管理流程相比，它涉及的業務專業知識更多、處理流程也更復雜。
有一點必須特別指出：我們組是中途接手、而非從零開始做這個項目的。在我們組接手時，這個項目已經完成了一半左右的需求。之所以強調這一點，是因爲有人認爲敏捷模式更適合於做新項目，而非接手老項目。但我認爲並非如此。我這一次接手老項目的敏捷之旅算得上很成功，但後來與另一支團隊以敏捷模式做的新項目卻以失敗告終。說到底，敏捷能否成功的關鍵在於人，而非人所面對的項目。
組織架構
組織架構方面，我們整個部門採用的都是強項目、弱職能的矩陣式架構。項目相關的工作由專門的項目團隊負責，除了項目工作之外的行政、人事等方面的管理工作則由各成員所屬的職能部門負責管理。
強項目的組織架構確實有敏捷有很大的幫助。有一位高人說，敏捷團隊要求項目組成員100%投入到項目中去。這種組織架構確實能很好的保證這一點。而且，強項目架構能夠讓項目團隊更有凝聚力，讓大家在項目工作中更有Owner意識、更有自組織性。
但是強項目架構可能會帶來其它問題。最常見的就是項目組之間壁壘森嚴、溝通協作簡直難於上青天。各項目組之間的產品同事之間很少溝通產品方向，開發同事之間很少有分享開發技術。各項目組之間的協作往往要靠更高層的領導來強推——即使如此也經常會有攬功諉過的現象發生，鬧得皆大不歡喜。而且，如果項目劃分不合理，項目組之間就容易出現業務重疊、產品雷同、系統重複等問題，很容易出現同一個功能要重複開發、或者同一個bug卻沒人跟進等問題。不過這屬於項目制的問題，與敏捷沒有太大關係，這裏就不展開討論了。
人
剛開始，我們項目組只有四個人，後來穩定爲六個人。業務部門同事S姐擔任產品。擁有四五年工作經驗的C姐負責項目管理和部分開發工作；當時只有一年半工作經驗的我負責主要的開發和運維工作；後來加入了兩個應屆畢業的開發小妹妹W和L；測試工作則由多年測試經驗的H姐負責。
（也就是說，除了我之外，整個項目組裏全是姑娘。而且這個項目做完之後，又招入了兩位姑娘。這就是爲什麼這一篇的標題是“我和姑娘們不可不說的故事”哈哈哈）
由於產品同事的本職是業務人員，所以S姐不在IT職場辦公。這爲我們的需求溝通製造了一點困難。所幸她對系統有非常明確的規劃，對項目需求池、迭代需求和需求優先級都成竹在胸。而且，因爲自己就是系統的最終用戶，她對需求的理解也入木三分，對我們的疑問總能在一兩天內給與明確的答覆。所以不在一起辦公造成的影響微乎其微。從與S姐合作的經驗來看，產品人員對項目的長期規劃和對業務的理解程度這兩點非常重要。我甚至認爲，產品人員可以不瞭解技術，但是必須深刻地理解業務需求。否則的話，敏捷迭代從需求階段就帶着“先天不足”，輕則導致後續工作被迫縮減範圍、放棄質量或壓縮時間，重則引發不斷的變更、返工和無用功，不僅打亂迭代節奏和項目計劃，而且非常打擊項目組的士氣，最後事倍功半甚至狼狽收場。
團隊中的四名開發人員（S姐、我、W和L）是敏捷團隊的主力，但是我們誰都沒有敏捷開發的經驗，甚至連開發經驗都略顯不足。這是我們“取經路上”的第一難。但是，“禍兮福所伏”，“一張白紙”未嘗不是我們的一個優點。在《灌籃高手》中，安西教練曾對櫻木花道說：你是初學者，動作不自然是理所當然的；好在你沒有養成壞的習慣，因此，從現在開始你必須掌握正確的動作要領。魏文帝曹丕也曾說：“從前陽慶勸淳于意放棄舊的不實用的一套，並教給他實用的劍術。現在，我也希望鄧將軍（奮威將軍鄧展）捨棄華而不實的劍法，改學實用的劍術之道”。我們是敏捷的初學者，會走彎路是理所當然的；但是，我們也沒有養成壞的習慣，沒有那些“華而不實的劍法”。面對“正確的動作要領”、“實用的劍術之道”，我們不會受困於過往的經驗並泥足不前，而能很虛心也很快地接受、理解並落實新的開發模式和工作方式。實話說，如果團隊沒有這種學習和接受新事物的態度和能力，我們的這次敏捷之旅會何去何從，實在未可知也。