Scrum靈活開發

Pair-Programming，結對程式設計。在靈活開發中，做任何事情都是Pair 的，包括分析、寫測試、寫實作代碼或
者重構。Pair 做事有很多好處，兩個人在一起探讨很容易産生思想的火花，也不容易走上偏路。在我們公司，還
有很多事都是Pair 來做，比如Pair 學習，Pair 翻譯，Pair 做PPT，關于這個話題，錢錢同學有一篇很有名的文章
對它進行介紹，名為Pair Programming (結對程式設計)。
Stand up，站立會議。每天早上，項目組的所有成員都會站立進行一次會議，由于是站立的，是以時間不會
很長，一般來說是15-20 分鐘。會議的内容并不是需求分析、任務配置設定等，而是每個人都回答三個問題：1. 你昨
天做了什麼？2. 你今天要做什麼？ 3. 你遇到了哪些困難？站立會議讓團隊進行交流，彼此互相熟悉工作内容，
如果有人曾經遇到過和你類似的問題，那麼在站立會議後，他就會和你進行讨論。
Frequent Releases，小版本釋出。在靈活開發中，不會出現這種情況，拿到需求以後就閉門造車，直到最後才
将産品傳遞給客戶，而是盡量多的産品釋出，一般以周、月為機關。這樣，客戶每隔一段時間就會拿到釋出的産
品進行試用，而我們可以從客戶那得到更多的回報來改進産品。正因為釋出頻繁，每一個版本新增的功能簡單，
不需要複雜的設計，這樣文檔和設計就在很大程度上簡化了。又因為簡單設計，沒有複雜的架構，是以客戶有新
的需求或者需求進行變動，也能很快的适應。
Minimal Documentation，較少的文檔。其實靈活開發中并不是沒有文檔，而是有大量的文檔，即測試。這些
測試代碼真實的反應了客戶的需求以及系統API 的用法，如果有新人加入團隊，最快的熟悉項目的方法就是給他
看測試代碼，而比一邊看着文檔一邊進行debug 要高效。如果用書面文檔或者注釋，某天代碼變化了，需要對這
些文檔進行更新。一旦忘記更新文檔，就會出現代碼和文檔不比對的情況，這更加會讓人迷惑。而在靈活中并不
會出現，因為隻有測試變化了，代碼才會變化，測試是真實反應代碼的。這時有人會問：代碼不寫注釋行嗎？
一般來說好的代碼不是需要大量的注釋嗎？其實簡單可讀的代碼才是好的代碼，既然簡單可讀了，别人一看就能
夠看懂，這時候根本不需要對代碼進行任何注釋。若你覺得這段代碼不加注釋的話别人可能看不懂，就表示設計
還不夠簡單，需要對它進行重構。
Collaborative Focus，以合作為中心，表現為代碼共享。在靈活開發中，代碼是歸團隊所有而不是哪些子產品的
代碼屬于哪些人，每個人都有權利獲得系統任何一部分的代碼然後修改它，如果有人看到某些代碼不爽的話，那
他能夠對這部分代碼重構而不需要征求代碼作者的同意，很可能也不知道是誰寫的這部分代碼。這樣每個人都能
熟悉系統的代碼，即使團隊的人員變動，也沒有風險。
Customer Engagement ，現場客戶。靈活開發中，客戶是與開發團隊一起工作的，團隊到客戶現場進行開發
或者邀請客戶到團隊公司裡來開發。如果開發過程中有什麼問題或者産品經過一個疊代後，能夠以最快速度得到
客戶的回報。
Automated Testing ，自動化測試。為了減小人力或者重複勞動，所有的測試包括單元測試、功能測試或內建
測試等都是自動化的，這對QA 人員提出了更高的要求。他們要熟悉開發語言、自動化測試工具，能夠編寫自動
化測試腳本或者用工具錄制。我們公司在自動化測試上做了大量的工作，包括Selenium 開源項目。
Adaptive Planning，可調整計劃。靈活開發中計劃是可調整的，并不是像以往的開發過程中，需求分析->概要
設計->詳細設計->開發->測試->傳遞，每一個階段都是有計劃的進行，一個階段結束便開始下一個階段。而靈活
開發中隻有一次一次的疊代，小版本的釋出，根據客戶回報随時作出相應的調整和變化。
靈活開發過程與傳統的開發過程有很大不同，在這過程中，團隊是有激情有活力的，能夠适應更大的變化，
做出更高品質的軟體。      

持續內建.      

主要是短平快的開發模式，原型模式開發。反複交流，确定。項目持續釋出內建。