agile - スクラム/アジャイル環境で誰がバグを修正する必要がありますか?

Question

誰がバグを修正するべきだと思いますか? プログラマーですよね？わかりましたが、本当に、誰が... 説明させてください。

私は多くのスクラムプロジェクトのスクラムマスターです。スクラムは、「可能な場合はリソースをリングフェンスする」と言っていますが、私はこの意見に心から同意します。

通常、各スプリントの特定の %age を統合して、前のスプリントからのバグ修正を行います - すべて順調です。

各スプリントの後、クライアントにデモと再調査を行い、開発コードを UAT 環境にプロモートします (クライアントは通常、プロジェクトの一部を公開することを望んでいませんが、それはクライアント次第です。動作するテスト可能なコードを確実にデプロイすることで、取引の側にいます）。

すべてのスプリントが完了すると、クライアントが完成したソフトウェアを徹底的にテストして最後のバグを見つける UAT フェーズがあります。理想的には、これらはすでに検出されているはずですが、現実的には、UAT 中にのみ発見されたものもあります。

この UAT フェーズでは、すべての開発者が 100% プロジェクトに必要とされるわけではないため、開発者を他のプロジェクトに再割り当てしたいと考えています。ただし、スクラムは「可能な場合はリソースを囲う」と言っています。

私の問題は、あるプロジェクトの UAT フェーズに開発者を割り当て、別の場所で別のスクラムプロジェクトを開始していることです。理想的ではありませんが、現時点では商業的な現実です。

次のいずれかを実行できます。

1) それを受け入れ、開発者に独自のコードを修正してもらい、開発者の時間 (たとえば 20%) を前のプロジェクトの UAT に割り当てます。

2) 引き継ぎが適切に行われていることを確認し、バグ修正コードに 100% 専任の開発者を 1 人または 2 人配置します。

私は 1) が好きですが、リソースを確保するのは非常に面倒です。

2) 恐ろしいことに、開発者は自分のコードの品質に責任を負わないと思います。開発者が自分のコードの所有権を確実に取得できるようにするためには、多くのことを言う必要があると思います。また、自分のバグを修正するよう依頼することは、品質を確保するための良い方法です。バグを修正するのが好きな人はいないので、開発者は通常、いずれにせよ発生した問題を修正する必要があることを知って、前もってより良い仕事をしようとします。ただし、2) の方が計画とリソースが簡単です。ただし、2) 他の人のコードのバグを修正するのは時間とリソースの面でコストがかかるため、時間がかかります。複雑な修正である場合は、いずれにしても元の開発者の助けが必要になる可能性があり、コードベースのそのセクションに精通していない人が修正するには、確かに時間がかかります。

人々はどう思いますか？

score 13 · Accepted Answer

人々は自分のコードを修正する必要があります。新しいものを書いている可能性があるときに、古いものに戻って修正することを好む人はいないという事実を利用してください。バグの責任者を特定できる場合は、その開発者が問題の修正を担当していることを確認してください。これにより、開発者は、壊れたものを修正し続けなければならない人物と見なされたくないので、最初からクリーンなコードを書くことにもっと熱心になるようになります。これは、開発中だけでなく、誰かが現在のビルドを壊した場合にも当てはまります。

更新：そうは言っても、私は必ずしも独断的ではありません。顧客のニーズが最優先され、バグを作成した人が修正を行うために再割り当てできない場合は、修正を他の人に割り当てる必要がある場合があります。

score 9 · Accepted Answer

スクラムマスターは開発者リソースを割り当てません。スクラムマスターは、チームの誰かが果たす役割です。

それはさておき、プロダクトオーナーは「チームのプロジェクトマネージャー」であり、製品を安定して運用するために必要なリソースを確保するために戦わなければなりません。

チームのバグがゼロに近づくように、エンジニアリングプラクティスを改善する必要があります。スプリントの終わりを過ぎても残っている「バグ」は、プロダクトバックログに移動して、プロダクトオーナーが優先順位を付ける必要があります。

score 5 · Accepted Answer

これは非常に興味深いトピックです。プロジェクト管理は不可欠であり、リソースの適切な割り当てが不可欠です。

私が指摘したい点の 1 つは、専任のバグ修正担当者がいると、コードの品質が向上する可能性があるということです。他の人が責任を負っていることを知っていた私の名前に反対するコードを開発していた場合、それが良いコードであることを確認するためにできる限りのことをします。

おそらく、組み合わせのアプローチが必要です。プロジェクトごとに 2 人の開発者 (プロジェクトごとに異なるペア) を採用し、その責任を事前に概説するバグ修正フェーズを担当させることができます。そうすることで、プロジェクトが進行し、最後に引き渡しが行われるときに、彼らは最新の状態にあることを確認できます. リソースの割り当てが容易になり、クライアントは一流のサポートを受けられます。

見方が少し違うだけです。

乾杯ネイサン

score 4 · Accepted Answer

