4

かんばんを使用できるソフトウェア開発 (プロジェクト) の種類と、かんばんを実装するための要件は何ですか? かんばんとその素晴らしさについてよく読んでいました。しかし今、私はかんばんの要件、特にかんばんが適合しないプロジェクトの種類に焦点を当てた論文を書かなければなりません。私はまだそれを理解できませんでした。

4

5 に答える 5

4

KarlM が概要を説明してくれました。

かんばんは、既存のプロセスを使用して視覚化し、WIP (マルチタスク) 制限を導入し、プルを使用してフローを最大化し、リード タイムを最小化するため、どのプロジェクトでも使用できると思います。私のチームは最近スクラムに移行しましたが、これまでのところ非常にスムーズに移行しています。

かんばんは、標準的な反復が意味をなさない状況に特に適しています。

たとえば、リリースが頻繁ではない場合があります。計画、デモ、ふりかえり、またはリリース スケジュールの 1 つまたは複数を分離したい場合があります。

良い例:

  • メンテナンスプロジェクト。優先順位やふりかえりなどについて話し合うために 2 週間 (または何でも) の会議を開きたいと思うかもしれませんが、2 週間ごとにデモやリリースを行うことはおそらくないでしょう。とにかく次の2週間ですべて。このような状況は非常に動的であるため、顧客から新しいフィードバックが寄せられると、優先順位が毎日変わります。この場合、スクラムやその他の反復プロセスは意味がありません。
  • イテレーションの長さよりも長いストーリーが本当に必要です。かんばんは、スクラムと同様に、小さなストーリー (より良いフロー、スラックなど) で繁栄しますが、スクラムとは異なり、本当に必要な場合は少なくとも大きなストーリーを許可します。
  • 非常にペースの速い開発。継続的な展開。反復はもはや意味がありません。照明の変更に迅速に対応している可能性があり、1 日に複数回リリースしている可能性があるからです。

code.flickr.com を参照してください。

Flickr が最後に展開されたのは 4 時間前で、2 人による 8 つの変更が含まれています。先週、19 人による 588 の変更の 85 のデプロイがありました。

Flickr は 2 週間のイテレーションを行っていると思いますか?それとも 1 日でイテレーションを行っていると思いますか? 疑わしい。彼らは超高速の動的フロー モードにあるように見えます...おそらくカンバンですが、間違いなくリーンの傘にいるように見えます。(かんばんはリーン思考の傘下にあり、継続的な展開は、昨年のエリック・リースによる著書「リーン・スタートアップ」によって人気を博しました。)

以下の環境には適合しない場合があります。

  • 組織文化は、事前の計画、過重労働/コミットメント、プルではなくプッシュ、スケジュール、範囲、およびコストのすべてを修正することなどから逃れることはできません。かんばんは組織の継続的な改善を引き起こし始め、多くは単純に反対します彼らが知っていて愛用している伝統的なオーバーエンジニアリング、オーバードキュメント、サイロ化、非リーン、非アジャイルのアプローチ以外には何もしません。それがウォーターフォールです。一部の政府契約もこのカテゴリに該当する可能性がありますが、少なくとも DoD は現在、プロジェクトでアジャイルを推進しようとしていると思います。しかし、一部の企業では、LESS を行う必要がある (つまり、進行中の作業を制限する、より明確なビジョンを持ち、より少ない作業をより速く完了させるが、したがって全体的により多くの作業を完了する) 必要があると伝えると、心臓発作を起こすでしょう。多くの（ほとんどの？）企業は過重労働にはまっていますが、SLACK (リーンの基本原則) は 4 文字の単語だと考えてください。残念ながら、待ち行列理論と制約理論は、一部の人々の頭を理解するのが難しいです。:) したがって、かんばんはそのような場所には合わないかもしれません。;)
于 2012-09-15T03:59:58.993 に答える
3

要件は、プロジェクトの全員が原則と実践を使用することに同意することです。

Principles

1. Start with what you do now
2. Agree to pursue incremental, evolutionary change
3. Initially, respect current processes, roles, responsibilities and job titles
4. Encourage acts of leaderships at all levels


Practices
1. Visualise what you do / knowledge discovery
2. Limit work in progress
3. Measure and manage flow
4. Make policies explicit
5. Develop feedback mechanisms
6. Improve collaboratively using models and the scientific method

これに同意しない場合、かんばんを使用することはできません。かなりクリアな。

于 2012-07-11T06:48:23.727 に答える
1

かんばんは、既存のプロセスを視覚化して改善するためのツールです。それが機能しないシナリオがある場合、そのシナリオにはおそらく 2 つのプロパティのいずれかまたは両方があります。

1) 既存のプロセスがないか、既存のプロセスがまったく機能していない、および/または混沌とした方法で絶えず変化しているような災害です。

2) 改善する意志や機会がない。

2 番目を欠いていることは契約を破るものではありません。かんばんは依然としてコミュニケーションと調整に役立つ可能性があり、明確性が高まると、改善への欲求が高まり、改善実験を強化するために必要な信頼を確立するのに役立つ可能性があります。これは、成熟度の低いかんばんの実装がチームの成熟度を高める一例です。

于 2013-03-12T11:23:31.960 に答える
0

カンバンは単純なプロセス ツールです。うまく適用されれば、ソフトウェアだけでなく、あらゆるプロジェクトに適しています。

于 2012-06-23T23:09:17.240 に答える
0

私の意見では、かんばんはあらゆる種類の組織やあらゆる業界で実装できます。

しかし...

  1. チームは変更の準備ができている必要があります
  2. 変化には進化的特徴がなければならない
  3. 組織は、日常業務を実行するのではなく、協力に集中する必要があります。
于 2013-05-07T13:11:13.577 に答える