帶透明材質(zhì)的描繪過程

這次，我想看看軟件開發(fā)過程中如何支持質(zhì)量。 我們將分析此類過程的某些階段，并檢查各個步驟的明確存在如何支持團隊和組織的質(zhì)量維護。

以下是我多年的觀察中的問題，在尋找有關(guān)質(zhì)量控制的答案時值得提出

• 在軟件開發(fā)過程的每個階段都明確定義了質(zhì)量概念嗎？
• 階段在什么基礎(chǔ)上可以正確完成？
• 是對“質(zhì)量”一詞進行了討論，同意，記錄和宣布，還是僅僅是員工對“質(zhì)量”的“期望”？
• 是否很容易在給定步驟中繞過質(zhì)量控制，例如由于緊急情況？

最簡單的板

在多家公司工作了近20年，并擔(dān)任培訓(xùn)師，我拜訪了許多辦事處，并與許多團隊進行了交談。 在這些辦公室中，我看到了許多板，這些板上都可以看到給定團隊的軟件開發(fā)過程，例如看板或Scrum。

這是最簡單的木板的一個例子

以上過程如何保證質(zhì)量？ 在哪里檢查代碼或添加缺少的測試用例？ 當(dāng)代碼在進行更改后不再被他人閱讀時，重構(gòu)的地方在哪里，這將阻礙代碼的開發(fā)？

我必須承認(rèn)，我多年以前工作的團隊也使用過類似的董事會。 很多時候，最常見的問題是該功能是否已經(jīng)實現(xiàn)。 這個問題通常是由充當(dāng)“測試員”的人回答的

質(zhì)量不是捉迷藏的游戲

根據(jù)我在上述情況下的經(jīng)驗，諸如添加缺失的測試，具有自動化的代碼質(zhì)量報告，重構(gòu)，根據(jù)新要求調(diào)整項目體系結(jié)構(gòu)之類的事情–如果發(fā)生，它們將以隱藏的方式執(zhí)行……您不會談?wù)撍麄冋?#xff0c;只有程序員將擴展編程或測試階段，以將它們?nèi)谀硞€地方..

可以輕松地跳過不是該過程正式部分的步驟。 另外，它們可以在過程外完成，但這總是會使程序員感到不適。

最壞的情況是基于不正確（不完整）過程的微觀管理。 當(dāng)程序員受到每小時一次的工作控制并且對質(zhì)量的關(guān)注不是過程的正式組成部分時，它肯定不會進入團隊。 如果程序員意識到技術(shù)債務(wù)的后果，也許會發(fā)生這種情況，但仍然會以隱藏的形式延長計劃的實施時間。

我遇到的最極端的情況涉及獎勵經(jīng)理以產(chǎn)品交付的速度，而開發(fā)人員/測試人員則是接下來幾個月客戶報告的缺陷數(shù)量的唯一“負(fù)責(zé)人”。 …

引入透明度

這個過程中是否有檢查點

• 代碼是否經(jīng)過審查？
• 更改后代碼仍然可讀嗎？
• 組件和/或集成測試是否覆蓋了代碼？

慣例是，如果我們沒有對工作中的事情進行正式評估，那么我們可能不會擔(dān)心。 可能同時發(fā)生的是，團隊成員只為交付速度付費，而從未根據(jù)客戶報告的缺陷數(shù)量來判斷。 在這種情況下，誰獲得薪水？ 這種方法可能在以較高速度工作的程序員與更加在意代碼質(zhì)量的程序員之間造成不健康的氣氛。

讓我們繼續(xù)分析下一個白板

這里對質(zhì)量的照顧看起來更好嗎？ 在這種情況下可以跳過代碼搜索過程嗎？ 此外，此過程強調(diào)，在代碼審查完成之前，沒有人可以在集成環(huán)境中測試解決方案。

盡管此配置在質(zhì)量控制方面聽起來更可靠，但我仍根據(jù)不同的工作組織規(guī)則看到了不同的結(jié)果。 這是兩個真實的例子

