web-dev-qa-db-ja.com

ソリューションアーキテクト向けのカンバンボードに関するフィードバック

始める前に、先取りの謝罪をする必要があります。

この投稿で使用している用語/用語の一部が明らかに間違っている可能性が非常に高いため、重要な側面の一部を完全に誤って解釈している可能性もあります。私はこれが初めてなので、批判的になりすぎないでください。建設的なフィードバックを歓迎します;）

バックグラウンド

現在、200名の開発部門をマルチメソドロジから「アジャイル」に移行しています。理由、理由、長所、短所は、この質問の範囲をはるかに超えています。

この開発部門には、正式に「ソリューションアーキテクト」と呼ばれる10人で構成されるアーキテクチャサービスチームが含まれています。実際には、彼らはソリューションだけでなく、プロジェクトのすべての技術的なアーキテクチャの側面（つまり、ハードウェア、ソフトウェア、セキュリティ、ガバナンスなど）をカバーする技術者です。また、開発チームにアドホック機能（コードレビュー、標準ガイダンスなど）と幅広いビジネス（入札への技術的インプット、顧客要件の事前契約技術プレビュー）も提供します。

この移行の一環として、私は、建築サービスチームが責任を負う作業アクティビティのビューを取得する目的で、かんばんボードを作成する必要がありました。開発/コーディングチーム用の無数のサンプルボードがありますが、アーキテクチャ用に見つけることができるものはありません。だから私は様々なソースから取って「何か」を作成しました、私はそれについて本当にフィードバックをいただければ幸いです。

また、これは開始点/進行中の作業としてチームに提示されることにも注意してください。それは彼らのボードであり、私は彼らにそれを所有してほしいと思っています。

これまでのところ私はこのようなものを持っています

メインボード

メインボードは、すべてのアクティブ/バックログプロジェクトを保持する場所です。すべてのアクティブな作業はこのボードで行われます。これは、毎日の建築スクラムで簡単にレビューされ、毎週の終わりにさらに詳細なレビューが行われます。

           ------------------------------------------------------------------------
           | Evaluation            | Implementation       | Ad- Hoc               |
           | Todo  | Doing  | Done | Todo  | Doing | Done | Todo  | Doing  | Done |
    -------------------------------------------------------------------------------
    Person |       |        |      |       |       |      |       |        |      |
    --------       -----------------       ----------------       -----------------
    Person |       |        |      |       |       |      |       |        |      |
    --------       -----------------       ----------------       -----------------
    Person |       |        |      |       |       |      |       |        |      |
    --------       -----------------       ----------------       -----------------
    Person |       |        |      |       |       |      |       |        |      |
    -------------------------------------------------------------------------------

列の説明/目的は次のとおりです。

評価：担当者が最初の技術分析を行っているプロジェクト。つまり、製品所有者との技術オプションを実行し、プロジェクトのサイズを決定します。例として、評価プロジェクトは、アーキテクトが新しいテクノロジーを評価したり、顧客と協力して相互に合意した技術的ソリューションを作成したりする場合があります。

実装：開発中（コーディング、テストなど）のプロジェクトであり、その人はSA幅広いプロジェクトチームのための機能を担当しています。例として、これは上記の「相互に合意した技術的解決策」のコーディング面の開発であると同時に、いくつかの新しいハードウェアの実装をアーキテクチャで監視することもできます。

Ad-Hoc：他の2つの列には入れられない、奇妙で素晴らしいものすべて。奇妙な再帰世界の例として、KanBanボードを作成するためのカードがアドホック列にあります:)。

Person：かなり自明で、その列のカードを「所有」している人。物事をもう少し楽しくするために、これには実際にはその人が選択したアバターが含まれています。

Todo：事実上、私たちのバックログであり、ここのカードは優先順位の高い順に並べられています。セルをしている人のスペースが利用できるようになると、私たちはtodoの上から取ります。

実行：かなり自明

完了：前回のフルボードレビュー（毎週金曜日の午後）以降に完了したアイテム

WIPの制限

私たちが今していることを行う（つまり、誰かが悲鳴を上げるまで仕事を配る）のではなく、メインボードで客観的/証拠に基づくWIP制限で作業したいと思います。ボードカードのサイズを以下のように設定することが目的です。

  • XS（Extra Small）：3ポイント
  • S（小）：5点
  • M（中）：8ポイント
  • L（大）：13点
  • XL（特大）：21ポイント

サイズは、アーキテクトのワークロードの観点から非常に大きくなります。たとえば、10人で1年間のコーディングを必要とするが、最小限のアーキテクチュラル入力はXSまたはSのプロジェクトです。ただし、大規模なアーキテクチュラル入力はあるが最小限のコーディングを持つプロジェクトはXLになる可能性があります。

時間の経過とともに、各ユーザーのWIP制限を解決できるはずです。したがって、ジョニー・スミスは42ポイントの速度で作業できるため、そのレベルまでプロジェクトを割り当てることができます。

