在上篇文章中提到
,敏捷開發並不是萬能的
,而是要結合自己公司的特點和問題摸索出適合自己的一套模式。而專案剛開始的時候
,也就是我們整個團隊開始摸索敏捷開發的時候.
第一次開始正式進行會議是把所有的相關人員都集合到乙個會議室
,在這會議室有三面牆
,一面是窗戶玻璃.
為什麼要提會議室的三面牆呢
? 這時候是敏捷教練開始讓大家一起活動了
,首先因為整個團隊是新組建的團隊
,對整個系統的框架,架構
,業務,流程等內容都不是很了解
,敏捷教練為了讓大家能夠在最短的時間內去消化這些內容
,就依託這三面牆來對比較核心的內容進行互動
. 這三面牆分別是業務
,技術架構和流程.
這裡需要再進一步解釋一下
,因為對於乙方而言要做的內容是空白的
,不知道具體的需求,技術
,架構等內容
,但是甲方已經對相關需求進行深入了解分析
,架構也有乙個模糊的模型
,這三面牆下都有乙個主負責人對其進行具體的解釋和說明.
比如在技術牆前
,架構師會對整個專案的架構進行說明
,這裡所有的人員都要進行仔細的聽
,看清楚
,是所有的人員
.因為當架構師講完之後會找人來對其進行描述說明
. 從這裡我們可以看到敏捷對個人的要求是比較高的
,這點很重要.
哦,忘了說了
,這裡的牆都是玻璃可以寫字擦除的牆
,下面會有進行示例,當然
,如果沒有條件的話可以拿紙條往牆上貼.
具體流程是這樣的
,整個人員先分三組
,三組人員各自在三個牆下
,然後聽各個主講人進行講解
.(當時的場面我個人覺得還是比較混亂的
…….)
當講述完畢的時候
,主講人會留下乙個人
,剩下的人然後輪轉到下乙個牆
,然後新來的聽眾們就開始聽留下人的講述
,當然主講人會對他出現的錯誤和不足進行及時的糾正
.然後大家就開始轉圈圈了……
在這個過程中你可以提出你的問題
,你可以在牆上畫畫寫寫
,總之最大限度的把你不知道的內容不清楚的內容去了解它.
技術牆上的一角
整個專案團隊通過三面牆的方式對整個專案的技術,業務
,流程有了乙個初步的認識
,這裡只是初步
,因為在具體的溝通交流中還有很多疑問
,很多未知點
.這裡沒有什麼是固定死的.
這個階段還處於初始階段
,除了一些文件
,沒有任何**
.這三面牆就是讓團隊對要做的事情有初步的了解.
會有讀者
到這裡感覺三面牆好像跟敏捷還沒有太大的關係
,我也是這麼認為的
, 而且接下來的事情跟所謂的敏捷也沒有什麼太大的關係.
敏捷開發（三） 估算故事
前兩篇文章介紹的是 蒐集故事和編寫估算，本篇文章接著前面的文章往下說，有了story 故事 之後如果對故事進行估算 下面主要是進行估算的大體checklists 對與乙個故事的估算方法應該具有如下特點 1 執行改變估算結果 2 適用於所有的故事 3 很容易很簡單的進行估算，不需要花費太多時間 4 提...
我和敏捷開發的故事 結對搭建開發框架
在整個團隊經過三面牆的快速對整個專案的三個方面進行整理了解之後 接下來便開始了開發的流程.因為專案是新開始的 沒有乙個現有的開發框架或平台 所以初始階段搭建框架的工作顯得十分迫切 如果沒有乙個基本的開發框架的話 其他的開發人員也是沒有進行相關的開發.因為基本的專案架構的內容已經設計完成 接下來需要根...
敏捷開發使用者故事系列之三 使用者建模
這是敏捷開發使用者故事系列的第三篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 使用者建模的目的，是為了更好地分析使用者行為和使用者價值，並因此獲得商機。有一次培訓中，分組建模的時候，一位學員就自言自語地說了一句話 真的啊 我好像不知道誰會使用我的產品 這其實是一種常見的現象。比如前文所說...