InfoQ ホームページ Pair Programming に関するすべてのコンテンツ
-
制約は利点の仮の姿だ
ソフトウエアを構築することは多くの制約を管理することと密接に関連する。制約とは時間、資金、技術、意思決定、互換性、規則、そして人や業務のプロセス、またはこれらすべてを合わせたものからなる。Jim Bird氏は、創造性を育て正しいソフトウエアを作る上で、スクラムやXPによって背負わされる制約が役にたつことについて論じた。
-
ペア・プログラミングの実際の効果
Stuart Wray氏は、チーム環境でペア・プログラミングの実際の効果について分析する記事を執筆し、ペア・プログラミングの効率の改善に適用可能な4つのメカニズムを特定しており、さらに、それらのメカニズムが、製品品質の改善をもたらす理由についても分析している。
-
-
PairWithUs:アジャイルソフトウェア��発のお手本動画が見られるサイト
多くのプログラマにとってプログラミング技術を学ぶよく知られている方法として例から学ぶ方法がある。具体的にいえば、他の人がどうしているのか、観察することだ。Antony marcano氏とAndy Palmer氏の"PairWithUs"では観察するだけの素敵なサイトを公開している。
-
ペアプログラミングは大衆向けでない？
ペアプログラミングはここ数年で一番議論が続けられているプラクティスのひとつだ。ほとんどの支持者はペアプログラミングの利点をほめたたえることを惜しまないが、その人たちでもペアで作業することの導入に苦労があることを認める人は多いだろう。それはなぜか。Obie Fernandez氏はそうなる理由と考えられる10の項目を挙げている。
-
XP祭り2009 ～XP10周年:ソフトウェア開発から日本が変わる～
XP10周年の今年、日本でXPの啓蒙を担ってきたXPJUGがXP祭り2009～XP10周年:ソフトウェア開発から日本が変わる～と題してカンファレンスを09月19日早稲田大学にて開催する。
-
Agileプロジェクトでどうやって知識を伝達する方法
知識の伝達を特徴づけるのは、文脈についての理解を、1つの単位(個人や、チーム、部門、組織)からもう1つの単位へ転送することだ。Steve Bockman氏は一連の実験を行い、Agileプロジェクトで知識を伝える最適な方法を探り出そうとした。
-
ペアプログラミングの1ドルの価値
"なぜこの世界では1つの仕事を2人でするのか?" 初めてペアプログラミングの考え方を紹介されたとき、多くの人は最初にこのように反応する。本質的に、彼らは、ペアプログラミングとはある部分のコードを書くコストが2倍になることだと考える。Dave Nicollete氏が、ある計量的な考え方を示し、ペアプログラミングはお金を無駄にするのではなく、節約することを示している。
-
なぜTDDとペアプログラミングで生産量が増えるのか
テスト駆動開発」と「ペアプログラミング」は、アジャイルプラクティスで最も広く知られているものの2つであるが、まだそれほど多くのアジャイルチームによって実践されてはいない。たいていその理由として、TDDやペアプログラミングなどのプラクティスを取り入れるには「忙しすぎる」点が挙げられるだろう。要するに、これは高いコード品質を得ようと努力することが生産性を低下させることを示唆している。Mike Hill氏は、この論理がなぜ重大な誤りであるか説明している。
-
良いベロシティ
Buddha Buck氏は、最近、Extreme Programmingのメーリングリストにおいて、2週間のイテレーションを行っている7人程のチームにとって「良い」と考えられるベロシティの範囲があるかどうかを尋ねた。Buck氏は、ベロシティが8以下の場合、チームのストーリーが大きすぎるのではないかと考えた。議論の結果、この質問の答えと、質問の裏にある別の質問が得られた。
-
コード再利用へのアジャイルアプローチ
Extreme Programming Yahoo Groupの最近のディスカッションにおいて、ソフトウェアを再利用可能にすることと、必要になるまでコードを書かないというXPのプラクティスの間で明らかな対立が起こった。Ron Jeffries氏その他の人たちは、コード再利用の費用と効果、そして、アジャイル環境でコードの再利用を行う方法と時期についての考えを共有した。
-
見習い期間のモデル
Bob Martinおじさんは、見習いとの経験、および見習いから熟練職人に進むための鍵が何かと考えるかについて、最近書いた。 彼は2人の仮想の見習いについて記述している:Samは同じ師匠の下で15年弟子として過ごした開発者。もう一人のJasmineは途中で彼女のスキルを伸ばすために数回仕事を変更した(したがって師匠も変更した)。
-
アジャイルにすべてを導入する
2ヶ月前、InfoQはJim Shore氏の人気の記事を紹介した。それは、組織が「アジャイル」を名前だけで導入し、実際にアジャイルであるために本当に意味するものの導入に失敗するという、現在増えているコミュニティの傾向を強調するものであった。コミュニティリーダーとその他の人たちは、この状況で何が起きているのか彼らの考えを投稿し、Shore氏の最初の立場から、最近さらに数歩踏み出している。
-
タスク単位ではなくストーリー単位で作業を行う
実装作業をチーム内で分散して行うために、また、適度な粒度での進捗のトラッキングを行うために開発者はユーザーストーリーをタスクへと分割する。不幸なことに、ストーリーをタスクへと分割してみると重大なタスクばかりになってしまいイテレーション内にそのストーリーを終えることができない、といったことが起こりうる。
-
ペア・プログラミング vs. コード・レビュー
ペア・プログラミングとコード・レビューは共にソフトウェアの品質を向上させると同時に知識を共有するための取り組みである。Agile vs. Lean、XP vs. Scrum、そしてvi vs. Emacsといった議論が収束した今、開発者たちはペア・プログラミングとコード・レビューのメリットを比較し始めている。