アジャイル開発のコードレビューで、建設的なコミュニケーションを行うための心構え
チームでのアジャイル開発において、コードレビューは最も重要な工程の1つです。『アジャイルプラクティスガイドブック』（翔泳社）では、その目的が「ソースコードを書いた人の持ち物から、チームの共同所有物にする」ことだとされていますが、メンバーの考え方が違ったり責任の所在が曖昧になったりと、トラブルの種となることも少なくありません。今回は本書から、コードレビューで建設的なコミュニケーションを行うための心構えを紹介します。 本記事は『アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知』（著者：常松祐一、監修：川口恭伸／松元健）の「第2章 「実装」で活用できるプラクティス」から一部を抜粋したものです。掲載にあたって編集しています。 コードレビューの目的 【プラクティス】ソースコードの共同所有 筆者はコードレビューの一番の目的を「ソースコードを書いた人の持ち物から、チームの共同
5つのスクラム開発で大事にしていること/取り入れたいこと - Qiita
no plan株式会社では、自社プロジェクトは全てスクラム開発を行っています。 そこで大事にしていることや、他のチームを見た時に取り入れたいと思ったことも書こうと思い筆を取りました。 今回はスクラム開発用語がわからない人でも読めるようにあえて用語を使わないようにしてみたいと思います。 スクラム開発とは スクラムは「問題に対する解決策を列挙」「高優先度の策を一定期間でチームで実行」「結果の検査に基づく調整」「その繰り返し」を実現できる環境を生み出すシンプルなアプローチである。スクラムのカギとなる基本原則は、プロジェクト開発の途中で、顧客は、要求や必要事項を変えられるという認識である。予想できない変更について、計画に基づく方法で対処することは、容易ではない。したがって、スクラムは経験に基づくアプローチを採用する。 (引用: Wikipediaより) スクラム開発についてもっとざっくり スクラム
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
