29

他の人が自分の会社の物理的なかんばん/スクラムボードに何を使用しているかについて興味があります。機密性の高いビジネス情報のため、ボードの写真を提供できない場合があります。私はあなたのボードがどのように見えるか、そしてユーザーストーリーとタスクが典型的なスプリント/イテレーションを移動するときにどのように整理するかを調べていますか？

通常、私はそれぞれで次のようにボードを整理する場所で働いてきました

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

これは、各タスク/ユーザーストーリー（付箋として表されます）と対話する人々を含む具体的なホワイトボードとして機能します。電子バージョンは、スプリント/イテレーションの前に作成され、現在の状況に対応するスプリント/イテレーションの最後にのみ更新されます。コメントや批評を歓迎します:)

4

11 に答える 11

15

Henrik KnibergのTrenchesの有名なScrumとXPに触発されたものを使用します。列は、コンテキストに応じて調整されます（多くの場合、TODO、ON GOING、TO BE TESTED、DONE）。

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

製品バックログアイテム（PBI）は、スプリント計画会議（少なくとも最も重要）の「物理カード」（A5形式）として印刷されます。チームが次のイテレーションのためにPBIを取得すると、アイテムはタスク/アクティビティに分割されます（付箋に）。会議の後、すべてがスクラムボードに送られます。テープ、画鋲、または磁石を使用することをお勧めします。PBIは重要度順に並べられており、ボードの上部で最も重要で、下部でそれほど重要ではありません。チームは、それが完了するまで、最初に最も重要な項目に取り組む必要があります。まず、アクティビティのポストイットが左から右に移動します。次に、PBIはDoneにジャンプします。予期しないタスクが「計画外のアイテム」ゾーンに追加されます（バーンダウンチャートでそれらを考慮に入れるため）。将来のPBIは「次の」ゾーンに表示されたままになります（反復中にすべてのアイテムが完了した場合、そこから新しいものを選びます）。ものすごく単純。

これらの方法により、たとえば次のように匂いを視覚的に検出できます。

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

よく働く。

より「かんばん指向」のものをお探しの場合は、「かんばんvsスクラム」をご覧ください。ある日、かんばんランドとかんばんとスクラムで、同じHenrikKnibergの実用的なガイドです。素晴らしいものも。

また、その他の写真については、Google画像検索でスクラム+かんばん、かんばん、スクラムバン、スクラム+かんばんを試してみてください。

于 2009-11-27T20:22:18.957 に答える
9

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

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

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

TargetProcessかんばんボード

UPD。現在、いくつかの小さなチームがあり、単一のボードを使用してhttp://www.targetprocess.com/3のすべてのチームの進捗状況を追跡しています。

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

于 2012-04-19T21:48:38.887 に答える
6

代替テキスト

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

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

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

列名：開始されていない、開始されたばかり、途中、ほぼ完了、ショーケースの準備ができている（QAに合格）

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

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

于 2009-11-27T22:08:44.637 に答える
4

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

于 2014-02-14T08:04:33.777 に答える
2

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

ストーリー、未開始、Req / Des / Dev *、ピアレビュー、QA、完了

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

作業者がイニシャルを付ける各タスクで、粘着性のある白いタブを使用します。完了したら、新しい白いタブを古いタブの上に配置して、誰でも手に取ることができることを示します。すべてのタスクが完了すると、ストーリーは[完了]列にも移動し、スタンドアップでは、すべての完了した作業が集計され、ボードの上部に移動して、下部にさらにストーリー用のスペースを確保します。

また、進行中の妨害を示すために、ストーリーとタスクの色付きのタブがあります（青は別のチームからの妨害を示し、赤はスクラムマスターの支援を要求します）。各スタンドアップでの障害について話します。

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

*要件/設計/開発

于 2009-12-04T16:12:00.587 に答える
2

I'm pretty keen on Lean/Kanban and we've been iterating on our process for a while, initially through a customized workflow in JIRA, but that's not exactly frictionless given the admin complexity in the enterprise version. We've now expanded our use of a whiteboard and have decided to iterate our process using the whiteboard for a while before re-codifying it in JIRA. Here is an example of our layout:

  • We are 6 developers
  • When a story is in dev, it's on a dev's desk. Likewise with being reviewed, being QA'd, etc. This means every card on the board represents and actionable item, and also provides a decently accurate snapshot of iteration progress. The rule is that only in exceptional circumstances do you have more than one card on your desk.
  • We've agreed not to have more than two cards "pile-up" in the Awaiting Review column. This maintains a degree of "flow".

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

