スクラムでは、開発環境のセットアップや機能開発などのタスクを実際のユーザーストーリー内のサブタスクとして管理する必要がありますか？

プロジェクトでは、次のようなタスクに時間を費やす必要がある場合があります。

1. 代替のフレームワークとツールの調査
2. プロジェクト用に選択されたフレームワークとツールの学習
3. サーバーとプロジェクトインフラストラクチャ（バージョン管理、ビルド環境、データベースなど）のセットアップ

ユーザーストーリーを使用している場合、この作業はどこに行けばいいですか？

1つのオプションは、それらすべてを最初のユーザーストーリーの一部にすることです（たとえば、アプリケーションのホームページを作成します）。別のオプションは、これらのタスクを急増させることです。3番目のオプションは、タスクをユーザーストーリーではなく問題 / 障害（たとえば、まだ選択されていない開発環境）の一部にすることです。

過去1年間、この問題についてかなり考えました。

プロジェクトを開始する前に基本的なフレームワークが存在する必要があることに同意しますが、実際の使用では、プロジェクト自体の一部にすることができます。なんとかして管理する必要があります。

プロジェクトのセットアップとユーザーストーリーを混合することは理にかなっている場合がありますが、製品バックログに追加してユーザーストーリーと同じ注意を引くことができる簡単なタスクに決着がつくことがあります。これらの技術的なタスクが時々必要であることは知っていますが、いずれにしても正当化されなければなりません。チームが特定の目標を達成するために絶対に必要であると考える場合、彼らはスプリントの一部になります。

あなたに最適なものを言うのは難しいので、実験してください！現時点ではスパイクで十分かもしれませんが、後で同じ問題が発生することになるので、事前に計画してください。やるタスクのような活動のためのプレースホルダです。ストーリー2からタスクを分離するために、経験に基づいてタスクをすばやく比較します。

タスク：タスクは技術的に必要です。コミット用のリポジトリの設定や、これまで見た中で最もホットなコードレビューツールの開発プロセスへの追加など、構成管理や一般的なプロジェクトのセットアップに使用できます。タスクは、ユーザーストーリーと同じように計画で考慮する必要があります。チームがプロダクトオーナーに、最新かつ最高のコードレビューツールを使用するとパフォーマンスが向上し、長期にわたるペアプログラミングセッションまたは対面のコードレビューがなくなることでチームのコミュニケーションが向上すると納得できれば、プロダクトオーナーの注意を引くことができます。

ストーリー：ビジネスの観点のみに焦点を当て、ストーリーは常に顧客に目に見える価値をもたらします。内部品質は、ビジネス価値を生み出すことに付随するものです。

ストーリーポイントをタスクに割り当て、ストーリーで行うのと同じように作業することもあります。

最後に、私はあなたのケースでこのソリューションを選びます（一般的にも適用できます）：

1. 「セットアップ」と技術的なものをタスク（製品所有者に直接ビジネス価値をもたらさないもの）に分けます。
2. プロジェクトのセットアップの前にスパイクを行って、最も重要なツール（SCM、開発ツール、プロセス定義、コーディング標準など）を導入することもできます。
3. これらのタスクがプロジェクトの期間中にポップアップすることを受け入れ、ストーリー以外のアクティビティの別個の「タイプ」を持つことでこれを計画します。

あなたの会社で最も意味のあることをしてください。他の人がどのように物事を行うかを常識の妨げにしないでください。

しかし、これらのタスクはすべて、開発を開始するずっと前に発生するはずの何かのように聞こえます。だから私はスクラムがこれらのタスクに関連しているのかどうか疑問に思う。継続的なメンテナンスなどがソース管理やデータベースに対して行われますが、これらはスケジュールされるべきではなく、ただ発生して速度に影響を与えるものでなければなりません。

プロジェクト中にフレームワークなどを選択する必要がある場合もありますが、私が言うには、.NETのようなフレームワークではなく、nHibernateのようなフレームワークを意味します。そのような場合、かなり短いことは言うまでもなく、調査を急ぎ、時間枠を設ける必要があります。開発者が数日間病気であるかのように管理してみてください。

知識の伝達は、一般的な開発速度とは別に管理する必要がある別の進行中のプロセスです。

プロジェクトを「公式」に開始する前に、できるだけ多くの設計決定を事前に下すための名前があります。滝と呼ばれます。「開発者として、フレームワークを選択する必要があるので、Webサイトの出発点があります」などのユーザーストーリーに問題はありません。それが大きすぎて反復に収まらない場合は、「開発者として、Drupalに基本的なホームページを実装する必要があるので、ニーズに合っているかどうかを確認します」のように分解してみてください。

1つのオプションは、それらをすべて最初のユーザーストーリーの一部にすることです。たとえば、アプリケーションのホームページを作成します。

「ユーザーストーリー」を概念として破ります。どのユーザーがこれに関与していますか？なし。これは、あなたがすでにやるべき仕事です。

