プロセスを修正し、注意散漫を減らす方法

昨年、私たちのチームは開発プロセスを徹底的に廃止しましたが、それを復元し、より良くすることができました。より明確で、より楽しく、より生産的です。



安定したプロセスを確保するために私たちが実装し使用しているプラ​​クティスとアプローチのいくつかについて説明します。 これらすべてが構築される重要な考え方は、開発者が開発に集中する必要があるということです。









1.オンコール開発者



チームの各開発者は製品の品​​質に個人的に責任があるため、サポートチームと直接やり取りします。これにより、ユーザーの痛みがより深刻に感じられます。



毎日、私たちの1人が勤務しています。 オンデューティ開発者の優先度の高い排他的なタスクは、サポートサービスの呼び出しを処理することです。 アプリケーションの流入により、アテンダントがコードを1行も書かずに、翌日新しいアプリケーションを離れた場合、コミュールファウトを書かない場合は正常です(同僚に行きます)。



簡単にするため、勤務担当者の属性(写真を参照)は毎日時計回りに次の開発者に送信されます(勤務スケジュールはありません)。



義務は、サポートチームにチームからの最速の応答を提供し、チームは気を散らすことが少なくなります。



2.チームへの単一のエントリポイント



チームは、製品の所有者とカスタマーサポートに対してのみ外部に公開されています。 製品プロキシは、機能などの実現可能性に関するすべてのリクエストをプロキシし、サポートサービスは、チームを通じて複雑なユーザーの問題を解決します。



このシンプルでキャプテンさえのルールは、「迅速な方法で」コーナーを切り、問題を解決したいと同時に、製品所有者とサポートサービスを提供したい過活動クライアントマネージャーからチームを保護します。



3.議論のための固定日



チームが参加するディスカッションは、割り当てられた曜日(この場合は火曜日と木曜日)に厳密に開催されます。 製品オーナとの新機能の定期的な議論/評価(グルーミング)、および次のスプリントの計画がこれらの日に予定されています。



このアプローチにより、制限内の割り当てられた日は、議論とそれらの間の切り替えで完全に占有されます(これもコード行ではありません)が、見返りに、残りの時間は開発に集中できるという保証が得られます。



4.ディスカッション-評価タスク



開発側の一部の人にとっては、チームを1時間ごとの会議に集中させることは、チーム作業の1時間に過ぎないようです。 スプリントでのそのような会議がいくつかあり、2週間がどこに行ったかは明らかではありません。



会議のコストを強調し、より効率的に実施するために、他のタスクと同様に各ディスカッションを計画および評価します。 反復の開始までに、チームがどの会議に時間を費やし、どのような結果が期待されるかが正確にわかります。



5.製品の埋蔵量



2週間の反復でスクラムを使用します。 つまり、スプリントの最初から、その中のタスクのリストは固定されており、通常のケースでは変更すべきではありません。



しかし、2週間で世界は変化する可能性があり、さらに2週間待つことは時々選択肢ではありません。 変更に対応できるようにするために、次のスプリントの計画中に予備を含めます。



予備は、説明のないタスクのように見えますが、ストーリーポイントで評価されます。 埋蔵量は、潜在的なニーズを考慮して、製品の所有者によって決定されます。 スプリントにスペースが残っていない場合は、まったくない場合があります。 予備金の最大量は制限されています。この場合、これらは異なる推定値を持つ3つのタスクです。





デモンストレーションがかぼちゃが燃え尽きる前の1日前に、使用されていない製品保存料が用意されます。 これにより、必要な予備が実現され、リリースに含まれることが保証されます。 チームは、その裁量で技術タスクに燃えた予備を使用するか、スプリントからそれを削除します(後者の場合、ストーリーポイントは授与されません)。



6.相談完了



以前は、特に「チーム全体がタスクの完了に同意している」という項目で、タスクの完了(完了の定義)を判断するのが困難でした。



ここで、作成者と開発者は、タスクが完了したと判断すると、他のチームメンバーをDone-consultationに集め、ミニデモを実施します。 チームは、元の問題が解決されたかどうか、以前に考えられていなかった何かが忘れられたかどうかを総合的に評価し、改善を提供する可能性があります。



相談を行うことで、チーム全体が問題の最終的な解決策に満足できるようになります。



イベントはチーム全体の気を散らす必要があるため、タスク間の休憩には特別な時間が割り当てられます。毎日の立ち上がりの直後と昼食の直後です。



7.コード転送



Done-consultationが終了し、作成者が必要な変更を加えると、タスクは別の開発者に転送されます。 彼はコードレビューを実施し、見つかったコメントを独自に排除するか、リファクタリングを実施します。



この方法により、コードの一般的な所有権と同僚のタスクへの没入が達成され、コードレビューに関するコメントを修正する時間が短縮されます。 さらに、新鮮な外観と2番目のヘッドの効果がここで機能し、多くの場合、非自明な問題の特定に役立ちます。



All Articles