我們部門是一個基礎(chǔ)平臺研發(fā)部門，主要為其他各部門提供技術(shù)接口和服務(wù)支持。

    也正是由于這個特性，部門內(nèi)正在考慮基于wcf搭建一套服務(wù)平臺。

    部門內(nèi)提倡敏捷開發(fā)，談?wù)勎易约簩γ艚莸暮唵卫斫狻?/p>

    對需求做足功課

    個人認為敏捷的前提是要對需求做充足的功課。

    一、明確需求

    比如我們每天都要為別的部門提供很多接口，在開發(fā)過程中逐漸發(fā)現(xiàn)我們其實做了很多重復(fù)性的工作。

    同時大量的技術(shù)接口（webservices調(diào)用、post調(diào)用）非常分散，難以管理。針對這種情況，我們迫切的需要一套統(tǒng)一的服務(wù)平臺。

    我們的目的就是能夠提供各種部門之間甚至是公司對外合作的技術(shù)接口支持。具體這個平臺叫什么，都包括什么，可能還不是很明確。

    二、合理的拆分需求

    我們的目的很明確，所以我們決定對目前的需求進行分析。通過和各部門同事交流我們對目前存在的需求做了分析。一是從業(yè)務(wù)上拆分，我們可以

    得到很多子系統(tǒng)。二是從技術(shù)上考慮，我們理出一些通用的基礎(chǔ)的功能以及支持業(yè)務(wù)擴展的功能。這樣呈現(xiàn)在我們面前的就是一個個經(jīng)過組合的子系統(tǒng)。

    雖然目前的這個模式還是沒有名字，不過我們已經(jīng)有了進行下去的勇氣。

    在我們了解需求的過程中，部門的同事都會提到兩個字“目前”。“這是我們目前的工作?！?，“這是我們目前存在的問題”。

    沒錯，沒人敢預(yù)測未來。我們也沒打算做一勞永逸的系統(tǒng)。但我們該如果應(yīng)對變化呢？

    了解變化點，我們做不到預(yù)測未來。但我們可以盡力去掌握哪些地方有可能變，哪些地方會經(jīng)常變。甚至能分析出他會朝著那個趨勢變。

    齊頭并進開發(fā)子系統(tǒng)

    一、“并列式”開發(fā)

    將開發(fā)團隊分割成小組，不同的子系統(tǒng)交由各個小組負責(zé)開發(fā)。大家可以同年同月同日開工，不一定非得同年同月同日完成。總比一條線的“瀑布”要快的多。

    二、關(guān)注代碼，以人為本

    不必在開發(fā)的每一個階段整理無窮盡的文檔。整齊的代碼更能體現(xiàn)程序員的智慧?？梢詻]有詳細設(shè)計，這樣其實更不害怕變化。

    沒有計劃變化也就無所謂變化了。

    三、迭代

    這是迭代法的解釋：迭代法也稱輾轉(zhuǎn)法，是一種不斷用變量的舊值遞推新值的過程,跟迭代法相對應(yīng)的是直接法（或者稱為一次解法），即一次性解決問題。

    敏捷開發(fā)中鼓勵迭代，周期性的停下來歇一歇，看看過去幾天寫的東西，整理整理思路。其實這是我們在自己尋找變化。所以說敏捷的核心思想是適應(yīng)變化！