什麼是類項目最好的敏捷方法？

Question

該項目定義不明確：我們將爲CS 111計算機編程I學生編寫針對功能的教育軟件。我們有6名在Flex中工作的不同背景的學生開發人員。該項目持續約7周。我們的面部時間非常有限（每週30分鐘），工作時間非常有限（每個開發人員每週有8小時<）。我們對客戶的訪問有限（我們課程教授，CS 111教授，CS 111學生）。

我們的工具包包括Flex Builder，Subversion和TRAC。

什麼方法最適合這個項目，爲什麼？或者，應該從各種方法學中收集哪些特徵以更好地適應這種情況？

Answer 1

是什麼讓你覺得在這種情況下任何方法都會成功 - 溝通很少，比時間要求更多，缺乏客戶接觸？這就是說，我將重點放在增量交付（每個迭代應該有幾個工作特性），單元測試（所有測試在簽入之前通過），增量版本的標記（回到工作版本的能力），並將強大的團隊成員與較弱的團隊成員配對，以提高團隊的整體生產力。考慮讓一個強大的團隊成員參與集成測試。

增量交貨是最重要的。顯示比要求的少的工作演示總比顯示非工作原型好。

Answer 2

您可以在這裏使用敏捷方法，但顯然您必須採用它來滿足您的需求。

例如，如果您無法獲得真正客戶的足夠訪問權限，那麼對您的目標最瞭解的人將不得不充當客戶代理。我還建議試圖讓客戶有更多的機會 - 幾乎每個人都試圖看起來更忙碌，然後通常有辦法解決這個障礙。

確保您的團隊在同一時間擁有的工作時間有限。當你不能一起工作時，可能沒有敏捷方法。

你肯定可以使用基於故事的估計，迭代開發過程等

什麼是真正重要的是太給每一位團隊成員的敏捷過程是如何工作的一個清晰明確的認識，什麼是每個人的角色該項目。很容易說你會使用SCRUM，但不幸的是沒有真正的理解和經驗，這並不意味着太多。

幾點建議：

1. 教育你的團隊成員
2. 獲取你想提供，如果你不會因時間/資源限制什麼的清單。
3. 找出什麼是現實的交付給你的約束。這可能不會太多。不要試圖過於樂觀。關注你真正可以實現的目標。
4. 請確保您的真實客戶是在船上。
5. 使用短迭代（1周或更少）。確保您可以在每次迭代結束時交付經過完全測試的產品。
6. 提前展示你的工作。