至少2位程序員應(yīng)檢查代碼更改。 但是在這種情況下，誰應(yīng)該對此做出全面負(fù)責(zé)？ 可能會發(fā)生兩個不同的程序員同時執(zhí)行粗略檢查的情況，以加快等待“可用”質(zhì)量工程師進行測試的任務(wù)。 而且，這兩個程序員中的每一個都可以假設(shè)另一個會更徹底地復(fù)習(xí)……

只有一個人可以同時審閱代碼，并對可讀性，測試用例的覆蓋范圍以及批準(zhǔn)變更所做的擴展可能性負(fù)全部責(zé)任。 如果這樣的人對質(zhì)量有任何疑問，他們有權(quán)將其評論提交給作者或下一位審閱者進行確認(rèn)。

第二種方法似乎更能抵抗“泄漏缺陷”。

引入更大的透明度

讓我們在董事會上再增加一列。

在上述情況下，很明顯質(zhì)量工程師執(zhí)行的測試僅在集成環(huán)境中進行。 您還可以清楚地看到任務(wù)何時已被檢查并且正在等待在集成環(huán)境中實施。

技術(shù)修復(fù)的透明度

代碼審查的結(jié)果可能是您需要進行更正。 這樣的更正可能是緊急的重構(gòu)，增加了缺少的集成測試。 它也可以設(shè)置約會會話以重新討論體系結(jié)構(gòu)，因為必須在整個團隊的層次上討論該問題。

一些團隊可能認(rèn)為這沒關(guān)系，只需將任務(wù)的最高優(yōu)先級放回“要做”一欄中。 但這是否有可能將具有新功能的任務(wù)與“補丁”任務(wù)區(qū)分開來？ 這是否意味著轉(zhuǎn)換任務(wù)將與“待辦事項”列中有關(guān)新功能的新任務(wù)競爭？ 因此，另一種選擇是顯式添加一列，其中任務(wù)將通過其他“修復(fù)程序”進行處理。

當(dāng)然，如果代碼復(fù)審順利，則可以省略“返工/修復(fù)”列，但是它的存在強調(diào)了對代碼質(zhì)量進行更正（例如，由于缺乏可讀性或缺乏測試范圍），即使代碼按預(yù)期工作。

任何其他透明度

要敏捷。 回顧期間定期討論所有質(zhì)量控制問題。 在過程中放置??有關(guān)質(zhì)量控制的最重要階段。 使他們“合法”和正式。 對質(zhì)量負(fù)責(zé)。

同樣，另一個示例：部署到生產(chǎn)環(huán)境中–讓每個任務(wù)的實際情況可見。 您可以自己討論這種專欄的好處。

摘要–確保質(zhì)量控制可見性

如果要保證質(zhì)量，則必須創(chuàng)建流程和程序來鼓勵人們提高質(zhì)量，并阻止人們跳過質(zhì)量。 在這樣的環(huán)境中，人們可以體驗因缺乏質(zhì)量而做出決策的后果，而且有權(quán)對這些原則進行自我完善。

密切注意過程的形狀。 使他的步驟非常清晰，并在質(zhì)量控制方面進行明確定義。 該過程應(yīng)突出顯示與需求有關(guān)的所有內(nèi)容，例如質(zhì)量，代碼可讀性，測試范圍，重構(gòu)選項，甚至交換技術(shù)和業(yè)務(wù)知識。

請記住，程序和流程可確保工作中的心理安全。 它們構(gòu)成了我們履行職責(zé)和評估工作的準(zhǔn)則。 如果未明確定義“預(yù)期”結(jié)果，則其發(fā)生的可能性將很小。

翻譯自: https://www.javacodegeeks.com/2019/08/transparent-quality-process.html

帶透明材質(zhì)的描繪過程

總結(jié)

以上是生活随笔為你收集整理的带透明材质的描绘过程_透明的过程质量的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。