【編者按】誤解和“最佳實踐”可能會讓你的團(tuán)隊原地打轉(zhuǎn)丸凭，無法高效產(chǎn)出代碼。本文主要介紹預(yù)示著敏捷方法走偏的15個標(biāo)志茵瀑，作者為 Steven A. Lowe间驮。文章系國內(nèi) ITOM 管理平臺 OneAPM 編譯呈現(xiàn)。
要趕時髦卻掉溝里的情況很常見瘾婿。這條準(zhǔn)則在敏捷開發(fā)中表現(xiàn)得尤為明顯蜻牢。很多公司因為敏捷的好處——容易變更、周期縮短偏陪、進(jìn)化構(gòu)架抢呆，等等短荐，而轉(zhuǎn)投它的懷抱宇攻，結(jié)果最后公司最好的敏捷實踐者紛紛離職，剩下的人員卻沒有能力修復(fù)開發(fā)過程中的問題梢夯。
大部分敏捷操作的問題并不在于敏捷概念饥脑，而在于敏捷方法(Agile)恳邀。敏捷并不是一種方法懦冰，把它當(dāng)做方法，就把開發(fā)過程與哲學(xué)和文化混在了一起谣沸，這樣做只會回到瀑布模型刷钢，甚至更糟的情況。
幸好乳附，辨別敏捷方法出錯的標(biāo)志并不難内地，還可以采取行動重塑和諧。本文列出了敏捷方法走偏的15個標(biāo)志赋除，任何一個都可能讓你軟件開發(fā)的前期努力付諸東流阱缓。
1、實施敏捷與敏捷實踐
敏捷以態(tài)度為先举农。如果你的公司強(qiáng)調(diào)實施敏捷荆针，而不是敏捷實踐，那么你們一開始就走錯方向了颁糟。敏捷是一個范例航背，是軟件開發(fā)方法的思路轉(zhuǎn)變。具體的技巧和儀式稍后再說滚停，而且重要性相對較低沃粗。重點在于敏捷實踐，擁抱和使用敏捷宣言中列出的理念键畴，你們自然而然就在“實施”敏捷了。
一定要認(rèn)真閱讀敏捷宣言突雪，里面的內(nèi)容都是字斟句酌才定下來的起惕。想一想其中的含義：去除無用的儀式、管理和書面工作咏删，專注于代碼和快速反饋周期惹想，自行組織、自行檢查督函、自行優(yōu)化嘀粱。這就是變革。實現(xiàn)宣言列出目標(biāo)的具體行動則需要不斷發(fā)展進(jìn)化辰狡。
如果你們強(qiáng)制所有團(tuán)隊遵循一刀切的通用敏捷“流程”锋叨，這種做法是錯的。這種“標(biāo)準(zhǔn)的”敏捷流程的想法是矛盾的宛篇，因為敏捷意味著持續(xù)不斷地適應(yīng)和改進(jìn)娃磺。
要想補(bǔ)救，不要忘了你們的主要目標(biāo)是交付可用的軟件叫倍，而不是遵循某個方法偷卧；沒有方法是萬能的豺瘤，適用于所有項目和團(tuán)隊。因此听诸，放手讓每個團(tuán)隊自行操作坐求，并修正和改進(jìn)實踐。
2晌梨、將故事分值當(dāng)成目標(biāo)
用戶故事是敏捷的一個重要方面瞻赶，從用戶角度描述軟件特征的需求。故事被賦予分值派任，以此來預(yù)估完成故事所需要的工作量砸逊。
這些故事分值既不是承諾，也不是目標(biāo)掌逛。它們并沒有本質(zhì)意義或衡量標(biāo)準(zhǔn)师逸，只是團(tuán)隊成員就項目復(fù)雜程度和團(tuán)隊能力達(dá)成的非正式共識。
你的團(tuán)隊的三分故事可能是其他團(tuán)隊的五分故事豆混。將故事分值當(dāng)做成功的衡量標(biāo)準(zhǔn)篓像，破壞了它作為預(yù)估方法的價值，并且會導(dǎo)致“鉆制度空子”來假裝成功（已達(dá)到速度 X）皿伺，實際上并沒有成功（交付可用且有用的軟件）员辩。
解決方法很簡單：與產(chǎn)品負(fù)責(zé)人（用戶更好）在有用目標(biāo)和衡量目標(biāo)上達(dá)成共識。不要誤將要估計的標(biāo)準(zhǔn)或要計劃的規(guī)則跟“成功”混為一談鸵鸥，只有交付了價值才叫成功奠滑。
3、比較團(tuán)隊或成員的速度
沉迷于指標(biāo)幾乎是大部分程序員的第二天性妒穴。但是宋税，如果你的團(tuán)隊將速度——迭代計劃中團(tuán)隊所用的每次迭代的故事分值衡量指標(biāo)——當(dāng)做比較點，你們就錯了讼油。
再次說明一下杰赛，速度只是用于預(yù)估的中性指標(biāo)。對比團(tuán)隊速度毫無意義矮台，因為每個團(tuán)隊的基本單位（故事分值）“定義”不同乏屯。每個團(tuán)隊都是獨一無二的，對比速度并無價值瘦赫，而且還會引發(fā)負(fù)面行為和團(tuán)隊之間的競爭辰晕，而非合作。
同樣的道理也適用于團(tuán)隊內(nèi)部成員耸彪。個體對故事分值的貢獻(xiàn)微乎其微伞芹。而且最重要的一點，故事分值本身并不是指標(biāo)。比較同一團(tuán)隊成員的速度并無意義唱较。唯一重要的指標(biāo)是一個主觀指標(biāo)：在開發(fā)軟件中交付的價值扎唾。
最簡單的解決辦法：停下來。否則只會事與愿違南缓，浪費(fèi)時間胸遇。
4、寫任務(wù)汉形，而不是寫故事
敏捷故事模板在構(gòu)建某個特征對某個特定用戶或角色的好處時很有用纸镊。這提醒了我們，目標(biāo)是為交付能夠滿足某些人的使用期望的軟件概疆。如果你的“故事”大部分內(nèi)容實際上都是任務(wù)逗威，那么開發(fā)過程就會變成任務(wù)導(dǎo)向（做事情），而不是交付導(dǎo)向（創(chuàng)造價值）岔冀。開發(fā)團(tuán)隊與用戶保持聯(lián)系很重要凯旭，沒有用戶的軟件一無是處。
這種問題的解決辦法是平衡：總會有一些必須完成的類似任務(wù)的事項使套，但是故事的規(guī)模應(yīng)該控制在單個迭代過程能夠完成罐呼，因此把它分解成多個任務(wù)并沒有意義≌旄撸“完成”75%的故事毫無用處嫉柴。要么做，要么不做奉呛，沒有中間值可取计螺。如果一個故事太過復(fù)雜，無法在一個迭代過程中完成侧馅，而且無法劃分成幾個故事危尿，那就應(yīng)該用幾個過程來完成（見下一部分）。
5馁痴、絕對不要重復(fù)故事
如果你把大的故事分解成幾個小故事，只是為了能夠符合一個迭代過程的時間長度肺孤，這樣做是不對的罗晕。這種行為會產(chǎn)生幾個聯(lián)系更弱、任務(wù)導(dǎo)向的“故事”赠堵。與之相反小渊，堅持更大的、更自然的故事茫叭，用幾個迭代過程去完成酬屉。有始有終，從能夠?qū)崿F(xiàn)預(yù)期性能的最小功能“核心部分”做起，然后在后續(xù)的迭代過程中加入其它行為和元素呐萨。這樣可以保證故事的完整性杀饵，從核心部分發(fā)展到可用性。
一旦核心部分完成谬擦，它的結(jié)構(gòu)和性能可能會引發(fā)其它子故事切距，或者你會在下個迭代過程中發(fā)現(xiàn)優(yōu)先級發(fā)生了變化，因此核心部分需要擱置惨远。但是谜悟，如果你把故事分解成幾個任務(wù)，以為把每個任務(wù)當(dāng)成一個“故事”來完成會更容易北秽，那么開發(fā)出來的軟件就不會包含可識別的附加價值葡幸，因為任務(wù)傾向于專注不關(guān)聯(lián)的部分，而不是相互聯(lián)系的價值流贺氓。
在本文的第二部分蔚叨，將繼續(xù)介紹預(yù)示著敏捷方法走偏的另10個標(biāo)志，敬請期待掠归。
本文系 OneAPM 工程師整理呈現(xiàn)缅叠。OneAPM 能為您提供端到端的應(yīng)用性能解決方案，我們支持所有常見的框架及應(yīng)用服務(wù)器虏冻，助您快速發(fā)現(xiàn)系統(tǒng)瓶頸肤粱，定位異常根本原因。分鐘級部署厨相，即刻體驗领曼，性能監(jiān)控從來沒有如此簡單。想閱讀更多技術(shù)文章蛮穿，請訪問 OneAPM 官方技術(shù)博客庶骄。
本文轉(zhuǎn)自 OneAPM 官方博客
原文地址：http://www.javaworld.com/article/3075443/agile-development/15-signs-youre-doing-agile-wrong.html
