“不管路走了多遠，錯了就要重新傳回。”
靈活意味着可以快速适應變化。
靈活開發宣言：一種把以人為本、團隊合作、快速響應變化和可工作的軟體作為宗旨的開發方法。
人員：它并不要求所有人都是有經驗的專業人員，但必須具有專業的工作态度——每個人都盡最大可能做好自己的工作。
開發需持續不斷，持續地推進系統前進和完善。
一句話總結靈活：靈活開發就是在一個高度協作的環境中，不斷地使用回報進行自我調整和完善。
“標明了要走的路，就是標明了它通往的目的地。”
在靈活團隊中，大家的重點是做事。你應該把重點放到解決問題上，而不是在指責犯錯者上面糾纏。
團隊成員在一起工作，應互相幫助，而不是互相指責。
壓力會迫使你走捷徑，隻看眼前利益，但是請記住：欲速則不達。
一個大型系統你自然不可能搞明白所有代碼，但是你可以從更高的層面來了解大部分代碼的功能。
對事不對人：在一個需要緊密合作的開發團隊中，如果能稍加注意禮貌對待他人，将會有益于整個團隊關注真正有價值的問題，而不是勾心鬥角，誤入歧途。
工作中不感情用事是需要克制力的，而你需要能展現出成熟大度來。
做正确的事。要誠實，要有勇氣去說出實情。
一句話總結：專業的态度應該着眼于項目和團隊的積極成果。關注個人和團隊的成長，圍繞最後的成功開展工作。
“即使你已經在正确的道路上，但如果隻是停止不前，也仍然會被淘汰出局。”
如何才能跟上技術變化的步伐呢？
疊代和增量式的學習；
了解最新行情；
參加本地的使用者組活動；
參加研讨會議；
如饑似渴的閱讀；
你不需要精通所有技術，但要清楚知道行業的動向，進而規劃你的項目和職業生涯。
一個學習型的團隊才是較好的團隊。
新技術會讓人感到有一點恐懼。你确實需要學習很多東西。已有的技能和習慣為你打下了很好的基礎，但不能依賴它們。
為了解決問題，你需要很好地了解系統的全局。
許多不成功的項目中，基本上都是随意安排工作計劃，沒有任何規律，那樣的随機安排很難處理。項目開發需要有一緻和穩定的節奏。
一句話總結：在一個企業化的社會中，隻有一個人會為你負責——你自己。是否能跟上變化，完全取決于你自己。
“沒有任何計劃在遇敵後還能繼續執行。”
業務應用需要開發者和業務負責人互相配合來開發。這種配合的感覺就應該像一種良好、誠實的工作關系。
設計可以分為兩層：戰略和戰術。前期的設計屬于戰略，通常隻有在沒有深入了解需求的時候需要這樣的設計。更确切的說，它應該隻描述總體戰略，不應該深入到具體的細節。
在考慮引入新技術或架構之前，你需要找到需要解決的問題，接下來考慮如下幾個方面:
這個技術架構真能解決這個問題嗎？
你将會被它拴住嗎？
維護成本是多少？
保證你的系統随時可以編譯、運作、測試、部署、示範。
提早內建，頻繁內建。代碼內建是主要的風險來源。要想規避這個風險，隻有提早內建，持續而有規律地進行內建。
提早實作自動化部署。
使用示範獲得頻繁的回報。
大部分使用者都是希望現在就有一個夠用的軟體，而不是一年之後得到一個超級好的軟體。
确定使産品可用的核心功能，然後把它們放在生産環境中，越早交到使用者手裡越好。
讓團隊和客戶一起，真正地在目前項目中工作，做具體實際的評估。由客戶控制他們要的功能和預算。
一句話總結：靈活——成功的軟體開發方法——取決于你識别和适應變化的能力。隻有這樣才有可能在預算之内及時完成開發，建立真正符合使用者需求的系統。
“一步行動，勝過千萬專家的意見。”
為了應對代碼的變化，你需要持續獲得代碼健康狀态的回報：它是在做你期望的事情嗎？最近一次修改有沒有無意破壞了什麼功能？這時你該帶上守護天使——自動化單元測試。
進行單元測試的理由：
單元測試能及時提供回報。
單元測試讓你的代碼更加健壯。
單元測試是有用的設計工具。
單元測試是讓你自信的背景。
單元測試是解決問題時的探測器。
單元測試是可信的文檔。
單元測試是學習工具。
人們不編寫單元測試的很多借口都是因為代碼中的設計缺陷。通常，抗議越強烈，就說明設計越糟糕。
隻在有具體理由的時候才開始編碼。你可以專注于設計接口，而不會被很多實作的細節幹擾。
不同環境，就有不同問題。使用持續內建工具，在每一種支援的平台和環境中運作單元測試。要積極的尋找問題，而不是等問題來找你。
我們不應該去計算工作量完成的百分比，而應該測定還剩下多少工作量沒有完成。
如果能一直讓下一步工作是可見的，會有助于進度度量。最好的做法就是使用待辦事項（backlog）。
不管它是否是産品的bug，還是文檔的bug，或是對使用者社群了解的bug，它都是團隊的問題，而不是使用者的問題。
每一個抱怨的身後都隐藏了一個事實。找出真相，修複真正的問題。
一句話總結：從實踐中得到回報，確定你明确知道項目的正确狀态，而不是主觀臆測。
“任何一個笨蛋都能夠讓事情變得越來越笨重、越來越複雜、越來越極端。需要天才的指點以及許多的勇氣，才能讓事情向相反的方向發展。”
開發代碼時，應該注重可讀性，而不是隻圖自己友善。
作為一個開發者，應該時刻提醒自己是否有辦法讓寫出的代碼更容易了解。
代碼被閱讀的次數要遠超過被編寫的次數，是以在程式設計時多付出一些努力來做好文檔（利用代碼本身；利用注釋），會讓你在将來受益匪淺。
與其花費時間去提升千分之一的性能表現，也許減少開發投入，降低成本，并盡快讓應用程式上市銷售更有價值。總而言之，要想應用成功，降低開發成本和縮短上市時間同樣重要。
對代碼做一些持續而有用的事情，而不是做一段長時間的程式設計或重構。
開發人員更應該為自己能夠建立出一個簡單并且可用的設計而驕傲，不要進行過分設計，也不要将代碼複雜化。
讓類的功能盡量集中，讓元件盡量小。
保持系統靈活性的關鍵方式，是當新代碼取代原有代碼之後，其他已有的代碼不會意識到任何差别。
一句話總結：在編寫代碼時，每天付出一點小的努力，可以避免代碼“腐爛”，并且保證應用程式不至變得難以了解和維護。
“你也許會對木匠那毫無差錯的工作印象深刻。但我向你保證，事實不是這樣的。真正的高手隻是知道如何亡羊補牢。”
把你曾經遇到的棘手問題的解決方案記錄下來，友善下次使用。不要在同一個地方跌倒兩次，也不要付出更多地時間成本查找曾經的解決方案。
盡量将編譯器的警告視為錯誤來解決，但實際中有些編輯器或第三方庫會産生一些無法也不必消除的警告，你需要仔細區分。
識别複雜問題的第一步，是将他們從大型系統中分離出來。
處理或是向上傳播所有的異常，而不是忽略或者壓制。
一方面要提供給使用者清晰、易于了解的問題描述和解釋；另一方面還要提供關于錯誤的詳盡技術細節來友善開發人員定位解決問題。
一句話總結：即使運作得最好的靈活項目，也會發生錯誤，你所要做的就是提高自己的調試能力去“亡羊補牢”。
“我不僅發揮了自己的全部能力，還将我所仰仗的人的能力發揮到極緻。”
使用站立會議，每個人都應該隻回答下述三個問題：
昨天有什麼收獲？
今天計劃要做哪些工作？
面臨着哪些障礙？
一個真正的架構師應該指導開發團隊，提升他們的水準，以解決更為複雜的問題。架構師也應該參與代碼編寫，一個系統的設計者也應該親自投入到實作中去。
實行代碼集體所有制：版本管理系統，結對程式設計，代碼評審都是手段。
分享自己的知識——付出的同時便有收獲。還可以激勵别人獲得更好的成果，而且提升了整體團隊的實力。
作為一個指導者，告訴團隊成員解決問題的方法，培養他們的思維和能力，而不是直接幫助他們解決。
及時通報進展與問題。讓協作者和管理者了解項目的進度與問題。
一句話總結：項目的成功與否，依賴與團隊中的成員如何一起有效的工作，如何互動，如何管理他們的活動。全體成員的行動必須要與項目相關，反過來每個人的行為又會影響到項目。
本文轉自永遠的朋友部落格51CTO部落格，原文連結http://blog.51cto.com/yaocoder/1353544如需轉載請自行聯系原作者
yaocoder
![碼農隻是一碗青春飯，準程式員該怎麼規劃自己的職業生涯。[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)