我們想分享處理任務的原則 Django 網絡開發公司 這是我們多年實踐形成的。 他們的目標是創造一種思維方式，旨在提高取得成果的有效性。
這篇文章對初學者和年輕的團隊很有用。 這些原則很容易應用於任何開發過程和工具。 它們基於對任務本質的理解以及如何完全使用它。
這裡的任務指的是特定的“任務”和“功能”或“史詩”。 文中不會有解釋原則的例子，以免誇大其詞。 我將留下一些推薦的材料，這些材料將更廣泛地揭示個別論文的本質，我很樂意在評論中回答剩餘的問題。
目標導向
為什麼每個任務都有一個目標？ 為了使實現它的過程有效，必須從任務中清楚地知道為什麼需要預期的結果。 問題表述的有用問題：
- 需要產生什麼結果？
- 為什麼需要這個結果？ 它是乾什麼用的？ 它會給誰帶來什麼價值？
- 如何理解問題解決了（得到了結果）？
考慮到正在開發的系統用戶的需求和特徵以及業務目標，提出這些問題。 把自己放在用戶或客戶的位置上。 這很困難，但您可以學習：嘗試檢查經驗豐富的同志的假設。
設置任務是什麼意思？
思考和描述：
- 目的、需要或問題。
- 期望的結果。 將其與目標對齊。 確保結果有助於其成就。
- 約束，例如時間或技術。
對於執行者、作者、測試者和其他有興趣解決它的人來說，任務應該同樣清楚。 依靠普遍接受的概念，排除雙重解釋，足夠但不多餘。 一方面，你不應該為表演者創造不必要的限制。 另一方面，有必要不要錯過對結果的重要要求。
接受任務是什麼意思？
- 了解所需的結果和目的。 同意他們彼此之間的最佳對應關係。
- 同意任務在時間或解決方案的最大復雜性方面的限制。
- 對在規定範圍內取得成果負責。
設置任務的人負責設置任務。 但在接受工作任務之前，您可以影響其措辭，並與作者一起討論和更正。
問題中存在不確定性始終是一種風險。 在接受一項任務之前，了解使用它的策略。
製作是什麼意思？
當任務的執行結果已準備好用於預期用途並且不需要額外的操作時，任務就“完成”了。 任務不能“幾乎完成”。 它要么完成，要么處於任何其他狀態。 提交測試的任務也是尚未完成的任務。
如果你聲稱你已經完成了任務，這應該意味著：不需要額外的測試、部署和驗證，並且可以使用工作的結果。 反之亦然：如果不需要進一步的操作，並且結果帶來了預期的收益，那麼任務已經完成，應該轉移到完成狀態。
當說一項任務必須在某個時刻完成時，到那個時候它必須已經通過了生命週期的所有必要階段，包括測試和驗收。 為了按時完成任務，您需要在截止日期之前開始“上交”。
這一原則也應適用於規劃。 說出解決問題的時間和勞力，考慮測試、調試等。
效率
越早獲得增值結果越好。 反饋出現得更快，質量管理、期望和整個項目都更有效。
將任務推向完成。 他們不應該停留在一種狀態或與一位藝術家一起積累。 這些是降低實現結果的有效性的問題的症狀。
需要“健康”的分解來維持性能原則。
根據需要分解
任務分解應該提高獲得整體結果的效率，簡化項目管理過程。
一個好的分解水平是當每個任務的結果都可以用來控制項目整體結果的實現及其質量。 同時，中間結果的出現並不會減慢實現目標的過程。 任務越小，在它們之間切換的干擾就越多。
通信時間跟踪
如果你需要記錄花在工作上的時間，可以考慮花在溝通上的時間。 熟悉問題及其討論是解決過程的一部分。 你不應該為“談話”開始單獨的任務。
例如，與 SaaS 程序員討論應用程序的設計（https://www.softformance.com/services/saas-development/)，設計師和開發人員之間的一個例子，是開發這個設計任務的一部分。 溝通是一種協作工具。 但在解決問題的複雜性上也需要考慮溝通。 有時，與編寫代碼相比，找出並達成一致需要更多的時間。 沒關係。
