ペアリング対コードレビュー: 開発者文化の比較
前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって
「アジャイルな見積りと計画づくり」読みました
「アジャイルサムライ」読んでなんとなくアジャイル分かった気になってたんですが、名著と名高い「アジャイルな見積りと計画づくり」ようやく読みました。 感想 結論から言うと、アジャイルやるなら絶対に読むべき。アジャイルサムライの倍ぐらい分厚い（適当な見積り）けれど、とても良い内容です。 「アジャイルサムライ」の方はそんなに分厚くなく、読みやすい内容で”アジャイル開発とは”ということを良い感じに紹介してくれてる、こちらもとてもいい本です。その一方で、「アジャイルな見積りと計画づくり」の方は、実際にアジャイルプロセスで見積りを行うには具体的にどのようにやればいいのか、というところがとても詳しく書かれています。 また、最終章にあるケーススタディも「そんなうまくいくわけねーよ」というとそれまでですが、アジャイルがうまく回るとどのように進むのか、ということが具体的に書かれていて読みやすかったです。 少し
データモデリングなきアジャイル開発は危ういか？：An Agile Way：オルタナティブ・ブログ
尊敬するDOAの先輩である、渡辺さんがこう書いている。 「データモデルなきアジャイル」の危うさ、より その種のシステム（※引用者補記：販売管理システムや生産管理システムといった基幹系業務支援システム）をアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。 それに対して、稲見さんがこんなコメントをしている。 アジャイル開発と言っても色々で、最近流行りのScrumという手法は、開発の中身に関しては何も言及していません。ですが、私の知っているある人達
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ricoh UCS for iPad でみる エンタープライズ アジャイル開発