私が意図する前にこれを行っていなかったので、初期制限を高く設定することです、というのは、人が悲鳴を上げるとき、私たちは（チームとして）これを客観的に見て、それが本当に多すぎるのか、それともプロセスが原因なのかを判断できるということです。などは面倒であり、合理化されるべきです。

  • [〜＃〜] note [〜＃〜]：ここでのすべてのうち、これらのWIP計算は、最低限の権利を「感じる」ビットです*

ファンネルボード

チームを飛行するすべてのランダムなものを追跡するために、ファンネルボードも用意しています。これは、次のような比較的シンプルなボードです。

    ------------------------------------------------------------------------
    | Evaluation            | Implementation       | Ad- Hoc               |
    ------------------------------------------------------------------------
    |                       |                      |                       |
    |                       |                      |                       |
    |                       |                      |                       |
    |                       |                      |                       |
    |                       |                      |                       |
    ------------------------------------------------------------------------

チームは「プロジェクト」を認識しているが、これはまだ公式に認可されていない（つまり、メインボードのTodo列に入れることができる）ため、ファンネルボードに移動します。ここのアイテムは個人に割り当てられていません。ランダムなものを追跡して、忘れられないようにすることができるという考えです。また、担当者が評価プロジェクトを完了すると、メインボードの評価完了から実装ファンネルボードに移動します（すぐに実装プロジェクトになる場合を除く）。

チームのメンバーは、ファンネルボードのすべてをフォローアップする必要がある場合があります。つまり、製品の所有者に電話して、これがまだ関連があるかどうかを尋ねます（これはメインボードのアドホックプロジェクトです）。

成功委員会

これは、過去Xか月間に行ったことを追跡するための単純なボードです。ファンネルやメインボードを通過したカードを保持します

    ------------------------------------------------------------------------
    | Successes                                                            |
    ------------------------------------------------------------------------
    |                                                                      |
    |                                                                      |
    |                                                                      |
    |                                                                      |
    |                                                                      |
    ------------------------------------------------------------------------

私たちは時々このボードを回避して、お互いに背中を叩くことができるという考えです:)

ボードカード

ボード上のカードには、次の情報が含まれています。

    ------------------------------------------------------------------------
    | SIZE (XS,S,M,L,XL)          | OWNING TEAM MEMBER             |  RAG  | 
    ------------------------------------------------------------------------
    |                                                                      |
    |                         PROJECT TITLE                                |
    |                                                                      |
    ------------------------------------------------------------------------
    |                                  |                                   |
    |        DEPENDENTS                |          DEPENDENCIES             |
    |                                  |                                   |
    ------------------------------------------------------------------------
    |                                                                      |
    |                         MISC INFORMATION                             |
    |                                                                      |
    ------------------------------------------------------------------------
    |                WIDER PROJECT TEAM (AS APPLICABLE)                    |
    | Other Architects, Project Manager, Principal Developer, Business     |
    | Analyst, Scrum Master                                                |
    ------------------------------------------------------------------------

カードの粒度がかなり高い「プロジェクト」レベルであることにお気づきでしょうか。タスクに分割された開発者スタイルのボードを実行する予定はありません（この歓迎の考え）。また、カードの場所によっては、すべてのセクションが適用されることにも言及する価値があります。私はまた、最初の刺し傷として、カードの色分けを計画しています：

黄色：顧客と契約しているものすべてピンク：内部にあるもの（つまり、エンドユーザーに面していないもの）緑：企業グループのプロジェクトにあるもの

カードはポストイットではなく磁気になります。物事の変化に応じて生活を楽にするため、ミニホワイトボードのようなカードを見つけたいと思っています。

他のもの

  • ボード上のカード上になければ、チームに関する限り、それは存在しません
  • ボード自体はホイール付きのホワイトボードであり、好きな場所に置くことができます
  • 将来、仮想ホワイトボードへの移行を検討する可能性があります（X列がYではなく、Yの左側が最適であると判断すると、物理的なホワイトボードを変更する方が簡単です）。

ご質問

  1. 私の初心者のかんばん戦争と平和を読んだ後、あなたの考えは何ですか？ （私に気楽に行ってください:)）
architectureagilekanban
8
MrEyes

うわー！完全に理解して理解するのに少し時間がかかりました。アジャイルイニシアチブにカンバンを採用することを決定したことをお祝いします。これまでに本当に素晴らしい分析とモデリング。ここでそれを共有し、私たちがそのイニシアチブを助けて貢献できるようにしてくれてありがとう！

私はいくつかの考えと提案を持っています–これらの助けを願っています！

A.最初に、全体的な「システムビュー」を得るために、あなたが示した3つのボードを集めます。開発部門の残りの作業ではなく、アーキテクトの作業を追跡するためだけのものです。それで正しいですか。