別のオプションは、このためのスパイクを行うことです。

悪くない。

3番目のオプションは、タスクをユーザーストーリーではなく、課題（たとえば、開発環境がまだ選択されていない）の一部にすることです。

計画とオーバーヘッドに関する限り、スパイクとほぼ同じです。

セットアップはユーザーストーリーではありません。

このプロジェクトを開始する前に、適切に準備しておく必要があります。

フレームワーク/ツールとサーバーをセットアップして準備が整っていない限り、プロジェクトを実際に開始することはできません。

私は、多くの企業が実際にまで存在していないことを十分承知した後に契約が締結されます。私はまた、多くの企業が技術までを選択しないことを十分承知した後に契約が締結されます。これらはすべて、ユーザーストーリーの外側にある非効率的なものです。

職場では、環境を準備するタスクを使用します。一部の人にとっては混乱を招くかもしれませんが、使用するタスクはユーザーストーリーのタスクとほとんど同じです。タスクはユーザーストーリーに属していませんが、数時間で推定され、特定のスプリントで完了するには製品所有者の同意が必要です。

また、「見かけの」ビジネス価値はないが、特にコードベースが大きい既存の製品の品質を製品に追加する、建築作業のタスクを使用します。

これらはあなたの職場環境には当てはまらないかもしれませんが、私たちにとってはうまくいきました。

あなたは2つの独立したものを混ぜていると思います。ユーザーストーリーに技術的な詳細を含めないでください。

フレームワークの選択、リポジトリとサーバーのセットアップ、およびその他のタスクは、最初のイテレーションに入る必要があります。

私は最近スクラムコースに参加しましたが、インストラクターは、このような問題を正確に解決するためにSprint 0という特別なスプリントを使用することを提案しました。コースにはスクラムのさまざまな程度の経験を持つ人々がいましたが、ほとんどすべての経験のある人々が同意し、同じことをしたと言いました。場合によっては、企業はスプリント0を使用してプロジェクトを評価し、実行可能かどうかを決定しました。

私のようなスクラムの方法論に慣れていない人にとっては、ユーザーストーリーや、ユーザーフィードバックなどの通常のスプリントの他のすべての側面から解放されるため、素晴らしいソリューションのように思えます。

スプリント0は他のスプリントと同じ時間であるため、後で調整できるため、セットアップに時間をかけすぎないようにする方法として機能します。主なポイントは、実際に製品の開発を開始できる状態にすることです。

2-3の代替フレームワーク/ツールの探索

これは、特別な要件がある場合に発生することがあり、POCを実行して要件を解決するための最適なツールを選択する必要があります。これは、どのフレームワークを使用するかを知らないと、おそらくストーリーを推定できず、推定なしでストアを計画してタスクに分割できないため、スパイクの理由です。

次に、プロジェクト用に選択したフレームワークを学習します

まあ。これは非常に危険です。顧客がSWに対してあなたに支払いをするとき、彼はあなたが彼のツールの使い方をすでに知っている専門家であることを期待しています。顧客は、学習またはトライアル/失敗した開発アプローチに対して料金を支払うことはありません。空き時間、または顧客ではなく従業員が支払う特別な時間に新しいツールを習得するのは開発者の責任です。顧客に通知せずに学習のために顧客のお金を使うことは専門的ではありません。

APIの使用方法を学習するために必要な時間によって価格が上昇することを顧客に通知する必要がある前に使用したことのない特別なもの（たとえば、顧客のAPIまたは選択したツール顧客）を本当に使用する必要がある場合 価格の上昇が大きすぎる場合、顧客は考えを変えるかもしれません。

もちろん、フレームワークで何度も使用した特定の新しい問題を探す必要があるという意味ではありません。学習にかなりの時間（プロジェクト外）を費やすことなく、新しいAPIまたはフレームワークの使用を開始する状況を意味します。

これに違反した場合、イテレーションごとに非常に少量のビジネス価値を提供するため、とにかく速度に表示されます。お客様が理由を認識していない場合、おそらくプロジェクトをキャンセルします。

これは、内部プロジェクトの場合でも有効です。新しいAPIまたはツールを学習するのに必要な時間をマネージャー/ビジネスに通知する必要があります。通常、マネージャーが通常の生産性を重視し、タスク中に学習しようとしている新しいAPIのために生産性がほんのわずかである場合、非常に悪い結果をもたらします。一部の販売担当者が顧客との契約に署名したときに通常の生産性で計算した場合、それは明らかにさらに悪化します。

サーバー（SVN、データベースなど）のセットアップ時

それがインフラストラクチャと内部コストです。プロジェクトを開始するときは、インフラストラクチャを準備しておく必要があります。開発環境をセットアップすることは、顧客にとって価値がなく、プロジェクト関連の指標（たとえば、スクラムの速度）の一部であってはなりません。これは、環境のセットアップ、基本的なインフラストラクチャの作成などに使用される特別なプロジェクト前の反復として実装されているのを見ました。