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


8

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

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

バックグラウンド

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

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

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

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

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

メインボード

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

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

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

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

実装:開発(コーディング、テストなど)が活発に行われているプロジェクトであり、その人がより広範なプロジェクトチームのSA機能で行動している。例として、これは上記の「相互に合意した技術的ソリューション」のコーディング面の開発である可能性があります。同様に、いくつかの新しいハードウェアの実装をアーキテクチャで監視することもできます。

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

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

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

実施:かなり自明

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

WIPの制限

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

  • XS(極小):3点
  • S(小):5点
  • M(中):8ポイント
  • L(大):13点
  • XL(特大):21ポイント

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

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

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

  • :ここでのすべてのうち、これらの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. 私の初心者のかんばん戦争と平和を読んだ後、あなたの考えは何ですか?(私に気楽に行ってください:))

8
これは、姉妹サイトのProject Management Stack Exchangeで、プログラマよりも良い答えが得られると思います。私は彼らのメインチャットルームで尋ねましたが、常連が質問が自分のサイトのトピックに関するものであることを確認した場合、そこに移行します。
yannis 2014

2
@MrEyes-「あなたの考えは何ですか」よりも具体的な質問(1つまたは複数)がある場合は、Project Management SEでこれを取り上げることができます。しかし、現状では、あなたは非常によく書かれていて、詳細な質問は残念ながらQ&Aの質問ではありません。お役に立てれば。
jmort253 2014

1
主題はPMSEで話題に上りますが、現在書かれている質問は、一連の標準的な回答を作成するのに役立ちません。OPへの私の提案は、プロセスの実装でチームが持っている特定の問題または問題点を特定し、PMSEでそれらの対象を絞った質問をすることによってこれを分割することです。
CodeGnome 2014

回答:


4

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

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

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

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

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

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

  3. したがって、目標到達プロセスのプロジェクト数と進行中の(任意の段階で)プロジェクトの数によっては、これらすべてを次の設計の単一のボードで管理する方が簡単でしょう-

ここに画像の説明を入力してください

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

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

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

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

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

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

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

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

    ここに画像の説明を入力してください

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

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

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

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

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

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

ベスト、

マヘシュ


2

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

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

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

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

これが役に立てば幸い

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.