アジャイル開発では、ユーザーには見えないタスクをどのように説明しますか？
私は長年アジャイル環境で働いてきました。ただし、私がいつも不快に思っていることの1つは、各ストーリーをエンドユーザーの要求にマップする必要があるという考えです。つまり、アプリケーションを使用している人にはっきりと見える拡張機能です。
ただし、実際のソフトウェアエンジニアリングにおける作業の重要な部分は、舞台裏と内部で行われます。たとえば、あるORMまたはDBMSを別のORMに切り替える（結果として生じるコードの変更が必要になる）。または、より効率的なデータ構造とアルゴリズムを実装することにより、アプリケーションのパフォーマンスを向上させます。または、ハードコードされた大規模なifブロックをFactoryパターンで置き換えることにより、アプリケーションをよりスケーラブル/拡張可能にします。等々。
問題は通常、これらの問題をスプリント計画で取り上げると、製品/プロジェクトマネージャーは「技術的負債」と「リファクタリング」という用語を捨て、これらのことはスプリント計画の懸念事項であってはならないことを繰り返します。代わりに、ユーザーが要求した変更のみに集中する必要があります。
私が上で述べたことの多くは「技術的負債」に分類できることを認めます。しかし、私の経験では、こうして分類されたものはブラックホールに入り、終わりのないユーザーリクエストの急流の中で忘れられてしまいます。
それでは、これにどのように対処しますか？どうすればこの専制政治から解放されますか？エンドユーザーにすぐに表示されるものを中心にしていないアジャイルでストーリーを作成する正当な方法はありますか？もしそうなら、これらをどのように「語る」のか？
私が取り組んできたチームでは、そのための特別な人物、The Developerを常に作成しています。このように、ある時点でストーリーを使用するアイデンティティがあります。
たとえば、現在のスプリントには、データベースの移行に関連するストーリーがあります。 「開発者として、データベースを現在のサーバーから新しいサーバーに移動して、アプリケーションのパフォーマンスを向上させたいと考えています。」
「真の」アジャイルではありませんが、私がこの方法で大成功を収めました。これは、物事を私たちが取り組むことができるものとして呼び、技術的な負債のブラックホールを回避するためです。さらに、利害関係者にビジネス上の利益をもたらします。彼らは今、この仕事をすることの利点が何であるかを技術的でない用語で理解しています。
ストーリーは常にエンドユーザーに関連している必要はありません。例えば
会計士として、より安価なデータベースソリューションに切り替えたい
さらに、パフォーマンスやその他の技術的な問題は確かにエンドユーザーに関連している可能性があります。
ユーザーとして、90％のケースで2秒未満で操作を実行したいと考えています。
または
ユーザーとして、9000人のユーザーが接続していてもシステムに接続できるようにしたいと考えています。
確かに、「開発者ユーザー」を使うには Adam Wellsの答え も適切な場合があります。
技術的な負債とリファクタリングは他のストーリーに何度もバンドルされる可能性があります。結局のところ、これらはほとんどが実装の詳細であり、POだけでなくエンドユーザーからも見えません。