今日は、最初の記事を公開します。
最初の記事の主なタスクは、かんばんの基本をできるだけ簡単に説明することです。それは何ですか、他の柔軟な方法論との違いは何か、なぜ必要なのか。
また、コメントで可能な限り多くの質問と疑問を収集して、次の記事でそれらに答えるようにしたいので、理解できないことや、かんばんについて他に知りたいことを書いてください。
私はこの新しい方法論の優れた専門家ではありませんが、チーム内の私たちは自分でカンバンに来て、SCRUMからカンバンへの突然変異のすべての段階を一貫して経験したので、実際の経験があります。
最初に、用語かんばんの起源について書きます。
この言葉は、狭い円で広く知られているトヨタの生産システムのおかげで、日本から来ました。 できるだけ多くの人に、このシステムと、そこに定められた基本原則（リーン生産、継続的開発、顧客重視など）について読んでもらいたいと思います。 これらすべての原則は、ロシア語に翻訳された本「小野泰一トヨタ生産システム 」に記載されています。
用語「かんばん」には、文字通りの翻訳があります。「かん」は視覚的、視覚的、「禁止」はカードまたはボードを意味します。
トヨタ工場では、事前に作成されたスペアパーツで倉庫や職場を散らかさないように、かんばんカードがあらゆる場所で使用されています。 たとえば、トヨタカローラにドアを置いているとします。 職場の近くに10個のドアのパックがあります。 それらを次々と新しい車に置き、スタックに5つのドアが残っているとき、新しいドアを注文する時が来たことを知っています。 かんばんカードを取り、10枚のドアの注文を書いて、ドアを作った人に持って行きます。 あなたは残りの5つのドアを使い果たした瞬間に彼が間に合うようにすることを知っています。 それがまさに起こることです。最後のドアを置くと、10個の新しいドアが到着します。 そして絶えず-あなたはそれらを必要とするときだけ新しいドアを注文します。
ここで、そのようなシステムがプラント全体で動作することを想像してください。 スペアパーツが数週間または数か月にわたって存在する倉庫はどこにもありません。 すべてが要求に応じて機能し、要求された数のスペア部品を生産します。 突然注文が多かれ少なかれ場合-システム自体は簡単に変更に適応します。
このシステムのかんばんカードの主な目的は、現在実行中の「進行中の作業」の量を減らすことです。
たとえば、生産ライン全体に正確に10枚のドアカードを割り当てることができます。 これは、ライン上のどの時点でも、既製のドアが10個を超えないことを意味します。 新しいドアを注文するタイミングと、それらを設置する人の仕事はいくらですか。 彼だけが彼のニーズを知っており、彼だけがドアメーカーに注文を出すことができますが、彼は常に10に制限されています。
この無駄のない製造方法はトヨタで発明され、現在、世界中の多くの製造会社がそれを実装しているか、すでに実装しています。
しかし、これはすべてソフトウェア開発ではなく生産を指します。
また、ソフトウェアに関連したかんばん開発とは何ですか？また、SCRUMであろうとXPであろうと、他の柔軟な方法論とどのように違いますか？
まず、かんばんは特定のプロセスではなく、価値体系であることをすぐに理解する必要があります。 ただし、XPでのスクラムとして。 これは、誰も何をどのようにすればよいかを段階的に教えてくれないことを意味します。
第二に、かんばん全体は、 「現時点で進行中の作業を減らす（進行中の作業）」という簡単なフレーズで説明できます。
第三に、かんばんはSCRUMやXPよりもさらに「柔軟な」方法論です。 つまり、すべてのチームおよびすべてのプロジェクトに適しているわけではありません。 また、これは、チームがSCRUMやXPを使用しているチームよりも柔軟な作業にさらに備える必要があることを意味します。
かんばんとスクラムの違い：
-かんばんには、（タスク用でもスプリント用でもない）タイムボックスはありません
-かんばんのタスク数は増えています
-かんばんでは、タスクの期限の見積もりはオプションであるか、まったくありません。
-かんばんでは、「チーム作業速度」はなく、タスクを完了する平均時間のみが考慮されます
次に、このリストを見て、スプリントを削除し、タスクのサイズを増やし、チームスピードの測定を停止した場合の柔軟な方法論の残りについて考えますか？ 何もない？
主な制御ツール（タイムライン、作業速度、スプリント）を削除した場合、一般的に開発管理について話すことができますか？ 私にとって、この質問はほとんど最も重要です。
マネージャーは常にコントロールについて考えて、それを取得しようとしますが、実際にはコントロールはありません。 マネージャーによる開発の管理はフィクションです。 チームが働きたくない場合、それを制御しないと、プロジェクトが失敗します。
チームが仕事からファンを受け取り、献身的に仕事をする場合、コントロールは必要ありませんが、干渉し、コストを増加させるだけです。
たとえば、よく知られているSCRUMの問題は、スプリントのジョイントでの議論、会議、および時間の大幅な損失です（少なくとも1日が1つのスプリントを閉じてから1日が新しいスプリントを開く場合。スプリントが2週間の場合は2日間週-それは20％で、非常に多くのことです）。 その結果、SCRUMを適用する時間のほぼ30〜40％がプロセス自体のサポートに費やされます-毎日の集会、5％のワークショップ、スプリントの回顧など。 30％オフ！
かんばん開発は、主にタスク指向においてSCRUMと異なります。 SCRUMでチームの主なオリエンテーションがスプリントの成功した実装である場合（そうであることを認める必要があります）、カンバンではタスクの最初の場所です。
スプリントはなく、チームは最初から最後までタスクに取り組みます。 タスクの展開は、準備ができたときに行われます。 行われた作業のプレゼンテーション-も。 チームはほとんど意味を成さず、ほとんどの場合最初は間違いであるため、タスクを完了する時間を評価すべきではありません。
マネージャーがチームを信じている場合、なぜ時間の見積もりがあるのですか？ マネージャーのタスクは優先順位付けされたタスクプールを作成することであり、チームのタスクはこのプールからできるだけ多くのタスクを完了することです。 それだけです 制御は必要ありません。 マネージャーに必要なことは、このプールにタスクを追加するか、優先度を変更することだけです。 それは彼がプロジェクトを管理する方法です。
チームはカンバンボードを使用して作業します。 たとえば、次のようになります（ ここで取得しました ）。
左から右への列：
プロジェクトの目的 ：
オプションだが有用な列。 ここでは、プロジェクトの高レベルの目標を設定して、チームがそれらを確認し、誰もがそれについて知っているようにすることができます。 たとえば、「作業速度を20％上げる」または「Windows 7のサポートを追加する」。
タスクキュー ：
タスクを実行する準備ができているタスクを保存します。 最上位の優先度の高いタスクが常に実行され、そのカードは次の列に移動します。
デザイン開発 ：
これと「完了」の前の残りの列は変更される可能性があります。 タスクが完了状態に至るまでのステップを決定するのはチームです。
たとえば、この列には、コードまたはインターフェイスの設計がまだ明確ではなく、議論されているタスクが含まれる場合があります。 ディスカッションが完了すると、タスクは次の列に移動します。
開発 ：
ここでは、機能の開発が完了するまでタスクがハングします。 完了すると、次の列に移動します。
または、アーキテクチャが正しくないか正確でない場合は、タスクを前の列に戻すことができます。
テスト ：
テスト中のタスクはこの列にあります。 エラーが見つかった場合、開発に返されます。 そうでない場合は、先に進みます。
展開 ：
すべてのプロジェクトには独自の展開があります。 これは、一部の人にとっては製品の新しいバージョンをサーバーに置くことを意味し、他の人にとっては単にコードをリポジトリにコミットすることを意味します。
終了しました ：
ステッカーは、タスクのすべての作業が完全に完了した場合にのみここに表示されます。
緊急の仕事はどんな仕事でも起こります。 計画されているかどうかはわかりませんが、今すぐ行う必要があるもの。 これらのために、特別な場所を割り当てることができます（「Expedite」としてマークされた画像内）。 1つの緊急タスクをExpediteに配置できます。チームはすぐに開始し、できるだけ早く完了する必要があります。 しかし、そのようなタスクは1つしかありません！ 別のものが表示された場合、それを「タスクキュー」に追加する必要があります。
そして今、最も重要なこと。 各列の下の数字をご覧ください。 これは、これらの列に同時に存在できるタスクの数です。 数値は実験的に選択されていますが、チーム内の開発者の数に依存すると考えられています。
たとえば、チームに8人のプログラマーがいる場合、「開発」行に4番を入れることができます。これは、プログラマーが同時に4つのタスクしか実行しないことを意味します。つまり、コミュニケーションと経験の交換の多くの理由があります。 そこに数字の2を入れると、2つのタスクに携わっている8人のプログラマーが退屈するか、議論に時間を費やすことになります。 8を入力すると、誰もが自分のタスクを実行し、一部のタスクは長時間ボード上に残りますが、かんばんの主なタスクは、タスクを最初から準備段階に完了するまでの時間を短縮することです。
これらの制限がどうあるべきかを正確に答える人はいませんが、最初に開発者の数を2で割って、チームでどのように機能するかを確認してください。 その後、これらの数値をコマンドに合わせて調整できます。
「開発者」とは、プログラマーだけでなく、他の専門家も理解しています。 たとえば、「テスト」列の場合、開発者はテスターです。 テストは彼らの責任です。
このようなボード上のタスクは、単なるタスクではなく、最小マーケティング機能と呼ばれるもの、つまり顧客に「販売」できる機能です。
MMFの良いテストは、それ自体に対する質問です。「この機能について会社のブログに書きますか？」 そうでない場合、これはMMFではありません。
そのような制限のあるボードで何が新しくて便利ですか？
第一に、 並行してタスクの数を減らすと、個々のタスクの実行時間が大幅に短縮されます。 タスク間でコンテキストを切り替えたり、異なるエンティティを追跡したり、それらを計画したりする必要はありません。 -必要なことだけが行われます。 次のように、スプリント計画と5％のワークショップを手配する必要はありません。 計画は「タスクキュー」の列で既に行われており、タスクの詳細な調査は、タスクの実行が開始されたときにのみ開始されます。
次に、 プラグがすぐに表示されます。 たとえば、テスターがテストに対応していない場合、すぐに列全体に記入し、新しいタスクを完了したプログラマーはテスト列に移動できなくなります。 いっぱいです。 どうする ここで、「私たちはチームです」ということを思い出して、この問題を解決します。 たとえば、プログラマーはテスターがテストタスクの1つを完了してから、新しいタスクを空いているスペースに移動するのを支援できます。 これにより、両方のタスクをより速く完了することができます。
第三に、平均的なタスクを完了する時間を計算できます。 カードにタスクキューに入った日付をマークし、次に仕事に取りかかった日付と完了した日付をマークすることができます。 これらの3つのポイントについて、少なくとも10個のタスクについて、タスクキューの平均待機時間と平均タスク実行時間を既に計算できます。 そして、これらの数値から、マネージャーまたは製品所有者は、必要なすべてをすでに計算できます。
すべてのかんばんは、次の3つの基本ルールで説明できます。
1. 生産を視覚化する
-作業をタスクに分割し、各タスクをカードに書き込み、壁またはボードに配置します。
-名前付きの列を使用して、実稼働中のタスクの位置を表示します。
2.生産の各段階でWIP （進行中の作業または同時に実行される作業） を 制限します。
3. サイクル時間 （1つのタスクを完了するための平均時間）を測定し、この時間を短縮するためにプロセスを常に最適化します 。
ルールは3つだけです！
たとえば、SCRUMでは-9つの基本ルール。 XP-13、およびクラシックRUP-120の場合。違いを感じてください。
これで、かんばんに関する最初の記事を終了します。
あなたのフィードバックとコメント、および以下の記事へのご期待をお待ちしております。
追加リンク（残念ながらすべては英語のみです）：