かんばん/スクラムボード[終了]

StackOverflow https://stackoverflow.com/questions/1807100

質問

他の人が会社の物理的なかんばん/スクラムボードに使用しているものについて興味があります。ビジネスの機密情報のため、取締役会の写真を提供できない場合があります。 ボードがどのように見えるか、およびユーザーのストーリーやタスクを整理する方法を見つけて、一般的なスプリント/イテレーションを移動するのを探しています >

通常、次のように各ボードでボードを編成する場所で作業しました

User Story   | Todo                   | In Progress  | Ready for QA     | Done   |
UC-001       | Domain Object, Service | DAO(Bob)     |                  |        |
UC-002       | Payment UI Screen      |              | Payment Srv (Don)|        |
UC-003       |                        |              | UC-003           |        |
             |                        |              |                  | UC-004 |
             |                        |              |                  | UC-005 |

要約すると：

  • UC-001のタスクは、チームの1人のメンバー（ボブ）によって進行中です。他の人が取得するタスクのリストはTodo列で待機していますが、これは作業を完了するためにボブと連携するチームの別のメンバーが取得できます。
  • UC-002の場合、支払いサービスタスクが完了し、QAの自動テストハーネスが完了し、UIなしでサービスをテストできるようになりました。テストが失敗すると、バグが発生し、Payment ServiceタスクとともにQAフェーズに戻ります
  • UC-003のすべてのタスクが完了し、QAの準備完了に移動しました。
  • Uc-004およびUC-005のすべてのタスクが完了したため、ユーザーストーリーは[完了]に移動しました。

これは、タスク/ユーザーストーリーのそれぞれと対話する人々を含む有形のホワイトボードとして機能します（ポストイットノートとして表示）。電子版は、スプリント/反復の前に作成され、現在の状況に対応するスプリント/反復の終わりにのみ更新されます。コメントと批判を歓迎します：）

役に立ちましたか？

解決

有名なトレンチのスクラムとXP Henrik Knibergから、列は状況に応じて調整されます（多くの場合、TODO、進行中、テスト予定、完了）：

代替テキストhttp://blog.realcoderscoding.com/ wp-content / uploads / 2008/09 / hk.png

製品バックログアイテム（PBI）は、「物理カード」として印刷されます。 （A5形式）スプリントプランニングミーティング用（少なくとも最も重要）。チームが次の反復のためにPBIを選択すると、アイテムはタスク/アクティビティ（付箋紙上）に分解されます。ミーティングの後、すべてがスクラムボードに置かれ、テープ、画thumb、または磁石を使用することをお勧めします。 PBIは重要度順に並べられ、最も重要なのはボードの一番上、一番下の重要度は低いです。チームは、完了するまで最も重要なアイテムに最初に取り組む必要があります。最初に、アクティビティはその左から右に移動します。次に、PBIはDoneにジャンプします。予期しないタスクが「予定外のアイテム」に追加されます;ゾーン（バーンダウンチャートでそれらを考慮する）。今後のPBIは、「次へ」で引き続き表示されます。ゾーン（反復中にすべてのアイテムが完了した場合、そこから新しいアイテムを選択します）。とても簡単です。

これらのプラクティスにより、匂いを視覚的に検出できます。例：

  • 潜在的な障害を示すスタックされたタスク（つまり、動いていないタスク）
  • チームが間違った順序で物事を行い、サンプルのように最優先項目に焦点を当てない：）
  • 進行中の作業が多すぎて何もしません
  • スプリントを殺している計画外のアイテム

素晴らしい作品。

より多くの「かんばん指向」を探している場合おそらく、かんばんvsスクラム、カンバンランドのある日とカンバンとスクラム-同じHenrik Knibergによる実用的なガイド。素晴らしいものも。

さらに写真を見るには、 scrum + board 、 kanban 、 scrumban 、 scrum + kanban 。

他のヒント

TargetProcess で使用しているカンバンボードは次のとおりです。タスクレベルではなく、ユーザーストーリーとバグレベルで作業します。タスクを作成することもありますが、ボード上で明示的に追跡されません。

