Scrum，但沒有測試或文檔

Question

當你加入一個聲稱他們使用Scrum的團隊時，你會做什麼？但是隻將它用作時間管理工具而不是整個過程？ 如何恢復測試和文檔？

我正在考慮從添加用戶故事開始，專門用於測試和記錄。 也許別人有更多的經驗，然後我會這樣做，因爲我相信它並不罕見。

Answer 1

的是，他們沒有任何文件和試驗問題或者他們沒有實施整個Scrum方法？在我看來，這是兩個非常不同的問題。

我更願意花費時間和精力尋找和適合符合其開發風格的開發流程的組織，而不是強制要求高度真實的流程。因此，如果他們使用他們稱之爲Scrum的流程，但不符合所有「官方」指南，我都不會感到擔心。嘗試確定過程爲何如此。有機會，如果他們花時間量身定製，團隊會接受你的想法，特別是如果你花時間來確定事情的方式。如果你把它簡單地理解爲「這不是Scrum，那麼它就不對了」，你可能不會取得多大進展，但通過對實用性的好處進行實質性的改進。

另外，如果他們沒有做測試，也沒有任何文件，我會認爲這是一個相當不好的跡象。通過文檔，我正在採取極簡主義的觀點 - 功能列表，錯誤跟蹤等。 - 我會非常擔心這些項目的缺失，而不是擔心抽象表中較高的項目不存在。在沒有管理層的支持下，我建議你以身作則。自行設置一個簡單的錯誤跟蹤系統（有幾個 - 在一箇中心位置簡單的文本列表也適用）。在其他人測試之前，不要將功能聲明爲完整。這可以像走到另一個開發人員那樣簡單，並要求他們在你面前嘗試。如果有人聲稱某項功能已完成，請花幾分鐘熟悉一下。如果您發現錯誤，請向責任開發者禮貌地提及。慢慢構建一個團隊可以看到運行測試和跟蹤功能和錯誤的好處的環境。

大多數團隊都是這樣操作的，只是因爲他們錯誤地認爲他們沒有時間「做得對」，或者他們稍後纔會去做。通常情況下，當一個開發人員或者兩個開發人員將一個簡單的概念證明變成一個完整的開發工作時，會發生這種情況。通過表明它實際上可以節省時間和精力，並降低團隊其他成員的初始成本，您通常會發現它作爲流程的一部分而變得根深蒂固，而沒有真正被官方認可或接受。

如果您有管理支持，它將使其變得容易得多，但請務必小心確保團隊能夠接受這些更改。這可能意味着它需要比您想要的更長的時間，但如果沒有團隊的支持，任何強制流程都會在首先出現壓力跡象時失敗，這是您最需要流程的時候。

*免責聲明 - 在我最後一個項目中，我帶頭開始調整SCRUM流程以適應我們的環境。對於我們的客戶來說，「官方」流程簡直站不住腳，但它仍然是定製我們流程的寶貴指南。

Answer 2

Scrum的關鍵在於任務在完成之前可以被識別爲「已完成」。您如何評估是否在沒有審閱文檔和測試的情況下完成某項工作？

也許他們有一個不尋常的，但有效的做法。或者他們可能錯過了「完成的任務」。我建議你先問問他們如何衡量，以及是否可以改進。然後建議將文檔和測試作爲改進流程的方式。

Answer 3

「添加專門用於檢測和記錄用戶故事」

雖然元的用戶故事可能會在某些圈子裏是有意義的，它很少工作搞好。軟件人員很少能夠很好地處理元用戶的故事，他們要麼沒有意識到他們可以通過編寫故事來改變自己的流程，或者更典型的是他們將元用戶故事設計成死亡。

當你在面試用戶時，感覺他們正在創造用戶故事。當然，當你傾聽他們並試圖捕捉它時，你就會做出決定。

當IT部門試圖編寫自己的用戶故事以瞭解IT應該如何工作時，流程就會崩潰。在組織完成了一些事情（例如測試）之後，他們並不真正有資格編寫用戶故事。然後，在他們完成之後，他們不需要軟件開發流程，他們只需一次一點點地自動化重要的部分。

我認爲改變必須來自一個不太正式的方向。實際上，呼叫未完成測試的「完成」是一個很好的起點。

除非強制，否則它不會執行任何操作。因此，與用戶見面，瞭解他們爲什麼不需要測試。教他們需要測試。告訴他們後果和使用的詞語。

很多組織可能會出現錯誤導致不良的流程。重要的是要知道什麼是錯的，並創造變革的需求。最好的辦法是讓你的老闆抱怨你沒有解決問題，而不是說你可能會解決這個問題。

[它不感覺權當你的老闆要求你修復的過程，但它是關於唯一的方法改變將會發生。]

Answer 4

請注意，測試和文檔實際上都不是Scrum的一部分。 Scrum是一種純粹的項目管理方法 - 所要求的工程實踐，就像你提到的那樣，應該在項目中「出現」。最具體的說，它們應該在每次衝刺結束時做的心跳回顧期間被識別出來。你在做這些嗎？你能否提出你的擔憂 - 他們是否真的是球隊最關心的問題？