前端的敏捷開發

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

保證界面及用戶體驗的前提下,寫代碼的速度是第一要務

不要拘泥於什麼技術可用,什麼技術不可用。讓它在最短的時間內跑起來,在用戶體驗的過程中完成迭代升級。利用高速的開發流程,為項目創造競爭優勢。有些可以用CSS實現的東西,沒必要掛JS。然後還跑過來問“我不想用CSS,這段JS為啥不能隱藏滾動條?”這種開發者,不僅是自虐,還是在虐待訪客的電腦。

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

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

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

在團隊內部,最具有效果並富有效率的溝通方式,就是面對面交談。

QQ或者MSN,沒有任何的語氣語調,無法更直接的表述業務的著重點在哪裡。容易產生誤會。

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

即時響應,高效開發

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

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

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

客戶勝於一切

之前有拿“海底撈”舉過例子,這裡再談一下他們的服務理念。

當客戶提出某個要求,只要不是太過分,他們的員工​​通常都不會詢問經理,而是直接幫你把事情辦好。

我個人最討厭聽到的答復是,“我們經理不在,對不起,我無權XXX”

你連這麼點權利都沒有,你連一個客人都服務不好,還做什麼服務員?

一樣的,一個小型的項目,當客戶電話打過來抱怨,你又很清楚怎麼做可以維護好公司的形象,直接去做就是了。

客戶勝於一切,用最快的速度完成他們的需求。當然,僅限於合理需求。

總之,還是要培養員工獨立思考的能力,只有他們去想了、去做了,才能高質高效的完成工作。

花時間,去鍛煉,去僱傭他們的大腦,而不是雙手。

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

特別注意:本站所有轉載文章言論不代表本站觀點,本站所提供的攝影照片,插畫,設計作品,如需使用,請與原作者聯繫,文章轉自alibuybuy

Comments are closed.