This is pretty close to mapping the value stream except for the awaiting deployment part, which is a hack to fix the problem where QA can't QA an item until we've deployed it on their server - we deploy 3/4 times during a 2 week iteration.

One thing I have noticed from mapping the value stream on an "information radiator" is that it does magically focus people on the actual value-add work that needs to be done, and that seems to up the pace of business-value development and keep up momentum.

Hope that helps!

于 2009-11-29T14:55:16.267 に答える
2

実際には、進行中のボードの構成は、チームが状況や環境に応じて決定するのに最適です。（アジャイル==自己管理。）

そうは言っても、これが私の前のチームで行ったことです。これは、アジャイルとスカムにとって比較的新しい300以上の開発者の取り組みの一部です。

2つのボードがありました。1つは今後のストーリー用のインデックスカードで、もう1つは現在のスプリントの作業であることがわかります。現在のスプリントボードのコラムは単純です

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

との隅にあるボックスBlocked。

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

開発者はそれぞれ、誰が何に取り組んでいるかを示すために毎朝スタンドアップで使用する小さな磁石を持っていました。私たちのチームは非常に大きかったので（ある時点で約12）、これは誰が誰とペアになっているかを理解するのに本当に役立ちました。

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

于 2009-11-27T06:41:38.407 に答える
2

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

| (Sprint) Backlog | In Progress | Done |

可能な限り、ストーリーの開発アクティビティとQAアクティビティの両方を表す単一のポストイットを作成するようにしています。

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

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

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

新しく追加されたセクションReadyforTestは、基本的に、以前はInProgressセクションの「反対側」であったボードの正式なセクションになりました。表面的には、これによりQAメンバーの状況がより明確になるはずですが、Ready for Testの意味について人々がさまざまな解釈をしているため、混乱が生じました（ここではさまざまな解釈に飽きることはありません）。

これにより、別のプロジェクトで使用しているボード構造の最新のイテレーションが作成されました。

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

これは確かに、最初のイテレーションの単純なバックログ、進行中、完了のセクションからはかなりかけ離れていますが、チームにとってはうまく機能しているようです。彼らは、ボードのさまざまなセクションでストーリーを移動することの意味を明確に理解しており、1つのストーリーについて、その特定のストーリーがライフサイクルのどこにあるかを明確に示します。現在のスプリントの開始（9日から10日のスプリント）以来、この構造を使用しているだけなので、この構造については、明日の回顧展で詳しく説明します。完璧ではないことは確かですが、それをパイロットしているチームで引き続き機能する場合は、組織内の他のチームに展開しようとします。

于 2009-12-03T15:31:12.137 に答える
0

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

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

個人的には、システムが不足していると思います...

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

個人的には、ポストイットはここでは適切なツールではないと思います。この種のものを完全にトラブルフリーにするデジタルツールがいくつかあります。私たちはTeamFoundationServerを使用しています。TeamFoundationServerとインターフェイスし、それらすべてをリアルタイムで管理する、非常に優れた、堅牢で、無料の、さらにはオープンソースのツールをいくつか見てきました。

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

于 2009-11-27T06:44:38.290 に答える
0

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

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

チームがワークフローを理解し、サイロにならないようにするために、チームはボードの作成に関与する必要があると思います。また、チームが取締役会の作成に関与した場合、チームは自分たちのプロセスをより適切に監視します。これは、チームが入力した製品であるため、自己組織化に役立ちます。

于 2013-04-01T09:57:50.317 に答える
0

弊社では以下のボード構成で行っております。

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

レーンは特定のメンバーに割り当てられます。私たちのオフィスではメンバーごとに仕事が異なるため、タスクも異なります。作業しなければならないことをバックログに追加し、締め切りに近づいたら次のスプリントに移動します。ブロックされたグリーンタスクは、毎日作業する必要のある継続的なタスクに使用されます。赤いカードはタスクの重要性を示しており、できるだけ早く終了する必要があります。私たちのボードでは、別の部門で何かを行う必要がある場合に、自由にコラボレーションして、お互いのスイムレーンにタスクを追加できます。

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

于 2013-11-14T13:11:53.767 に答える