《敏 捷 教 練：如何打造優秀的敏捷團隊》—6.5 難關

6.5? 難關

在實踐過程中，可能會碰到以下難關。

沒有面向用戶的功能

用戶故事最適合用于描述真人用戶的需求。如果項目要重寫基礎框架或架構，通常就不會有任何明顯的面向用戶的功能描述。

類似“作為一名……我想要……這樣是為了……”這樣的模板恐怕沒什么作用。但“誰想要這個？為什么？”等類似的問題依然有助于理解工作安排。團隊照樣可以交談，討論要解決什么問題，能帶來什么好處，要用哪些故事測試來確認故事是否已可交付。

用戶故事也可以用于給一堆技術任務包裝一個更有意義的描述，這能讓客戶和管理層更清楚每個迭代里所做的事情。如果用開發人員的技術語言來描述這些工作，像庫啊、代碼段啊、什么的，對客戶來說就跟聽天書一樣了。

下面來看個例子。下面有一段描述了一些基礎框架相關的工作內容，但沒有講清楚為什么需要做這件事情。“在Fred上安裝WIBLv2”，WIBL是一個代碼庫，Fred是一個網絡服務器。讓我們假定使用WIBLv2更新軟件的目的是針對亞洲市場處理不同的字符集。我們可以把它重寫成一個用戶故事：“作為產品經理，我想要看到用亞洲字符集顯示的書籍信息，這樣我們就能夠把書賣到亞洲市場了。”這樣能更清楚地闡明這件事情的緣由。最初的描述“在Fred上安裝WIBLv2”是實現這個新用戶故事的一個任務。新的用戶故事還能夠指引團隊得出需要運行的測試，以證明此故事。

需求必須有記錄

有些組織嚴格要求正式記錄軟件需求，通常是因為它們處在受監管的行業之中，必須顯示它們遵守了某個可審核的流程。也有些時候是因為要使用這些信息來支持團隊間的工作移交，例如把工作移交給某個運營團隊。

用戶故事還是可以用，只是現在還需要把它們記錄下來。可以采取拍數碼照片(或是復印件)的方法，快速創建故事的電子記錄。討論用戶故事時在白板上畫有草圖，你或許也想把它們記錄下來。如果你需要記錄十分完整的文檔，可以在用戶故事交談完成后再寫。

創建文檔而不受代碼干擾還有另一種方式，使用FIT[1]這樣的測試框架以可執行需求的形式來寫故事測試。

團隊無法見面

顯然，如果團隊成員分布在不同的辦公室里，交談的時候就無法使用卡片和便事貼。你仍然可以以用戶故事為基礎進行交談，討論用戶的需求和確認故事已實現所需要進行的故事測試。若無法使用索引卡，就選擇其他簡單可行的辦法。例如，可以使用桌面共享軟件(如NetMeeting或WebEx)，以便各地團隊能看見相同的畫面。索引卡沒法用，就配合使用一些簡單的軟件，只要能創建虛擬便事貼即可。

敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。