2つの一般的なアジャイル手法
スクラムとかんばんは、アジャイルファミリー手法の代表です。 どちらも柔軟で反復的と見なされます。 それらの違いを理解する前に、それらを結合するものを簡単に思い出しましょう。
17年以上前、ITリーダーはアジャイルマニフェストを作成しました。 マニフェストから強調できる主なもの：
- 人と相互作用は、プロセスとツールよりも重要です。
- 実用的な製品は、包括的なドキュメントよりも重要です。
- 顧客とのコラボレーションは、契約条件の交渉よりも重要です。
- 変化への意欲は、当初の計画に従うよりも重要です。
実際、次の理由から、すべての引数に安全に同意できます。
- 人々はツールよりも重要です。何人かの人々が団結し、1つの共通の目標に「チャージ」されると、より大きな可能性が得られ、最終的にはより大きな結果が得られるからです。
- 開発におけるMVPアプローチ：ASAP市場で最小限の実行可能なバージョンの製品をリリースします。 すべての「ホイッスル」は後で使用できます。
- 「顧客」という言葉は、「ユーザー」に変更することを強く求められています。 プロジェクトの要件は、顧客からではなく、将来の製品のユーザーから収集する必要があります。 これについては、 Karl WigersとJoey Beattyが詳しく説明しています。
多くの場合、プロジェクトはスタートアップです。 スタートアップのコンテキストでは、「 顧客開発 」が思い浮かびます（元の技術は、 Steve Blank によって著しく説明されました ）。
実際、顧客の開発中に、プロトタイプを開発する前に仮説をテストします。 私たちの目標は次のことを確実にすることです。
-私たちが扱っている問題は、ユーザーの人生に存在します。
-これらの問題は重大です。
-ユーザーが支払います
-市場があり、これは一人にとって問題ではありません。
-ユーザーを引き付けるためのチャネル（Facebook広告やGoogl Adwordsなど）があり、利益をもたらすユーザーを引き付けるコストを見つけることができます（CAC <LTV）。
- UXまたはプロジェクトマネージャーがタスクの要件を変更する場合、柔軟性についてのポイントが必要であり、プログラマーは「週に7つの金曜日があります。」と言います。 空間と時間のこの時点で、あなたは柔軟性についてのポイントに言及しています。 一般に、より深く「掘る」必要があります。 変更の準備が必要なのはなぜですか？ フィードバックに対応できるようにするため。 本番環境で機能を起動し、ユーザーの行動の統計を収集し、機能の一部の機能を変更する必要があることを確認し、さらなる開発のために送信しました。 そして今、あなたは製品の改良版を持っています。 これをすべて行うには、変更（これはアジャイルに関するものです）およびこれらの変更をキャッチする能力（これは分析とデータに関するもの）に備える必要があります。
これらはマニフェストの主なアイデアですが、それでも有名な12の原則があります。 そのため、それらについて深く掘り下げるのではなく、スクラムとかんばんの違いという主要な問題に戻ります。
スクラムとかんばんの違いは何ですか？
スクラムは、通常2〜3週間の短い反復またはスプリントに基づいています。 スプリントの開始前に、チーム自身が反復用の機能のリストを作成し、スプリントが開始されます。
スプリントが終了すると、完成したフィーチャがプロダクションに注ぎ込まれ、不完全なフィーチャは別のスプリントに転送されます。 原則として、スプリント中に作成される機能は変更されません。スプリントの開始時に起こったことは、スプリントの終了までにすべてのコストで実行される必要があります。
かんばんが発生した場所を確認します。 トヨタ車用の部品が作られているコンベアを想像してください。 工作機械があり、彼は車の鏡を作ります。 彼は、サンバイザー用の左ミラー、右ミラー、リア、ミラーの作り方を知っています。 原理は簡単です。ボタンを押してモードを変更し、新製品を入手してください。
そのため、モスクワのクトゥゾフスキーで最高速度で新しいトヨタカムリを注文すると、バイザーのミラーがすでに作成されています（バイザーのミラーのために最高速度を選択しました）。 ここで重要な点は、いつでも優先順位を変更できることです。 マシンを別のモードにすばやく切り替えることができます。
スクラムとかんばんの主な違いは、反復の長さです。 スクラムイテレーション-2週間、カンバンでは、プログラマーのタスクを少なくとも毎日「緩和」できます。
柔軟性が優先順位を変更する頻度を意味する場合、かんばんにより柔軟性が与えられます。 昨日、製品に新しい機能をアップロードしましたが、今日、最前線からデータを受信し、これが意図したとおりに機能しないことがわかりました。人々は購入ボタンをクリックしません。 UXに「帽子を与える」ことで、新しい要件が与えられます。 このタスクを上げると、プログラマーはこのタスクを「上から」実行し、実行します。修正がすでに製品に反映されるまでに、支払いへの変換は12％増加しました。 これは勝利です。
スクラムでは、タスクは通常、ストーリーポイントまたは時間単位で評価されます。 評価なしでは、スプリントを形成することはできません。結局、2週間でタスクを完了することができるかどうかを知る必要があります。 2週間後、貴重な統計情報-チームがスプリントのために何時間またはストーリーポイントを処理できたかがわかります。 Velocityは、1回のスプリントでのチームのパフォーマンスです。 このパラメーターを使用すると、スクラムマネージャーはチームが2週間後にどこにいるかを予測できます。
かんばんでは、評価を行うことは習慣ではありません。 これはオプションであり、チームが自ら決定します。 「チームの作業速度」の概念はなく、タスクごとの平均時間のみが考慮されます。 この時間は、特別なレポート-サイクルタイムを使用して計算されます。
タスクのサイクル時間=タスクの実行時間-タスクの作業を開始するのにかかる時間。 たとえば、列があります：行う、再開、開発、テスト、ステージテスト、展開。 タスクのサイクル時間は、デプロイされた開発と同じです。つまり、タスクが実行され始めてからデプロイされるまでに経過した時間です。
したがって、スクラムでは、カンバンでのスプリントを完了することが目標です。
スクラムは、グループで出かける特定の停留所でのみ停車するバスです。 かんばんはミニバスです。乗客は外に出たいと思い、運転手に尋ねて必要な場所を離れました。
かんばんの何がおもしろいので、スプリントでうまく使うことができますか？ プロジェクト管理ツールHygger.ioの例を見てみましょう。
仕掛品
1つ目はWIP（進行中の作業）です。 1人の従業員が同時に実行できるタスクの数に制限を設定しました。 ナポレオンとシーザーのみがいくつかのタスクを同時に実行できました。 彼らがどのように終わったか知っています。 したがって、私たちは従業員を保護し、燃え尽きから保護します。彼らは単位時間あたり1つのタスクしか実行しません。
しかし真剣に、「タスクからタスクへ」のプログラマーの切り替えには平均15分かかります。 お茶を飲みながら、Habrを閲覧しながら、新しいタスクの要件を読み、中断した場所を覚えて、コード内の場所を見つけます。 各スイッチはストリームから抜け出す方法であり、常にストリームに入ることはできません-外部の刺激物が干渉する可能性があります。 したがって、すべてが厳格です：従業員ごとに1つのタスク。 これをどのように制御しますか？ ここで明確にする必要があります。
かんばんを初めて導入したとき、WIPの制限はすぐにプロセスのボトルネックを示しました。テスト列に蓄積されたタスクの大きなキュー-テスターはタスクの検証に対処できませんでした。 タスクは非常に長い間並んでいました。 その結果、プログラマは、1〜2週間後にテスターが再発見したタスクを忘れることができました。 忘れてしまったら、コードを見て、そこで議論された内容を覚えて、再度詳細に飛び込む必要があります。 これらはすべて、効率を低下させたコストです。 次に、別のQAをプロジェクトに接続し、問題を解決しました。
スイムレーン
第二に、それはスイムレーンです。 あなたのサイトが「敷設された」と想像してください。 よくあること-勤務時間中。 タスクをリードまたはdevopsに委任します-「今すぐサイトを上げる」。 そして今、彼は別のタスクを実行しており、明日の午後にそれを完了する予定です。 どうする 彼に走って、ブロッカーに切り替えるように頼みますか？ 可能ですが、すぐに「ブラックスワン」というニックネームが付けられます。 したがって、スイムレーンを使用します。
この場合、ブロッカーと呼ばれるスイムレーンがあります。 リアルタイムで解決する必要があるすべてのタスクは、このブロックで設定されます。 プログラマは現在のタスクをすぐに停止し、一時停止してブロッカーを開始します。
Somedayという非常に便利なSwimlaneもあります。 そこで、「はい、いつか絶対にやる」というタスクを昇華させます。これは、目から不要なものをすべて取り除き、人々が主要なことに集中できるようにするのに役立ちます。 そして、これらのタスクは、原則として、永遠にそこに残ります。
「正しい」テスターは多くの「正しい」バグを見つけますが、これはすべてプログラマーの手に落ちます。 これらのバグがチェックされずにメインタスクキューに残っている場合、プログラマーは重要でないナンセンスで忙しいことにすぐに気付くでしょう。 したがって、チームには人がいなければなりません。できれば、いつか、どのバグが重要で、どのバグが不確実な未来に向かうべきかを理解している人が必要です。
サブ列
「プログラミング」列に続いて「テスト」列があります。 プログラマーはタスクを完了すると、テストに転送します。 そして、テスターが何らかの形でタスクのテストを開始したことがわかりました。 しかし、実際には、テスターは別のものをチェックします。 とにかく、タスク数にWIP制限を設定し、プログラマがタスクをテストに転送した後、QAはこの制限に違反しました。 2つのタスクがありました。
プログラマーがタスクをTestingに転送せず、プログラミングのままにしておきます。 しかし、違反できないWIP制限がある場合、どのようにして次のタスクを実行できますか。 この場合、サブ列が助けになります。 たとえば、「プログラミング」列では、「進行中」および「完了」サブ列を作成します。 そして、プログラマーがタスクを完了すると、彼はそれを完了に転送します。 テスターが自由になったら、彼はプログラミング列の完了サブ列から新しいタスクを取得し、テスト列に転送します。
おわりに
要約すると、スクラムは柔軟な開発手法であり、かんばんはさらに優れていることに注意してください。 すべてに時間と場所があります。 これが新製品の開発である場合、開発の開始時およびリリース前に、開発をより時間管理できるようにするため、スクラムを使用することをお勧めします。 また、スクラムはチーム内で多くのコミュニケーションを取ります：開始前に全員がスプリントバックログ全体について話し合い、タスク作成者（UX、製品マネージャー、ビジネスアナリスト）に質問し、Planning pokerを使用してタスクを一緒に評価します。 スクラムは、製品の本質にチームを詳細に没頭させるのに役立ちます。
そして、製品のリリース後、完全に異なる人生が始まります。製品のユーザーからのフィードバックが出始め、すぐにそれに対応する必要があります。 HADIサイクルの作業を開始します-さまざまな仮説を常にチェックする必要があります。ボタンの色が仮説を腐食させる可能性があります。 Pirate Metrics（AARRR）などの製品メトリックスの測定と最適化を開始します。 すべてが開発サイクルを増加させ、予測できないシーケンスで多くの小さなタスクを実行し始めます。 このため、かんばんはまさに完璧です。
どのアジャイル手法を選択したとしても、プロジェクト管理プラットフォームHygger.ioを使用して定性的に実装できます。
そして、あなたは何を選びましたか：スクラムとかんばん？ コメントであなたの例と観察を共有してください！