新しいプロセス組織システムを試してみたいと思う頃には、成功したスクラム開発をリードする定評のあるチームでした。
私はポストに理論とあらゆる種類の水をロードしません。かんばんと無駄のない製造に関するHabrに関する十分な記事があります。 プロセスの説明に直接進みます。
かんばんを導入することで、開発プロセスを最大限に改善し、製造された製品に欠陥がないようにしました。 そのため、現在のプロセスを分析することにより、この方法論の実装を開始しました。このプロセスは、当時スクラム上に構築されていました。 分析は、生産プロセスのすべての段階を表すグラフである値マップのコンパイルで構成されていました。 プロセスの各ステップを考慮して、私たちを遅らせたり、制作の参加者に不快感を与えたりした段階を除外しました。 私たちは絶えずプロセスの分析に戻ったことに注目します。
分析の結果は、将来のプロセスのマップでした。 プロセスの各ステージには、かんばんボード上に独自の列があり、各ステージ（プルを除く）には2つの列があります：In ProgressとDone。
ステージごとに、可用性基準のリストが定義されています。 機能が基準の少なくとも1つを満たさない場合、次の列に移動できません。
各ステージについて説明します。
引く
プルは、製品所有者（PO）がバックログから新しいタスクを追加するバッファーです。 バッファーには、タスクの数に制限があります。 ボードでは、タスクは優先度順に配置されます。 POはいつでもタスクの優先順位を変更したり、タスクを別のものに完全に置き換えたりできます。
分析
完全に無料の開発者が開発プロセスに登場すると、最も優先度の高いタスクをプルから取得し、そのタスクを分析ステータスに移行します。
通常、機能を開発に取り入れる開発者が責任を負います。 開発段階全体の責任者は機能のステータスを監視し、いつでもPOで機能の現在のステータスを確認できます。
分析段階では、テスターと開発者で構成されるグループが組み立てられます。 多くの場合、バックログの説明では十分ではないため、あらゆる方法でPOからタスクの詳細を抽出します。 このような議論の過程で、POは機能の一部の機能を変更することが多く、場合によっては拒否します。 分析中に、テストケースも書き出されます。 あらゆる種類のユーザーの行動とそれに対応するシステムの反応。 受信したすべての情報は仕様に記録されます。 機能にインターフェースの作成が含まれていた場合、インターフェースのプロトタイプ（スケッチ）が描画されます。これにより、インターフェース開発者用のサブタスクを配置できます。
分析フェーズのおかげで、機能は顧客の要望に正確に対応し、やり直しに時間を無駄にしませんでした。
設計
分析後、開発チームはタスクの技術的な実装の設計を開始します。 この設計の結果は、アーキテクチャの技術仕様（クラス図、シーケンス図など）です。 開発者は多くの場合、チーム全体が批判に耳を傾けたり、提案されたソリューションが完璧であることを確認したりするために、アーキテクチャのプレゼンテーションを行います。
技術的な詳細を処理したら、タスクを小さなサブタスクに分割できます（それが理にかなっている場合）。
思慮深く詳細な設計のおかげで、コードはほとんどバグなしで出てきました。
開発
したがって、この機能はすぐに実装する準備ができています。 無料の開発者はタスクを解析し、開発コラムでそれらを上回る。 各機能は、メインリポジトリの個別のブランチで開発されます。 ほとんどすべてのタスクをコーディングする場合、TDDとペアプログラミングを使用します。 各開発者は、機能テストと統合テストを実施します。 これらのプラクティスの利点について多くのことが書かれていますが、それらに注目する価値はありません。
コード、インターフェイス、データベース移行ファイル、およびタスクを含むすべての作業が完了したら、レビューのために公開します。
復習
無料の開発者、そして時には開発チーム全体がレビュータスクを実施します。 私たちはこの段階に大きな注意を払っています。 コードの規則に準拠しているかどうかのコードの概要に加えて、レビュー担当者は実装された機能の機能をチェックし、記述された単体テストを分析します。
この段階では、コードの軽微な不正確さが回避され、開発されたシステムのさまざまなコンポーネントをチーム全体が把握できるようになります。
テスト中
レビューに合格したタスクは、テストのためにキューに入ります。 解放されたテスターが機能を循環させます。 それは、テスターの地獄のすべてのサークルで駆動され、機能的でストレスの多い回帰テストを受けます。 テストは機能ブランチで厳密に実施されます。
展開する
テストプロセスが完了すると、機能がデモサーバーに展開されます。コードがマージされ、必要な移行がロールバックされます。 デモサーバーでは、POは作業の結果を監視できます。
検証
正常に展開された機能は検証の対象となります-統合および回帰テストが実行されます。
制限事項
生産プロセスのすべての段階を扱ったので、制限について話しましょう。 彼らは何のために？ そして、製品の品質にすべての注意を向けるためです。 開発者が機能を制御不能にまとめてリベットで開始する場合、テスト部門は期限までにすべての機能をテストする時間がないでしょう。 このような状況を回避するために、実用的な方法で、列または列のグループに制限を選択します。 現在、たとえば、レビューでハングするタスクが多すぎる場合、開発者は既製の機能のレビューが実行されるまで、新しい機能を開発に取り込むことができません。 したがって、私たちは、ずさんな性急な開発者から、欠陥のあるコードを作成する誘惑を奪います。
返品
生産プロセスを説明する過程で、私は各段階の成功結果のみに言及しました。 まさにそのような結果に努力する必要があるためです。 しかし、理想的な生産プロセスの形成中に、欠陥製品が現れます。 タスクを1ステップ（またはそれ以上）戻す必要があります。 たとえば、タスクがレビューとテストに合格しなかった場合、再び開発に、場合によっては設計に戻されます（これは制約を設定するときに考慮する必要があります）。 このような戻りが発生した場合、これはプロセスで欠陥（損失）が発生したことを示す信号であり、プロセスを停止してこの欠陥を分析する必要があります。 実際には、停止することはめったにありませんでした。多くの場合、損失は戻りログに記録されます。 ジャーナルに十分な重大な欠陥が蓄積すると、欠陥を分析する集会を収集します。 分析の結果に基づいて、製造プロセスでの欠陥の繰り返しを回避するための対策が講じられます。
結果
もちろん、すべてが一度にスムーズかつ美しくなったわけではありません。 しかし、プロセスの継続的な改善は結果をもたらしました。 半年後、開発プロセスを大幅に加速することができました（バーンダウングラフは加速を2.1倍に示しました）。また、製品の品質を大幅に向上させることができました。 テスターは、バグを見つけることがより困難になり、「そこで修復され、壊れた」状況が完全に消えたことを認めました。
有用性
プロセス
かんばん（開発）
ソフトウェア開発へのかんばんの適用：アジャイルからリーンまで
リーンソフトウェアエンジニアリング
ツール
かんばんボードのレビュー