なぜコードとプロジェクトボードは連携すべきなのか

コードを書いているなら、1日はおそらくこんな感じです。プロジェクト管理ツールを開いて何に取り組むべきか確認します。そしてGitHubを開いて実際に作業をします。ブランチを作り、コードを書き、コミットをプッシュし、プルリクエストを開きます。マージされたら、プロジェクトツールに戻ってタスクを手動で「完了」に移動します。 週に50回それをやることを想像してください。すべてのタスクで、互いについて何も知らない2つのツール間を切り替える必要があります。GitHubリポジトリはあなたのプロジェクトマイルストーンについて知りません。タスクボードはどのプルリクエストがどのタスクに関連するか知りません。あなたがすべてを接着している糊であり、それはあなたの頭脳の無駄です。 この切り離しは単に面倒なだけではありません。本物のブラインドスポットを生み出します。プロジェクトマネージャーは開発者に更新を求めずに開発の進捗を確認できません。タスクボードとコードベースが異なる話をするため、開発者は優先度を見失います。物事がすり抜けていきます。

すべてのチームがまず手動アプローチを試みます。「PRが終わったらタスクを更新するだけ。」「コミットメッセージにイシュー番号を追加して。」「マージされたらチームチャットにリンクを投稿して。」 約1週間はうまくいきます。そして誰かがボードの更新を忘れます。別の誰かがGitHubのイシューをクローズしますが、対応するタスクはまだ「進行中」のままです。プロジェクトマネージャーはボードを確認して、実際には完了しているのに作業が遅れていると思います。または最悪な場合、完了していないのに完了していると思います。 手動同期は完璧な人間の行動に依存していますが、それはスケールしません。チームが大きくなるほど、早く崩れていきます。ソロ開発者でさえ怠けます。機能を完成させてPRをクローズし、次のことを考え始めているのでタスクボードの更新を忘れます。人間の本性です。

解決策は単純です。2つのツールを接続して自動的に情報を共有させます。 GitHubのイシューをプロジェクトボードと同期すると、すべてのイシューが見えるタスクになります。他の作業と並んでカンバンボードで確認できます。優先度を割り当て、締め切りを設定し、他のすべてと同じワークフローで追跡できます。 これは特に、外部コントリビューターからのGitHubイシューとして一部の作業が始まるオープンソースプロジェクトやチームに有用です。GitHubを別に確認する代わりに、それらのイシューがプロジェクトビューに表示されます。ワークスペースを離れることなく、トリアージ、割り当て、追跡ができます。 主な利点は可視性です。プロジェクトマネージャーは開発チームが何に取り組んでいるかを見るためにGitを覚える必要がありません。ボードを見るだけです。そして開発者は何をすべきかの2つの別々のリストを管理する必要がありません。

マイルストーンはプロジェクトの進捗を測定する方法です。「4月までにバージョン1.0を準備。」「月末までにベータ版ローンチ。」「ユーザーテスト前にすべてのコア機能を完了。」 しかしマイルストーンの追跡とコードが別々のツールにあると、推測することになります。マイルストーン達成にチームはどれくらい近いか？GitHubを確認し、マージされたPRを数え、コミットメッセージを読み、精神的にそれをタスクボードにマッピングしなければなりません。明らかであるべき情報のために多くの手作業が必要です。 コミットとプルリクエストがプロジェクトと同期されると、真の状況が把握できます。どのタスクがアクティブな開発中か、どれがレビュー待ちのプルリクエストを持っているか、どれがマージされて完了しているかを確認できます。それは誰もステータス更新を書く必要なく、マイルストーンの進捗に直接マッピングされます。 インディー開発者や小さなチームにとって、これは特に価値があります。おそらくすべてを追跡する専任プロジェクトマネージャーはいません。あなたが開発者でありPMです。自分の進捗を追跡するオーバーヘッドを減らすものはすべて、実際のコーディングに戻せる時間です。

ほとんどのチームでは、開発者がすることとプロジェクトマネージャーが見るものの間に翻訳レイヤーがあります。開発者はブランチ、コミット、プルリクエストで考えます。プロジェクトマネージャーはタスク、マイルストーン、締め切りで考えます。2つのグループは多くの場合、異なるツールを使用し、同じ作業について異なる言葉を話します。 GitHub統合はそのギャップを閉じます。開発者がコミットをプッシュすると、プロジェクトボードはそれを反映します。プルリクエストが開かれると、タスクが更新されます。コードがマージされると、タスクが前進します。翻訳は必要ありません。 この透明性は全員に利益をもたらします。開発者はステータス更新を書く時間が減ります。プロジェクトマネージャーはリアルタイムの可視性を得ます。ステークホルダーはミーティングを設定することなく進捗を確認できます。そしてチーム全体が作業について話す時間が減り、実際の作業が増えます。 IndieDevBoardはGitHubリポジトリに接続し、イシュー、プルリクエスト、コミットを直接プロジェクトに同期します。マイルストーン、メモ、タイムラインの隣で、タスクボード上のすべてを確認できます。手動管理が一つ減り、ただ機能するものが一つ増えます。

これの恩恵を受けるために、ワークフロー全体を再考する必要はありません。シンプルに始めましょう。メインリポジトリをプロジェクトに接続します。イシューを同期させます。すべてを一つのビューで見る感覚を確かめてください。 そこから洗練させられます。PRをマイルストーンに対して追跡し始めるかもしれません。タスクラベルを使用してGitHubイシューを機能エリアでカテゴリ化するかもしれません。コミットの可視性があるとよりよいスプリントレビューが書けると気づくかもしれません。統合はあなたと一緒に成長します。 目標はGitHubを置き換えることではありません。コードベースとプロジェクトプランを2つの無関係なものとして扱うのをやめることです。それらは同じ作業で、異なる角度から見ているだけです。ツールがそれを反映するとき、管理に費やす時間が減り、構築に費やす時間が増えます。