あなたのチームは、現在のプロジェクトが出荷されるまで、新しいプロジェクト作業を開始するべきではありません。ほとんどのスクラム実践者は、(ウォーターフォールで行われたように) UAT の場所はスクラムにないと主張するでしょう。あなたが求めているのは安定化スプリントと呼ばれるもので、本番前の最後のスプリントです。チーム全体がそれに取り組んでいます。この間に行われる作業には、土壇場でのバグ、GUI の美化の微調整、ドキュメントのロールアウト、ヘルプガイド、操作トレーニング、長いランチが含まれます。また、チームにとって、未処理の項目を提出するという「プレッシャー」を感じずに新しいことを自分で学習したり、何か新しいことを始める前に少しリラックスしたりする絶好の機会になる可能性もあります。顧客の UAT 時間枠の期待に基づく。それが長い側にある傾向がある場合;

何をするにしても、スプリントの境界の外で仕事をしてはいけません。それは、ウォーターフォールのようなスケジューリング忘却への滑りやすい坂道です。

score 2 · Accepted Answer

バグは元の開発者によって修正されるべきだと思います。他の誰かが書いたコードのバグを開発者に修正させると、より多くの時間がかかる可能性があり、さらに、バグを修正することはそれほど興味深いものではないため、開発者のやる気を失わせる可能性があります。

score 2 · Accepted Answer

オプション 2) は本当に好きではありません。理由は次のとおりです。

それは人々に仕事が終わったという感覚を与えますが、まだ終わっていません (それは終わっていません、バグがあります)。
人は他人ではなく、自分が書いたコードに責任を持つべきだと思います。
「バグフィクサー」は仕事ではないと思います。これを行うとき、あなたは人々を尊重していません。

したがって、オプション 1) が私の好みです (ただし、リソースとリソースについて話すのはやめてください)。

最後に、少し引用します。

テストと修正のサイクルが分かれていると、テストが遅すぎます。--M. ポッペンディーク

はい、私は知っています、言うよりも実行するのは簡単です...しかし、それにもかかわらず、彼女は非常に正しい.

score 2 · Accepted Answer

#2に投票します。開発者として、私はコンテキストの切り替えが嫌いであり、それが本質的に #1 で課されていることです。コードの所有権の問題に関しては、開発者がコードの一部を所有することはアンチパターンです。所有権の共有に努める: ペアリング、ローテーションなどを導入します。

2 番目の @kevindtimm のコメントに、UAT は単なる別のスプリントです。おそらく開発者は少ないでしょう。

一方、アジャイルソフトウェアマニフェストの中核は、ビジネス価値を段階的に提供することであるため、理想的には、各スプリントの終わりに PROD にプッシュすることになっています。もしそうなら、UATをすべてのスプリントの一部にするべきではありません。それがデモの目的ではありませんか？

score 1 · Accepted Answer

これの一部は、いくつかのバグが私の考えているいくつかのカードよりも重要であるかどうかを優先するプロダクトオーナーに委ねられます。PO が「これらのバグを今すぐ修正する」である場合、リストの一番上に移動されたバグ修正があるはずです。優先度の高いバグが多数ある場合は、バグが修正され、新しい機能が実行されない安定化スプリントを行う価値があるかもしれません。PO にバグにどれだけの時間を費やしてほしいか尋ねたくなるでしょうが、それがどれほど実用的かはわかりません。

保守開発者を配置するという考えは素晴らしいですが、保守が行うコードの変更と、新しい機能を開発する開発者が行うコードの変更をマージしなければならない場合に、どこに問題があるかを考えたことはありますか? ええ、これは単につま先を踏んでいるだけですが、テスト環境と開発環境の間で非常に多くの変更があったため、2 人の開発者がコードを宣伝しようとして 1 日が費やされたという、苦痛なマージがありました。

別の開発者がバグを修正して、何かがどのようにコーディングされているかを誰かが理解できるようにするというアイデアを提案してもよろしいですか? 複数の人が特定の機能に取り組むことで、コードの個人所有ではなく共同所有を促進することができます。別の部分は、以前にその種のバグを修正したことがあるために、他の誰かがバグを簡単に処理できる場合があるということです。ただし、これは定期的にチェックする必要がある依存関係にもつながる可能性があります。

score 1 · Accepted Answer

