-ホフスタッターの法則
ほとんどのアジャイルYouTubeビデオを視聴しました。 この記事の公開時点での744,625ビュー。 プレゼンテーション、写真、わずか15分の軽いスタイルが、私が見た中で最高です。 TEDは休んでいます。
役割
これは、製品の所有者であるパットです 。 彼女は技術的な詳細を知りませんが、全体像のビジョンを持っています。私たちがなぜ製品を作っているのか 、どのような問題を誰のために解決するのかを知っています。
これらは利害関係者です。 彼らは、製品を使用するか、サポートするか、何らかの形で開発に関与します。
これらはユーザーストーリーです。 彼らは、利害関係者の希望を表明した。 たとえば、「ユーザーはフライト予約システムのフライト検索システムを持っている必要があります。」
利害関係者には多くのアイデアがあり、Patはアイデアからカスタムストーリーを作成するのに役立ちます。
これは開発チームです。 作業システムを構築する人 。
スループット
チームは柔軟な開発方法論を使用しているため、これらのストーリーを大規模リリースまで蓄積せず、逆に、できるだけ頻繁にリリースします。 通常、彼らは週に4-6ユーザーストーリーをリリースします。 これが彼らの帯域幅です。 7日間のユーザーストーリーの数を測定するのは非常に簡単です。
一部のストーリーは大きく、2つと見なすことができ、一部のストーリーは小さく、半分と見なすことができます。
このリズムを維持し、手動の回帰テストにとらわれないために、チームは自動テストと継続的統合に懸命に取り組んでいます 。 したがって、機能ごとに自動テストを作成する必要があり、ほとんどのコードには自動テストが組み込まれています。
問題は、多くの利害関係者がおり、彼らの要求が週に4〜6ストーリーで満足できないことです。
ユーザーストーリーを実装するたびに、彼らはさらにいくつかのアイデアを得て、そこからさらに多くの要求が続きます。
彼らが私たちに尋ねるすべてを行うとどうなりますか？ オーバーロードが発生します。
あるチームが今週10の新しいストーリーを作成することを約束した場合、入力に10、出力に4〜6があると、チームは過負荷になります。 急いで、タスクを切り替え、モチベーションを失い、その結果、生産性と品質が低下します。 これは負け戦略です。
この場合のスクラムとXPは、「昨日の天気」の方法を使用します。 チームは次のように述べています。「最近、週に4〜6個の機能を実行していますが、来週は4〜6個の機能を実行しますか？」
製品所有者のタスクは、今週実装するユーザーストーリーを正しく選択することです。
Kanbanは、いくつかのタスク（WIP制限）に制限することをお勧めします。 チームが、5が許容できる数のユーザーストーリーであると判断したとします。ユーザーストーリーは、オーバーロードせずに、一方から他方にジャンプすることなく同時に作業できます。
これらのアプローチは両方ともうまく機能し、両方ともタスクキューを作成します。これはスクラムではバックログ、またはタスクの優先順位リストと呼ばれます。
このキューも管理する必要があり、関心のある人が週に10ストーリーを要求し、チームが4〜6ストーリーを実装する場合、このキューはますます増えます。 まもなく、バックログは6か月前にスケジュールされます。 つまり、1つのストーリーが6か月のリリースを待つことになります。
タスクのリストを管理する方法は1つしかありません-「いいえ」という言葉
これは、製品所有者にとって最も重要な言葉です。 彼は毎日鏡の前で彼を訓練しなければなりません。
はいと言うのは簡単です。 しかし、より重要なタスクは、すべきでないことを決定し 、その責任を負うことです。 また、製品の所有者は、私たちが今何をし、その後何をするかの順序を決定します。 これは複雑な作業であり、開発チームと少なくとも1人の関係者と一緒に実行する必要があります。
適切に優先順位を付けるには、製品所有者は各ストーリーの価値とその範囲を理解する必要があります。
意思決定
一部のストーリーはひどく必要であり、一部は単なるボーナス機能です。 一部のストーリーを作成するには数時間かかり、他のストーリーを作成するには数か月かかります。
ストーリーのサイズはその価値とどのように比較されますか？ まさか。 多いほど良いというわけではありません。 タスクの価値と複雑さは、Patの優先順位付けに役立ちます。
製品所有者は、ストーリーの価値と量をどのように決定しますか？ まさか。 これは推測ゲームです。 そして、すべてに参加する方が良いです。 パットは、各ストーリーの価値を知るために利害関係者と絶えず通信し、作業量を知るために開発チームと通信しますが、これらはすべておおよその推測であり、正確な数字ではありません。 最初は常に間違いがあり、これは正常です。 コミュニケーションは、非常に正確な数字よりもはるかに価値があります。
開発者が新しいものをリリースするたびに、より多くの情報を学習し、より適切にナビゲートできます。
優先順位付けだけでは十分ではありません。 ストーリーを迅速かつ頻繁にリリースするには、2、3日でできる小片に分割する必要があります。 目標到達プロセスの最初に小さく明確なストーリーを、最後に大きく不確実なストーリーが必要です。 そのような内訳を行うには、製品とユーザーのニーズに関する最新の発見を活用することができます。 これはすべてバックログクリーンアップと呼ばれます。
パットは、毎週水曜日の11から12にバックログをクリーンアップする会議を開催します。通常、チーム全体と、時には複数の関心のある人々が集まります。 会議の内容は異なります。 評価、ストーリーの内訳、受け入れ基準に焦点を当てます。
IT製品の所有者は、常に全員と通信する必要があります
経験の浅い製品所有者は、成功への2つの要素、仕事への情熱とコミュニケーションを区別します。 製品所有者は、チームとその場でどのタスクを決定しますか。
開発の複雑さとユーザーストーリーの価値のバランス
早い段階で、バランスは不確実性といくつかのリスクによって同時に脅かされます。
リスク
ビジネスリスク：「私たちは正しいことをしていますか？」
社会的リスク：「必要なことを実行できますか？」
技術的リスク：「プロジェクトはこのプラットフォームで動作しますか？」
コストと実装条件に関するリスク：「成功し、十分なお金がありますか？」
知識はリスクの反対とみなすことができます。 不確実性が大きい場合、知識の獲得に焦点を当てます-インターフェースプロトタイプ、技術実験、
知識の価値とクライアントの価値のトレードオフ
顧客の観点から見ると、曲線は次のようになります。
顧客価値に関しては、この曲線は次のようになります。 不確実性が減少するにつれて、顧客価値に集中することができます。 私たちは何をどのように行うかを知っています。 するだけです。 メインストーリーを実装したら、ボーナス機能を実行するか、新しいプロジェクトを開始します。
短期的思考と長期的思考のトレードオフ
最初に実装するもの 緊急にバグを修正するか、ユーザーを驚かせるすばらしい機能の開発を開始します。 または、プラットフォームの複雑なアップグレードを実行して、将来の作業を加速させます。 リアクティブな作業とプロアクティブな作業の間のバランスを常に維持する必要があります。
正しいことをするか、正しいことをするか、それとも速くしますか？
理想的には、3つすべてを同時に使用しますが、実際には選択する必要があります。
ここにいるとします。 完璧なアーキテクチャを使用して完璧な製品を作成しようとしています。 多くの時間を費やすと、「マーケティングの窓口」に入らない可能性があり、お金に問題が生じます。
または
製品の簡単なプロトタイプを作成します。 短期的には、これは悪くありません。 長期的には、技術的なリスクが生じます。 そして、開発速度はゼロに低下します。
または
記録的な速さで美しい神殿を創造しています しかし、ユーザーは寺院を必要としませんでした、彼は住宅のバンを必要としました。
スクラムの役割の間には健全な対立があります
製品所有者は、適切なものを構築することに焦点を当てています。 チームは物事を正しく構築することに焦点を当てています。 スクラムマスターまたはアジャイルトレーナーは、フィードバックループの短縮に重点を置いています。
それとは別に、短いフィードバックループが学習を高速化するため、速度の重要性を強調する価値があります。 これにより、どのものが正しいか、どのように正しく構築するかをすばやく見つけることができます。
新製品の開発と古い製品の改善とのトレードオフ
製品は常に変更する必要があるため、完全に完成することはできません。 チームが新しい製品の作業を開始すると、古い製品はどうなりますか？ あるチームから別のチームに製品を転送することは、非常に費用がかかり、リスクがあります。 通常、チームは古い製品を維持しながら新しい製品を開発します。 したがって、むしろ、「バックログ」の概念は製品ではなく、チームを指します。 バックログは、製品所有者がチームに求めているもののリストです。 また、さまざまな製品の一連のストーリー。 製品の所有者は、実装のために常に局所を選択する必要があります。
歴史破壊スケジュール
興味のある関係者は、時々、「私の機能はいつリリースされますか？」または「クリスマスまでにいくつの機能がリリースされますか？」とパットに尋ねます。 製品所有者は、ユーザーの期待を管理できる必要があります。 そして、期待を現実的に管理します。
2つの傾向-楽観的および悲観的（目で確認可能）。 トレンド間の距離は、チームの速度がどれほど不安定かを示しています。 時間が経つにつれて、これらの傾向は安定し、不確実性のコーンは減少します。
興味のある人がこの機能をいつ行うかを尋ねるとしますか？
これは、無期限の固定コンテンツの問題です。 パットは2つのトレンドラインを使用して応答します。 答えは4月または5月です。
興味のある人がパットに尋ねます：「クリスマスまでにどのくらい行われますか？」これは、不確かな内容を持つ期間限定の質問です。 トレンドラインは、実装する時間がある可能性のあるセグメントを垂直スケールでカットします。
「クリスマスまでにこれらの機能を作成できるようになりますか？」これは、固定の時間枠と固定されたコンテンツを持つ質問です。 トレンドに焦点を当てて、パットは「いいえ」と答えます。 追加：「クリスマスまでに、私たちは多くのことをする時間がありますが、この作業をすべて完了するには非常に多くの時間が必要です。」
通常、時間を増やすよりもプロジェクトの内容を減らす方が良いです。 コンテンツを減らすと、締め切りを延期する機会があります。 ここで何かをリリースし、残りは後でリリースできます。
製品の所有者は、週単位で計算を行い、経験的データのみを使用し、有効であることが望まれるものを提供しません。 彼は正直に不確実性について語っています。 チームは作業のペースを維持し、パットは彼らに圧力をかけず、強制的に加速させます。
いくつかのチーム
複数の製品所有者と複数のチームがあります。 モデルは同じです-帯域幅管理、利害関係者とのコミュニケーション、ユーザーストーリーの拒否に関する意思決定。 速度は、すべてのチームの速度の合計です。 予測は、一般的または各チームに対して行うことができます。 製品所有者には、他の製品所有者とのコミュニケーションという追加のタスクがあります。 依存関係を最小限に抑え、同期を確保するために、バックログの作業を整理する必要があります。 大規模プロジェクトでは、他の全員の同期を保つためにマスタープロダクトオーナー（CPO）が必要です。
全体像
ソース- アジャイル製品の所有権の概要
英語ビデオ
ロシア語のビデオ
続きを読む
11月2日-1年で最もITの日
出版サポート- エジソン 、 電子チケットシステムおよび商品とサービスの連邦カタログを開発する会社。
そして、これがEdisonがアジャイル製品を開発する方法です：