SCRUMは、1人だけのプロジェクトで使用する必要がありますか？

当社では、3つの異なるプロジェクトに同時に取り組んでいるチームがあります。通常、各プロジェクトに関係するのは1人か2人だけです。プロジェクトの作業には、多くの場合、新技術の習得やバグの解決が含まれますが、どちらも推定が非常に難しいタスクにつながります。この状況では、管理者は引き続きSCRUMの使用を主張し、予期しない状況のためにスプリントの最後に安全バッファーを割り当てることはできません。スタンドアップミーティングはチーム全体で行われますが、ほとんどの人は無関係のソフトウェアコンポーネントや異なるソフトウェアプロジェクトを一緒に作業します。

• 単一の開発者とファジータスクを含むプロジェクトでSCRUMがうまく機能しているのを誰かが見たのではないかと思いますが、プロセスをどのようにうまく機能させましたか？

• 新しいテクノロジーの研究/マスタリングに関連するタスクを推定する方法（これには、新しいプログラミング言語、プラットフォーム、および開発ツールの学習が含まれます）

• 特定のプロジェクトにSCRUMを使用しないように経営陣を説得することに成功した人はいますか？

ありがとう！

「パーソナルスクラム」を参照してください。これを実行している人々のブログ投稿を2、3回見ました。フルスクラムには、独身チームに完全に変換されない概念があります。（私の経験-約4人の特定の「クリティカルマス」は、チームスタッフをうまく機能させるようです。）

http://blog.jgpruitt.com/tag/personal-scrum/など。

ただし、タスクリストが「保護」されているタスクの見積もり、速度、時間制限スプリントなどは、1でもうまく機能します。

もちろん違います。毎日のスクラムは非常に短く、非常に退屈です！

あなたがあなたを助けるだろうと思うビットをチェリーピックすることができます、しかし、あなたはそれらを完全に記入する必要はありませんが、カードは理にかなっています。設定した時間の経過後に進捗を確認するために停止することも理にかなっています。しかし、それをしている場合は、かんばん、Crystal、およびその他のすべてのアジャイルメソッドもチェックしてください。

いいえ、チームなしでスクラムを行うことはできません。SCRUMで定義されているチームは、SCRUMで重要な役割を担っている「製品を開発するために自身を管理する責任を負う複数の機能を備えたグループ」です。

http://www.scrum.org/storage/scrumguides/Scrum_Guide%202011.pdfによると

開発チームのサイズ 最適な開発チームのサイズは、敏remain性を保つのに十分なほど小さく、重要な作業を完了するのに十分な大きさです。開発チームのメンバーが3人未満の場合、相互作用が減り、生産性の向上が小さくなります。小規模な開発チームは、スプリント中にスキルの制約に遭遇する可能性があり、開発チームがリリース可能な増分を提供できない可能性があります。メンバーが9人を超えると、調整が必要になります。大規模な開発チームは、経験的なプロセスを管理するには複雑すぎます。製品所有者とスクラムマスターの役割は、スプリントバックログの作業も実行していない限り、このカウントには含まれません。

ただし、アジャイルであり、製品/スプリントバックログの維持、スプリント/イテレーションの下での計画と作業、すべての利害関係者からのレビューとフィードバックの取得、再計画など、SCRUMの他の特性を使用できます。ここで説明されているように、スクラムの詳細については、こちらをご覧ください。

私は同様の店で働いています。ここで他の人が述べたように、あなたが説明するのはアジャイルかもしれませんが、スクラムではありません。また、バックログとスプリントが理にかなっているかどうかは、それが新しい作業であるか、メンテナンスであり、継続的なサポートであるかによって異なります。前者の場合、ウォーターフォールアプローチは1人のチームにとってより意味があります。そうでない場合、PMの観点からは、彼らのポートフォリオに複数のプロジェクトがある場合、彼らがしていることは良いアプローチのように思えます。

アジャイル愛好家にとって、滝の使用に関する単なる言及は、犠牲です。しかし、人々は常識を使う必要があります。

