將項目分解爲小任務

Question

上午我想知道，當一個新項目到來時，說建立一個社交網站，我該如何將項目分解成小任務。每個項目通常有2-4名程序員，通常沒有測試人員。我應該從一開始就把整個網站分成4小時的任務。我們應該分階段進行嗎？怎麼樣測試，讓程序員測試代碼可以嗎？

謝謝你的時間。

Answer 1

我們使用一個相當簡單的系統。

• 首先我們將項目分爲用戶故事或「垂直」。例如「更新客戶」。
• 製作電子表格第一列所有行的列表。
• 然後沿着頂部放置圖層或活動。例如數據層，用戶界面，日誌記錄。
• 對於矩陣中的每個元素，您都可以分配一個估計並決定誰應該開發它。
• 將其分解爲4小時的元素是很好的，因爲然後每個開發人員都可以在scrum中說：「我今天要做這兩項任務」。

我們通常爲每個sprint執行sprint中要完成的活動。

測試程序員應該通過編寫單元測試來測試代碼，但測試人員應該執行系統測試。

Answer 2

你需要拿出一本關於項目管理的基本書，閱讀並練習你從中學到的東西。查看維基百科有關項目管理的文章是一個很好的起點：http://en.wikipedia.org/wiki/Project_management

一種分解項目的方法是設置里程碑並做粗略估計以達到這些里程碑。不要過於複雜的事情。通常項目計劃和估算在項目開始時不可靠。但隨着你逐步進行評估，計劃會隨着你瞭解你正在建設的項目而改善。

你可能會把你的項目分解成4小時的任務，但這將是微觀管理（除非你真的可以將一個工作單元適合4小時:)）我建議不要這樣做，特別是在開始時項目。

對於程序員測試自己的代碼：今天

這是很常見的有程序員測試自己的代碼，測試就像是項目管理的一個巨大的領域。比如你做的系統開發生命週期的不同階段，不同類型的測試：

1. 在開發過程中，你可以做測試驅動開發 - >讓你的開發人員首先編寫測試，當他們的代碼是針對驗證該測試已準備好提交給您使用的任何源代碼庫。

2. 一旦您提交了所有代碼，並且您有軟件的早期版本，您可以執行內部測試，例如系統測試，您需要測試人員或程序員測試應用程序。

3. 當您對系統測試感到滿意時，您可以在用戶接受測試之前將其部署到任何位置。用戶驗收測試應該由您的目標用戶進行。

祝您與您的項目:)好運氣

Answer 3

這是一個論壇，一個很大的問題，所以我會與推薦一本書開始：

Agile Estimating Planning by Mike Cohn

，你可以從標題中可以看出它呈現出敏捷的方法。

直到你買和讀的書，這極短的版本可能是一些使用：

• 首先做一個粗糧規劃。例如：我們計劃在兩個月後部署第一個版本，其中包含非常基本的功能以使其真正可用。之後，我們將有一個關於每個月的新版本。確保你沒有深入細節。因爲無論如何，現實會殺死所有的詳細計劃。你可以認爲這個計劃，階段步驟，但請注意，他們不比賽經典的階段分析，設計，實現，測試，部署

• 對於更詳細的你是什麼樣的第一階段計劃將要做。使用垂直切片進行規劃，即不要規劃：首先，我們先製作GUI然後是模型，然後是數據庫，但使用完整的特徵，通常建模爲用戶故事。例如「作爲用戶，我想向系統輸入訂單」這將是一個用戶故事。該用戶故事的實現意味着將所有的用戶界面內容都做到持久化，還包括測試。 （谷歌的用戶故事「和「迭代計劃」有關的更多信息。）

對於您的測試問題：開發人員測試他們的代碼是更好然後沒有測試的。但是有更好的方法來確保高質量的代碼。我建議採用以下方法：

• 做測試驅動開發，即先寫測試，然後執行。這種做法迫使你和你的團隊使代碼結構合理，它支持代碼的快速更改，因爲測試會告訴你有關事件被破壞。

• 至少有部分時間做配對編程（越多越好）。這可以確保至少有兩個人瞭解每行代碼。它也可以作爲隱式培訓，最終作爲代碼審查，這是一件好事，因爲已知代碼審查比查找更有效地發現錯誤。

• 您仍然需要完整應用程序的手動測試。

更多的東西閱讀和谷歌：敏捷，Scrum，極限編程，TDD，BDD，計劃撲克，

Answer 4

另一本書中，你可能會發現有用的是

Software Estimation: Demystifying the Black Art

由史蒂夫·麥康奈爾

除了我只能重複其他人所說的：這基本上是「分而治之」。

Answer 5

怎麼樣測試，讓程序員測試代碼可以嗎？

如果您沒有任何質量保證，程序員必須測試他們的代碼！

我還建議程序員在做代碼評論（查看對方代碼）。作爲領隊我用來檢討一切從新員工，他們在檢查前：

• 質量控制（確保它們不會簽入的錯誤）​​
• 此外，培訓（看看是否有什麼東西他們不」知道和應該知道，我可以告訴他們）

我會停止審查一個人的代碼時，我的評語停止查找錯誤，當他們學會測試自己的代碼，會發生。