在整個團隊經過三面牆的快速對整個專案的三個方面進行整理了解之後
,接下來便開始了開發的流程.
因為專案是新開始的
,沒有乙個現有的開發框架或平台
,所以初始階段搭建框架的工作顯得十分迫切
.如果沒有乙個基本的開發框架的話
,其他的開發人員也是沒有進行相關的開發.
因為基本的專案架構的內容已經設計完成
,接下來需要根據架構來搭建相關的開發框架
,所設計到的技術都有
kissy,bui,springmvc,spring,dubbo,zookeeper,ibities,mysql
集群等.
這些技術是組成開發框架的基本支撐
,因為涉及行業及相關的保密協議
,這裡不再對具體框架的內容進行說明了.
搭建開發框架的任務落在我跟另外乙個同事的身上
,我們兩個運用了敏捷開發裡的結對程式設計方式對整個系統的雛形開始動手了.
大概我們兩個人用了乙個星期的時間
(中間加班到十點十一點是很正常的事情
……)從資料庫底層到頁面上層的分布式框架基本搭建成功
.這個過程我還是比較欣慰的
,因為雖然在過程中遇到了很多的問題和困難
,但基本上都能夠解決
,兩個人結對程式設計的默契度還是非常的高的
.我們遇到主要的困難是集中在分布式這塊,因為
dubbo
和zookeeper
這塊是我們之前沒有接觸過的內容
.對於新的事物我們還是比較興奮的
,在這個過程中通過學習
,解決問題再學習.
另乙個遇到比較大的困難時沒有網路
,由於工作性質的原因
,銀行內部開發是對安全非常的重視
,我們的工作機裡的系統都是行裡統一給分配的虛擬機器
,大家都是在虛擬機器裡進行開發和設計
.因而以前給力的巨人
--網路
,我們基本上是指望不上了
.可以想象一下沒有網路工作的樣子
,不過現在反過頭來看
,快兩年的時間基本上已經習慣了無網路的工作環境
.但總感覺有點與世隔絕的味道.
所以在沒有網路的環境下
,結對程式設計可以在一定程度上能夠把無網路的不利因素化解一些.
這裡要對結對程式設計進行一下說明.
敏捷開發是十幾種開發方法的統稱，極限程式設計就是這十幾種開發方法之一。極限程式設計包括了十幾種實踐（就是一些具體做法），結對程式設計是極限程式設計的一種實踐。
結對程式設計技術是乙個非常簡單和直觀的概念，能達到事半功倍的工作效果。但是，人與人之間的合作不是一件簡單的事情
,尤其當人們都早已習慣了獨自工作的時候。兩個有經驗的人可能會發現配對程式設計裡沒有什麼技能的轉移，但是讓他們在不同的抽象層次解決同乙個問題會讓他們更快地找到解決方案，而且錯誤更少。
在我們平時的程式設計當中，如果遇到乙個非常難解決的問題（困難到對該專案產生厭煩的態度），那麼你勢必會希望錄求幫助，無論是從資訊量龐大的網上
(這個路暫時在我的工作環境中是不通了
)，還是從身邊的同事那裡，我們都會努力去解決。這個時候不妨採用結對程式設計試一下，其它的不說，可能感覺就不同。搭建開發框架是筆者對結對程式設計一次感覺良好的實踐體驗.
敏捷開發 怎麼驗收敏捷故事
接著上篇 估算故事 講，故事估算完成以後就要開始考慮如何進行驗收測試了，只有驗收通過故事才算開發完成.對於乙個故事，開發人員和客戶可能會討論很多，討論的內容可以以測試用例的形式記錄下來，這樣就為我們故事測試做了鋪墊，目前敏捷開發中測試大約有如下2個步驟 1 將測試要點記錄到敏捷的故事卡的背面，任何時...
我跟敏捷開發的故事 三面牆
在上篇文章中提到 敏捷開發並不是萬能的 而是要結合自己公司的特點和問題摸索出適合自己的一套模式。而專案剛開始的時候 也就是我們整個團隊開始摸索敏捷開發的時候.第一次開始正式進行會議是把所有的相關人員都集合到乙個會議室 在這會議室有三面牆 一面是窗戶玻璃.為什麼要提會議室的三面牆呢 這時候是敏捷教練開...
敏捷開發之故事牆
需求澄清後，se把所有的故事卡貼到故事牆上，等待開發人員的開發。故事牆的模板為 分析 需求澄清完成後，se把所有的故事卡都貼到分析階段 等待開發 開發人員和se確認了需求，明確了做什麼以及怎麼做以後，把故事卡從分析階段移到等待開發 開發中 開發人員一次只開發一張故事卡，把相應開發的那張卡移植到開發中...