實習的第乙份工作是在某一線遊戲公司做遊戲客戶端實習生，大的公司或許在管理制度上的確要更加完善先進，這是不可否認的，整整實習了一年，差不多是半年的客戶端實習生，半年的專案管理實習生，那麼談談我自己對敏捷開發的看法。
一.每日站會
剛到公司的時候，每天早上我都發現旁邊的伺服器組準時在10點，所有人站在一起，悄悄的說十多分鐘的事，偶爾還會在旁邊的白板上勾勾畫畫，然後就散了。觀察了很久，我甚至不知道他們在幹嘛，甚至於剛開始我還以為以為伺服器組怎麼每天早上都在一起閒聊一會。之後後來我問了他們在幹嘛？我們客戶端也實施同樣的方式。我才知道我們在做一件事----敏捷開發中的每日站會。
1.時間問題：站會開始時間一般在上班半小時內，或者午飯前十五分鐘，上班半小時內舉行可以讓大家同步完資訊後，立刻投入到工作，午飯前十五分鐘則是為了在吃飯這個前提下，讓大家高效的溝通完。時間長度則一般為15分鐘，需要有人進行時間控制。
2.站會目的：每日站會的目的則是高效的同步資訊，方便今天一整天開展工作。通常形式是每個人說一下自己昨天做的事，今天做的事，遇到的困難。一輪站會下來，團隊可以高效的完成同步資訊這個操作。白板的框架大致就是上面的這張圖。我們專案這段時間內要做的事分成乙個個story，每個story在細分成乙個個小的task。story一般是乙個功能，工時大概在一周以內，而task則是將這個story繼續拆分得來的，拆分粒度一般是乙個task保證在乙個工作日內完成。我們將task的狀態分為todo， doing， done。每個task，我們使用一張task貼紙標註詳細內容。內容有task開始日期，預估工時，負責人。需要用貼紙的顏色來變現task的緊急程度，即優先順序（紅》黃》藍），然後根據task的狀態將其每天進行狀態更新。
為什麼使用白板？最大的因素是方便團隊成員清楚的知道我們最近的大目標是什麼，將自己的工作以目標為導向，知道自己在團隊中的角色，自己做的事對團隊大目標的關鍵性。其次是資訊同步，知道團隊成員各自在幹什麼
上面的兩個原因也決定了白板的形式不是一成不變的，而是不停的優化，從而達到最適合團隊的使用。
三.擁抱變化，迅速反應
因為網際網路產品的開發充滿了不確定性，在已有的開發流程中，突發一些情況是非常的正常。按照以往的瀑布式開發，產品功能，原型設計好交付開發，這時候開發就根據詳細文件開始自己的工作，接下來pm 就很少接觸這件事。但是問題來了，等這個產品開發上線後，可能已經一年半載過去了。那麼你上線的產品起初設計時的大前提是否還存在？前提存在，是否又出現其他影響因素？往往這時候上線的產品已經不合適市場的要求。所以瀑布式開發的確點是顯而易見的。但是瀑布式也有優點，程式設計師喜歡瀑布式，因為當初約定好的功能點後期不會改變，這對開發工作是十分友好的。而現在的敏捷開發呢？pm會在任何時候提出自己的新想法，或許不著急上線，但是整個產品的設計永遠不是事先約定好的，而是在不停的優化。
因為經常出現不確定性因素，開發人員對敏捷開發常常是抱著負面態度的。但是團隊的目標是做一款適合市場的好產品，那麼敏捷開發又不失為很好的選擇。
我們在這裡宣揚「擁抱變化，迅速反應」。把這種改革性的思想傳授給整個團隊，這是需要一定的軟技能。當我們發現需要改變的設計時，我們接受且迅速作出反應。因為我們工作是以目標為導向，而大的目標就是一款好的產品。
**
我所接觸的敏捷開發
自從進入這個專案以來，我們採用的是敏捷開發，本部有八個專案組成員，客戶那邊有乙個on site，剛開始專案leader進行資料庫設計，以及任務模組分配，每個人都分到乙個或者幾個模組，然後進行開發，從頁面做到資料庫，這樣子下來每個人都對整個專案結構有個大概了解，隨著專案的進行，隔著一段時間，發布乙個版...
我所認知的BIOS ADU exe
by lightseed 2009 5 12 在學習的過程中，肯定會要用不少的工具，作為底層的 engineer 那麼用的工具大多是 dos下。在 dos下所用的工具對於一般的人來說 相對於當今流行的圖形介面的作業系統 總是感覺比較陌生，也批著一層神秘的面紗。那麼今天我就以我最常用的 adu.exe...
我所認知的 ANT DESIGN
由於工作的關係對於 react 並沒有過度的深入，因此對 ant design 並無太多了解。當然也是因為工作中存在大量的 angular 專案，後來ng zorro antd的發布引起我極大的關注。當我決定基於ng zorro antd發布一款企業後台管理模板 ng alain 之前，我深深被 a...