B.説明したとおり、ファンネルボードの各列は、基本的にメインボードの対応するセクションの「準備完了」列であるように見えます。

  1. 別のファンネルボードが必要ですか？メインボードの各セクションに「Funnel」または「Ready」の列がある場合、単一のボードを使用する方が簡単ではありませんか？

  2. 同様に、Successes Boardは、メインボードの右側にある大きな列と見なすことができ、正常に完了したすべての作業が一定期間蓄積されますか？

  3. そのため、目標到達プロセスのプロジェクト数と進行中の（任意の段階で）プロジェクトの数に応じて、次の設計を持つ単一のボードでこれらすべてを管理する方が簡単でしょうか。

enter image description here

もちろん、すでにこれを評価しており、1つのボードで管理するには大きすぎる可能性があると判断した可能性が非常に高いです。 （ファネルレーンが同じ目的を果たす可能性があるため、各セクションにTo-Doレーンをドロップすることを検討できますか？）

C.メインボードの設計に関しては、カンバンを実装するための全体的な目標が何であるかによります。ボード設計に関するいくつかの質問：

  1. 個人（現在の設計で簡単に行うことができます）またはさまざまなタイプのプロジェクト（よりトリッキーになる可能性があります（ただし、カラーコーディングが多すぎない程度））のリード/サイクルタイムを改善しますか？後者の場合、レーンを人ではなくプロジェクトタイプ（サービスクラスと同様）で定義することをお勧めしますか？

  2. 2人の建築家が1つのプロジェクトに取り組んでいる可能性はありますか？もしそうなら、人々がレーンを持っていると、同じプロジェクトに対して2枚のカードが各人に対してない限り、モデル化が難しくなりますか？

  3. 異なるタイプのプロジェクトが異なるワークフローを持っている可能性はありますか？たとえば、顧客のプロジェクトは他のプロジェクトよりも詳細な検証（検証、テスト、またはレビュー）を必要とするでしょうか？その場合、かんばんでは、作業の種類ごとに異なるワークフローを使用できますが、この設計では不可能です。

    上記のポイント1〜3のいずれかがあなたの状況で理にかなっている場合は、人ではなく他の側面に基づいて車線を検討することをお勧めします。先ほどお話ししたとおり、プロジェクトの種類ごとに行うのも1つの選択肢のようですが、他にも基準があると思います。

  4. さらに直感的な視覚化のための別の提案–人々は左から右へのフロー（または世界の一部の地域では右から左）をフローの方向に関連付けるため、アドホックセクションを実装列の右は混乱するかもしれませんか？私の好みは、アドホックプロジェクトに独自のスイムレーンを用意することです。

    したがって、メインボードは次のようになります。

    enter image description here

  5. 上記のすべてにおいて、「アバターステッカー」をいくつか用意して、プロジェクトカードに貼り付けることができる各プロジェクトでどの建築家が作業しているかを示すことができます。必要に応じて、ボードの片側の凡例で、どのアバターがどのアーキテクトであったかを説明できます。

  6. 最後に、より大きな質問–あなたは最初に、これらのボードはアーキテクトが責任を負うプロジェクトを追跡するためのものであると述べました。これらのプロジェクトは、おそらく、開発部門全体で行われている（より大きな）プロジェクトの一部だと思います。それらの（より大きな）プロジェクトと建築家の作業との間の依存関係をどのように示すことを計画していますか？

D. WIPの制限については、私が多くのお客様が行っていることを見てきましたが、最初はあまり気にしないでください！ただし、WIP制限を設定するのではなく、必要に応じてWIP制限を設定することが重要です。各アーキテクトまたはアーキテクトチーム全体が過去数か月で処理したプロジェクトの数に関するデータが既にある場合は、そのデータを使用して初期のWIP制限をすでに定義できます。

将来仮想カンバンボードに行くことを検討している場合、これらの一部は、管理、変更、操作が簡単になる可能性があります。

  • カードに取り組んでいる人を表示する
  • ボード内およびボード間カードの依存関係の設定と表示
  • 人、プロジェクトタイプ、またはその他の属性によるボードのフィルタリング
  • ボードやカードのデザイン等の変更.

これがお役に立てば幸いです-少なくとも、あなたが検討するいくつかのアイデアを投げ出す上で。

ベスト、

マヘシュ

4
Mahesh Singh

興味深い読み物で、ほとんどが理にかなっています。

私がすぐにコメントするのは、カンバンボードは左から右への作業の流れを表すためのものです。私はあなたの仕事が実装からアドホックに流れていないと思うので、これは実際にはあなたのボードではうまくいきません。

より良い（imo）オプションは、評価、実装、およびアドホックとして水平レーンを設定し、カード自体にその人の名前を含めることです。これには、複数の人がアクティビティに取り組むことができるという利点があります（多分あなたはこれを必要としません）。

さらに、他の投稿者が言うように、外部依存関係を考慮していません。チーム外の誰かまたは何かを待っている作業を表示するには、「ブロック」列を設ける価値があるかもしれません。

これが役に立てば幸い

2
Neal Champion