「バグの負債」と呼ばれるバックログ項目を把握し、チームに反復ごとに見積もってもらいませんか。その項目は、一部の開発者がそれを修正する時間を保持するために使用されます (#1 のように)。

また、UAT に現れるバグも少し気になります。それらのテスト担当者の何人かをチームに配置して、早期にキャッチすることは可能でしょうか? この種のことは、グループからグループへとフェンスを越えて放り出されるプロジェクトでは非常に一般的です。私が見た唯一の方法は、他のグループをチームに統合し、テスト戦略を再考することです。次に、UAT はユーザーがやりたいことを実行します... 使いやすさの問題と要件を把握します。確かに完全になくなるわけではありませんが、最小限に抑えられます。

score 1 · Accepted Answer

私はスクラム主導のチームの主任開発者です。私の組織でよく使われている方法は次のとおりです。

スプリントの開始前に、各開発者には、スプリント中に生産性が向上すると思われるパーセンテージが割り当てられます。たとえば、より熟練した経験豊富な開発者は、スプリント中の総時間の 70 ～ 80% で生産性を発揮できる可能性があります。これにより、予期しないミーティングやバグ修正のための時間ができます。すぐにバグ修正について説明します。サインオフされたすべてのタスクの見積もりを取得し、開発者の作業を計画します。

スプリントに入ると、開発者は計画した作業を実行し、独自のテストを完了します。可能であれば、作業の各ブロックが完了すると、別のテストフェーズがスクラムリーダーまたはプロダクトオーナー (プロジェクトマネージャー) のいずれかによって行われます。このテストフェーズで発生するものはすべて、スプリントで完了するためにそれを書いた開発者に直接返されます。チームがスプリントの開始時に与えられたタスクを完了することに効果的に取り組んでいるため、何らかの方法でそれらを完了する必要があると私たちは考えています。

チームに緊急のバグが発生し、今すぐに実行する必要がある場合、私とスクラムリーダーは、計画された作業に影響を与えずにバグを修正できるかどうかを判断します。やっています。IE 予定より半日早く、バグの見積もりが半日である場合、計画された作業を変更せずにそれを行います。それが不可能な場合は、スプリントから除外する必要があるものを決定するプロダクトオーナーに戻ります。

スプリントの途中で緊急ではないバグがチームに割り当てられた場合、プロダクトオーナーはそのバグに優先順位を付け、ポットに残ります。プロダクトオーナーが次の一連の目標を思いついたとき、彼はバグに優先順位を付け、プロジェクトは協力して作業し、これらは次のスプリントの計画項目になります。

注意すべきことは、バグがどのプロジェクトから来たかは問題ではないということです。すべてに優先順位があり、それを管理する必要があります。結局のところ、特定の開発リソースしかありません。どの開発者がそれを行うかということになると、それはいくつかのことに依存します。誰のコードがバグを導入したかを常に正確に把握できるとは限りません。特にそれが非常に古いプロジェクトからのものである場合。同じ開発者がそれを修正できる場合、明らかに時間的なメリットがありますが、正確な開発者が利用できない可能性があります。私たちが試み、取り組んでいる方法は、すべての開発者が任意のタスクに取り組めるようにすることです。現実の世界では、これは常に可能であるとは限りませんが、それが常に私たちの最終目標です。

私はここで茂みの周りを叩いてきたことを認識していますが、誰がバグ修正を行うべきかというあなたの質問に答えて、要するにこれは私が言うことです:

作業が行われていたのと同じスプリント中にバグが特定された場合は、元の開発者に送り返します。
緊急の場合は、できるだけ早く完了する必要があるため、タスクを実行するのに最適な人に行く必要があります。それは、最初にコードを書いた人ではないかもしれません。より経験のある人かもしれません。
バグの優先順位を付けて計画を立てた場合は、誰がその仕事をするのに最適かを判断する時間もあるはずです。これは、実行が必要な他の作業、開発者の空き状況、および一般的な判断に基づいて行われます。

引き継ぎに関しては、これらはかなり最小限に抑える必要があります。結局のところ、開発者は、再検討するタスクを持っているすべての開発者にとって明確でクリーンで明白な方法でコードを作成する必要があります。チームの開発者が基本的にこれを行っていることを確認するのは、私の仕事の一部です。

これが役立つことを願っています:)

score 0 · Accepted Answer

私は通常、オプション 1 に従いました。多くの場合、リソースが他のプロジェクトに割り当てられるためです。バグがどのように作成されたかを議論することによって根本原因の分析を行う場合、世間に恥をかかせるという小さな副作用があります。プロジェクトに所有権の感覚を植え付けた場合、開発者は、自分のコードが他のコードよりも高い割合のバグを表示したり、妥当なものを表示したりした場合、少し当惑するはずです。

これらの場合、ほとんどの開発者は、忙しすぎて古いバグを修正できないと、実際に不満を感じていることがよくあります。彼らは、他の誰かが自分の過ちを片付けなければならないことを嫌います。

所有感と誇りを植え付けることが重要です。もしあなたがそれをしていないなら、あなたは彼らに正しいことをさせるために罰の脅威に常に頼っています.

score 0 · Accepted Answer

人々は自分のコードも修正するべきだと思います。引き継ぎでいつも時間を無駄にするのはなぜですか？

各機能が完成したら、UAT を実行する価値があるかもしれません。したがって、「テスター」は「開発者」のテスト機能と並行して作業します。テスターは、UAT 基準を実行できる必要があります。

利害関係者との UAT 内にさらに問題がある場合、それらは変更要求であるか、そもそも承認基準があいまいである可能性があります。

agile - スクラム/アジャイル環境で誰がバグを修正する必要がありますか?

13 に答える 13

Related

Reference