私の最近のプロジェクトの例を挙げましょう。私は3つの開発者からなるチームを率いて、5か月間の積極的なスケジュールで2つの主要なWebサイトを再設計しました。毎日のスタンドアップミーティングがありました。しかし、それは小さなチームであり、ライフサイクルが限られていて、開発者は全員、立ち上げまでプロジェクトにコミットした短期の請負業者であったため、ウォーターフォールプロジェクトでした。このプロジェクトは、非常に伝統的な滝のライフサイクルに従いました。絶対に悪いことではありません。「アジャイル」な方法で作業した以外は、スタンドアップミーティングを維持し、アジャイル開発のベストプラクティスを維持しました。私たちの小さなチームは、大きなチームの毎週のスプリント計画会議から除外されました。どうして？毎週の展開がなかったからです。そして、私たちのチームは、他のチームが行っている作業に依存したり、影響を与えたりしませんでした。実際、私たちはほとんど自律的に作業しました。Webサイトの立ち上げ後、継続的なメンテナンスとサポートのためのアジャイルプロセスに移行しました。他の開発者は現在どこかで作業しています。すべての機能強化は、定期的な展開に従って計画されます。

重要なのは、各プロジェクトのサイズ、複雑さ、および成熟度にとって最も意味のあるプロセスを使用することです。多くの研究を行っている場合、今後5か月間を予測するのは難しいので、アジャイルはおそらくウォーターフォールよりも優れたアプローチです。

問題の一部は、次の5つのスプリントを事前に計画できると考える人がいるように見えることです。それは以前私にも当てはまりました。あなたがそうならあなたはスプリントを持っているという全体の目的を破っているので、3つ以上のスプリントを計画するべきではありません。スプリントは、設定された時間内に現実的な量の強化を提供することを約束することになっています。よくわからないことにコミットしてはいけません。スプリント計画は本質的に短期計画ですが、それは一種のポイントです。長期的なスケジュールがある場合は、物事をより小さな成果物に分解することを検討してください。または、SDLCのどこにいるかに基づいてチェックポイント会議をセットアップします。

スプリント計画は、特定の時間枠内に完了することが保証されるものについての現実的なコミットメントであると想定されています。計画が未知の変数を考慮していないことがわかった場合は、おそらく範囲または悲観的な推定値の提供を開始する必要があります。または、他の提案として、ストーリーポイントを使用します。スプリントは、スリッページやその他の重要なタスクを考慮して、完全に予約されるべきではありません。

あなたのチームに一人だけがいるべきではなく、実際にそこにいるとは思えません。SCRUMの「チーム」は開発者だけではありません。あなたは顧客担当者、スクラムマスター、開発者などですか？あなたは本当にこの製品に関連して何かをしたり、それについて決断したり、販売しようとする唯一の人ですか？

研究の見積もりについては、ストーリーとしてそれを行います。「Research XXX」専用のストーリーを作成し、ストーリーポイントを与えます（ここでは時間を見積もるのではなく、難易度を上げます）。また、テクノロジーを研究する必要がある場合でも、いくつかの機能を実装する難しさをかなり適切に推定できるはずです。後者の事実は、単に物語を「最大の難易度」に変えることもあります。

いいえ、スタンドアローンとしてすべての開発者と会うべきではありません。チームと会う必要がありますが、これも開発者だけではありません。

がんばろう。皆さんに理解していただければ幸いです。

製品所有者とスクラムマスターがいると仮定すると（そうでない場合はスクラムではありません）、スクラムは1人のチームで機能します。スクラムアーティファクト（バックログ、バードダウンチャート）は、多人数チームで使用されるのと同じように使用されます。ミーティングについて：

毎日のスタンドアップ：毎日のスタンドアップを使用して、製品所有者、スクラムマスター、または進捗状況に関心のある他のすべての人を更新します。スクラムマスターは、この会議を使用して、あなたが持っている障害について学習します。プロダクトオーナーは、必要に応じて/必要に応じて、スコープの再検討を支援できます。

スプリントレビュー：各スプリントの終わりに、ソフトウェアの作業増分を製品所有者またはクライアントに引き渡します。スプリントの目標が「何か」を学ぶことだった場合、管理者（つまり、一般的にPoCのクライアント）が使用できるPoCを実証します。