使用看板和 Trello 管理軟件開發的初學者指南

已發表: 2022-03-11

每個人都是項目經理。 無論您是在管理新應用程序的開發和發展您的初創公司，還是在處理一個價值數十億美元的新企業項目，或者只是想通過一些 DIY 美化來讓您的院子活躍起來，您總是在管理一個項目。

項目的成功取決於許多因素，但項目失敗的最常見原因之一是缺乏管理或完全糟糕的項目管理。 無論您的團隊多麼小，或者您的需求記錄得多麼清晰，如果您沒有正確管理您的團隊，您的項目就注定會失敗。

您花在管理項目上的每一分鐘都是值得的。 它將使您更接近成功完成您的項目。

敏捷項目管理是一種被廣泛接受的處理現代軟件開發項目的方法。 但是敏捷的真正含義是什麼？

敏捷項目接受範圍和需求的頻繁變化作為過程的一個組成部分。

為了更深入地了解敏捷原則，我建議閱讀我們的敏捷項目管理終極指南。

在這篇文章中，我們將用看板解釋敏捷項目管理的基礎知識。

即使您是一位經驗豐富的項目經理，深入了解敏捷原則，您也應該刷新記憶並提醒自己核心概念。 軟件開發中的創新周期不斷加快，每次迭代都使項目管理變得更加複雜。 回歸基本原則並鞏固敏捷的核心原則始終很重要。 畢竟，重複是所有知識之母。

看板是管理任何敏捷軟件開發項目的最簡單方法之一。 您可以輕鬆地處理在同一辦公室或分佈式團隊工作的本地開發團隊，這些團隊分佈在多個時區。

看板不是一個過程。 這是一種管理任何流程的方法，只需對團隊已建立的運營活動進行最小的更改。

為了將看板原則應用到您的工作中，您必須應用兩個簡單的規則：

  1. 可視化您的過程。
  2. 限制正在進行的工作。

可視化您的流程

數據可視化是一種以通用且易於理解的方式傳達信息的快速、簡單的方法。 在看圖片時，人腦可以同時處理多條信息。 一些研究表明，這可以比閱讀文本快 60,000 倍。

用於我們視覺感知的大腦神經元占大腦灰質的 30%。

可視化流程的最流行方式是看板。 看板是一個垂直分為幾列的板，每一列代表您流程中的一個狀態。

讓我們來看看一個簡單的軟件開發板會是什麼樣子。 首先，我們需要為我們的開發功能定義狀態：

  1. 待辦事項- 功能正在等待開發
  2. 開發- 功能分配給開發人員，他/她正在開發它
  3. 質量保證- 功能正在審核中
  4. 已部署- 功能被接受並包含在應用程序發布中

基於此，您的電路板應具有以下佈局：

具有四列的 Trello 看板：待辦事項、開發、質量保證和已部署。

可視化單個任務就像創建一張簡單的卡片（很像便利貼）一樣簡單，它代表需要完成的工作。 您可以為任務命名、將指定開發人員的姓名、截止日期和任何其他相關信息添加到此卡中。

當您將該卡片添加到看板板上的一列時，您已經看到，例如，特定的開發人員正在處理某個特定的任務，該任務在某個日期到期並且當前正在開發中。

Trello 卡的特寫，標籤突出顯示其任務顏色標籤、任務標題、任務截止日期、任務描述存在指示器、評論計數器、附件計數器、核對清單項目完成的總分數和分配的人員指示器。

限制在製品 (WIP)

人類多任務處理是一種錯覺。 我們的大腦不會同時關註一兩件事，而是在它們之間快速切換。

這在軟件開發中比其他任何地方都更明顯。 開發人員一次只能處理一段代碼，切換到另一項功能會導致延遲並影響他們的注意力和表現。

這並不意味著您必須將分配的數量限制為一次。 開發是一項複雜而富有創造性的工作，有些任務需要更多的時間才能完成，而另一些任務則需要更少的時間來完成，並且在開發人員等待某事或某人時總是會有延遲。 重要的是要將分配的任務限制在一個不會產生混亂的合理數量（這通常是一次三到五個任務）。

假設您的開發團隊由兩名開發人員和一名 QA 工程師組成，您的主板可能具有以下 WIP 限制：

  • 待辦事項 - 無限
  • 開發 - 六卡限制（兩名開發人員每個限制最多三個任務）
  • 質量保證 - 三卡限制（1 QA 工程師限制為最多三卡）
  • 已部署 - 無限制
