私たちはソフトウェア開発会社です。スクラムを導入しました。
問題は、開発者が他の多くの企業のようにスクラム スプリントにフルタイムを費やすことができないことです。彼らは、SCRUM プロジェクトのタスクのうち、多くの非開発を行わなければなりません!
私はそれを読みました：スクラムはパートタイムの開発者を許可していません
それで、これについてあなたの経験は何ですか？
スクラムは、SCRUM スプリントに焦点を当てた開発タスクにのみ時間を費やす開発者がいるチームにのみ適した方法ですか?
御時間ありがとうございます
私はこれも問題となる会社で働いています。スクラムを使用しようとしていますが、次の問題があります。
これらすべての問題があるため、本でスクラムを行うことは不可能です。チームの人数が常に変化する場合、各スプリントの速度は基本的に無意味です。
それでも私はあなたがいくつかの利益を得ることに気づきました：
したがって、私の提案はスクラムに行くことです。私の会社のように、経営陣や開発者が短いサイクルなどのメリットを実感し始めると、スプリントタスクではないと見なされる作業の多くが結局スプリントタスクになるように変更を加え始めます。 。ですから、スクラムをやろうとすることの利点は今でも見られます。一部の本がどれほど難しいと主張しても、とにかくスクラムを行うための100％正しい方法はありません。
各開発者がスプリント コンテンツのみに取り組むことができる時間の比率であるフォーカス ファクターを定義します。このフォーカス ファクターは、スプリント アイテム (電子メール、サポート、会議など) に取り組めない時間を説明します。
スプリント計画では、そのフォーカス ファクターに従って達成できることだけを計画します。チームが 80% で 600 時間ある場合、480 時間だけを計画します。
初期値は、任意に、または前のスプリントで達成されたものに基づいて決定できます。60 日が計画され、45 日が完了した場合、75% のフォーカス ファクターが得られます。
次に、時間管理がすべてです。スクラム以外のタスクが中断されない場合は、それらを同時に実行することをお勧めします (たとえば、金曜日には、チームのすべてのメンバーがスプリント タスクではなく、これらの他のタスクに取り組みます)。
このフォーカス ファクターは、チームのすべてのメンバーで同一である必要はありません。これにより、チームにパートタイムのメンバーを持つこともできます。
私たちのチームには、スプリントに含まれるサポートタスクがあります。スプリントごとに、各製品に必要と思われるサポート時間を見積もり、それらをスプリントのタスクとして追加します。そうすれば、サポートの需要が予想よりもはるかに高くない限り、スプリントは影響を受けません（もちろん、これは今後のスプリントでのサポートのために予約された時間に影響を与える可能性があります）。
スクラムには多くのアプローチがありますが、正直なところ、「純粋な」スクラムを行う会社は1社も見たことがありません。あなたがあなたのスクラムをうまく組織することができるならば、あなたはこれから利益を得るかもしれません。しかし、なぜプロセスをスクラムに変更したいのかを考える必要があります。それは無意味です。
スクラムを試して、それが価値があるかどうかを確認する必要があると思います。
私は SCRUM で最大のマイレージを持っているわけではありませんが、一般的なルールとして、SCRUM がうまく機能していない場合、それは通常、スプリントが集中しすぎていて、チームがスプリントの範囲を超えた多くのタスク (責任) を抱えていることが原因です。考慮されていないこと。そのため、これらのタスクは、スクラム内のチームによって厄介なものとして認識され、スクラムは、外部に残されている人々によって厄介なものとして認識されます。
私たちはまだ SCRUM をすべて試したわけではありませんが、実装できる多くの方法についてここでいくつかの経験をしました。最良の結果は、チームに多くの部門 (テスト、QA、実装、開発、アーキテクチャ、マーケティング) の人々が含まれていたときでした。これは、これらの人がチームでフルタイムではないことを意味しますが、現在のプロジェクトの範囲内でタスクが割り当てられているという事実は、通常、そのために時間を費やすことをいとわないことを意味します。
次の最大の利点は、疑似的ではあるが重要なサポート開発など、未知のもののためにバッファ時間を確保できることです。これらが発生すると、小さなチームが形成され、問題に対処するためにメインスクラムから一時的にスピンオフします。
最後に、インストール、構成などはスクラムの一部であり、スクラムと一緒に集計されます。
私が次に試みるもう 1 つのアプローチは、アイデアを拡張して、1 つのスクラムですべてをルール化するアプローチの代わりに、特定のニーズごとに小規模なチームを配置することです。これに関する現時点での主な問題は、スクラム マスターの役割を引き受けることができる人が多くないことです。
より一般的な注意として、ここでは SCRUM を使用しましたが、本に基づいて適用することは決してありません。私は、これらの手法とアプローチをアイデアのバケツと考えており、そこから引き出して実験し、私たちのニーズに可能な限り最適なものを見つけます. ただし、この実験を機能させるには、場合によっては破壊的に実行する必要があります (スクラムを行いますが、スクラムを行うことを形式化することはありません)。彼らを和らげて新しいアプローチを採用し、私たちが常に直面している固有の変化への抵抗をより簡単に切り抜けるには、それが最善の方法だと思います。
これまでのところ、これを行うことで、ワークフローはスクラム-XP-アジャイル-TDD タイプに自然に進化し、彼らが侵入している恐ろしいカスケードをゆっくりと回避するようになります。フェンスの私の側:-)
効率性は、スプリントに含まれるタスクに集中できることから生まれます。これは、別の開発モデルで回避できるものではありません。しかし、サポート、トレーニング、技術的なプリセールスなど、「他のタスク」が開発者に割り当てられていることは依然として現実です。
サポートは、ほとんどの場所で本質的に計画不可能です。トレーニングとプリセールスは、「X 氏が顧客と N 日間過ごす」のように、多少時間制限が設けられる傾向があります。
開発者を 2 つ以上のチームに分けることをお勧めします。チーム間のこのスプリント サイクル中にサポートを受けるタスクがあります。そのチームは、達成できないことを許容できるタスクのみを持つべきです。他のチームを妨害することなく、サポートの問題を解決するために最善を尽くす必要があります。
これで良い結果が得られました。
説明されている管理者は、実際にはスクラムを使用していないようです。1 週間程度の非常に短いスプリントをお勧めします。そのため、営業担当者または経営陣が中断したい場合はいつでも、1 週間もかからない次のスプリントに向けて、彼らが自分の仕事をやり遂げるのを待つことができるかどうか試してみてください。スクラムは、開発者が単独で行うものであってはなりません。顧客に至るまでのチェーン全体に存在する必要があります。
スクラムがパートタイマーを許可しない方法がわかりませんか？私は多くのスクラムチームに所属しており、ほとんどの場合、フルタイムではないリソースを持っています。または、いくつかのプロジェクトに分割されたリソースがあります。これは、開発者にプロジェクトに指定された時間を費やしてもらうことで管理し、その割り当てられた時間を中心に計画します。ほとんどのアジャイルプロジェクト管理ソリューションでは、このスタイルのリソース管理が可能です。
私が働いている場所では、開発者がサポート リクエストのような理由でプロジェクトから引き離されたり、チーム リーダーが他のプロジェクトについて会議を開いたりすることがあります。現在、スプリントに貢献しています。
本当に良い質問です。ほとんどすべての論文、記事、本などで、「すべてのメンバーはフルタイムでなければならない」という声明を見てきました。私はスクラムに赤を持っていますが、なぜそうしなければならないのかについての議論は見たことがありません。大規模な組織では、他に何もしない開発者がいると思いますが、小規模な組織では、スプリントに 100% コミットできない開発者がいることが非常に一般的であり、スクラムは小さなチーム向けに設計されています! フォーカス係数は、これを他のものと同じように処理できる必要があります。