按時發貨軟件的最佳實踐

Question

想象一下，您不會遇到功能蠕變的問題，您擁有一支積極穩定的團隊，明確定義的問題需要解決，並瞭解與您的項目相關的域/語言/工具。

你怎麼樣堅持一個時間表並完成這個1.0里程碑？
你對迭代運輸的方法是什麼？

我想特別爲一個小團隊提供建議，那裏幾乎沒有或幾乎沒有任何溝通問題。

Answer 1

1. 專注於功能而不是實施任務。
2. 在迭代中工作（如每週或每兩週）。
3. 按照優先順序將工作特徵發佈到臨時環境中。
4. 單元測試你的代碼，所以你沒有放慢buglist，當你接近發佈日期時，它會以幾何形式增加。
5. 準備從較不重要的特徵中縮小範圍。東西總是比你想象的要長。
6. 確保您提前勾畫出用戶界面（如果有用戶界面），並將其展示給潛在用戶。
7. 測試，測試和測試更多。這似乎與直覺相反，但它比所花費的時間更多。

Answer 2

這可能是一個烏托邦的場景;-)。但不管怎麼說，如果沒有功能蔓延，非常優秀的球隊，有絕對再沒有任何通信問題可能明確要求，按時將

1. 與團隊每週會議，評估目前的狀況的產品的最佳方式（下午有團隊，如果有PM）
2. 團隊負責人可以與團隊成員每天舉行一次小型會議，以評估他們在委派給他們的問題/要求上的狀態。如果有問題，他/她應該採取必要措施解決問題。
3. 項目計劃跟蹤和工作授權（團隊領導需要知道每個團隊成員的適當委派工作的個人優勢）。
4. 測試可以在技術允許的範圍內自動進行。
5. 每個團隊成員的工作所有權。

一天結束時，它歸結爲一個人對工作充滿激情。

只是我的2派士的;-)

Answer 3

Question: How does a large software project get to be one year late? Answer: One day at a time!

不提供回答你的問題，但我認爲它確實表明，需要堅持你的日程安排 - 如果你連得到一天後，你需要以某種方式追上它。 （不幸的是，神話人月的其餘部分都是關於如何在大多數項目中沒有「莫名其妙」......）

此外，看看產品中的基於證據的調度，如FogBugz。這會爲您提供產品何時可能發貨的最新估計 - 事實上，它會給出一系列日期，並提供每個日期的概率。如果你看到你的發行日期可能會越過最後期限，這會讓你知道你需要做些什麼 - 並希望有足夠的時間來產生效果。

Answer 4

以前的海報錯過了一小點。爲了達到最終期限，首先應確定實際的時間表。 該項目應該分成小任務它取決於項目規模，但在我的項目需要大約3-4個月的世界裏，我們試圖將它們分成最多2-3天的任務。這樣，時間估計大部分是現實的，並且提前計算風險並將其添加到提議的時間表中。

Answer 5

在這個線程中有很多很好的建議。我唯一需要補充的是採用定期發佈的時間表。幾年前，我的公司轉向了這一點，開始時這很痛苦，但它確實有很多好處，其中最大的好處就是允許人們輕鬆推遲功能。

推遲功能是可以的，因爲您知道您的功能可以使其進入下一個版本，並且您知道該版本的發佈時間。這意味着您不必急於在最後一分鐘獲得您的一半功能，您可以花更長時間並在下一個版本開始時使用它。

Answer 6

除銷售/市場/管理不合理的時間表外，您幾乎排除了項目無法按時發貨的所有原因。的軟件開發方法的歷史，是一組方法來解決，減少的影響，和/或避免：

• 不好界定範圍
• 功能蔓延
• 缺乏領域知識
• 大型團隊通信問題
• 無心/無能開發商

Answer 7

階段定期（每月？每週？）產品演練使用當前接受的版本，爲產品團隊的利益。儘可能早地開始。演示每個功能，無論其當前的可用性如何;不要跳過那些落後的問題。

關鍵是要讓利益相關者清楚地瞭解產品在項目過程中的當前狀態。通過這種方式，決策者更有可能迅​​速處理進度風險，而不是危及發貨日期。

Answer 8

瞭解客戶的關鍵任務特性。保護他們的進展。成功的80％通常來自20％的工作。

Answer 9

我喜歡說你可以選擇一個功能集或一個發貨日期，但不能同時選擇。

這裏有一些個人的想法： - 不被看好 - 做最困難的部分第一 - 寫在這樣一種方式，你可以把它們打的特點 - 不不打滑的時間表 添加功能日程表

http://shipcamp.com