Principle 10: Simplicity--the art of maximizing the amount of work not done--is essential.

翻譯 ：精簡——將不需完成的工作量最大化的技能——是不可或缺的

初看這句話覺得很詭異，具體翻譯來說是“精簡性——最大化未完成的工作量的藝術——是根本的。”除去中間的插入語，剩下的部分就是很直接的“Simplicity is essential.”。細想之下，發現這個原則在軟件開發中卻是很有道理。于是乎，我想到了一個關于效率efficiency的基礎原則：KISS Principle—Keep it Simple, Stupid.這是一個很關鍵的概念，但是很多人都總是忽略遺忘它。不要給自己添加額外的工作，要找到針對某個問題的最簡單的解決方法。Work smarter, not harder. 就我個人看來，在很多事情上可以去做到維持工作最簡化。首先就是使用類型和模板，知道什么樣的模板是可用的可以為我們節省很多時間；其次，盡量寫簡短簡單的模塊化的東西，用概念，任務和引用來組合不同的內容。把要實現的任務分成小塊，就能夠很容易地完成添加、刪除和重構；盡量避免使用那些很復雜的分支和過程，否則不僅是用戶，大概連構建者本人都會覺得很混亂吧；最后就是我覺得最重要的做到“maximize the amount of work not done”的方法就是不要包含任何用戶并不需要的信息在你的工程里，要始終把他們的需求和任務記在腦海。否則，即使你實現了這樣那樣酷炫的功能，對用戶而言沒有任何吸引力，不是偷雞不成蝕把米么？

Principle 11：The best architectures, requirements, and designs emerge from self-organizing teams.

翻譯 ：最好的架構、需求和設計源于能有效自我組織的團隊

團隊合作的有效性和活力是一切開發工作的基礎。然而，有效合作的團隊并不是想當然的，首先團隊的組建就需要仔細考慮，寧缺勿濫應該是比較好的準則吧，畢竟這里面如果來了南郭先生就不像樂隊一樣聽不出來了，這種潛在的矛盾源（請允許我這樣說吧）必須扼殺在萌芽階段，恩。另外，團隊有效的自我組織能力還來源于成員們的默契，互相尊重，以及互相的了解。所以，項目中大家適量地出去玩，胡侃，腐敗等是必須而且需要注意利用的哦。

Principle 12：At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

翻譯 ：團隊內部定期的思考如何變得更有效，并按此來修正及優化自身的行為。

定期的審查可以使成員對當前的團隊狀態達成統一認識，這樣才能更好地制定下一步計劃。可能有人會說不是敏捷開發嗎？不是應該刷刷刷開到極致（extreme-programming)，趕緊開發完就行了嘛。然而就像你要獨自去一個陌生的地方，說一帆風順永遠都是安慰話~開發中不可避免的會遇到困難，進而導致與計劃的不一致，團隊成員間進度的不一致，理解的不一致等。定期進行集體的交流，探討做的不好的地方，是什么原因，應該怎么彌補修正，然后吸取經驗教訓繼續前行。也讓整個團隊的成員達成一致，互相有交流的基礎。所謂心有靈犀一點通，在團隊的級別上要達到這一點不可避免要通過一些有組織的“爭論”、“思考”。每個成員都應該在思考的過程中爭取把問題暴露出來，并坦誠接受有益的改變和建議，這樣自己才能做得更好，從而團隊才能表現得更好。

Twelve Principles of Agile Software