スクラムチームは、計画会議でインフラストラクチャタスクをどのように説明しますか？
スクラムチームは、計画会議での開発/インフラストラクチャタスクをどのように説明しますか？
一見、エンドユーザーに価値を提供しないため、ユーザーストーリーのようには見えません。
ただし、特定のユーザーストーリーにタスクとして添付しても意味がない場合があります。たとえば、タスクが「Bambooのセットアップ」であるとします。チームは手動でビルドおよびデプロイできるため、ユーザーストーリーを完了するためにそのタスクは必要ありません。したがって、ユーザーストーリーを完了するためにこのタスクは必要ないため、ユーザーストーリーに添付しても意味がありません。
したがって、これは、これらのタスクがユーザーストーリーになることを示唆しています。しかし、チームストーリーがそれらをポイントしている場合、プロダクトオーナーは一連のテクニカルユーザーストーリーが添付されたバックログではなく、バックログに対するベロシティを知りたいので、これは奇妙なベロシティを変更します。
それらは実際にはユーザーストーリーではありません。それらは利害関係者の物語です。ソフトウェアが実際にユーザーから直接支払われない限り、ストーリーが完全にユーザーの利益のために作成されることはまれです。
いくつか例を挙げます。
- 広告主がより効果的な広告を掲載できるキーワード付き記事
- CAPTCHAは、モデレーターが手動でスパムに対処する必要をなくすためにあります。
ほとんどのテクニカルストーリーは実際にはビジネス上のメリットをもたらしますが、ユーザーにとってめったにありません。別の方法でそれらを表現することは助けることができます。私は通常、Chris MattsのFeature Injectionテンプレートを使用します。
In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.
これにより、開発チームを含むあらゆる種類の利害関係者が明確に認識されます。これで、技術的なストーリーをフレーズにして、ビジネス上のメリットを強調できます。
In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.
私はこれについて2、3のブログ投稿を書きました： ユーザーストーリーではありません 、および 機能の注入とテクニカルストーリーの処理 。彼らが助けてくれることを願っています。
速度は、（ドラッグとは対照的に）有用な作業を行うチームの能力の尺度です。インフラストラクチャタスクは、間接的にではありますが、チームを長期的に効率化することにより、エンドユーザーに価値をもたらします。私はこれらのことをユーザーストーリー（この場合、ユーザーは開発チームです）として追跡し、適切に優先順位を付けることに問題はありません。顧客と良好なコミュニケーションをとっている製品所有者は、成果物を中断することなく、そのようなタスクがどこに当てはまるかを理解できるはずです。
徐々に実行してください。
利害関係者がそれを望まない場合は、それをストーリーにしないでください。少しずつ注意してください。たとえば、初めて手動でデプロイするとき。 2回目は、少し自動化します。 3回目は、もう少し自動化します。結局、あなたのビルドは最大の問題ではないので、何か他のことに集中します。
最初は、これらの開発者に焦点を当てたタスクがさらに多くなりますが、それは問題ありません。速度（ストーリーで測定）は低くなります。それは状況の正しい表現です。しかし、常にいくつかあるので、プロセスを改善するために必要なことを行う習慣をチームが得ることが重要です。
私見の理想的なアプローチは、インフラストラクチャの取り組みを、最初に価値をもたらすユーザーストーリーの下のタスクとして配置することです。あなたが言ったように。
あなたの例を取ってください。手動で構築および展開することは、それが継続的な取り組みであり、完了の形がないことを意味します。それは無期限に存在します。
同じことが、以前は手動で行われていた典型的なアプリケーションでの作業の一部を自動化するコードについても言えます。この取り組みをユーザーストーリーの下のタスクとして定義すると、完了と定義されます。これはまさにその性質上、エンドユーザーにとって価値があります。
あなたは確かにすべてのスプリントをアプリケーションを構築してデプロイすることができますが、それはバックログを介して正式に追跡されない日常のタスクの一部になり、これはすべてが問題になります。
ユーザーストーリーは、ユーザーの観点からビジネス価値を定義します。そのため、インフラストラクチャタスクは一般に「廃棄物」と見なされます。それは彼らが必要ではないという意味ではありません。つまり、より多くのインフラストラクチャタスクを実行すると、ビジネス価値が低下します。そのため、インフラストラクチャタスクはユーザーストーリーと見なしてはならず、ユーザーストーリーに添付するべきではありません。
計画会議では、チームは次のスプリント中に絶対に必要なインフラストラクチャタスクを検討する必要があります。コミットメントは、これらのインフラストラクチャタスクを念頭に置いて行われます。ベロシティはチームが提供できるビジネス価値を測定するため、チームのベロシティに影響します。これは正しい結果です。
ユーザーストーリーをエンドユーザーに価値を提供する必要があると見なすことはありません。一般的かもしれませんが、ユーザーストーリーの処理方法は異なります。これらの種類のタスクはスパイクと見なされる場合がありますが、他のユーザーストーリーと同様にポイント推定された通常のユーザーストーリーもありました。
私が見てきたことから、インフラストラクチャの多くは所定のものと見なされています。これには次のようなものが含まれます。
- 改訂管理システム;
- 自動ビルドシステム。
- IDEおよびその他の開発者ツール。
- 開発サーバー;
- 展開プロセス;そして
- プロジェクトのプロセスと標準。
私が使用したほとんどの方法論は、それらにあまり注意を払っていません。これらは私がリリース0と呼んでいるものです。これらは開発を始める前に準備しておく必要があります。ストーリーの作業を開始すると、これらの変更はプロセスの改善として追跡できます。
開発チームが情報を提供している場合でも、これらの項目のほとんどはプロジェクトサポートチームが処理する必要があります。これらの項目を複数のプロジェクトにわたって標準化することは、組織にとって大きな見返りがあるはずです。
以下を検討してください。
既存の製品スイートに主要な機能を追加するスクラムチーム。
エンジニアリングのベストプラクティスに基づいて最新の状態を維持するには、開発テクノロジー/ツール/ユーティリティをアップグレードする必要があります。
リリースの過程でSprintsの問題を解決できるように、この作業でリリースをフロントロードすることは理にかなっています。
企業はこれらのアイテムから間接的な価値を得ているので、透明性の観点から、これらはProduct Backlog Items（PBI）であることをお勧めします。
チームはこれらのアイテムのサイズを調整し、PBIと同じように扱います。
私にとってのこの問題は、他のよりビジネス中心のPBIの下にタスクとしてこの作業を隠す方法を理解しようとする時間を無駄にしたくないという事実に要約されます。
この種のインフラストラクチャの作業によってPBIサイジングがゆがめられたくありません。私は何が行われているのかを見て、私が何を支払っているのかを理解したいのです。
また、高品質のソリューションを提供するために必要なインフラストラクチャに投資することで、ビジネスが行っているコミットメントをチームに理解させることにも価値があると思います。
私たちのチームでは、次のことを行います。
- 低いフォーカス係数を想定します。
- 実際にそれらを実装する必要があるこのようなタスクをユーザーストーリーに含めるを試してください。
- 一部のタスクが完全に必要であるが、直接的なビジネス価値を提供しない場合（ユニットテストをあるフレームワークから別のフレームワークに移行するなど）、スプリントの最初に「継続的なタスク」のリストを作成する。これらはストーリーではない開発関連のタスクですが、開発チームはそれらを実行することを望んでいます。私たちは黒板にこれらのタスクをリストしますが、ストーリーとは別にします。スプリント中、毎日のミーティングで、それらを達成するために何が行われたかを確認します。
ステップ2が最も重要です。アジャイルプラクティスの場合と同様に、スクラムでは、タスクを達成するためにできる限り少ないことを試みます。不要な作業を行うことであなたの人生を無駄にしない方法としてそれを取りなさい：私の経験は「結局クールなもの」の50％ものものが結局見捨てられて維持されないままになることを示しています。
XP お勧め すべてのツールとインフラストラクチャがセットアップされている「反復ゼロ」を持つことを提案しています。これらの記事を書くことはオプションですが、おそらく良い考えです。インフラストラクチャをテストできること（増分ビルド、自動テストとデプロイ、通知など）は有益です