アジャイルチームにおけるコードレビュー – パートII

第一回目の記事では、コードレビューがどのようにアジャイル開発プラクティスに関係しているかを説明しました。特に分散したチームを持っていたり、人員を変更したり、チームにまたがる調整が必要な場合においてです。 あなたのチームや組織内にコードレビューを導入してみようという気になりましたか?どうぞ読み進めて下さい。 誤解されていること まず最初に、チームのためにコードレビューは何ができて、何ができないのかを明確に理解する必要があります。 コードレビューとは下記のことではありません: バグハント:参加した人数に関わらず、コードに存在する全てのバグを見つけることを、コードレビューは保証するわけではありません。良いソフトウェアにするために、自動化テスト、マニュアルテスト、静的解析等の他のツールを使用することを考慮してください。 責任のなすり合い:コードよりもむしろ人々に存在する欠陥を見つけることに集中してしまうとき、コードレビューはすぐに嫌われ、チームを助けるのではなく破壊するものになってしまうでしょう。その代わりに、学んだり教えたり、チームの集団としてのパフォーマンスを改善する機会として、コードレビューをとらえましょう。 コードレビューを始めよう どのようにして、組織内のコードレビューを採用する意思決定者を説得するのでしょうか?それは場合により異なります。もし彼らが、コラボレーションにおける改善、イノベーション、そしてコードと従業員の両方における継続的な改善を奨励するような人々であれば、コードレビューの導入は簡単でしょう(驚くべきことに、ユニットテスト、リファクタリング、あるいはペアプログラミングといった人気のあるアジャイルプラクティスを導入するときとさほど変わりません)。もし意思決定者が、前向きな考え方ではない場合、チーム内部から始めてみるのがよいかもしれません

続きを読む »

ドッグフーディング と頻繁な内部リリース

リリースサイクルが短いのは素晴らしい 2, 3 か月ごとに、ソフトウェアの新しいフィーチャーバージョンを出荷すること - 2, 3 年ごとにではなくて - は素晴らしいことです。 短いリリースサイクルは、フィーチャーがゆっくりになることを避けるのに役立ちます。なぜなら、いつも締切が迫ってくるからです。そして、この締切はデベロッパーとステークホルダーに緊急性の感覚を保たせるのに役立ちます。 短いリリースサイクルは、"絶対にこのリリースに入れなければいけない"

続きを読む »