我所認知的敏捷開發

　　實習的第一份工做是在某一線遊戲公司作遊戲客戶端實習生，大的公司或許在管理制度上的確要更加完善先進，這是不能否認的，整整實習了一年，差很少是半年的客戶端實習生，半年的項目管理實習生，那麼談談我本身對敏捷開發的見解。

 

一.每日站會

　　剛到公司的時候，天天早上我都發現旁邊的服務器組準時在10點，全部人站在一塊兒，悄悄的說十多分鐘的事，偶爾還會在旁邊的白板上勾勾畫畫，而後就散了。觀察了好久，我甚至不知道他們在幹嗎，甚至於剛開始我還覺得覺得服務器組怎麼天天早上都在一塊兒閒聊一會。以後後來我問了他們在幹嗎？咱們客戶端也實施一樣的方式。我才知道咱們在作一件事----敏捷開發中的每日站會。

　　1.時間問題：站會開始時間通常在上班半小時內，或者午餐前十五分鐘，上班半小時內舉行可讓你們同步完信息後，馬上投入到工做，午餐前十五分鐘則是爲了在吃飯這個前提下，讓你們高效的溝通完。時間長度則通常爲15分鐘，須要有人進行時間控制。

    2.站會目的：每日站會的目的則是高效的同步信息，方便今天一成天開展工做。一般形式是每一個人說一下本身昨天作的事，今天作的事，遇到的困難。一輪站會下來，團隊能夠高效的完成同步信息這個操做。

    3.站會人數：正常一個小團隊大概保持在10我的之內，而且爲了提升你們的主人翁意識，須要每人輪流作站會主持人，主持人主要負責控制每一個人的發言時間，改變白板上任務狀態。

 

二.白板的使用

 

　　白板的框架大體就是上面的這張圖。咱們項目這段時間內要作的事分紅一個個Story，每一個Story在細分紅一個個小的Task。Story通常是一個功能，工時大概在一週之內，而Task則是將這個Story繼續拆分得來的，拆分粒度通常是一個Task保證在一個工做日內完成。咱們將Task的狀態分爲Todo， Doing， Done。每一個Task，咱們使用一張Task貼紙標註詳細內容。內容有Task開始日期，預估工時，負責人。須要用貼紙的顏色來變現Task的緊急程度，即優先級（紅>黃>藍），而後根據Task的狀態將其天天進行狀態更新。

    爲何使用白板？最大的因素是方便團隊成員清楚的知道咱們最近的大目標是什麼，將本身的工做以目標爲導向，知道本身在團隊中的角色，本身作的事對團隊大目標的關鍵性。其次是信息同步，知道團隊成員各自在幹什麼

    上面的兩個緣由也決定了白板的形式不是一成不變的，而是不停的優化，從而達到最適合團隊的使用。

    三.擁抱變化，迅速反應

    由於互聯網產品的開發充滿了不肯定性，在已有的開發流程中，突發一些狀況是很是的正常。按照以往的瀑布式開發，產品功能，原型設計好交付開發，這時候開發就根據詳細文檔開始本身的工做，接下來PM 就不多接觸這件事。可是問題來了，等這個產品開發上線後，可能已經一年半載過去了。那麼你上線的產品起初設計時的大前提是否還存在？前提存在，是否又出現其餘影響因素？每每這時候上線的產品已經不合適市場的要求。因此瀑布式開發的確點是顯而易見的。可是瀑布式也有優勢，程序員喜歡瀑布式，由於當初約定好的功能點後期不會改變，這對開發工做是十分友好的。而如今的敏捷開發呢？PM會在任什麼時候候提出本身的新想法，或許不着急上線，可是整個產品的設計永遠不是事先約定好的，而是在不停的優化。

    由於常常出現不肯定性因素，開發人員對敏捷開發經常是抱着負面態度的。可是團隊的目標是作一款適合市場的好產品，那麼敏捷開發又不失爲很好的選擇。

    咱們在這裏宣揚「擁抱變化，迅速反應」。把這種改革性的思想傳授給整個團隊，這是須要必定的軟技能。當咱們發現須要改變的設計時，咱們接受且迅速做出反應。由於咱們工做是以目標爲導向，而大的目標就是一款好的產品。

未完待續。。。。