スクラムでは、開発環境のセットアップや機能開発などのタスクを実際のユーザーストーリー内のサブタスクとして管理する必要がありますか？
プロジェクトでは、次のようなタスクに時間を費やす必要がある場合があります。
- 代替フレームワークとツールの探索
- プロジェクト用に選択されたフレームワークとツールを学ぶ
- サーバーとプロジェクトインフラストラクチャのセットアップ（バージョン管理、ビルド環境、データベースなど）
ユーザーストーリーを使用している場合、この作業はどこに行ったらよいでしょうか。
1つのオプションは、それらすべてを最初のユーザーストーリーの一部にすることです（アプリケーションのホームページを作成するなど）。別のオプションは、これらのタスクを急増させることです。 3番目のオプションは、ユーザーストーリーではなく、タスクを Issue / Impediment （たとえば、まだ開発環境が選択されていない）の一部にすることです。
昨年、この問題についてかなり考えました。
基本的なフレームワークはプロジェクトの開始前に存在する必要があることに同意しますが、実際には、プロジェクト自体の一部にすることもできます。どういうわけか管理する必要があります。
プロジェクトセットアップとユーザーストーリーを混合することには意味があるかもしれませんが、製品のバックログに追加してユーザーストーリーと同じ注意を引くことができる単純なtasksで解決する場合があります。これらの技術的なタスクが必要になることもありますが、いずれにしても正当化する必要があります。チームが特定の目標を達成するには絶対に必要であると考える場合、それらはスプリントの一部になります。
何があなたに最適かを言うのは難しいので、実験！今のところスパイクで十分かもしれませんが、後で同じ問題が発生すると思いますので、事前に計画してください。実行タスクこれは、そのようなアクティビティのプレースホルダーです。ストーリー2からタスクを分離するために、自分の経験に基づいてタスクをすばやく比較します。
Task：タスクは技術的に必要です。これは、コミット用のリポジトリーのセットアップや、今まで見た中で最もホットなコード・レビュー・ツールの開発プロセスへの追加など、構成管理または一般的なプロジェクトのセットアップに関するものです。タスクは、ユーザーストーリーと同様に、計画で検討する必要があります。最新かつ最高のコードレビューツールを使用することで、長期にわたるペアプログラミングセッションや対面のコードレビューを排除することで、パフォーマンスが向上し、チームのコミュニケーションが向上することをチームが製品所有者に納得させることができれば、製品所有者の注意を引くことができます。
ストーリー：ビジネスの視点のみに焦点を当て、ストーリーは常にお客様に目に見える価値を生み出します。内部品質は、ビジネス価値を生み出すことに伴うものです。
ストーリーポイントをタスクに割り当て、ストーリーと同じように作業することもあります。
最後に私はこの解決策をとりますあなたの場合（一般的にも適用できます）：
- 「セットアップ」と技術的なものをタスク（製品の所有者にビジネス価値を直接生み出さないもの）に分離します。
- プロジェクトのセットアップの前にスパイクを実行して、最も重要なツール（SCM、開発ツール、プロセス定義、コーディング標準など）を導入することができます。
- これらのタスクがプロジェクトの期間中にポップアップ表示されることを受け入れ、ストーリー以外の別の「タイプ」のアクティビティを用意して、この計画を立てます。
あなたの会社で最も意味のあることをしてください。他の人が物事をどのように行っているかを常識の妨げにしないでください。
しかし、これらのタスクはすべて、開発を開始するずっと前に起こるはずのように聞こえます。だから私はスクラムがこれらのタスクにさえ関係があるかどうか疑問に思う。ソース管理やデータベースには継続的なメンテナンスなどがいくつかありますが、これらはスケジュールされるべきではなく、発生してあなたの速度に影響を与えるものでなければなりません。
プロジェクト中にフレームワークなどを選択する必要がある場合がありますが、私が言うには、.NETのようなフレームワークではなく、nHibernateのようなフレームワークを指します。それらの場合、かなり短いことは言うまでもなく、研究は急上昇し、タイムボックス化されるべきです。数日間開発者が病気であるかのように管理してください。
知識の伝達は、一般的な開発速度以外で管理されるべきもう1つの進行中のプロセスです。
プロジェクトの「正式な」開始前に、できるだけ多くの設計決定を前もって行うための名前があります。それは滝と呼ばれています。 「開発者はフレームワークを選択する必要があるので、Webサイトの出発点はあります」などのユーザーストーリーに問題はありません。それが大きすぎてイテレーションに収まらない場合は、「開発者として、Drupalに基本的なホームページを実装する必要があるので、ニーズに合うかどうかを知ることができます」のように分解してみてください。
1つのオプションは、それらすべてを最初のユーザーストーリーの一部にすることです。申し込み用ホームページを作成します。
「ユーザーストーリー」をコンセプトとして破る。これにはどのユーザーが関与していますか？なし。これは、あなたがすでに行っているはずの作業です。
別のオプションは、これを急上昇させることです。
悪くない。
3番目のオプションは、ユーザーストーリーではなく課題を課題（たとえば、まだ開発環境が選択されていない）にすることです。
計画とオーバーヘッドに関する限り、スパイクとほぼ同じです。
設定はnotユーザーストーリーです。
それはあなたがこのプロジェクトを始める前にあなたがすべきを持っているものです。
フレームワーク/ツールとサーバーをセットアップして準備ができていない限り、プロジェクトを実際に開始することはできません。
after契約が署名されるまで、多くの組織が実際には存在しないことはよく知っています。 後契約が締結されるまで、多くの組織がテクノロジーを選択しないこともよく知っています。これらはすべて、ユーザーストーリーの外にある非効率的なものです。
職場では、環境を準備するためのタスクを使用します。混乱するかもしれませんが、私たちが使用するタスクは、ユーザーストーリーのタスクとほとんど同じです。タスクはユーザーストーリーに属していませんが、数時間で見積もられ、特定のスプリントで完了するには製品の所有者の同意が必要です。
また、「明らかな」ビジネス上の価値はないが、特に大規模なコードベースを使用する既存の製品の場合、製品に品質を追加する建築作業にもタスクを使用します。
これらはあなたの職場環境には当てはまらないかもしれませんが、私たちにとってはうまくいきました。
あなたは2つの独立したものを混ぜていると思います。ユーザーストーリーには、技術的な詳細を含めないでください。
フレームワークの選択、リポジトリとサーバーの設定、およびその他のタスクは、最初の反復に入る必要があります。
私は最近スクラムコースを受講し、インストラクターはSprintと呼ばれる特別なスプリントを使用してこれらの種類の問題を正確に解決することを提案しました。コースにはさまざまな程度のスクラムの経験を持つ人々がいて、経験豊富な人々のほとんどが同じことをしたと言って同意しました。場合によっては、企業はSprint 0を使用してプロジェクトを評価し、それが実現可能かどうかを判断しました。
私のようなスクラム方法論に不慣れな人にとっては、ユーザーストーリーやユーザーフィードバックなどの通常のスプリントの他のすべての側面から解放されるため、素晴らしいソリューションのように見えます。
スプリント0は他のスプリントと同じ時間の長さなので、後でいつでも調整できるため、セットアップに時間をかけすぎないようにする方法として機能します。主なポイントは、実際に製品の開発を開始できる状態にすることです。
2-3の代替フレームワーク/ツールの探索
これは、特別な要件がある場合に発生する可能性があり、要件を解決するための最適なツールを選択するためにPOCを実行する必要があります。スパイクの目的は、どのフレームワークを使用するかを知らなければ、ストーリーを推定できず、推定せずにストアを計画してタスクに分割できないためです。
次に、プロジェクトに選択したフレームワークを学習します
上手。これはかなり危険です。顧客がソフトウェアの代金を支払うとき、彼はあなたがすでに彼のツールの使い方を知っている専門家であることを期待しています。顧客は、学習または試用/失敗の開発アプローチに対して料金を支払いません。新しいツールを彼の自由時間または特別に割り当てられた時間彼の従業員が支払うで学ぶのは顧客ではなく、開発者の責任です。顧客に知らせずに学習のために顧客のお金を使うことは専門家ではありません。
実際に使用したことがない特別なもの（たとえば、顧客のAPIやツールの顧客が選択したもの）を本当に使用する必要がある場合は、APIの使用方法を学ぶのに必要な時間までに価格が上がることを顧客に通知する必要があります。値上げが大きすぎると、顧客は気が変わってしまうかもしれません。
もちろん、何度も使用したフレームワークで特定の新しい問題を探す必要があるという意味ではありません。学習に（プロジェクトの外で）かなりの時間を費やすことなく、新しいAPIまたはフレームワークの使用を開始する状況を意味します。
これに違反すると、反復ごとに非常に少量のビジネス価値しか得られないため、とにかく速度に表示されます。お客様が理由を知らない場合は、おそらくプロジェクトをキャンセルします。
これは、内部プロジェクトの場合でも引き続き有効です。新しいAPIまたはツールの学習に必要な時間について、マネージャーまたはビジネスに通知する必要があります。マネージャーがあなたの通常の生産性を考慮に入れ、あなたの生産性があなたの仕事の間に学ぼうとしている新しいAPIのためにほんの一部であるなら、それは通常非常に悪い結果をもたらします。一部の販売担当者が顧客との契約に署名したときに通常の生産性で計算した場合、それは明らかにさらに悪いことです。
サーバーのセットアップ（SVN、データベースなど）
それがインフラストラクチャと内部コストです。プロジェクトを開始すると、インフラストラクチャの準備が整っていることが期待されます。開発環境のセットアップは顧客にとって価値がなく、プロジェクト関連のインジケーター（スクラムの速度など）の一部であってはなりません。これは、環境のセットアップ、基本的なインフラストラクチャの作成などにのみ使用される特別なプロジェクト前の反復として実装されているのを見ました。