不要指望開發人員是明智的，並自行限制他們的 WIP。 如果你把待辦事項列表中的所有東西都扔給開發人員，那就像給孩子太多玩具一樣。 他們不會玩一個玩具，而是把它們扔來扔去，在你整潔的家中製造混亂，但他們仍然不會開心，你可能會發脾氣。

作為項目經理，您的工作是確保待辦事項列表的優先級正確，並且在需要時立即將任務分配給開發人員。

一個與​​第一個類似的 Trello 板，但它的第二列稱為 WIP，並且在其第三張卡片下方繪製了一條名為“WIP LIMIT”的紅線。

管理得當的看板將讓您對項目狀態一目了然。 您可以看到您的開發人員有足夠的工作，您已經準備好新任務，他們可以在他們的任務完成後接管，並且您的 QA 工程師正在等待新任務的審核。

使用 Trello 管理看板

Trello 是一個基於 Web 的看板項目管理應用程序。 它支持團隊成員甚至多個團隊和項目之間輕鬆、實時的協作。

要在 Trello 中創建看板，請單擊“創建新看板...”菜單項，然後為看板設置標題。

在 Trello 中創建看板的屏幕截圖。板標題只有一個字段。

您將從一個空板開始。 使用“添加列表...”框為您的看闆卡創建列。

在 Trello 中添加任務列的屏幕截圖。新列的標題是可編輯的，其下方有保存和 X 按鈕。

通過單擊任何列表底部的“添加卡片...”，您可以輕鬆創建任務。 您創建的每張卡片都應代表將由團隊成員執行的任務。

可以通過多種方式自定義 Trello 中的卡片：

  • 分配負責執行任務的團隊成員
  • 根據您要添加的特定分組對它們進行顏色編碼
  • 設置截止日期
  • 添加附件
  • 添加自定義字段，例如清單，您可以在其中跟踪組成任務的較小元素的進度
  • 團隊成員可以對卡片發表評論，並且每個人都會收到所做的任何更改的通知。

Trello 卡片詳細視圖的屏幕截圖，顯示其標題、清單部分、評論和活動歷史記錄，以及側邊欄中可能的卡片級操作。

可視化是看板中的一切，因此卡片在板上的外觀如下：

在 Trello 板級查看前一張卡片的屏幕截圖，具有前面描述的相同元素，但與最近的卡片的詳細信息相匹配。

只需查看卡片，無需打開詳細視圖，您就可以看到：

  1. 設置 GitHub 代碼庫的任務正在待辦事項列表中等待執行。
  2. 任務截止日期為 1 月 27 日。
  3. 任務有描述。
  4. 該任務有一條評論。
  5. 有兩個項目的清單，這些項目目前都沒有完成。
  6. 任務已分配給用戶 DS，接下來由誰接手。
  7. 任務屬於一組綠色的色卡，這意味著在項目啟動之前需要它。

估計開發工作的時間和復雜性

如果不了解完成某項任務所需的努力和時間，就不可能規劃和管理項目。 然而，在軟件開發中最難做的事情之一就是確定交付一個新的軟件產品或功能需要多長時間。

Scrum 是最流行的敏捷原則之一，它在很大程度上依賴於估計，無論它們是基於時間還是“複雜點”。

團隊應該花費大量時間來確定任務的範圍。

這是因為 Scrum 是基於時間間隔的，即預期完成某組任務的時間。 為了計劃交付，您需要全面了解為該時間框計劃的所有工作。

看板不依賴於限時交付，您可以根據需要計劃每日交付。 它依賴於優化流程，這意味著團隊的重點是盡快完成並清空 WIP 列。

團隊不會花太多時間提前估計工作。 開發人員將從 To-Do 中獲取下一個項目； 盡快完成； 並拿起另一個任務。

這並不意味著團隊不應該估計他們的工作量。

您可以使用每週或每天的電話來更新和驗證到期日期。

然而，對於一個小團隊來說，更重要的是要確保開發人員在任何給定時刻都在處理最高優先級的任務，並且沒有瓶頸，迫使開發人員暫停他們的工作。

最終，您的項目將會增長，您將需要開始更詳細地估計開發工作量。 當您遇到這種情況時，請花一些時間閱讀我們的敏捷項目管理中的軟件成本估算指南。

必備的管理實踐

到目前為止，您已經了解了可視化流程和限制 WIP 的重要性，以及如何使用 Trello 來管理您的項目。

