30日の保証期間
30日の保証期間
自分のチーム以外からのコントリビューションを受け入れる場合、チームが書いていないコードの責任を持つことに抵抗があることは自然なことでしょう。 「30日の保証期間」プラクティスを利用すると、コードにコントリビュートしたチームはコードを受け取ったチームに対してバグフィックスを提供することを承諾することになります。 そうすることで、両チーム間の信頼度が高まり、コントリビューションが受け入れられる可能性が高くなります。
あるチームが、組織全体で使用されるコンポーネントを開発しています。 このチームはコントリビューション(機能への要求を含む) を受け入れることに抵抗したり、完全に拒否したりします。 この振る舞いは進行を妨げたり、エスカレーションによる頻繁な混乱につながります。
- コントリビューションを受け入れる側のチームによって生み出されたコンポーネントを、コントリビュートした側のチームが使えるかどうか、それは他のチームが受け入れてくれるかに依存してしまいます。
- 受け入れる側のチームが、コントリビュートされたコンポーネントや機能に対するリソース・知識・許可を持っていないか、もしくは(それに加えて) それらのコンポーネントや機能を自分自身で書く意欲がない場合があります。
- 過去に不正行為があったため、コントリビューションに対する不信感があります。例として、チームは中途半端にしたコントリビューションを提供し、その後に本番で使えるように修正するよう要求してきました。
- チーム外からコードを提供された場合、他のチームはチームの期待に沿うようなコードの書き方を知らないのではないかという疑念を持つことは自然なことです。
- 各チームは、自分のリーダーが目標を達成するための活動を第一に考えます。この忠誠心の方向性が、この問題の解決を複雑にすることがあります。
- 自分で書いていないコードに責任を持つことに抵抗があることは自然なことです。
- コントリビュートされたものは、コードベースに受け入れる前に大きく書き換える必要があります。
- コントリビュートした後、バグフィックスなどのサポートが受けられなくなる恐れがあります。
- コントリビュートされたコードが高いメンテナンスコストにつながることを恐れているが、それをどのように管理すればよいのかわかりません。
- 受け入れ側のチームは、他の人にコードを提供する方法を教えることで、自分たちのシステムの技術的負債が露呈し、それによって損害が発生することを恐れています。
- 受け手のチームは、いくら指導しても納得のいくコードが得られるとは思っていないかもしれません。
- どちらのチームも、リスクを測定したり、コントリビューションの中でリスクが軽減されていることを証明することに自信を持てないかもしれません。例えば、システム自体がややもろいなどの理由が挙げられます。(テストが完全でなかったり全ての問題を拾いきれてないかもしれません。）
コントリビュートしたコードが本番稼動した時点から 30日の保証期間 を設けることで、受け入れた側とコントリビュートした側の双方の不安に対処します。この保証期間中、コントリビュートしたチームは受け入れたチームにバグフィックスを提供することに同意します。
なお、保証期間は45日、60日、100日のいずれでもかまいません。この期間は、プロジェクトの制約、プロジェクトのソフトウェアライフサイクル、顧客との約束事項、その他の要因に基づいて変化される可能性があります。
30 Day Warranty
- 受け入れ側のチームがコントリビューションを受け入れ、初期適応/修正の作業負担を分担することができます
- 透明性と公平性が高まります
- エスカレーションが重荷になりすぎないようになります
- これは PayPal で試みられ、成功したことが証明されています。
- GitHub は社内でこのパターンを使っており、6週間という修正された保証タイムラインを使っています。
- Microsoft はこのパターンを原則として推奨しています。チームは自分たちのニーズと自信にマッチするよう具体的な時間目標を設定します。
- Cedric Williams
- Dirk-Willem van Gulik
- Padma Sudarsan
- Klaas-Jan Stol
- Georg Grütter
- Structured
- Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.
最終更新 8mo ago