テストチームのコーディネーターとしての私の専門的関心の1つは、ソフトウェア開発方法論です。 現在、いわゆるアジャイル手法、特にスクラムとかんばんがますます人気を集めています。 「ゆるい」用語での悪徳な「トレーナー」プレイ、セミナーおよび認定（「認定スクラムマスター」、「認定製品所有者」など）は飛躍的に成長しています。
ほとんどの悪徳な記事やトレーニングでは、方法論は魔法の特効薬として提示され、コミュニケーションの問題を即座に解決し、個々のチームメンバーをすぐに無能から救います。 一般に、問題の解決に役立ちます。 今年、私は「人事管理技術」の専門分野でベラルーシ州立大学の修士課程に入り、長所と短所、および最も一般的なソフトウェア開発方法論の適用可能性の制限を詳細に検討する予定です。
その過程で、方法論ツールの誤解や誤った解釈、文脈を考慮せずにファッショナブルな方法論を使用することにしばしば遭遇しました。 記事を読んだ後、私は問題がローカルよりもグローバルであることを認識しました。 今日は、少しかんばん、その歴史、基本原則、適用の可能性のある境界を検討することを提案します。
学歴
かんばんは、20世紀の60年代にトヨタで生産に関連して使用され始めた日本語の用語です。 この原理は、コンベアの生産方法と、生産における個々の技術操作のさまざまな速度に基づいています。 私は指で説明しようとします。 どの生産にも、メイン生産（「メインコンベア」）と追加生産（「追加コンベア」）があります。 メインコンベヤーは最終製品の放出速度を設定しますが、追加のコンベヤーは製品の放出速度を加速することはできませんが、必要な部品が時間通りに配送されない場合は速度を落とすことができます。
さらに、生産中に優先順位のシフトが発生する場合があります。 たとえば、左のミラーを製造したステーションは20個、右のミラーを製造したステーションは10個を製造しましたが、コンベヤーには15台の車があり、両方のタイプのミラーが15個必要です。 メトリクスの矛盾があります-定量的には、生産は落ちていません（追加のコンベヤーが30の製品を時間通りにリリースしました）が、生産は停止するリスクがあります。 かんばんは、この問題を解決することを目的としています。
簡易バージョンでは、かんばんには2つの単純なルールが含まれています。
- 生産ステーションには、部品生産計画（「バックログ」）があります。 計画は優先度順にソートされ、いつでも変更できます（たとえば、左ミラーが多すぎるステーションでは、できるだけ早く右ミラーに切り替えることができます）。
- ステーションで実行されるタスクの数は同時に制限されます（つまり、一度に指定された数のミラーのみを生成します）。 この制限は、ステーションでの生産速度、および計画の変更への対応速度を制御するために必要です。
プレゼント
最近、カンバンはソフトウェア制作で非常に人気が高まっています。 この方法論が非常に役立つと考えるチームもあれば、カーゴカルトの原則を使用するチームもあります。 私の経験に基づくと、純粋なかんばんは製品チーム（「メインパイプライン」を参照）には適していませんが、次のようなサポートチームには最適です。
- 「計画」は重要ではないが、変更への対応の速度が重要であるソフトウェアサポートグループ。
- 開発チームとは別に機能するテストグループ。
- サポートサービス;
- 「非中核産業」の他の例。
別に、かんばんは明確な計画はないが、開発に積極的に取り組んでいる新興企業でうまく機能していることに注意する必要があります。 ソフトウェア開発におけるかんばんの使用例を検討することを提案します。 advanceいイラストをおaびします。 ある開発者が小さなプロジェクトに取り組んでいるチームを想像してみましょう。 開発計画（バックログ）は作業の優先度順にソートされ、プロセス内のタスクのチーム制限は1個です。
プロセスを管理するために、プロジェクトマネージャーは次のことができます。
- 作業中のタスク数の制限を変更します。
- より高い優先度（p0など）のタスクを追加して、できるだけ早く実行されるようにします。
作業の過程で、作業がブロックされることがあります（ホスティングが壊れている、必要なフレームワークがダウンロードされていないなど）。 一般に、ブロックされたジョブはバックログに戻り、新しいタスクが最高の優先度で選択されます。 タスクの性質とチームのタイプに応じて、制限を増減できます。 たとえば、開発者は登録フォームを同時に作成して、新しいサーバーの展開プロセスを監視できます。 ただし、完了時間が必要な時間より短い場合、プロジェクトマネージャーは制限を減らすか、チームを増やすことができます。 このように、有能なリーダーシップにより、カンバンはこのチームに最高のスピードを提供し、変更への対応の最大スピードを提供すると同時に、方法論をサポートする「コスト」を削減します。 一般的に、すべて！ かんばんは簡単でも単純でもありません。 とても簡単です！
製品チームで使用する場合のカンバンの制限には次のものがあります。
- この方法は、大規模なチーム（5人以上）ではうまく機能しません。
- 最も純粋な形では、かんばんは職域を超えたチームではうまく機能しません。 つまり スクラムとは異なり、テストと開発を1つのチームにまとめることは困難です。 より良いアイデアは、プロセスを「開発」ステーションと、個別のマネージャーとバックログを持つ「テスト」ステーションに分割することです。
- その歴史と特異性により、かんばんは長期計画を目的としていません。
おわりに
結論として、「誰がよりクールであるか」という原則に関する方法論の比較は、生産的ではなく、反構築的でもありません（キャプテン証拠）。 多かれ少なかれ一般的な方法論には、それぞれ長所、短所、アプリケーションの制限があります。 さらに、アジャイル手法は、原則として、チームメンバーの調和と経験に大きな要求を課します。
このトピックに興味がある場合は、引き続きかんばんの詳細を確認します。 後で、私は棚と写真スクラムとRUPを確認することを提案します。
より詳細に、そして明確に見つけることができます：
- Wikipedia.orgのカンバン記事 。
- 優秀な本「SCRUM andかんばん：最大限の搾り出し」、ヘンリック・ニベルグ、マティアス・スカリン。