一個軟件項目不能只用卡片和欄目來管理。 因此，實施敏捷最佳實踐也很重要：

  • 組織一次定期的團隊會議。
    至少每週執行一次，以查看已完成的工作，並在需要時改進積壓工作（待辦事項列表）並確定其優先級。 這樣，整個團隊將同時獲得更新，並且可以分享想法。 在這些會議中，讓項目利益相關者（客戶、公司 CTO 或產品團隊中可以做出決定和回答問題的任何人）最終提供非技術反饋非常重要。

  • 確保與各個團隊成員保持持續溝通。
    這將使每個人的日常工作變得更加輕鬆。 保持這些會議或同步非常簡短和簡單，只需在您最喜歡的聊天程序中進行快速更新即可。 每天簽到是很有用的，這可能是您與團隊進行的約 15 分鐘的每日會議。 在這次會議上，每個團隊成員都會發言幾秒鐘，說明：

  • 他們昨天的工作。
  • 他們今天打算做什麼。
  • 他們面臨什麼挑戰或瓶頸。


在通話過程中做筆記並註意發現可能的問題（阻礙者、對任務的錯誤關注、意想不到的技術挑戰），並與團隊一起解決這些問題。

引導您的軟件開發項目

雖然每個軟件開發項目都不同，但您幾乎可以在所有項目中找到某些任務。 以下是您在開始軟件開發項目時應該計劃的一些任務：

  • 設置代碼版本控制和存儲庫。
    跟踪更改和監控代碼非常重要，尤其是在多人協作更新相同代碼的項目時。

    最流行的代碼版本控制服務之一是 GitHub。 GitHub 是一個基於 Web 的 Git 或版本控制存儲庫，提供 Git 的所有分佈式版本控制和源代碼管理 (SCM) 功能。

    它為每個項目提供訪問控制和多個協作功能，例如錯誤跟踪、功能請求、任務管理和 wiki。

  • 定義數據庫備份策略。
    使用 GitHub 等服務將確保您的代碼得到定期備份。

    數據庫通常不是版本控制系統的一部分，您也應該設置頻繁的數據庫備份。

    開發過程容易出錯，在開發過程中很容易出錯，更新錯誤的數據。 如果發生此類問題，備份將為您省去麻煩。

  • 設置協作工具和文件共享。
    項目文檔、功能規範、設計文件以及在項目開發過程中使用的任何其他文檔和文件會不斷更新，並應分發給您的團隊。

    您可以使用許多不同的服務來共享這些文件。 Google 提供了一種簡單且經濟高效的解決方案來解決此問題。 使用 Google Drive、Google Docs、Google Sheets 和其他 Google 應用程序來共享和協作處理文件。

  • 設置單獨的開發和測試服務器。
    開發過程必須始終持續下去。

    開發人員不應該等待應用程序測試的結果，他們應該在質量保證審查完成的功能時繼續完成他們的任務。

    同時，客戶端應該能夠隨時檢查應用程序的當前狀態，而無需等待開發團隊。 擁有一個定期更新的專用測試服務器將消除此過程中的所有瓶頸，並確保您的團隊不間斷地運行。

  • 定義每週團隊電話的固定時間和每日團隊跟進電話或聊天的固定時間。
    讓您的所有團隊成員在他們的日曆中安排通話和會議的時間。 這為您的團隊提供了穩定的日程安排，沒有工作中斷。

帶走

項目管理是一項複雜且經常壓力很大的活動。 為其添加結構並使項目狀態始終可見和準確可以減輕這種壓力。 使用看板方法和敏捷原則，結合適當的工具，將為您節省大量時間。

話雖如此，沒有任何工具或方法可以補償您作為項目經理必須致力於管理項目的時間。

僅僅因為一個項目很小，並不意味著它必然需要更少的時間。 這種心態是解決大頭痛的好方法。

這是一個簡單的清單，可幫助您驗證您的項目是否得到妥善管理：

  1. 您的過程是否正確可視化？
  2. 每個團隊成員的 WIP 是否受到限制和最小化？
  3. 您的團隊是否有一致安排的會議——每週或每天？
  4. 您的看板是否定期更新？
  5. 你有一個代碼庫嗎？
  6. 您是否安排了數據庫備份？
  7. 您是否設置了團隊溝通和協作工具？
  8. 您的開發環境是否與測試、驗收和生產分開？

請記住，此列表遠未確定和完成； 這僅僅是個開始。

請留下您的評論，並與剛剛開始為軟件開發團隊賦權的永無止境旅程的項目經理分享您的技巧和實踐。