ユーザーストーリーとバグは推定しませんが、ストーリーをより小さなものに分割しようとします（混合成功）。列は一目瞭然です。 [テスト済み]列にアイテムを蓄積し、ブランチを作成してテストし、新しいビルドをリリースします。通常、2週間ごとに新しいビルドをリリースします。

また、ボードには、開発者とテスターの負荷と色分けによるサービスのクラスが表示されます。

TargetProcess Kanban Board

UPD。現在、複数の小さなチームがあり、単一のボードを使用して http：//www.targetprocessですべてのチームの進捗を追跡しています。 com / 3

ここに画像の説明を入力

alt text

スクラム/エクストリームプログラミングストーリーボード。

http://www.flickr.com/photos/dafydd_ll_rees/4138686549/

作業は左から2番目の列に表示され、完全性のさまざまな段階を経て全面的に進行します。

列名：開始していない、開始したばかり、半期、ほぼ終了、ショーケースの準備完了（QAに合格）

最初の行は、バグ修正のために特別に予約されています-バグをクリアするための修正された優先度のように。

シンプソンズのキャラクターは、チームの各メンバーを表しています。移動されているので、誰が何に取り組んでいるかを確認できます。

アイリーンの掲示板をご覧になることをお勧めします。 http://www.eylean.com/?utm_source=geffort&utm_medium=content&utm_campaign = geffort 直感的なインターフェイス、統計、ダッシュボードにより、あらゆるニーズに対応できます。また、どのプロセスにも適合し、最も重要なことは非常に使いやすいです。このボードでは、行を使用して1つのボードで複数のプロジェクトを表すことができます。すべての行は一度に表示されるか、選択された行をスコープから削除できます。別の解決策は、カテゴリごとのタスクのグループ化とフィルタリングです。すべてのタスクは1つのボードと行に表示できますが、異なるカテゴリにアタッチできます。 / p>

実際には、作業中の委員会の組織は、状況と環境に応じてチームが決定するのに最適です。 （アジャイル==自己管理。）

とはいえ、アジャイルとスカムにとって比較的新しい300人以上の開発者の努力の一環として、以前のチームで行ったことは次のとおりです。

私たちは 2つのボードを用意しました。1つは近日中のストーリー用のインデックスカード付きで、もう1つは現在のスプリントの作業用です。現在のスプリントボードのコラムは単純に

Not Started
Under Development
Dev Done 
In QA
Complete ("Done Done")

および Blocked の隅にあるボックス。

ポストストーリーは各ストーリーを表しています。

各開発者は、誰が何に取り組んでいるかを示すために、毎朝スタンドアップで使用する小さな磁石を持っていました。私たちのチームはかなり大きかった（一度に12個まで）ので、だれが誰とペアになっているかを知るのに本当に役立ちました。

私たちは電子版を気にしませんでした（ポイントはありません）が、プロダクトオーナーには最新の状態を維持するために必要なScrumworksシステムがありました。私たちはできる限りそれから遠ざけました！

Lean / Kanbanに非常に興味があり、最初はJIRAでカスタマイズされたワークフローを使用してプロセスを繰り返していましたが、エンタープライズバージョンの管理の複雑さを考えると、これはまったく問題ありません。ホワイトボードの使用を拡張し、JIRAで再コード化する前に、ホワイトボードを使用してプロセスを反復することにしました。レイアウトの例を次に示します。

  • 私たちは6人の開発者です
  • ストーリーが開発中の場合、それは開発者の机の上にあります。同様に、レビュー、QAの実施などが行われます。これは、ボード上のすべてのカードが実行可能なアイテムを表し、反復の進行状況のかなり正確なスナップショットを提供することを意味します。ルールは、例外的な状況でのみあなたの机に複数のカードがあるということです。
  • 「パイルアップ」カードは2枚までにしないことに同意しました。 [レビュー待ち]列で。これにより、ある程度の「フロー」が維持されます。

Backlog   | Awaiting Dev   | Awaiting Review   | Awaiting Design  | Awaiting Deployment | Awaiting QA | Done |
Story11   |    Story2      |    Story9         |     Story 6      |   Story1            |    Story9   |
Story3    |    Story7      |                   |                  |                     |    Story12  |
Story8    |    Story10     |                   |                  |                     |             |
          |                |                   |                  |                     |             |
          |                |                   |                  |                     |             |

