2008-09-22 27 views
13

我們剛剛開始一個非常大的項目,其中有很多子項目。我們目前不使用任何形式的命名過程,但我希望在後門得到某種敏捷/類似Scrum的過程。管理大型項目的用戶素材

我最關注的領域是爲整個項目準備好積壓,至少在我的腦海裏,有一個迭代的想法,從積壓中取出一些東西,更詳細地研究和開發到合理的期限。

我想知道人們用什麼技術將項目分解成積壓的東西,一旦積壓被創建,如何維護和訂購。也是如何維護元素之間的關係(即這必須在可能之前完成,或者這是一個故事,現在它是五)

我不知道我期望這個問題的答案看起來像。我認爲最有幫助的是,如果有一個開源項目能夠以某種方式保留其在線備份,那麼我可以看到別人是如何做到的。

別的東西,就從我這裏得到+1是從實際項目實際用戶案例(實例的「用戶可以登錄」的故事並不能幫助我的圖片的東西在我的項目。

感謝。

+1

由於兩個原因,我不得不放棄你。我喜歡聽到關於這類東西的人們的想法,而且你的聲望也在666上! – mattlant 2008-09-23 01:17:10

回答

9

我會建議你在採用工具之前仔細考慮,特別是因爲聽起來你的腳步起初很容易流動。我的感覺是,一個工具可能更容易限制你,而不是在這個階段啓用你,你會發現它不能代替good card-wall in physical space。我建議你把精力集中在手邊的任務上,當你覺得自己真的需要時,抓住一個工具。到那個階段,您將更有可能清楚地瞭解您的需求。

我已經運行了幾個敏捷項目,我們從來不需要比電子表格更復雜的工具,以及預算超過一百萬英鎊的項目。大多數情況下,我們發現白板和索引卡片(每個用戶故事一張)就綽綽有餘。

當確定你的故事時,確保你始終用對你的用戶有意義的術語來表達它們 - 一些(可能只是很小的)浮現功能。永遠不要讓自己陷入有關技術細節的書面故事,而這些故事無法向用戶展示。

安排故事的技巧是嘗試優先考慮你最不瞭解的事情(計劃你想學什麼,而不是你想做什麼),同時從故事開始,讓你可以開發應用程序的核心功能,使用後續故事來圍繞它們打包功能(和技術複雜性)。

如果您確信自己可以在後期留下一些難題,請不要爲了詳細描述而放棄 - 只需編寫一張代表您需要擁有的大對話的單一故事卡即可之後,繼續做更重要的事情。如果您需要了解將要發生的事情的大小,請看一下稱爲planning poker的寬帶德爾菲估計技術。

Mike Cohn的書籍,特別是Agile Estimating and Planning將在這個階段幫助你很多,併爲你提供一些有用的技巧。

祝你好運!

2

我不確定這是不是你想要的,但它可能仍然有幫助。從codesqueeze的Max Pool有一段視頻來解釋他的「敏捷牆」。看到他的過程很酷,即使它不可能必然涉及到你的問題:

My Agile Wall (Plus A Few Tricks)

2

所以這裏有一些提示: 我們使用RallyDev。
我們創建了一個我們的需求所在的包的視圖。 大型故事被標記爲史詩,並被放入他們打算髮行的版本的發行版積壓。童話故事被添加到史詩。我們已經發現最好保持故事非常細化。粗粒度的故事使得難以真實地估計和執行故事。

所以一般:

  1. 通過釋放

  2. 組織保持

  3. 產品負責人需要2-4周的 迭代和項目經理 添加故事釋放積壓

  4. 開發團隊估計 個基於T恤的尺寸, 點等的故事...
  5. 在Spring規劃 meeetings開發團隊選擇從 釋放積壓的迭代 工作。

這就是我們過去4個月一直在做的事情,並且發現它運作良好。保持故事的規模小而精細非常重要。

記住投資和智能首字母縮寫,用於評估用戶的故事,一個好的故事應該是: 我 - 獨立 N - 元 N - 價值 ë - 估 的S - 小 筆 - 可測試

智能:

的S - 具體 米 - 可測量 A - 可實現 的R - 相關 筆 - 時間盒裝

1

我會說Keep it Simple ..使用共享電子表格跟蹤(和備份)。如果您看到擴展或同步問題,從而使積壓狀態維持在一致狀態變得越來越耗時,則需要進行交易。這將自動驗證和證明支出/再培訓成本。

我讀過一些關於Mingle from Thoughtworks的好東西。

4

和DanielHonig一樣,我們也使用RallyDev(小規模),聽起來它可能對您至少是一個有用的系統進行調查。

另外,關於用戶故事開發方法的一本很棒的書是Mike Cohn的User Stories Applied。如果你還沒有,我肯定會推薦閱讀它。它應該回答你很多問題。

1

很多這些迴應已與有關工具的使用建議的迴應。然而,事實是,你的過程將比你用來實現過程的工具重要得多。遠離那些試圖將方法壓縮在喉嚨上的工具。但是,要謹慎使用新工具來實施舊的非敏捷流程。這裏有一些強大的事實確定過程的工具時要考慮:

  1. 一個糟糕的過程與軟件工具將導致不良 軟件工具FPGA實現儀表。
  2. 流程將根據您管理的組而發生變化。 重要的是人,而不是過程。實施 他們可以成功地工作,並且你的項目會成功。

所有這一切說,這裏有一些準則,以幫助您:

  • 開始與純實施文件化的過程中,
  • 讓你的迭代小,
  • 每次迭代的講話之後與你的團隊,並問他們他們 會改變,實施有意義的變化。

對於較大的組織,如果您使用SCRUM,請使用級聯站立機制。 Scrum大師與他們的團隊見面。然後Scrum大師以6 - 9的立場開會,超級Scrum-MAster負責將Scum-Master的Scrum項目報告給下一級...等等。

你可能發現每週超級會議會在您的層次結構的最高級別上滿足要求。