スクラム プロセス管理 - ヒント、落とし穴、アイデア [終了]

Question

しばらくチームでスクラムをやっていますが、何らかの理由で物事が面倒に思えます。私はそれらをどのように変更できるかを考えてきましたが、ここで提起したいいくつかの質問があります。

まず、スクラム プロセスにおいてテスター、デザイナー、非開発者全体としての役割はどうあるべきでしょうか?彼らが他のチームメンバーと同等である場合、いくつかの問題が発生します。デザイナーとテスターは通常、開発が完了した後にタスクに取り組むため、この依存関係によりスプリントを適切に計画することができません。

第二に、期限があります。これらは厳密であり、優先順位付けに大きな影響を与えます。最終的には、期限の変更によりスプリントの途中でバックログが変更されたり、スプリントの終わりに悪い結果が生じたりします。また、カスタマーサポートなどの非技術的な仕事もたくさんありますが、その間にやらなければならない作業は状況によって大きく異なるため、計画することはできません。したがって、チームの構造、文化、慣行はスクラムとは互換性がないのではないかと考えています。Scrum for me は、単一のソフトウェア製品の開発に取り組むチームのためのプロセス管理ツールです。

より具体的で複雑なシナリオにそれを適用することについてどう思いますか?共有できる経験はありますか?

Answer 1

一般に、テスターとドキュメンター (およびその他の非開発者) はすべて、スクラム チームの同等のメンバーです。その背後にある考え方は、リスクを最小限に抑えることです。

完全にテストされ文書化された潜在的に出荷可能な製品を含む完了の定義を要求すると、各スプリントの終了時にプロジェクトをまとめることが強制されます。

開発後までテストが開始されない場合。開発者がタスクを完了した後に、多くのバグが発見されることが起こります。したがって、これらのバグを修正する必要がありますが、バグが相互作用することと、一般的なルールが次のとおりであるため、非常に時間がかかり、コストがかかります。「バグを修正する費用は、時間とともに指数関数的に増加します。」あなたが早くキャッ​​チするバグは安価で簡単に修正でき、遅いバグは悪夢です。

だからこそ、テスト (およびドキュメント) を開発と歩調を合わせて進めたいのです。そして今、あなたは「どうやって」と尋ねるはずです。テストが遅いのですが、どうすれば開発と歩調を合わせて進めることができるのでしょうか?

答えは自動化です。つまり、SCRUM は常に XP またはアジャイルの上に位置し、どちらも優れた単体テスト カバレッジと TDD を必要とします。ここでもう 1 つ注意すべき点があります。機能開発者は、単体テストとシステム テストの両方を作成する必要があります。すべてのテストの自動化は機能開発者が行う必要があります。チーム。いくつかの場所では機能開発が分割されています。オートメーション開発者よりそしてそれは悪いことです。

これで、優れた自動テストが完成し、少なくとも 1 日に 1 回は実行できるようになりました。そして明らかに継続的インテグレーションを実践していますよね?これにより、テスターの作業負荷が大幅に軽減されます。そうすることで、テストと開発の歩調を合わせることができます。もう 1 つ、テスターは現在、自動化が不可能または非常に困難な非常に困難で創造的な作業に取り組んでいます。そのようにしてバグを見つけるたびに、バグを明らかにするために必要な作業はすべて自動化され、毎日の回帰テストの一部になります。 。ふぅ、長い答えですね！

それでは、質問の 2 番目の部分に移ります。スクラムは規律を重視します。スプリントは短く、スプリント中にバックログの変更が発生してはなりません。技術的以外の作業はカスタマー サポート チームに分掌し、それを中心にスクラムを実行できるようにする必要があります。あなたの文化や慣行がスクラムと相容れないように聞こえるという意見は正しいです。

私の経験では、スクラム/アジャイルへの移行は非常に苦痛でストレスの多いプロセスであり、移行の試みのほとんどは失敗します。成功の鍵の 1 つは、経営陣のスクラム/アジャイルのチャンピオンです。あなたの説明からすると、あなたは持っていないようです。