これは値ストリームのマッピングに非常に近いです。は、サーバーに展開するまでQAがアイテムをQAできないという問題を修正するためのハックです。2週間の反復中に3/4回展開します。

バリューストリームを＆quot; 情報にマッピングすることで気づいたことの1つラジエーター＆quot;必要な実際の付加価値のある仕事に人々を魔法のように集中させ、ビジネス価値の開発のペースを上げ、勢いを維持しているようです。

役立つことを願っています！

実行中のいくつかの異なるプロジェクトで、いくつかの異なるボード構造を実験しています。 1つのプロジェクトには、使用できる最も基本的な構造があります。

| (Sprint) Backlog | In Progress | Done |

可能な限り、ストーリーの開発アクティビティとQAアクティビティの両方を表す単一のポストイットを用意します。

上記の構造は、プロジェクトの開発者にとっては問題なく機能しているように見えますが、QAメンバーは、ストーリーの開発作業が完了し、そのストーリーのテストを実行できる時期を知るのに苦労しています。ストーリーを「向こう側」に移動していることがわかりました。 進行中セクションのセクションで、開発作業が完了し、QAがそのストーリーを取り上げることができることを示します。 In Progress セクションがいっぱいになると、これはすぐに管理不能になりました。

これにより、別のプロジェクトのボード構造の2回目の反復が行われました。

| (Sprint) Backlog | In Progress | Ready for Test | Done |

新しく追加されたセクション Ready for Test は、以前は「反対側」だったボードの正式なセクションになりました。 進行中セクションの表面的には、これによりQAメンバーにとって物事が明確になっているはずですが、人々は Ready for Test の意味について異なる解釈をしているため、これはまだ混乱を引き起こしました（私はあなたに退屈しません）ここで異なる解釈）。

これにより、別のプロジェクトで使用しているボード構造の最新の反復につながりました。

| (Sprint) Backlog | Dev in Progress | Dev Done | QA in Progress | Done |

これは、最初のイテレーションの単純な Backlog 、 Ingress 、および Done セクションからかなり遠い方法ですが、チームのためにうまく働いている。ストーリーをボードのさまざまなセクションに移動することの意味を明確に理解しており、どのストーリーでも、特定のストーリーがライフサイクルのどこにあるかを明確に把握できます。現在のスプリントの開始時からこの構造を使用しているだけなので（10日間のスプリントに9日かかります）、明日のレトロスペクティブでこの構造をさらに詳しく検討します。完璧ではありませんが、パイロットしているチームで引き続き機能する場合は、組織内の他のチームに展開してみます。

ホワイトボードは次の列に分かれています：

ストーリー、未開始、要求/説明/開発*、ピアレビュー、QA、完了

最も優先度の高いストーリーは上から下に進みます。 各ストーリーには複数のタスクを設定できるため、ストーリーには大きなポストイットを使用し、タスクには小さなポストイットを使用します。タスクは左から右に移動します。毎日、最も優先度の高いストーリーに取り組んでいることを確認しています。

私たちは各タスクに粘着性のある白いタブを使用し、そこで作業している人がイニシャルを置きます。完了したら、古いタブの上に新しい白いタブが配置され、誰でも利用できるようになります。すべてのタスクが完了すると、ストーリーは「完了」列にも移動し、スタンドアップでは、すべての「完了」作業が集計され、ボードを上に移動して、下部に追加のストーリー用のスペースを空けます。

また、進行するブロックを示すストーリーとタスクのタブが色分けされています（青色は別のチームからのブロックを示し、赤色はスクラムマスターアシスタンスを要求しています）。各スタンドアップの障害について説明します。

特定の列にタスクが多すぎる場合を確認し、重点をシフトしてより多くのタスクを完了できるようにします。レビュー列を意図的に追加して、QAに到達する前に、作業を行う人以外の人が作業をレビューする必要があることを強調しました。

*要件/設計/開発

私たちの外観はかなり似ています。各開発者には列があり、「完了」、「テスト中」、「進行中の作業」、「バックログ」の行があります。

