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，可調整計劃。敏捷開發中計劃是可調整的，並非像以往的開發過程當中，需求分析->概要
設計->詳細設計->開發->測試->交付，每個階段都是有計劃的進行，一個階段結束便開始下一個階段。而敏捷
開發中只有一次一次的迭代，小版本的發佈，根據客戶反饋隨時做出相應的調整和變化。
敏捷開發過程與傳統的開發過程有很大不一樣，在這過程當中，團隊是有激情有活力的，可以適應更大的變化，
作出更高質量的軟件。

持續集成.

主要是短平快的開發模式，原型模式開發。反覆交流，肯定。項目持續發佈集成。

其餘參考:https://www.jianshu.com/p/89e59933caad>https://www.jianshu.com/p/89e59933caad