Tangible, Embedded and Embodied Interaction - Lecture 9 - Next Generation User Interfaces (4018166FNR)
チームでのアジャイル開発において、コードレビューは最も重要な工程の1つです。『アジャイルプラクティスガイドブック』(翔泳社)では、その目的が「ソースコードを書いた人の持ち物から、チームの共同所有物にする」ことだとされていますが、メンバーの考え方が違ったり責任の所在が曖昧になったりと、トラブルの種となることも少なくありません。今回は本書から、コードレビューで建設的なコミュニケーションを行うための心構えを紹介します。 本記事は『アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知』(著者:常松祐一、監修:川口恭伸/松元健)の「第2章 「実装」で活用できるプラクティス」から一部を抜粋したものです。掲載にあたって編集しています。 コードレビューの目的 【プラクティス】ソースコードの共同所有 筆者はコードレビューの一番の目的を「ソースコードを書いた人の持ち物から、チームの共同
〜エンジニアチームが、明らかに変わる。「 スクラム開発 」のエッセンスをうまく取り入れた、クラウドワークスのエンジニアマネジメントの取り組みとは〜 国内最大級のクラウドソーシングサービスを展開する、株式会社クラウドワークス。同社は事業の拡大に伴い、開発チームの組織化という課題に直面した。その課題に取り組んだのが、過去に100名規模の組織にスクラム開発を導入した経験を持つ、安西 剛さんだ。 安西さんは、ひとつの大きな開発チームを少人数のチームに分割し、スクラムのエッセンスを取り入れることでコミュニケーションを増やす工夫を行った。すると、チームが「同じ目標に向かう」ようになり、成功体験を積み上げていけるようになったそうだ。 アジャイルやスクラムに関わった経験の長い同氏だが、組織をチーム化していくために「スクラムをやろう」と呼びかけるのはアンチパターンだと語る。 あくまでもチームやコミュニケーシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く