かんばんの大きな内部機能
今日、私はかんばんプロセスとアジャイル方法論に関するいくつかのチュートリアル/アドバイスを読んでいますが、このかんばん方法論について2つの大きな質問があります。
私が理解したのは、ユーザーストーリーは、お客様が使用できる機能のように、ビジネス価値を追加することに関するものです。主な問題は、些細なように見える機能がたくさんあることです（たとえば、solrの同義語を管理する単純な形式）が、実装が難しく、クラスターのスケーリング/調整の詳細のために、完了するまでに数日/数週間かかる場合があります（ zkを使用して同義語を更新し、データベースから再ロードします（例）。
かんばんはすべてのユーザーストーリーを独立させる必要があるため、このユーザーストーリーをどのように小さなものに分解しますか？実装の詳細に関するユーザーストーリーに分解できますか？ （調整アルゴリズムの実装、Xストレージサービスの実装など）
そして私の最後の質問は、アーキテクチャの変更/リファクタリングについてです。それはビジネス価値を追加しないので（私たちの顧客には見えません）、この方法論にこのタスクをどのように反映しますか？
かんばん は、進行中の作業を特定する（そしてそれを最小限に抑える）ことに焦点を当てたアプローチです。それがその中核となる概念です。これは、日本の自動車会社のジャストインタイムワークフローに基づいています。どこかに詰まっているものは、ワークフロー全体で可能な限り速く移動していません。多くの場合、スクラムとペアになっています。その場合、 scrumban として知られていますが、これはagileとはあまり関係がありません。原則。
かんばんがうまく機能するには、ストーリーまたはタスクのサイズが同じである必要があります。ミニバンにスクーターサイズのものを作るように設計されたプロセスを通過させると、組立ラインで問題が発生します。そのため、1週間のタスクをプッシュしたいワークフローで、1か月かかるタスクをプッシュしようとすると問題が発生します。それは可能ですが、それがワークフローの残りの部分に何を意味するのかを理解する必要があります。
ストーリーまたはタスクには依存関係があります。依存関係が完全であることを確認する必要がありますbefore次の依存関係が先に進みます。 AとBの2つのタスクがある状況を考えてみましょう。 Aをコーディングする前に、Bを実行する必要があります。これらのタスクの両方が同時にバックログにある場合、誰かmight最初にBを取ります-これはタスクがあるので悪いでしょうこれは、cannotを前に進めるという状態です-作業中です。さらに、Aが開始され、部分的に実行された場合、Bが開始されると、先に進むことができない進行中の作業が再び発生する可能性があります。
そのため、独立したタスクに重点が置かれています。ただし、これはすべてのタスクが独立している必要があるという意味ではありません。2つの依存タスクが同時にまたは間違った順序で処理されてはならないということです。これを制御するのは、物事をバックログに入れる機能です。
プロセスを移動する同様のサイズのストーリーに注意を払い、一度に特定の列に含めることができる量を制限することで、ワークフローを通過するのにかかる時間について、顧客により良いフィードバックを提供することができます。
したがって、絶対に実装ストーリーまたはタスクに分解することができます。物理的なかんばんボードを使用している場合は、より大きなストーリーの部分的な詳細に特定の色の付箋を使用して、これらを表示および理解できるようにし（場合によっては、依存関係情報を含めて）、より多くのストーリーを表示およびフォローできるようにすることを検討してください。ボードの全体像を把握しようとするとすぐに。
かんばんにはnonethがあり、設計時間を最小限に抑えようとするアジャイルのよく見られるアプリケーションと類似しています（ の原則には何もありません。アジャイルマニフェスト の背後には、「設計は価値がない」と解釈される「開発の後半でも、要件の変更を歓迎する」または「動作するソフトウェアが進歩の主要な尺度である」に対する反応かもしれないが、設計を示唆していない「-しかし、マニフェストの署名者がその主張をするのではないかと思う）。かんばんボードのさまざまなデモを見ると、次のようなものがあります。
その最初の画像には「指定」列があります。 2つ目は、「分析」列と「設計」列を示しています。
アジャイルマニフェストの背後にある原則で説明されているように、重要なことは、動作するソフトウェアを用意し、顧客と連携することです。タスクをバックログに入れる責任がある個人は、内部リファクタリングタスクをそこに完全に入れることができます。また、マネージャーが必要に応じて80％の内部タスクであるスクラムスタイルのスプリント全体を実行している、または金曜日にコードのクリーンアップに取り組む金曜日のリファクタリング日があると聞いたことがあります。賢明なマネージャー/製品の所有者は、内部の（エンドユーザーに面していないタスク）に対処せずに、通過できるタスクのサイズがますます小さくなる（そして同様のサイズのものの見積もりが時間の経過とともに大きくなる）ため、これを行います技術的負債は製品に累積されます。
アジャイルまたはかんばんにはnonethがあり、「リファクタリングライブラリXYZ」という性質のタスクを実行できないことを示しています。製品の所有者が実行するタスクを承認した場合（または、バックログに処理するためのワークフローが承認された場合）、それを実行します。前述のように、do n'tを実行すると、開発は最終的に停止します。
notこれを行うことは、「技術的な卓越性と優れた設計への継続的な注意が敏捷性を高める」という原則に反することを指摘します。コードベースを特定の品質の一定の状態に保つことにより、プロジェクト全体にかかる時間を予測する上でより良い仕事をすることができます（技術的負債のために物事が難しくなるにつれて速度が遅くなるのではなく）。
theoryでは、アジャイルプロセスは常にコードをリファクタリングすることになっていますが、これは私が行ったことではありませんよく見られます。部分的には、プログラマーが「これは何かにかかる時間です」と言う力がどれほどあるかに関係しています。プロジェクトに取り組んでいるコンサルタントの状況では、「これには、私が言う限り時間がかかる」というかなりの部分があり、絶え間ないリファクタリングを考慮に入れています。そのような発言は、「1週間かかる」➔「手抜きをしたり、リファクタリングをしなかったりすると、3日で完成できるか」という社内開発では難しい。 ➔「ええ、そうです...」➔「素晴らしい！3日です。」これはアジャイルの問題ではなく、組織内の開発者のエンパワーメントです。
関連読書：
- スクラムバンとは？
- リーンソフトウェア スクラムバン
- リーンソフトウェア かんばんブートストラップ この投稿は具体的に大規模な分解を扱う非常に大規模なプロジェクトの問題に対処していることを指摘します小さなものに物語。
かんばんの仕様すべてのユーザーストーリーは独立している必要があります
これはどこから入手したのですか？かんばんでは、作業単位が「ユーザーストーリー」である必要はありません。かんばんには、最初にコンポーネントを開発し、次に最初のコンポーネントを使用して2番目のコンポーネントを開発することを禁じるものはありません。また、この各コンポーネントは、最初に分析を行い、最後にテストと展開を行うことで、通常のかんばんワークフローに従うことができます。このコンテキストで「展開」が何を意味するかを再考する必要があるかもしれません。
何週間にもわたって開発される大きな機能がある場合、少なくとも、合理的なアーキテクチャを開発しようとしている場合は、これを小さなサブ機能、またはさらに優れたコンポーネントに分割する必要があります。もちろん、一部の中間コンポーネントは、それ自体では顧客にビジネス価値を提供しない場合があります。ただし、実際には、サブ機能またはコンポーネントごとにテストを開発するため、作業テストを使用して、特定のコンポーネントが「準備完了」であることを証明できます。また、コンポーネントは、コンポーネントを使用するチームの開発者に「ビジネス価値」を提供します。したがって、かんばんの解釈に適応する必要があるのは、内部コンポーネントに関しては、「完了の定義」だけです。
とはいえ、これは、最終的な顧客にできるだけ早く、より小さなステップで価値を提供できる方法で開発プロセスを編成する方法について考えることを妨げるものではありません。あなたの例を使用すると：バックグラウンド自体にいくつかの複雑なアルゴリズムを持つフォームは、最初に非常に基本的で単純な「ダミー」アルゴリズムで開発され、アルゴリズムは2番目のステップで改善または改良されます。ストレージサービスを機能させるには、ある種の管理コンソールやある種のロギングメカニズムが必要になる場合があります。これも、「ビジネス価値」としてカウントされます。
かんばんに固有のことは何も知りませんが、一般的にアジャイルでは、すべての反復の最後に、顧客に役立つ新機能を実証できなければならないという文化があります。このデモンストレーションは、UI、ビジネスロジック、および永続化プロセスが機能している必要があるという意味で、通常は完了している必要があります（これは、多くの場合vertical sliceと呼ばれます）。
ただし、「些細な」機能で技術的な労力がかかりすぎる場合は、イテレーションの終わりまでに部分的なデモンストレーションのみを表示することに顧客が同意するかどうかをチームが尋ねる場合があります。たとえば、UIとビジネスロジックのみが機能しますが、永続性はありません（それがボトルネックであるため）。顧客が同意した場合は、永続性を別のストーリーに分割できます。
顧客が同意しない場合は、ストーリーをさらに細かく分割してみてください。あなたの場合でも、話を壊すことは役に立たないかもしれません。単純なCRUDの場合、C、R、U、およびDの操作を個々のストーリーに分割できますが、これらのストーリーの最初のストーリーを開発するときは、永続性レイヤーで「数週間」の技術的努力が必要です。
したがって、最終的に、顧客が「部分的な垂直スライス」のアイデアに同意せず、ストーリーを細かく分割できない場合、またはそれらを分割しても役に立たない場合は、1つの非常に可能性の高い結果が得られます。 ：1回の反復で機能を提供することはできません。
これが発生し、チームが反復ごとに行われたストーリーポイント（速度）をカウントしている場合、速度がゼロの反復があります。これは通常、チーム内の何かを変更する必要があることを示しています。これはあなたの最後の質問（リファクタリングについて）への答えに私をもたらします：
私の（非常に限られた、文脈から外れた）観点から、あなたのチームは技術的な借金を残すことで問題に直面しているようです。速度を妨げる永続化メカニズムを使用しているという事実は、技術的負債に直接関係していない可能性があります。チームが開発している特定のビジネスにとって本当に必要な場合があります。ただし、そうでない場合は、現在使用しているものが解決するよりも多くの問題を作成するとすぐに、チームは別の永続化メカニズムに切り替えることができる必要があります。
たとえば、「スキーマ」を変更する手間を減らしたい場合（NoSQLにはスキーマがないため）、または大規模な移行を実行する必要がある場合（必要がないため）、NoSQLデータベースを使用できます。ただし、システムが混乱している場合は、この切り替えを行うと「不可能」と表示されることがあります。アーキテクチャが現在使用しているデータベースに結合されすぎている場合、切り替える唯一の方法は、システムをリファクタリングして永続化メカニズムから切り離すことです。
したがって、リファクタリングを方法論に適合させる方法については、このトピックはすでに この他の質問 でカバーされていると思います。したがって、ここで繰り返すことはお勧めしません。
これは、多くのアジャイル手法の弱点であるという課題です。 ユーザーストーリー 、ユーザーに見える価値、およびユーザーフィードバックに非常に強く集中することで、「内部」の改善に焦点を当てることが難しくなります」 技術的負債） "または、将来のユーザーに表示され、ユーザーに認識できる改善のためにプロジェクト/コードベースを準備します。内部の改善は、ほとんど定義上、ユーザーには見えません-確かに体系的で、評価しやすい、または 先行指標 の意味ではありません。
物事の壮大な計画では、アジャイルは、漸進主義、フィードバックループ、または開発者の入力の方法がほとんどない、常にすべてのアーキテクチャであり、深く事前に計画された以前の方法論への反応および/またはそれからの逃避です。 。シフトは価値がありましたが、ソフトウェアプロジェクト（多くの真の欠陥が何であれ）が持っていた深いアーキテクチャ、長期的な計画、および内部の焦点の多くの結果としての回避は、以前のいくつかの美徳がより困難であると主張することができます楽しい。アジャイルの形式が極端であるほど、 準備作業を心から軽蔑する になる可能性が高くなります。
このパターン名が必要な場合は、「 お風呂の水で赤ちゃんを捨てる 」です。