如何將敏捷應用於個人項目？

瞭解了源代碼控制後，我做的第一件事就是用svn做一個項目。在瞭解了git之後，我在一個個人項目中使用了它。在學習了關於UML /設計模式/設計原則/ TDD之後，我將它們應用於個人項目。我怎樣才能實現敏捷開發？對於團隊和大項目來說敏捷嗎？我如何設置這些迭代的東西？如何將敏捷應用於個人項目？

來源

2009-06-12 kthakore

我認爲敏捷絕對不只適用於團隊項目。敏捷提倡一套適用於多種類型項目（甚至是個人項目）的價值觀。我剛剛處於你的情況，試圖將敏捷開發應用於個人大學項目，並在此過程中學到了很多東西。一些有用的東西，敏捷的思維可以給你包括：對東西

的工作，增加價值，最終產品。讓自己積累一些功能並優先考慮它們，就好像你是客戶一樣。然後訓練自己根據對產品的價值對功能進行處理，而不是現在想要執行的功能。這可以爲您節省大量不必要的，過度設計的代碼，您不會使用它。如果你有期限，那更重要。
有一個進化的設計：從最簡單的事情開始，可能工作和重構殘酷。
推遲決定，直到最後負責任的時刻。
時間盒自己進入衝刺或迭代（上大學的項目很重要）。
...

如果你去一些敏捷方法再次，我想你會發現很多，你可以自己申請的價值觀和做法。

在寫這個答案的時候，至少有3個其他的答案出現了，並且打敗了我。我同意所有這些。 :)

來源

2009-06-12 18:07:09 Avish

例如，如果結果更加靈活和健壯，不要害怕重構自己的代碼，即使它有效。

來源

2009-06-12 18:01:04 kmarsh

所以我重複迭代？或者我先開發一些功能然後迭代它們然後繼續？ – kthakore 2009-06-12 18:05:37

單元測試你的代碼。 *然後*採取kmarsh的建議和重構。通常情況下，特定卡片的估計值會考慮到重新構造新特徵所涉及的代碼區域所需的時間。 – JeffH 2009-08-04 14:07:41

很難真正將敏捷編碼應用於單人項目，因爲其許多好處都針對小團隊，您可以在專注領域快速合作。

這就是說，你可以採取一些技巧：

發行往往
專注於用戶需求
隨意從主要版本的計劃偏離 - 你可以改變方向時，你感覺需要
花費更少的時間建立主要框架，儘快獲得工作。然後返回並重構以完成您的原始需求（如果它們仍然適用）

來源

2009-06-12 18:05:18 Oli

無論如何，很多獨立開發者可能會遵循敏捷技術，因爲他們沒有其他人的負擔，這取決於他們的代碼結構從一天到另一天都是一樣的。最大的不同在於項目的開始。你仍然需要計劃的東西，但得到*的東西*工作ASAP比其他方法（如瀑布）更關注 – Oli 2009-06-12 18:08:32

在您的應用程序中創建您想要的任務和功能列表。把這些任務放在card wall上。

你自己真的不能開會，但早上決定你今天會做些什麼，以及你昨天做了些什麼。採取這些任務，做他們，然後移動到下一個。確保在每一點上您都能提供持續集成的工作軟件，並更新您的積壓工作。你可能有「bug bash days」，你只需修復bug。這將是一個單人混亂。 :)

來源

2009-06-12 18:05:44

是一個方法來拿出故事卡片？ TDD？設計和架構在哪裏完成？ – kthakore 2009-06-12 18:35:14

對於單人項目，我會說Feature Driven。設計完成後，你知道你正在建設什麼功能。 – 2009-06-12 23:58:30

是可能使用Scrum的一個男人項目。

創建積壓
最佳時間選擇一個衝刺是

半天在週五創造下週併爲每個項目每半天更新burndowns計劃。

來源

2009-06-12 18:05:58 MicTech

在這幾個想法：

迭代只要你想他們是
的IPM仍然是可能的，你選擇你想要做主持的時間長度是什麼
演示結束時仍然看到一個有點專業的方式工作的功能，而不是你自己的小調試區域可能不乾淨有序的
回顧展仍然看是什麼，是不工作有用有用爲自己在一個點，你可以選擇e森林樹木在某種意義上

在IMO這樣的個人單人項目中，很有可能成爲Agile。

來源

2009-06-12 19:15:24

這裏的所有建議都很好，但是敏捷的一個重要方面通常沒有提到：監控。

敏捷要求你看看你做了什麼，你在做什麼，你要去哪裏，並根據需要進行適當的修正方向。

我覺得大可見圖表和燃盡/燃耗圖表是非常有用的，我寫了一個程序，Task Analytics，容易使這些圖表。它非常適合小型或單人項目。

祝你好運。

來源

2009-06-12 23:51:34 Ray

除了成對發展之外，如果您願意扮演多個角色，則可以執行其餘的練習。如果你有願意和你一起工作的人，你也可以配對開發。

首先，您會構建產品積壓。這將是您希望開發的功能或故事卡的優先列表。沒有一張卡應該比你在一次迭代或衝刺中完成的工作更大。如果您的衝刺週數爲一週或兩週，這將決定您的優先級產品待辦事項中功能或故事卡的大小。作爲產品所有者，您可以更改每次迭代的產品積壓優先級。從產品積壓中，您可以構建您的迭代和發佈計劃。

由於您正在扮演多個角色，您需要留出時間讓您創作故事卡片。故事卡應該勾畫GUI，描述主要和次要工作流程，最重要的是具有驗收標準。

一旦你簽署了書面故事卡，你就可以開始在卡上進行開發。您可以使用TDD（測試驅動開發）先編寫測試，然後再編寫代碼。你會重複，直到卡完成。驗收標準將幫助您確定要編寫哪些單元測試。

卡的開發完成後，您可以編寫自動功能測試。您可以使用Quick Test Pro，FIT，黃瓜或其他一些最受歡迎的自動化單元測試工具。我會遠離任何遊戲和錄製功能，因爲這會在您重構時在未來推動返工。

一旦單元測試完成和該卡道，它可被添加到所有其他自動功能測試，並且可在每張支票至少每日如果不運行。

在迭代的結束和在將工作軟件移至生產之前，您可以執行用戶驗收測試。

作爲開發人員，您應該使用持續集成，自動化構建將隨每次頻繁檢入您的源代碼控制系統而啓動。

在故事卡寫完之後，開發卡片進行迭代之前，您可以完成任務（即，爲開發卡片所需的每項任務提供估計值）。您可以確定是否可以在您的估算中完成所需的任何重構，或者您需要創建一個新的故事卡片來捕獲您確定的技術債務。如你所見，你可以把一個單一的成員敏捷團隊帶到很遠的地方。鑑於敏捷管理實踐有助於協作並確定重要的事情，您也可以從這些實踐中受益。鑑於工程（XP）實踐使代碼保持健康，從而支持可持續的步伐，您的代碼將保持靈活性，包含強大的單元和功能性自動化測試工具，使您可以無限期地以可持續的速度繼續開發。

來源

2009-06-27 02:33:24

如何將敏捷應用於個人項目？

回答

相關問題