バックログには未解決のバグがいくつありますか? 100? 1000?
彼らはどれくらいそこに横たわっているのでしょうか？ 一週間？ 月？ 何年？
なぜこのようなことが起こるのでしょうか? 時間がない？ もっと優先度の高いタスクを実行する必要がありますか? 「今、緊急の機能をすべて実装します。その後、バグを解決する時間は確実にあります。」?

... ゼロバグポリシーを使用する企業もあれば、バグを扱うというよく発達した文化を持っている企業もあり (バックログをタイムリーに更新し、機能が変更されたときにエラーを修正するなど)、バグをまったく含まずに記述するウィザードを育成する企業もいます。 (ありそうにありませんが、おそらくこれが起こるでしょう)。

今日は、バグのバックログを解消するためのソリューションである Bagodelnya プロジェクトについてお話します。

Счеговсеначалось？

増え続ける未解決のバグのバックログをもう一度調べてみると、私たちは沸点に達しました。 これ以上このままでは生きていけない、何としてでも切り詰めようと決意したのです。 アイデアは明らかですが、どうやって実現するのでしょうか? 私たちは、最も効果的な方法は、ハッカソンに似たイベントであるということで意見が一致しました。つまり、チームを日常業務から解放し、1 労働日をバグの処理のみに割り当てるというものです。

彼らは規則を書き留め、大声で叫び、待ち始めました。 応募者が少なく、非常に少ないのではないかと心配されていましたが、結果は私たちの予想を上回り、最大 8 チームが登録しました (ただし、最後の瞬間に 3 チームが統合されました)。 私たちは金曜日の営業日を丸一日イベントのために割り当て、大きな会議室を予約しました。 昼食はオフィスの食堂で用意され、軽食にはクッキーが追加されました。

具現化

X 日目の朝、全員が会議室に集まり、短い説明会が開催されました。

基本ルール

• 2 チームは 5 ～ XNUMX 人で構成され、そのうち少なくとも XNUMX 人は QA です。
• バグは、すべての内部運用標準に従ってチーム メンバーによって解決される必要があります。
• 各チームには、コードの修正が必要な解決済みのバグが少なくとも XNUMX つ存在する必要があります。
• 修正できるのは古いバグのみです (バグが作成された日 < バグ ハウスの開始日 - 1 か月)。
• 修正されたバグの場合、重大度に応じてポイント (3 ～ 10) が付与されます (不正行為を避けるため、バグデーの日付が発表された後は重大度を変更できません)。
• 無関係で再現不可能なバグを閉じると、1 ポイントが与えられます。
• すべてのルールの遵守は監査チームによって監視され、再発見されたバグについてはポイントが取り消されます。

その他の詳細

• 私たちは場所の選択について誰も制限しませんでした。彼らは自分の職場に滞在することも、気が散ることなく情熱が感じられる会議で全員と一緒に座ることもできました。

• 競争心を維持するために、レーティング表が大画面に表示され、戦闘のテキスト放送が常にスラックチャンネルで放送されました。 ポイントを計算するには、Webhook 経由で更新されるリーダーボードを使用しました。

リーダーボード

• すべてのルールの遵守は監査チームによって監視されました (経験上、これには 1 ～ 2 人で十分です)。
• バゴデリヌイ終了からXNUMX時間後、再検査の結果が発表された。
  優勝者にはバーへのギフト券が、参加者全員にはお土産（「虫」のキーホルダー）が贈られました。

結果

過去XNUMXか月間で、私たちはすでにXNUMX回の救援活動を開催しました。 結局私たちはどうなったのでしょうか？

• 平均チーム数は5です。
• 処理されたバグの平均数は 103 です。
• 無関係または再現不可能なバグの平均数は 57% です (そして、このゴミは常に目障りであり、その量に怯えていました)。

結果発表の瞬間

そして、誰もが好んで尋ねる最も難しい質問に対する答えがここにあります。「新しいバグは何個見つかりましたか?」
回答: 処理されるのは全体の 2% 未満です。

レビュー

バゴデレンの後、参加者からフィードバックを収集しました。 「参加プロセスで最も気に入った点は何ですか?」という質問に対する回答は次のとおりです。

• このようなモチベーションでバックログを整理するのはとてもクールです。 通常、これは非常に退屈なプロセスであるため、定期的に実行する必要があります)。
• ワクワク、クッキー。
• これは、重要ではないが修正したい小さな点を修正するための待望の機会です。
• スプリントの外で古くて不快なバグを最終的に修正できるのが気に入りました。優先度の高いタスクが常に存在するため、これらに費やす時間はありません。 私たちは必要な人材をすべて XNUMX か所に集めることに成功し (たとえば、私たちのチームには DBA がいた)、特定されたバグの関連性とそれらを修正する技術的な可能性について共同で議論しました。

まとめ

バグ ショップは万能薬ではありませんが、バグのバックログ (さまざまなチームで 10 ～ 50%) をたった XNUMX 日で減らすための実行可能なオプションです。 私たちにとって、このイベントは、製品をサポートし、ユーザーの幸せを気にかけている、やる気のある人々のおかげでのみ始まりました。

バグが少なくて最高です!

出所： habr.com