スクラムにはコストとメリットがありますが、やり方が下手だと、メリットがほとんど、またはまったくないのにコストが発生している可能性があります。スクラムのやり方が間違っていてひどい場合は、スクラムをまったくやらないほうが良いかもしれません。

Answer 2

まず、スクラム プロセスにおいてテスター、デザイナー、非開発者全体としての役割はどうあるべきでしょうか?彼らが他のチームメンバーと同等である場合、いくつかの問題が発生します。デザイナーとテスターは通常、開発が完了した後にタスクに取り組むため、この依存関係によりスプリントを適切に計画することができません。

開発の依存関係が原因で設計者とテスターがスプリントを計画できない場合、それは開発が正しく計画されていないことを意味します。それは解決する必要がある問題です。

チームは、「タスク B にはタスク A を最初に完了する必要があります。タスク A には 8 時間かかり、タスク B には 4 時間かかります。」タスクの見積もりが正確であれば、依存関係はまったく問題になりません。

第二に、期限があります。これらは厳密であり、優先順位付けに大きな影響を与えます。最終的には、期限の変更によりスプリントの途中でバックログが変更されたり、スプリントの終わりに悪い結果が生じたりします。また、カスタマーサポートなどの非技術的な仕事もたくさんありますが、その間にやらなければならない作業は状況によって大きく異なるため、計画することはできません。

このようなことが起こっている場合、問題はスクラムを実行していないことです。スクラムが機能する唯一の方法は、経営陣がプロセスに完全に同意する場合です。これは、開発者が計画されたスプリントに取り組んでいる間 30 日間放置し、そのためにスクラムが用意している方法で新しい作業を追加することを意味します。ウィッシュ リストの項目を製品バックログに追加し、スプリント計画中に開発者と関係者が次のスプリントで取り組む内容について合意します。

通常の開発を妨げるカスタマー サポートの問題が常に発生する場合は、チームを分割することを真剣に検討し、1 つのグループをスクラムでの開発に専念し、別のグループでカスタマー サポートの問題を担当する必要があります。その後、各スプリントの終了時にメンバーを前後にローテーションできます。

Answer 3

スプリント中に発生した変更に基づいてスプリント バックログに変更を追加すべきではありません。変更はプロダクト バックログにのみ追加され、スプリントが終了するまで無視されるべきです。

締め切りとスプリントを調整する必要があります。スプリントの途中でタスクをリタイアすることは許容されますが、新しいタスクを導入することは許容されないと思います。

スプリントの途中で多くのタスクを追加していることに気付いた場合は、スプリントが長すぎる可能性があります。各スプリントで約 20 日間の作業を目標としているのですが、それ以上になると、説明したような問題が発生し始めることに注意してください。

テスターはあらゆるアジャイル プロセスにとって重要ですが、アクティブなタスクを持たない人が次のタスクを選択するという理論があるスクラムにはあまり適合しません。タスクと人々の間の関連付けを選択しようとすると、全体が避けようとしていたスケジューリングが開始されます。

テスターは、開発者の近くで作業している場合、作業項目が実際に完了したかどうかを判断するのに役立ちます。

Answer 4

まず第一に、あなたはスクラムをまったく使用していません。スクラムの実践をいくつか使用している可能性がありますが、プロセス全体では使用していません。

デザイナーとテスターは通常、開発が完了した後にタスクに取り組むため、この依存関係によりスプリントを適切に計画することができません。

タスクの依存関係は関係なく、ウィッチはほとんど発生せず、適切に計画する能力があります。スプリント計画では、チームは完了の定義に関するストーリーを見積もる必要があります。ストーリーの設計とテストが含まれており、実際にそうすべきである場合、ストーリーの受け入れ基準を達成するために必要な労力の見積もりには、設計とテストのタスクが含まれている必要があります。

最終的には、期限の変更によりスプリントの途中でバックログが変更されたり、スプリントの終わりに悪い結果が生じたりします。

スプリントの長さが必要以上に長いようです。短くしてみませんか。適切なスプリントの長さは、スプリントに変更を加えないようにするためにコミットできる長さです。1週間もあれば効果があると思います。

そして、この行動は、スクラム マスターが障害を取り除いていないため、自分の仕事を適切に行っていないことを示しています。