起點(diǎn)課堂會(huì)員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會(huì)特權(quán)
個(gè)人IP打造特權(quán)
30+門專項(xiàng)技能課
1300+專題課程
12場(chǎng)職場(chǎng)軟技能直播
12場(chǎng)求職輔導(dǎo)直播
12場(chǎng)專業(yè)技能直播
會(huì)員專屬社群
榮耀標(biāo)識(shí)為什么我不推薦敏捷開發(fā)？
當(dāng)項(xiàng)目成員越多，我越不推薦敏捷開發(fā)，原因在于「當(dāng)連自己要做什么事、為什么這樣做、這樣做為了解決什么問(wèn)題」都搞不清楚前，就跳下去玩敏捷開發(fā)，那和比通靈還慘，通靈起碼還有個(gè)目標(biāo)物在前面，搞不清楚狀況的人只能陪他跳世界迷霧開地圖了 。
敏捷開發(fā) – MBA智庫(kù)百科?最下方有段「對(duì)敏捷開發(fā)的誤解」。可順便參考?敏捷軟件開發(fā) – 維基百科。
誤解一：敏捷對(duì)人的要求很高
說(shuō)高不高啦，撇開實(shí)作技術(shù)不談，你覺(jué)得要找到清楚項(xiàng)目開發(fā)流程、知道每位項(xiàng)目成員的工作內(nèi)容、職責(zé)范圍、產(chǎn)出，并清楚項(xiàng)目目標(biāo)、需求、用戶需要的開發(fā)人員（含設(shè)計(jì)師）很容易嗎？
如果上述條件無(wú)法達(dá)成，又怎么確定運(yùn)用敏捷開發(fā)方式后，所有項(xiàng)目成員方向都是正確的？就因?yàn)檫@種人太難找，所以會(huì)產(chǎn)生「對(duì)人要求很高」印象。
連在有企劃書、規(guī)格書、用戶研究報(bào)告的文件情況下都還不知道自己要干嘛、同事在干嘛，能談敏捷嗎？
誤解二：敏捷沒(méi)有文檔，也不做設(shè)計(jì)
文件撰寫與否和敏捷開發(fā)一點(diǎn)關(guān)系也沒(méi)有，敏捷開發(fā)強(qiáng)調(diào)「適應(yīng)性而非預(yù)見性」，并沒(méi)有強(qiáng)硬規(guī)定。雖然有一句「可用的軟件：重于 詳盡的文件」，但它沒(méi)有叫你不要寫文件。
先想看看寫文件是為了解決什么問(wèn)題？如果不寫文件會(huì)產(chǎn)生什么問(wèn)題？
以 UI 設(shè)計(jì)師來(lái)講，交出 UI Flow、Wireframe 這種文件是為了解決什么問(wèn)題？要敏捷開發(fā)嘛就不用寫了跳過(guò)，直接出 Mockup 吧。因?yàn)榘l(fā)現(xiàn)出包有漏改來(lái)改去改到死，和找到產(chǎn)品問(wèn)題改良，是兩回事??！
敏捷開發(fā)不是沒(méi)文件沒(méi)流程的包裝紙。
誤解三：敏捷好，其他方法不好
敏捷開發(fā)就是一直小幅度改啊改啊改啊，可以增加工作效率，讓大家工作更順利喔～～（就算是瀑布流式的傳統(tǒng)開發(fā)流程，設(shè)計(jì)師也是一直改啊改啊改啊，效率了什么、順利了什么?。。浚?/p>
先承認(rèn)有問(wèn)題，才能找出問(wèn)題，之后找解決方法。而不是先有方法，再想這個(gè)方法能解決什么問(wèn)題。敏捷開發(fā)只是一種「方法」，方法論用在敏捷開發(fā)上，要回答兩個(gè)問(wèn)題：
- 現(xiàn)有模式為何不能滿足你的需求？
- 敏捷式開發(fā)為什么可以？
敏捷開發(fā)不是萬(wàn)靈丹，先找到問(wèn)題點(diǎn)、知道為什么要采取敏捷，重點(diǎn)是卡在哪里需要敏捷這個(gè)「方法」來(lái)解決。設(shè)計(jì)師改來(lái)改去是為什么解決什么問(wèn)題？敏捷 開發(fā)的小幅度改來(lái)改去、和現(xiàn)況設(shè)計(jì)師的改來(lái)改去有什么不同？如果都一樣為什么要采取敏捷？（不要跟我說(shuō)因?yàn)檐浖_發(fā)主力是 RD 所以忘記算上設(shè)計(jì)師。）
現(xiàn)實(shí)的扭曲
個(gè)人與互動(dòng)：重于流程與工具
開會(huì)是非常燒錢的行為，如果項(xiàng)目成員一多，要用什么方式降低溝通落差、盡量讓每個(gè)人理解到的都相同？怎么確保部門和部門間的信息交流順暢？靠出張嘴溝通就能辦到嗎？
可用的軟件：重于詳盡的文件
有文件產(chǎn)生/解決什么問(wèn)題？沒(méi)有文件產(chǎn)生/解決什么問(wèn)題？不寫文件最愛用「我們是敏捷開發(fā)」當(dāng)借口了，不會(huì)寫就不會(huì)寫、不知道文件寫來(lái)干嘛就老實(shí)承認(rèn)，少拿這個(gè)當(dāng)說(shuō)詞。
與客戶合作：重于合約協(xié)商
如果客戶沒(méi)有在好的引導(dǎo)下一起合作，現(xiàn)實(shí)狀況會(huì)變成「最后一次-確定最終版-說(shuō)好不改了-V21.psd」。嗯？改來(lái)改去不就是敏捷開發(fā)嗎？（喂）
回應(yīng)變化：重于遵循計(jì)劃
這不是改來(lái)改去改到死的好理由！為什么要「變化」，變化是為了解決什么問(wèn)題？沒(méi)有問(wèn)題改它干嘛？完全不代表可以沒(méi)計(jì)劃就上?。?/p>
結(jié)論
敏捷開發(fā)宣言里各種許愿…拔掉敏捷二字不也是所有項(xiàng)目開發(fā)的理想？所以為了解決什么問(wèn)題而采用敏捷式開發(fā)？為了改善工作流程加快效率？
那設(shè)計(jì)師修改到死的工作情況在敏捷開發(fā)里要怎么被改善？
我覺(jué)得敏捷開發(fā)適用「頭腦清楚」的人，只是這種人往往是大神級(jí)的了。和大神 PM、大神 Planner、大神 RD 合作，都清楚知道自己在干嘛、別人在干嘛，還能 Cover 一點(diǎn)別人的領(lǐng)域，知道解決這個(gè)問(wèn)題可以往目標(biāo)更進(jìn)一步，這種合作模式才有辦法做到「敏捷」，而不是因?yàn)樽ヂ┳ハx在修改。是啦這也算朝目標(biāo)邁進(jìn)，但「創(chuàng)新改 良產(chǎn)品」和「讓產(chǎn)品看起來(lái)洞沒(méi)那么大」的改來(lái)改去本質(zhì)上是兩回事??！敏捷開發(fā)只是個(gè)方法，不是萬(wàn)靈丹。
敏捷式開發(fā)就是改來(lái)改去？
那「字大一點(diǎn)、Logo大一點(diǎn)、換一張照片、多出幾版讓我挑」也算啊～
原文地址：blog.akanelee.me
作者：@Akane_Lee
確實(shí)沒(méi)什么邏輯性
樓主說(shuō)話像是西南地區(qū)人士
LZ講的很不錯(cuò)，稍微偏激的描述還是刺激出了一些人的槽點(diǎn)
我覺(jué)得敏捷還挺好用的啊 可能因?yàn)槲覀冇敏~骨敏捷項(xiàng)目管理開發(fā)過(guò)程吧 一個(gè)標(biāo)志的大看板 再加上需求 迭代 bug這幾個(gè)模塊的管理 就很簡(jiǎn)單了啊
你是賣產(chǎn)品的，需求是什么，你怎么描述的。就是幾行字嗎。哈哈
通過(guò)以上內(nèi)容，鑒定書呆子一個(gè)。
有點(diǎn)理解樓主的抱怨，不是說(shuō)敏捷不好，而是說(shuō)在很多現(xiàn)實(shí)情況下，采用敏捷并不能解決問(wèn)題。對(duì)于敏捷方式的采用，需要考慮好需要解決哪些問(wèn)題，而不是盲目的認(rèn)為敏捷可以解決現(xiàn)實(shí)中出現(xiàn)的任何項(xiàng)目問(wèn)題。敏捷宣言中的四條，在現(xiàn)實(shí)中有時(shí)確實(shí)很無(wú)力。個(gè)體和交互，現(xiàn)實(shí)中有很多的技術(shù)大牛、有能力有經(jīng)驗(yàn)的人、有學(xué)習(xí)鉆研精神的人，但是現(xiàn)在的很多軟件開發(fā)人員，很多都是培訓(xùn)機(jī)構(gòu)培訓(xùn)幾個(gè)月就出來(lái)工作的，可想而知（當(dāng)然不排除有優(yōu)秀的人）。客戶合作，很多客戶都是想在最短時(shí)間，實(shí)現(xiàn)最多的功能，尤其對(duì)于不懂軟件的人，頻繁出現(xiàn)——這個(gè)功能應(yīng)該很簡(jiǎn)單吧，明天可以給我吧，之類的。怎么樣引導(dǎo)客戶合作，確實(shí)是一個(gè)比較大的問(wèn)題。響應(yīng)變化，確實(shí)如樓主所說(shuō)，有些變化真的是無(wú)理變化，或者說(shuō)是舉棋不定的結(jié)果，并不是所有的變化我們都需要及時(shí)響應(yīng)的，同時(shí)也會(huì)導(dǎo)致很多浪費(fèi)。而這種變化，可能在項(xiàng)目中卻是多數(shù)。以上僅為個(gè)人工作中的經(jīng)驗(yàn)，可能情況會(huì)有些極端吧。
個(gè)人感悟：敏捷首先從兩個(gè)層次去理解，要做什么？為什么要這樣做？然后就是3個(gè)“最”最短的時(shí)間，最有價(jià)值的事務(wù)和最小可用版本。在就是兩個(gè)持續(xù)，持續(xù)進(jìn)行迭代開發(fā)與運(yùn)營(yíng)，持續(xù)與用戶溝通。我們都知道也常在嘴邊念叨計(jì)劃趕不上變化，敏捷的開發(fā)模式擁抱變化。
一直不理解，什么是傳統(tǒng)開發(fā)模式，為什么傳統(tǒng)開發(fā)模式就是瀑布模式，瀑布模式就沒(méi)有迭代了嗎？瀑布模式也可以多次迭代啊，也能擁抱變化啊，為什么瀑布模式不能多次迭代？
LZ，說(shuō)實(shí)話沒(méi)看懂你到底想說(shuō)什么，思路太不清楚了，表達(dá)的目的也沒(méi)說(shuō)清楚
lz這篇文章的核心論點(diǎn)是：敏捷不是萬(wàn)靈丹，它是適合那些層次稍微高一點(diǎn)，知道大體框架要做什么的團(tuán)隊(duì)，敏捷的核心也是要在有足夠強(qiáng)魯棒性的框架下，再不斷根據(jù)需求的變化而不斷迭代優(yōu)化，讓這個(gè)大體框架逐漸明晰。這個(gè)和那些根本不知道自己的大體框架要干什么，上來(lái)就是東抓一把西抓一把，最后改成一鍋粥的做法是有根本性區(qū)別的，首先魯棒性上面都不夠強(qiáng)！
所以他強(qiáng)調(diào)，在用敏捷方法前，先弄明白自己團(tuán)隊(duì)的項(xiàng)目大體框架上面要做什么！
敏捷對(duì)成員的要求確實(shí)高，但是也不全是這個(gè)樣子的。
感覺(jué)作者不是特別理解敏捷開發(fā)，從外表看，敏捷開發(fā)和傳統(tǒng)的瀑布開發(fā)差別很大，本質(zhì)上敏捷也不是萬(wàn)能的，但是，之所以現(xiàn)在數(shù)以千計(jì)的項(xiàng)目轉(zhuǎn)來(lái)做敏捷，尤其是大而復(fù)雜的項(xiàng)目，說(shuō)明存在必有其道理。不可否認(rèn)敏捷也有問(wèn)題，但是相對(duì)于傳統(tǒng)的那種要確定需求，設(shè)計(jì)，流程后才能開發(fā)產(chǎn)品的方法，敏捷能更大限度的減少損失（如果失敗的話），我們都不喜歡改來(lái)改去，所以敏捷第一宣言就是，歡迎改變，究其原因是因?yàn)?，事物是發(fā)展的，產(chǎn)品的環(huán)境是變化的，所以，我們一定要想那個(gè)小老鼠嗅嗅一樣，保持敏感，從而達(dá)到敏捷。
從你的回答來(lái)看，你只會(huì)照版的別人的東西。多實(shí)踐一下再去做回答。為什么傳統(tǒng)的開發(fā)模式就一定是瀑布開發(fā)模式，瀑布開發(fā)模式為什么就不能迭代了。傳統(tǒng)的開發(fā)開發(fā)模式也可以擁抱變化，快速迭代。為什么沒(méi)有這樣做？請(qǐng)思考一下這個(gè)問(wèn)題？
從你的回答來(lái)看，你是來(lái)吵架的
說(shuō)的好，就是這樣。
lz試試真正的瀑布流就能知道效率有多低了~ps：瀑布流意味著有嚴(yán)格的界限，而界限意味著有繁冗的流程，更坑的還意味著不可逆性。
不是樓主需要知道什么，你經(jīng)驗(yàn)太少，主要是人，瀑布流不一定效率低下，瀑布開發(fā)模式也可以多此迭代，主要是人。主要是即懂技術(shù)，有懂業(yè)務(wù)的大牛，有這樣的人管理項(xiàng)目，不管瀑布和敏捷效率都會(huì)很高。沒(méi)有這樣的人，那個(gè)效率都很低。不要盲目的去下結(jié)論。
如果需求明確，確實(shí)適合瀑布模型，如果需求不明確，使用瀑布模型確實(shí)很麻煩，逆向修改要改動(dòng)的東西太多，從需求規(guī)格說(shuō)明書，概要設(shè)計(jì)，詳細(xì)設(shè)計(jì)都要修改，但是在實(shí)際的開發(fā)中沒(méi)有人會(huì)使用嚴(yán)格的某一種模式，大多是混合模式
瀑布模型效率是最高的，迅速就能做完整個(gè)項(xiàng)目，然后客戶說(shuō)我們的需求不是這樣的，你理解錯(cuò)了，然后你就再次的從新設(shè)計(jì)整個(gè)項(xiàng)目
沒(méi)有哪個(gè)人一生來(lái)就是大神的，樓主這個(gè)吐槽明顯看出是個(gè)幽怨的UI。。。被pm要求改過(guò)去改過(guò)來(lái)了吧。。。。
贊