InfoQ ホームページ Pair Programming に関するすべてのコンテンツ
-
チームの腐ったリンゴを扱う
ここ数日間、Scrum Development Yahoo Groupでチームの1人の「働きが少ない」場合に何をするかについてとても活発な議論がなされている。Rotten apple in Scrum team(スクラムチームの腐ったリンゴ) の130以上のレスポンスの中で、最初の質問へのアドバイスから、チームのやる気や誰がそれを管理するかという話、個人を計測する昔からの論争、チームが本当に「チーム」であるかどうか見分けることなどへ議論が及んだ。
-
職人のペアプログラミングツアー
Corey Haines氏が、最近米国中部でとてもユニークな「ペアプログラミングツアー」に乗り出した。この革新的な旅を始めて三週間になり、Haines氏は数多くのユニークな洞察を明らかにするビデオインタビューを投稿している。
-
ルールを破ってもいいのはいつか？
「Just Ship Baby」の中で、JUnit Frameworkの作者、Kent Beck氏は、すべてのアジャイルプロセスとプラクティスのポイントは、出荷するソフトウェアを作り出すことだと指摘する。それらがソフトウェアを出荷する障害になるならば、おそらくあなたはルールを破る必要がある。
-
Minibook: 塹壕より Scrum と XP
Agileを始めるときは、とても分かりにくいです。一体どこから手をつければいいのでしょう？この物語はそんな皆様の一助になれば幸いです。本書は、スウェーデンにある、とある40人ほどの会社で、どのようにAgileとXPを実行したか、プロセス改善を行ったかを記しています。
-
XPにフィットするかを見極める方法
多くのアジャイラーたちは、誰もがアジャイルに馴染むわけではないと考えている。人によっては、アジャイルの哲学にうまくフィットせず、否定的な傾向をチームにもたらす。XPグループ上で、人がXPにうまくフィットするかを見極める方法について興味深い議論があった。
-
TDDへの見解：品質は思索と熟考から得られる。バグの抑制からではない。
Michael氏はユニット・テスト、インテグレーション・テスト、TDDそしてクリーン・ルーム・ソフトウェア開発について言及し、コードの品質というのは思索と熟考から得られるのであってバグの抑制から得られるのではないと結論付けている。
-
-
Interview: Coplien氏とMartin氏、TDDとCDDそしてプロフェッショナルの定義について大いに語る。
JAOO '07 で「今時、ユニットテストを実施してないコードを納品するのは無責任な開発者だ」というBob Martin氏の主張について、議論が起こった。このInfoQビデオは、BobとJim Coplien氏がこれに関連する話や、いくつかの他の話題について議論する様子を納めたものだ。
-
中国でのスクラム導入の話
InfoQ China の編集者Jacky Li氏による最近の調査で、中国のスクラム導入のまったく異なる５つの事例が比較された。これには、成功した実施例も、失敗した例も含まれている。Jacky氏は、各プロジェクトに同じ質問をして、まったく異なる回答を得た。サンプルが少ないとはいえ、スクラムによる改善が成功を確実にするものではないことを指摘する興味深い比較である。
-
ベッドタイムユーザストーリー: カウボーイとおとぎ話
「ソフトウェアエコノミストで国際的なコンサルタント」を自称するDavid Longstreet氏が、昨年、アジャイルソフトウェア開発はおとぎ話で、ただ「カウボーイ」開発を正当化しようとしているだけだと主張する論文を発表した。
-
継続インテグレーションとデータベースのバージョン管理
原則として、データベースに対する作業は必ずバージョン管理しなければならない、と強く主張した記事を投稿した後で、Scott Allen氏はデータベースのバージョン管理を最大限に利用する手法について詳しく述べている。彼は、ベースラインを作成し、スキーマのリビジョン管理に変更スクリプトを使い、データベースの（ビューやストアドプロシージャ、ファンクション、トリガ等の）プログラムされたオブジェクトを管理し、そしてブランチやマージ処理を利用する、包括的で実用的な手法を紹介している。
-
TDD/BDDは不完全なユニットテストを招くか？
Peter Ritchie氏は、TDDやBDDにこだわることで、良いユニットテストを書かなくなる傾向があるのではないか、という懸念を表明した。特に「インタラクションテスト(interaction testing)」というマントラは、不完全なユニットテスト、すなわち、どのような条件下で利用されても稼働するユニット(オブジェクト)である、という証明ができていないテストをもたらすと述べている。Peter氏の考えで最も興味深いのは、TDDとBDDのそもそもの意図に対する反対意見と受け取れるところだ。
-
開発のスピードとは本当に素晴らしい「ものさし」なのだろうか？
近い将来を予測する能力以外に開発のスピードを測定することによって、どんな価値が得られるのだろうか？J.B.Rainsberger氏は速度を追求する時間を削減し、また削除することによって最大の益がもたらされるような、チームに無駄な労力を使わせている領域が何なのか特定���る事を推奨している。