どうして？一部のタスクは来週まで待てないのですか？週末までにすべてを完全に終えることはそれほど重要ですか？いいえ、それほど重要ではありません。これはすべて、「タスクの実行が悪い」という事実によるものです。
スクラムはもはやアジャイル開発方法論ではありません
スクラムでは作業プロセスに重点が置かれているという結論に達しました。または、少なくとも、人々はそれにあまりにも注意を払っています。これは次のように表現されます。
- スプリントの最終日にユーザーストーリーを終了しても問題ありません。しかし、来週の月曜日に仕事を終えることはすでに「タスク転送」です。
- - ( , ), , , , , .
- , , , . , , , ( , ).
その結果、スクラムはもはや目標を達成するのに役立たないことがわかりました。このプロジェクト管理方法は、現在私たちを制限していました。
以上のことから、私のチームメンバーは何が起こっているのかについて不満を感じ始めたことに気づくでしょう。これは、私たちが作成したものの品質に影響を与えました。プログラマーは、望ましい品質レベルを達成することよりも、納期を守ることに関心を持っていました。
この時点で、私たちは仕事を整理する他の方法を探し始めました。私たちの仕事の方法によりよく適合する別のアジャイルフレームワークを探しました。
それからかんばんを見つけました。
かんばんとは
かんばんは、1950年代にトヨタで始まった生産管理方法です。当時、トヨタは計画、進行中、完了の3つの列を持つボードを使用していました。このフレームワークにより、生産ラインのどこかでボトルネックが発生した場合に、トヨタはより効率的にリソースを割り当てることができました。
その後、かんばんを使用することでソフトウェア開発の速度を上げることができることが明らかになったとき、かんばんは技術分野に移行しました。
スクラムとカンバンのフレームワークの比較
近年、スクラムとカンバンは、主要なアジャイルフレームワークになるために闘っています。スクラムが1位にランクされているにもかかわらず、かんばんは次第に広がっています。それらを比較するとどうなりますか？
スクラムをベースにしてカンバンと比較すると、次のようになります。
- , ().
- .
- «». , .
- , , .
- () -.
スクラムとかんばんのより詳細な比較は、こちらにあります。
かんばんは、開発チームにかなり高いレベルの柔軟性を与えます。ユーザーストーリーは、スクラムと比較して、より自由な方法で実行されます。しかし、自由は責任です。かんばんでは、開発者が2週間ごとにコミットメントを約束する必要はありませんが、この開発管理方法には独自の制御があります。これらは、たとえば、サイクルタイムやシステムスループットなどのメトリックです。
それはすべてメトリックに関するものです
専門的な測定基準なしに作業の有効性（または非効率性）を評価することは不可能です。スクラムとカンバンで使用されるメトリックを見てみましょう。
▍スクラムメトリック
スクラムを適用する場合、次のメトリックとグラフが使用されます。
- (velocity). , .
- , , (commitment vs. done). , , .
- (Burndown Chart). , .
これらのメトリックがワークフローの改善に役立つことはほとんどありません。
「速度」は、完成品のサブシステムがリリースされる速度を測定するものではありません。このメトリックは、ユーザーストーリーに関連する完了したワークステップの数のみを測定します。ストーリーの完了に予定よりも時間がかかる場合、この指標は意味がありません。
「完了したタスクの量に対する開発者のコミットメントの比率」は、メトリックとはまったく見なされるべきではありません。この「メトリック」は、結果への取り組みを比較します。言うまでもなく、これにより、タスクを完了させるためだけに、タスクを閉じて再度開くことができます。
バーンアウト図は私が個人的にあまり注意を払わなかったものです。これは主に、そのようなチャートが以下のようなものに見えることが多いためです。
バーンアウト図
これはなぜですか？たとえば、空白のボードから始めて、たとえば3つのユーザーストーリーで並行して作業を開始するとします。これらのストーリーは同じ速度で処理される可能性が高いため、バーンアウトダイアグラムでこのような強力な下向きの動きを見ることができます。さらに、すべてのタスクの作業結果をテストする必要があるテスターがチーム内に1人だけいる場合、そのテスターがチームのボトルネックになります。
▍かんばんメトリック
指標はかんばんの強みの中で最も重要だと思います。かんばんには、チームで何が起こっているかをよりよく理解するのに役立つ多くの異なるメトリックがあります。例えば：
- チームのスループット 特定の期間内に完了したユーザーストーリーの数。
- サイクルタイム 作業開始後、履歴作業が完了するまでの日数。ここでは、信頼区間などの指標が使用されます。最も一般的なのは85％の信頼です。
- 累積フロー図 このような図を使用すると、ユーザーストーリーに基づいて問題を解決するプロセスを視覚化できます。この図は、次の図のようになります。
累積フローチャート
Jiraには、これらすべてのメトリックを活用できるプラグインがあります。これは、Jira-AgileメトリックのActionableAgileです。作業の管理に使用したのと同じプラットフォームを使用して、チームのパフォーマンスに関連するメトリックを調査するのに役立ちます。
かんばん適応
「純粋な」かんばんを使用すると、スクラムを使用するときに必要な操作の一部が提供されません。しかし、このプロジェクト管理方法は、そのようなアクションが有用であると思われる場合にワークフローに追加できるように十分に柔軟です。
レトロスペクティブは、最も重要なタイプの会議の1つです。チームメンバーは、これらの会議で、達成したこと、うまくいかなかったこと、改善できる点について話すことができます。ふりかえりは、あなたの問題について話し、彼らの成功について素晴らしい仕事をした人々を祝福することができる穏やかなイベントです。
かんばんではフラッシュバックは必要ありません（スクラムの各スプリントの最後に保持されます）が、フラッシュバックは貴重であり、スキップしたくありませんでした。実際、以前のように2週間ごとではなく、毎週それらの作業を開始しました。これにより、問題の発生により迅速に対応することができました。また、これらの会議を使用して、チームのメトリックを分析し、問題やボトルネックがないかワークフローを確認します。
スクラムタイムからもう1つの要素を保存しました。これは、かんばんを使用する場合はオプションです。これは、ユーザーストーリーの作業に必要な時間を見積もることです。これは、歴史に残るタスクの精緻化中に行われます。スクラムはこれらの推定値を使用して、スプリントに何が適合するかをよりよく理解します。かんばんにはスプリントがないので、ストーリー評価は不要だと思うかもしれません。しかし、実際にはそうではありません。
ユーザーストーリーを完了するのにかかる時間を見積もると、すべてのチームメンバーが、ストーリーの作業中に完了する必要があるタスクの範囲を同じように理解できるようになります。誰かがストーリーのグレードを8、誰かを3にした場合、この問題の議論を続ける必要があることは明らかです。誰かが、タイミングを評価するとき、他の人が知らないいくつかの問題を考慮に入れるかもしれません。誰かの理解では、ユーザーストーリーの作業の範囲には、他の人がそのように考慮していないものを含める必要があります。
実際、これらすべてがチームメンバーを議論に駆り立てています。
このようなことが発生すると、特定のユーザーストーリーに対してどれだけの作業を行う必要があるかを誰もが明確に理解しているわけではないことが明らかになります。
別の一般的なシナリオは次のようになります。チーム全体がストーリーの面倒さをかなり高い評価（通常は8ポイントを超えるすべてのもの）にします。これは不確実性を物語っています。これは、私たちが多くの作業について話しているか、非常に困難な問題を解決することについて話していることを意味し、チームメンバーを不快なものにします。このような場合は、ユーザーストーリーをいくつかの小さなストーリーに分割し、作業の目標をより明確に定義するのが最善です。
結果
スクラムは、最初の広くアジャイルな方法論として私たちの心に永遠に残ります。しかし、企業が継続的な導入スキームに移行するにつれて、時間制限のあるスプリントの使用はもはや意味がありません。
スクラムがうまく機能できる特別なプロジェクトが常にあります。ただし、企業がアジャイル方法論をますます使用しているという事実を考えると、かんばんは徐々にトップになり、スクラムに取って代わります。
あなたに一番合うのは何ですか？スクラムかかんばん？