そして、各フェーズを通過するときに物理的に移動する実際のポストイットスタイルのメモを使用します。

個人的に、システムが不足していることがわかりました...

  • ポストイットを手動で移動すると、しばらくすると苦痛になります。私たちのQAチームは主にチケットの移動を管理します-そして、それらをTFSと同期させるための絶え間ない努力です。
  • ポストイットは本当に粘着性がなくなる前に何度も動かすことができます。チケットがテストから返送されて「進行中」に置かれ、その後テストなどに戻された場合など、最終的にフロアに到着するのにそれほど時間はかかりません。
  • 時々、膨大な量のノートが圧倒されることがあります。メモは、遠くからでも見えるように積み重ねる必要があります-各メモの一意の識別子を表示できるようにレイヤーを重ねます（できる限り）...しかし、10個のメモのスタックがあり、スタックの5位であり、床の上のメモで終わる粘着性の低下に急速に貢献しています。
  • チケットが床に着くと、どこに行くべきかを見つけるのがかなり面倒です。その開発者Aのチケットでしたか？またはB？そして、それはテストでしたか？それとも行われましたか？ TFSに戻ってそれらのチケットを検索し、それに応じてポストイットを移動しましょう。

個人的には、ここではポストイットノートが適切なツールだとは思いません。この種のものを完全にトラブルフリーにするデジタルツールがいくつかあります。私たちはTeam Foundation Serverを使用しています-そして、Team Foundation Serverと連動し、すべてをリアルタイムで管理する、本当に素晴らしい、堅牢、無料、さらにはオープンソースのツールをいくつか見ました。

http：/ /www.telerik.com/community/labs/tfs-work-item-manager-and-tfs-project-dashboard.aspx

私たちのボードは、チームとして進歩するにつれて時間とともに進化する傾向があります。チームにコロケーションを配置している場合は、物理的なカードボードを好む傾向があります。これは、一般的に私の経験から、より良い対面コミュニケーションを促進するためです。明らかにオーバーヘッドは増えますが、チームを連携させる価値はあります。物理的なボードで私が見たもう1つの利点は、ビジネスへの関与に役立つことです。リモートの利害関係者は、サインインして現在のスプリント内の進行状況を確認したり、カードが完全なストーリーを伝えないことがあるため、コンテキストから物事を取り出すことはできません。彼らは会話をし、取締役会に出席しなければなりません。それは物事が説明できるので有益であり、障害を解決するために彼らを励ますことができることも意味します。ただし、これは物理的なボード専用ではありませんが、役立ちます。

前述のように、ボードはチームのニーズに合わせて時間とともに進化します。多くの場合、教科書のスクラムから始めますが、継続的な改善を奨励し、通常はスクラムバンソリューションになります。これらの変更は、ボードを通じて新しいワークフローを視覚化することで反映されます。ご興味のある方は、砂時計スクラム/かんばんボード

チームがワークフローを理解し、サイロ化しないようにするのに役立つので、チームはボードの作成に関与する必要があると思います。また、チームがボードを作成することに手を携えていた場合、彼らは自分のプロセスをよりよくポリシングし、それは彼らがインプットを持っていた製品なので、自己組織化に役立ちます。

当社では、次のボード構造を採用しました。

Backlog | Next sprint |      Current sprint         | Done
                         Buffer    |     Working

レーンは特定のメンバーに割り当てられます。私たちのオフィスではメンバーごとに仕事が異なるため、タスクはさまざまです。処理する必要があるものをバックログに追加し、期限に近づいたら次のスプリントに移動します。ブロックされた緑のタスクは、毎日作業する必要がある継続的なタスクに使用されます。レッドカードはタスクの重要性を示しており、できるだけ早く終了する必要があります。 私たちの掲示板では、さまざまな部門で何かをする必要がある場合、自由に共同作業し、スイムレーンにタスクを追加できます。

KanbanTool（Kanbantool.com）を使用して、ワークフローを視覚化し、プロジェクトを管理します。本当に直感的で使いやすいです。チームのコミュニケーションが大幅に改善されました。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top