スクラムでは、スプリント終了時に競合/ワークロードを処理する方法


9

私のチームは数日前にスクラムを使い始めました。私たちのプロジェクトには、物理​​デバイス(ロボットやセンサーなど)とのインターフェイスとなるソフトウェアの構築が含まれており、通常の製品バックログは、通常、システム全体に制御デバイスを追加することを表しています。

ここでは、例に近いタスクを分割します。各デバイス統合機能は、コード、テスト、統合テスト、ピアレビューなどに分割されます。明らかに、各製品バックログアイテムに固有のシーケンスがあります。通常、スプリントは2週間続き、チームには4〜6人のメンバーがいます。

スプリントの最後に2つの問題が発生します。

  • 1つは、スプリントの終了時に全員を忙しくしておくことです
  • 2番目の(関連する)1つはシステムの競合です。私たちはスプリントの最後の数日間でほとんど統合することになります。統合システムは1つしかありません。そのため、システムにアクセスできないため、多くの場合、作業の継続が妨げられます。これはスプリントの終わりなので、スプリントバックログで行う必要のある作業は多くありません。これらの人々は何に取り組むべきですか?現在のアイテムが完了していないため、商品のバックログの一番上からアイテムを受け取ることは、商品の所有者から十分に受け取られていません。取り組む技術的負債は、プロジェクト全体を支援しますが、スプリントを完了助けにはなりません。

これらの問題を回避するためにスプリントを構成するためのベストプラクティスはありますか?製品所有者と交渉するためのヒント?


7
「継続的統合」という言葉が思い浮かびます。
ロバートハーヴェイ

1
継続的インテグレーションは、インテグレーターが各デバイスをその上に統合的に統合すると、インテグレーションシステムがそのテルフによってすべて行うことです。残念ながら、私たちのセットアップでは、コードをチェックインするほど簡単ではありません。モーターとI / Oカードとの物理的な接続のセットアップが必要です。新しいデバイスをCI環境で実行すること自体がタスクであり、それが競合の原因となっているタスクです。興味深いことに、CIシステムにあるものをすべて取り込んで実際のマシンに配置するのは、かなり簡単なプロセスです。CIがそれに値することを証明します。
Vincent Hubert

2
実際の統合デバイスを待つ必要があるのはなぜですか?ハードウェアに移行する前に、少なくとも基本的なテストとソフトウェアの統合を実行するために使用できるシミュレータ(少なくとも、機能的でない場合は機能します)はありませんか?
Thomas Owens

回答:


6

いくつかの点で、スプリントの終わりに遅いことは良いことです。つまり、私が取り組んできたスクラムチームで、忙しくしている限り、過大評価をせずに見積もることで、常に次の予定の調査タスクを追加しました。スプリント。

これは、今後の予定の概念実証を行ったり、既存のコードをリファクタリングする場所を調べたり、コードのテストカバレッジを改善するために作業したりする場合があります。


2
バグの修正は、スプリントの最後に忙しくさせていたもう1つのタスクでした。
Sjoerd、2011

5

スプリントの最後にビッグバンを待つのではなく、各タスクが完了するとすぐにチームが作業を統合できるように、統合システムを修正する必要があります。

数日で終了するのに十分短いユーザーストーリーを使用することをお勧めします。ここで終了とは、コードが完成し、テストされ統合されたことを意味します。


2
実際には、システム上でいつでも統合を行うことができます。問題は、タスクが統合段階に入る前に統合するものがないため、ほとんどがスプリントの終わり近くのその段階に到達するため、競合が発生することです。
Vincent Hubert

1
あなたのタスクを短くすることについての私の推奨はここで助けになるでしょう、いいえ?
マーティンウィックマン

4

個々のメンバー自体ではなく、チーム全体が責任を持って提供することを忘れないでください。4人から6人のメンバー全員が各タスクを一緒に処理することが可能です。つまり、プロセス全体を1つずつプッシュして、次のタスクに進みます。これは最初は非効率に聞こえるかもしれませんが、表示されているボトルネックがそれほど悪い場合は、有効なオプションである可能性があります。

また、制約の理論(GoldrattのThe Goal)を調べて、これらの統合のボトルネックがある理由と場所を分析する方法を確認することもできます。


3

カンバンアプローチを採用することで、これに対処しました。

追跡ソフトウェア(Jira)には最小値と最大値のキューがあります。

「必要に応じて」グルーミングします。週に1回の場合もあれば、3回の場合もあり、制限と実行される作業によって異なります。

これにより、商品の所有者がキューをたっぷりと実行できるようにすることに集中でき、個々のチケットのマイクロ管理を減らすことができます。いつものように、変化には時間がかかることを覚えておいてください。

引き続き2週間ごとにデモを行い、毎週リリースします。


2

うわー、ロボットと言わなかったら、あなたは今私のチームにいると思います。我々は持っている正確に同じ一連の問題。マニフェストへの忠実度の度合いと成功の度合いが異なる多数のアジャイルプロジェクトに取り組んだ経験から、私の分析では、スプリントが短すぎることが問題です。2週間のスプリントを行っているため、いくつかの問題が発生します。1つは、計画を立てるのに慎重すぎて、最後に死者が出ることが多いということです。2つ目は、2週間ごとに1、2日かかるレビュー、回顧、計画の膨大な量です。もう1つは、あなたが言ったように、レビューの直前に統合する必要があり、レビューの前に頻繁に失敗することです。私の最初で最も成功したアジャイルプロジェクトには4週間のスプリントがありました。これは、業界標準ではかなり巨大ですが、それは私たちにとってはうまくいきました。

編集:恩恵であった最初のプロジェクトからもう1つ覚えていました。私たちは常に完全に優先された製品のバックログを持っていて、スプリントタスクが完了して他のスプリントタスクが利用できない場合、開発者がタスクをそこから取得する自由を与えました。


「レビュー、振り返り、計画の膨大な量」-振り返りが非常に煩わしいと感じた場合は、すべてのスプリントで行う必要はありません。計画は計画した内容にのみ依存するため、より長いスプリントではそれほど少なくないはずです。
sleske 14

0

2番目の問題は、おそらく問題1以外を修正しようとした結果です。忙しいことのない人を仲間を助けるために手に入れるべきです。非スプリントタスクに取り組む代わりに、限られた統合で競合を引き起こします。

また、スプリントの最後ではなく継続的に統合する必要があります。


0

あなたはまだ始まったばかりです。チームに回顧プロセスを通じてこの問題に取り組む機会を与えます。

次に、製品の所有者はチームを信頼して、自分自身を整理して最適化する方法を最もよく知っている必要があります。代わりに、チームはPOを信頼して、顧客が何を必要としているのかを最もよく知っています。

これらは、新しいアジャイルチームにとって非常に一般的な課題です。チームが自分のサイロを分解して成長する時期を知るのは素晴らしいことです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.