前端的敏捷開發

幾天前，就網站的開發流程做了一個總結，觀點比較片面、極端，僅供參考：

保證介面及使用者體驗的前提下，寫代碼的速度是第一要務

不要拘泥于什麼技術可用，什麼技術不可用。 讓它在最短的時間內跑起來，在使用者體驗的過程中完成反覆運算升級。 利用高速的開發流程，為專案創造競爭優勢。 有些可以用CSS實現的東西，沒必要掛JS。 然後還跑過來問「我不想用CSS，這段JS為啥不能隱藏捲軸？ 」這種開發者，不僅是自虐，還是在虐待訪客的電腦。

針對某些要求1小時上線的變態專案，大可以用PS直接生成html，什麼是標準？ 什麼是規則？ 這些都是輔助我們製作網站的建議，當我們有實際需求的時候，大可以打破這種標準。 標準是人制定的，HTTP://www.aliyun.com/zixun/aggregation/6980.html">前端開發者的追求目標，應該是去做制定標準的人，而不要被標準所束縛。 當我們有實際需求的時候，當伺服器被拖慢速度的時候，不用誰來指揮，自然會去想如何降低頻寬壓力。 讓你的團隊自發思考，勝過於你拿各種標準來壓迫執行。

負面影響：招聘的難度會大大增加，除非每個員工都有股份、或者是你親自教出來的。 不然，拿同樣多的薪水，很少有人會自發思考公司的業務。 另外，反覆運算的開發成本也會很高，純靜態展示頁還好，載入程式的頁面進行結構調整，會增大員工的工作壓力。 注意僅在合適的專案上玩速度。

開發人員和業務人員盡可能天天都在一起工作

在團隊內部，最具有效果並富有效率的溝通方式，就是面對面交談。
QQ或者MSN，沒有任何的語氣語調，無法更直接的表述業務的著重點在哪裡。 容易產生誤會。

開發過程中，要避免晦澀的文檔及專業術語。 每次溝通帶上紙筆，說不明白就畫，畫不明白就抓一個業務坐你身邊，讓他看著做。 領導層要給他們提供所需的環境和支援，有可能的話，抓一個領導坐在身邊。 減少交接的流程，簡化開發文檔。 一個好的文檔，是讓開發人員明白每一步的要求是什麼。 而不在於文檔字數的多少。 沒有文檔更好，只要你能給團隊講清楚。

即時回應，高效開發

在某些領域，為什麼一些很小的網站可以戰勝大的公司？

他們不遵循守則，他們無需層層審批，他們發現什麼好的技術可以直接應用到自己的網站上。 說服經理，即使很順利，也需要一個說服的過程。 況且有很多計畫會夭折在領導層的審批上。 用人不疑，如果你有一個不大的專案，如果你有一個可以信任的人，放手讓他去做。

這個有執行力的人，一定要選好。 做正確的事情比做錯誤的事情要困難很多。

客戶勝於一切

之前有拿「海底撈」舉過例子，這裡再談一下他們的服務理念。
當客戶提出某個要求，只要不是太過分，他們的員工通常都不會詢問經理，而是直接幫你把事情辦好。

我個人最討厭聽到的答覆是，「我們經理不在，對不起，我無權XXX」
你連這麼點權利都沒有，你連一個客人都服務不好，還做什麼服務員？

一樣的，一個小型的專案，當客戶電話打過來抱怨，你又很清楚怎麼做可以維護好公司的形象，直接去做就是了。
客戶勝於一切，用最快的速度完成他們的需求。 當然，僅限於合理需求。

總之，還是要培養員工獨立思考的能力，只有他們去想了、去做了，才能高質高效的完成工作。
花時間，去鍛煉，去雇傭他們的大腦，而不是雙手。

來源：uicss.cn/agile-development-of-front-end/