敏捷軟件開(kāi)發(fā)團(tuán)隊(duì)必須確保他們開(kāi)發(fā)出來(lái)的產(chǎn)品質(zhì)量能夠滿足要求，管理團(tuán)隊(duì)也經(jīng)常希望開(kāi)發(fā)團(tuán)隊(duì)能夠提高速度以實(shí)現(xiàn)為客戶提供更多的功能。本篇
文章中多個(gè)作者探討了質(zhì)量和速度之間的關(guān)系，并提出了一些既能提高質(zhì)量也能加快進(jìn)度的方法。
Bob Galen曾今在他的博客中發(fā)表了讀懂我的唇語(yǔ)-敏捷并不快速的文章，在其中寫(xiě)到了追求軟件開(kāi)發(fā)進(jìn)度下質(zhì)量的重要性。
敏捷是一個(gè)“質(zhì)量游戲”，如果你以正直，承諾以及平衡的心態(tài)來(lái)玩這個(gè)游戲的話，那么結(jié)果將會(huì)是非常好的“速度游戲”，但它（速度）卻并非沒(méi)有代價(jià)。。。
如果你無(wú)法玩轉(zhuǎn)這個(gè)質(zhì)量游戲，你所采納的
敏捷開(kāi)發(fā)方法甚至比你以前使用的開(kāi)發(fā)方法更慢。
團(tuán)隊(duì)必須致力于把
工作在一個(gè)迭代中完成，這也就意味著這些工作需要滿足定義工作完成的所有標(biāo)準(zhǔn)。
很多敏捷團(tuán)隊(duì)允許返工 – 修復(fù)漏洞，完成
測(cè)試自動(dòng)化，重構(gòu)，或者設(shè)計(jì)不良導(dǎo)致sprint迭代的延誤。即使大多數(shù)的敏捷工具允許拆分用例故事以捕捉在sprint迭代中已經(jīng)完成的工作對(duì)比延期的工作，我也還是認(rèn)為這給團(tuán)隊(duì)傳達(dá)了錯(cuò)誤的信息，讓他們認(rèn)為工作不在一個(gè)sprint迭代內(nèi)完成是可以接受的。
讀懂我的唇語(yǔ) – 并不是把所有事情做完，做完，做完！
正如Bob解釋的：一個(gè)組織不應(yīng)該總是力圖讓進(jìn)度變得更快，而應(yīng)該更加注重質(zhì)量。
因此，下一次當(dāng)你聽(tīng)到有人在激情澎湃的談?wù)撝艚荽砹烁斓乃俣葧r(shí)，請(qǐng)打斷他們，嘗試向他們解釋敏捷并不是一個(gè)“速度游戲”，而是應(yīng)該強(qiáng)調(diào)敏捷是一個(gè)“或許能夠快速運(yùn)轉(zhuǎn)的質(zhì)量游戲”。
Tim Ottinger曾今寫(xiě)過(guò)關(guān)于敏捷團(tuán)隊(duì)進(jìn)度的14個(gè)奇怪觀點(diǎn)，其中一個(gè)觀點(diǎn)中就提到了質(zhì)量和速度之間的關(guān)系。
盡管大家通常會(huì)降低質(zhì)量要求以求在較短時(shí)間內(nèi)盡快完成工作，但是如果團(tuán)隊(duì)所開(kāi)發(fā)的代碼質(zhì)量不高的話，經(jīng)過(guò)全部sprint迭代后的進(jìn)度最終都還是會(huì)被降低。
Stephen Haunts在他的題目為進(jìn)度并不是目標(biāo)或者目的博客帖子中，描述了當(dāng)管理者設(shè)定團(tuán)隊(duì)的進(jìn)度目標(biāo)后對(duì)質(zhì)量會(huì)產(chǎn)生什么影響：
（…）為了增加交付的功能點(diǎn)數(shù)目以滿足績(jī)效目標(biāo)，團(tuán)隊(duì)會(huì)犧牲掉系統(tǒng)的質(zhì)量，但從長(zhǎng)遠(yuǎn)來(lái)看這樣最終還是會(huì)降低團(tuán)隊(duì)的進(jìn)度，并且會(huì)引入技術(shù)隱患。敏捷團(tuán)隊(duì)最好關(guān)注正在開(kāi)發(fā)系統(tǒng)的質(zhì)量與流程過(guò)程（持續(xù)交付和集成等等），以及負(fù)責(zé)開(kāi)發(fā)系統(tǒng)的團(tuán)隊(duì)成員本身。
軟件開(kāi)發(fā)者必須在進(jìn)度和質(zhì)量之間掌握平衡，正如Blake Haswell在文章什么是代碼質(zhì)量中解釋的那樣：
雖然經(jīng)常會(huì)有很多的外部壓力向進(jìn)度方面傾斜，但是如果你不夠重視質(zhì)量的話，進(jìn)度最終還是會(huì)趨于緩慢以及停滯，以至最終整個(gè)項(xiàng)目走向顛覆。考慮到一個(gè)項(xiàng)目的代碼質(zhì)量決定了它能夠在多大程度上適應(yīng)需求的變化，一個(gè)可以持續(xù)改進(jìn)的事情是你需要花費(fèi)一部分時(shí)間來(lái)優(yōu)化自己項(xiàng)目的代碼質(zhì)量。
Blake提供了一個(gè)可以用來(lái)檢查代碼質(zhì)量的屬性列表：
可理解性： 代碼需要在各個(gè)層面上能夠被容易地理解。理想情況下，軟件應(yīng)該非常簡(jiǎn)單，并沒(méi)有非常明顯的缺陷。
可測(cè)試性： 代碼需要被編寫(xiě)的非常容易被測(cè)試。
正確性： 代碼需要滿足功能和非功能性的需求。
有效性： 代碼需要有效的使用系統(tǒng)資源（內(nèi)存，CPU，網(wǎng)絡(luò)連接，等）。
Hugo Baraúna在他的博客文章名為內(nèi)部質(zhì)量低下軟件的癥狀中解釋了軟件是如何因?yàn)樽兏?#8220;變得更糟”的，最終導(dǎo)致質(zhì)量低下并且降低進(jìn)度。
假如你正在領(lǐng)導(dǎo)一家創(chuàng)業(yè)公司的技術(shù)或者產(chǎn)品團(tuán)隊(duì)，你是首席技術(shù)官，并且已經(jīng)推出了你們產(chǎn)品的第一個(gè)版本，做的還挺成功的。你們的業(yè)務(wù)模型已經(jīng)得到了驗(yàn)證，現(xiàn)在你們正處于快速發(fā)展期。這真是太棒了！但這也是有代價(jià)的，它帶來(lái)了一系列新的挑戰(zhàn)。
你們產(chǎn)品的第一個(gè)版本工作的很好，但是代碼庫(kù)卻無(wú)法滿足持續(xù)發(fā)展的要求。或許你的團(tuán)隊(duì)進(jìn)度并沒(méi)有像以前那樣好了，團(tuán)隊(duì)成員一直在抱怨代碼的質(zhì)量問(wèn)題，首席執(zhí)行官和產(chǎn)品經(jīng)理想要一些新的功能，但你現(xiàn)在代碼規(guī)劃根本無(wú)法滿足業(yè)務(wù)的需求。
他提供了一個(gè)指示質(zhì)量低下的癥狀列表，這個(gè)列表能夠幫助你來(lái)決定是否需要重寫(xiě)或者重構(gòu)：
所有事情都很艱難
進(jìn)度慢
測(cè)試套件運(yùn)行緩慢
無(wú)法避免的缺陷
你的團(tuán)隊(duì)是消極的
知識(shí)缺乏共享
新開(kāi)發(fā)人員成長(zhǎng)周期太長(zhǎng)
你又是如何平衡質(zhì)量和進(jìn)度的呢？
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters