かんばんとは
2つの状況を考慮して、次の例を調べてみましょう。
最初の状況 -ソ連時代のコンベヤー工場を想像してください。その活動は州の計画に直接依存していました。 この計画は、生産する製品の量を明確に定義しました。 その結果、国家計画委員会の起草者がしばしば需要と間違われる可能性があるという事実のために、倉庫がいっぱいになりました。 製品には販売する時間がありませんでした。
2番目の状況は、最近のトヨタのショールームです。 買い手はモデルを選択し、支払いを行います。 ただし、現時点ではトヨタは車両の色ではありません。 注文はトヨタ本社に送られます。 マシンが配達されるときに通知されます。 この瞬間から車が生産を始めます。 特にあなたのために。 原則があります：最初の販売、次に生産。 つまり、 ジャストインタイム（JIT）原則が機能します。 最初の目標と期限、次に計画と作業。
トヨタの在庫は、最初の状況のように、スペア部品を長期間保管する必要がないため、いっぱいになりません。 これは、ラインで現在生産されているものが、最近販売された一部の車にとって必要な基準であるためです。
JIT原則の主要なコンポーネントの1つはかんばんです。 かんばんボードとカードは、ジャストインタイムシステムの一種の信号機です。 かんばんにより、最初に説明した状況で発生したように、ニーズを予測するのではなく、ビジネスが顧客のニーズに対応することができます。
同様の例をソフトウェア開発分野に投影できます。
スペアパーツの代わりに-開発タスクまたはバグ。 テスターは検証のためにいくつかのタスクを受け取ります。 QAが検証タスクを使い果たすと、プログラマーに新しいタスクを受け取るように通知する必要があります。 プログラマーが新しいタスクを完了する時間がない場合、テスターはしばらくの間仕事をせずにいるだけです。
反対の状況も発生します。QAには多くのタスクが蓄積されており、時間どおりにすべてをチェックする時間はありません。 この場合、製品のリリース日も遅れます。
ソフトウェア開発において、かんばんのバランスを取ることは製造業よりもはるかに困難です。 マシンが同じタイプの詳細を生成する場合、プログラマーは脳の独自の努力を使用してコードを操作します。ここでは、約1,000億のニューロンと1つの重要なヒューマンファクターがあります。
ソフトウェア開発にかんばんが必要なのはなぜですか？
2008年にかんばんの完全な利点を発見した後、陶磁器のワークショップでのかんばんの個人的な計画、開発、さらには実装まで、あらゆる場所でかんばんボードを使用しています。
かんばんに切り替える13の理由
ソフトウェア開発に関与するIT企業にかんばんを実装する必要がある13の理由を次に示します。
1.ボトルネックの特定
通常のタスクリストからかんばんボードに切り替えると、すぐにボトルネックがわかりました。「テスト」列に蓄積されたタスクの大きなキューです。 私たちのQAはタスクの検証に対処しませんでした。 彼はチェックするためのタスクを長時間遅らせました。 テスターが修正のためにタスクを返した後、プログラマーはすでにそれを忘れることができました。 コードをもう一度見て、詳細を覚えておく必要がありました。 ご存知のように、これは貴重な時間です。 チームには別のテスターが必要でした。
かんばんボードを使用すると、キューが形成されるプロセスのボトルネックを確認できます。 Hygger.ioでは、 WIP制限はこのタスクに対処するのに役立ちます。 必要以上のタスクがある場合、列はそれぞれ赤または黄色で強調表示されます。
2.リリース機能の正確な順序
多くの場合、機能のリリースの順序は非常に重要です。 優先度に基づいたリストでは、順序を正確に制御することは困難です。 プログラマーが主な優先順位で同時に5つのタスクを持っている場合、これらのタスクのどれを最初に行うかを見つけることは困難です。
かんばんは、注文が重要な場合に状況から抜け出す方法を提供するだけです。 この視覚的なソリューションは、タスクを含む垂直列です。 タスクが高いほど重要です。 ところで、かんばんには、方法論の重要な側面の1つとして優先順位が含まれます。 要件は常に変化しており、多くのタスクは関連性を失い、「ダウン」する可能性があります。 反対に、ある種のタスクが突然「上昇」する可能性があります。 マネージャーは、プログラマーが最も必要なことを達成するために常に「後れを取らない」必要があります。
3.主なタスクの優先度
かんばんは、主なことに集中することを教えます。 製品に本当に価値を加えるもの。 多くの役に立たないバグと改善を「下げる」ことができました。 結果が出ました。
重要なバグを優先度の低いバグと区別することは製品マネージャーにとって簡単な作業ではありませんが、ここではSwimlanes機能が役立ちます。 これらは、かんばんボードの水平列です。 原則として、ボード上のプログラマーには次のようなスイムレーンがあります。
- ブロッカー-リアルタイムで修正する必要があるタスクとバグ。 例は壊れたレジストリです。
- タスクとバグ-現在の定期的なタスクとバグ。
- いつか-何らかの理由で関連性を失ったタスク。
このシステムは、 アイゼンハワー象限に似ています。 重要かつ緊急な問題はブロッカーです。 重要だが緊急ではない-タスクとバグ。 重要ではなく緊急、重要ではなく緊急ではない-これはいつかです。 ところで、水平カラムがないことは、 Trelloがアジャイル開発のために何を欠いているかを確認する要因の1つです。
4.仕事に集中する
プログラマーは自分の仕事に集中する必要があります。 したがって、彼がタスクキューを受信し、次に何をすべきかを考える必要がない場合、それは良いことです。マネージャーはこれについてすでに考えています。 次のタスクまたはバグを処理するだけです。
かんばんは、プログラマーが上記のタスクを独自に選択することを想定している場合があります。 そうすれば、最も困難なタスクがジュニアスペシャリストに「落ちる」ということが起こらないように、すべての人々の専門レベルは等しくなければなりません。
[ マイタスク]フィルターは、タスクに焦点を当てるのに役立ちます。 ボード上のタスクをすばやく確認するのに役立ちます。
5.パノラマビュー
あなたの目の前-プロジェクトの全体像。 ボードを開くことにより、重要な質問に対する回答をすばやく取得できます。
- この時点で誰が何をしていますか？
- 各スペシャリストの次は何になりますか？
- バグのためにどのタスクが再発見されましたか？
- タスクのない人は誰ですか？
- 誰がタスクの大きなキューを持っていますか？
- 最終日にどこで変更が行われましたか？
- 特定のタスクはいつ行われますか？
- 特定の専門家のタスクはいつまでに終了しますか？
- すでに計画よりも多くの時間を費やしているタスクは何ですか？
6.柔軟性
かんばんは、より柔軟になります。 これは、製品がリリースされ、多くの有用なフィードバックを得るときに特に必要です。 これらは、サポートメッセージ、行動分析、a / bテストの結果、レビューなどです。 新機能を本番環境に「アップロード」するとすぐに、フィードバックに基づいてすぐに変更を開始します。 以前は、プログラマーはスプリントの締め切りを「埋め尽くす」ことを恐れて、「左利き」の仕事をしたくありませんでした。 かんばんによれば、プログラマはプロセッサのように動作します。つまり、1クロックサイクル-1タスクです。
対策が頻繁になればなるほど、開発チームはより柔軟になります。 私たちのチームにとって、理想的なタクトは8〜12時間です。 大きなタスクは必然的に分解されます。
7.機能を評価する必要はありません
スクラムは、スプリントを開始する前に機能を評価するのに長い時間がかかりました。 かんばんによる評価の必要はありません。 私たちがするとき、それは行われます。
8.より多くのビジネス
スクラムには多くのコミュニケーションが含まれます。 スプリントの開始には計画が伴います：タスクの分析と評価。 スタンドアップは毎週必要です。 スプリントの後、回顧展が行われます。 その結果、すべての通信に約30％の時間がかかります。 しかし、チームはこの時間を仕事に費やすことができました。
9.チーム精神
かんばんにより、チームはより協調して作業を開始します。 テスターは、プログラマーが作成したほぼすぐに機能をチェックします。 他の分野でも同様に：デザイナー、UX、編集者、販売。
以前は、QAは、プログラマが行ったときではなく、長い時間をかけて機能をチェックしました。 この間、プログラマーは、このタスクの詳細を含め、世界のすべてを忘れることができました。
10.早い段階での間違い-より迅速に解決策を見つける
スクラムでは、スプリントの終了時にのみ生産に関する機能を「入力」します。 3週間に1回程度。 かんばん-テスターに受け入れられた直後。 数日に一度。
そのため、この機能がユーザーに適用されたかどうかをすぐに確認します。 そうでない場合は、どこかでエラーが発生しました。 そして、最初に間違いを犯すことが重要です。 これは、私たちがエラーを愛しているという意味ではありません。 しかし、最初にエラーについて学習した場合、最初に何をすべきかを知り、決定します。
11.より多くのフロー
プログラマを常に「プル」する必要はありません。 かんばんボードを開き、誰が何をしていたか、すべてのステータスをすぐに確認しました。安全に経営陣に戻ることができます。 そして、プログラマーはフローの状態のままであり、新たな高みをとることを期待しています。
12.プロジェクトの知識が多いほど良い。
以前は、プログラマーは同僚が何をしていたかを知りませんでした。 かんばんを使うと、プログラマーは、マネージャーと同じように、役員会に行って同僚が何をしているかを見ることができます。 彼らは、プロジェクトに関する共同の取り組みを調整するために、こうした情報を必要としています。
13. 1つのタスクに集中
以前は、プログラマーが複数のタスクを同時に並行して実行していました。 彼は気分に応じてタスクを選択できましたが、金曜日に行っていたことを月曜日に完全に忘れることができました。
現在、WIPの制限とパノラマビューはプログラマを正しく制限しています。彼は一度に複数のタスクを実行することはできません。
結論として
かんばんはスクラムよりも優れていると主張しているように見えるかもしれません。 しかし、これはそうではありません。 すべてに時間がある。 Hyggerの経験から次のことを述べることができます。スクラムは製品開発の開始に適しています。かんばん-製品がすでにアリーナに入っているときです。
かんばんはどんなビジネスにとっても万能薬ではありません。 はしごを間違った壁に置くと、どんなに急に登っても、まだ必要な場所にいません。 したがって、かんばんは製品またはプロジェクトを成功させるための必要条件ですが、十分条件ではありません。