私はいくつかのオープンソースソフトウェアを開発するための個人的なプロジェクトを始めています。これのPMプロセスとしてスクラムを使用したい（製品バックログ、優先順位付け、およびそれらを取得できる場合はバーンダウンが好きなので）が、取得できないため、完全な値を取得できないようです。最初に、私と私の協力者が特定のスプリント中に作業にコミットできる時間を保証します。
スクラムを使用することで得られるメリットは他にもありますが、バーンダウンチャートやタイムボックス化された反復などの価値を得ることができる、知らないバリエーションやトリックやテクニックはありますか？それとも私は希望がありすぎているのでしょうか？
TIA。
Regs、Andrew
これは趣味のプロジェクトなので、実際に締め切りを気にすることはありますか? スプリント後にどれだけのことが行われるかを知ることは、実際にどのくらいの価値をもたらしますか?
答えが「いいえ」の場合は、代わりにかんばん方式を検討することをお勧めします。
私はソフトウェア開発におけるアジリティについて考え、真の有用性を提供する 3 つの側面に戻ります。
私の 9 時から 5 時までの作業環境では、このような方法論を採用するのは簡単です。毎週、週に少なくとも 40 時間はそこにいる開発者がいるので、スクラムのようなアジャイルの実践に従事するための障壁はほとんどありません。
「勤務時間外」の設定では、参加者のコミットメント レベルが異なることがよくあります。それが人生だ。だからあなたはあなたが持っているもので働きます。マットがプロジェクトに興奮しているが、彼のスケジュールが忙しく、プロジェクトに専念できる時間数が少し変動する場合、どうすればよいでしょうか? 彼が「参加」しており、プロジェクトに投資する時間を真剣に考えている場合は、それに応じて反復を計画する方法にすぎません.
ただし、個人的にはこれについて車軸に巻き込まれることはありません。結局のところ、採用するスクラムや「アジャイル」プロセスは、目的そのものではなく、目的を達成するための手段であるべきです。特に、9-5 の世界とは条件が異なる環境では、反復計画を柔軟にする必要があります。あなたはまだ自分の仕事を計画し、あなたが計画し、定期的なコミュニケーションと「私たちは今日どこにいるのか」に従事しています。全員がループに参加できるように運動します。
目標は堅固なソフトウェアです。スクラムの特定の側面やプロセスから多くのユーティリティを引き出すことができない場合はどうすればよいでしょうか? いずれにしても、ハイブリッド プロセスを開発する可能性があります。バーンダウン チャートやベロシティなどを取得することについて、あまり心配する必要はありません。正直なところ、開発中の高品質のソフトウェアにもっと焦点を当てる必要があり、次のイテレーションまたはその後のイテレーションで役立つ可能性のあるアーティファクトには焦点を当てる必要があると思います. それは私の意見ですが。
私のアドバイスは、機能するものを使用し、シンプルに保つことです。未処理分は素晴らしいものであり、毎日の「ミーティング」は、たとえこれが IM によって行われる仮想的なものであっても、全員とベースに触れるための真の価値が見出される場所です。趣味や副業は大変なことですので、よろしくお願いします。しかし、プロセスが 9 時から 5 時までのようにうまく機能しない可能性があるという事実を受け入れてください。
チームがすべての反復で投入できる時間が大きく変化する場合、特に最初は速度も変化するため、速度はスプリントの計画に実際には役立ちません。ただし、平均速度は、数回のスプリント後に安定し始める場合があります。
それでも、バーンダウンチャートは、現在の反復の正確なステータスを示しているため、引き続き役立ちます。
また、アジャイルプロセスがもたらす「キャリブレーション」の見積もりを利用します。
この種のプロジェクトでのスクラムの問題は、スクラムがサポートするように設計された開発チーム構造のタイプ、特に毎日のスタンドアップ ミーティングでのチームのコロケーションに関係しています。物理的に同じ場所にいないと、毎日スタンドアップ ミーティングを行うのは困難です。さらに、チームにプロダクト オーナーがいて、スクラム マスターと開発者の両方になるとは思えません。これに加えて、あなたと他の開発者は異なる時間に作業することになり、何の作業も行われずに日が過ぎてしまうことがあります。これにより、チームの調整が困難になる場合があります。
すべてのプロジェクトは、開発方法論に関係なく、何をする必要があるか (プロダクト バックログ)、何をすぐに行う必要があるか (スプリント バックログ)、およびこれらのタスクを実行するのにどれくらいの時間がかかるかについて良い考えを持っている必要があります。プロジェクトにかかる時間の合理的な見積もり (プロジェクトの速度とバーンダウン)。問題が発生する可能性があるのは、スクラムの他の部分です。ミーティングのために同じ場所に配置されていない、プロダクト オーナーがいない、掲示板を使用してスプリント ステータスを表示するなどです。
これは、目的に合わせてスクラム プロセスを変更できないということではありません。例えば：
スクラムの本質は、主に効果的なコミュニケーションに関するものであるため、それが正しく理解できれば、スクラムの修正版を機能させることができるはずです。コミュニケーションの有効性はリストの下の方に低下することを覚えておいてください。
そのため、会議で自由に使える最も効果的な方法を使用するようにしてください。
本の設定では、バーンダウン チャートの計算にリアルタイムではなく、ストーリー ポイントを使用します。数回のスプリントの後、平均ベロシティが表示されるため、バーンダウン チャートを生成し、このベロシティを使用してスプリント アイテムに取り組むことができます。
そして私は、スケールダウンのポイントに関するウォーレンの投稿に強く反対します. 私が目にする主な問題は、2 つのスプリント間で速度が大きく異なることです。これは単なる趣味であるためです。