InfoQ ホームページ アジャイル技術 に関するすべてのコンテンツ
-
Simple Module SystemはJSR294を救えるか?
この1ヶ月の間、Java Modularityワーキンググループ(JSR 294)の現状について多くの議論がなされた。JSRは、異なるモジュールシステム(特にSunのProject JigsawとOSGi)間の共通基盤を見つけようとしているが、現在の提案はあまりにも複雑であり、世界初となるメタモジュールシステムという概念を導入している。Simple Module SystemはJSR294を救えるか?
-
ペアプログラミングは大衆向けでない？
ペアプログラミングはここ数年で一番議論が続けられているプラクティスのひとつだ。ほとんどの支持者はペアプログラミングの利点をほめたたえることを惜しまないが、その人たちでもペアで作業することの導入に苦労があることを認める人は多いだろう。それはなぜか。Obie Fernandez氏はそうなる理由と考えられる10の項目を挙げている。
-
スプリント計画：ストーリーポイント VS 作業時間
スプリント計画にストーリーポイントと作業時間のどちらを用いるかについて，決着の付かない議論が長く続いている。Mike Cohn 氏がユーザストーリーをタスクに分割して時間見積を行う方法を推せば，Jeff Sutherland 氏が自身の関わった最高のチームでのストーリーポイントを使ったバーンダウンの例をあげてみせる，といった具合だ。
-
コンテキストスイッチ対策が必要だって？じゃあ邪魔されよう
コンテキストスイッチとは、あるタスクから別のタスクへと、焦点や注意を比較的短時間で切り替えることだと定義される。これはチームメンバとその人が取り組んでいるプロジェクトにとって、有害であると広く考えられている。Charles Miller氏はAtlassian社で使っていたコンテキストスイッチに対処する方法について述べた。
-
機能テストツールのワークショップ
機能テスト自動化ツールのテスト技法を改善することに興味を持つ人々が、Agile 2009の前の日曜日に、年に１度のワークショップに集まった。そこでは以下のようなトピックが扱われた。様々なツールのライトニングトークデモ、 Cucumberの.NETへの移植、既存の機能テストツールの互換性についてスプレットシートを使った文書化、キャプチャ/プレイバックツールの限界。
-
XP祭り2009 ～XP10周年:ソフトウェア開発から日本が変わる～
XP10周年の今年、日本でXPの啓蒙を担ってきたXPJUGがXP祭り2009～XP10周年:ソフトウェア開発から日本が変わる～と題してカンファレンスを09月19日早稲田大学にて開催する。
-
'アジャイルの三角形'によるアジャイルのパフォーマンス測定
伝統的なソフトウェア開発チームは，ソフトウェアの'鉄の三角形(Iron triangle)'の領域内で活動すると考えられている。この三角形の３つの辺は，スコープ，スケジュール，費用である。Jim Highsmith 氏は，この鉄の三角形がアジャイルチームの柔軟性に対して多くの制約を課すものだとして，それに代わるアジャイルの三角形(Agile Triangle)を提案した。
-
デプロイメントにおける最終責任時点を可能にする
設計判断をするときに問われる興味深い質問がある。「これは正しい設計か？」ではなく「このアプローチはコミットメントを生み出すか」というものだ。 KanvanDev Yahoo!グループでは、こうした質問やうまい答えを実現するための様々なアプローチ、そこから得られる利点などについて議論がなされた。
-
Agileプロジェクトでどうやって知識を伝達する方法
知識の伝達を特徴づけるのは、文脈についての理解を、1つの単位(個人や、チーム、部門、組織)からもう1つの単位へ転送することだ。Steve Bockman氏は一連の実験を行い、Agileプロジェクトで知識を伝える最適な方法を探り出そうとした。
-
テストを分類する
単体テスト、機能テスト、システムテスト、結合テストの違いは何か？デベロッパテスト、ストーリーテスト、受入テストはどうだろう？テストのネーミングと分類に関してコンセンサスは形成されていないようだが、多くのアジャイル開発プロセスにおいてテストは中心的な役割を担っている。TDDディスカッショングループの議論ではこれらの分類が行われ、見通しを良くするよう試みられている。
-
２タイプのアジャイル文書 ― ２種類しかない
アジャイルマニフェストには、「動くソフトウェアが、どんな文書よりも理解しやすい」、とある。このおかげで、アジャイルプロジェクトでは、文書は、要らないと多くのチームに信じられるようになった。アジャイルを批判する人たちは、その方法論の弱点を示すのに、アジャイルの少ない文書を指摘する。 Eelco Gravendeel氏は、アジャイルには、たった２種類の文書しかない、と言う。
-
価値とベロシティ、そしてバリューベロシティの比較
多くのアジャイルチームでは'価値'とチームの'ベロシティ'は正比例すると、暗黙的に前提している。幾つかのケースにおいては本当にそう見られる。しかしながら、多くの場合はチームのベロシティが本当に価値を提供できたかはほとんど示されない。
-
スピードアップのためのスローダウン
チームが最も生産的なのはそのチームのメンバが能力を最大限に発揮して活動している時である，と普通は考えられている。この常識に反してSteve Bockman 氏は，このような仮定が常に正しいとは限らない，ということを言っている。生産性を向上させるために時にはスローダウンし，最大限の能力以下で働くことが必要である，というのだ。
-
FisheyeとCrucibleで「ソーシャルネットワーキング」が可能に
Atlassian社のFisheye 2(ソースコードリポジトリブラウザ)とCrucible 2(コードレビュア)の最新版は、完全に刷新されたUIを持ち、開発者が、作業に対するのと同様に、ある意味ソーシャルネットワーキングであるチームをフォローできるようになった。Crucible 2は、同時に反復的なコードレビューの概念もサポートする。
-
アジャイル/スクラムプロジェクトにおけるバグへの対応
よくされる質問がある。スクラムでは、チームがバグをどう処理することを推奨しているのか？プロダクトバックログに入れるべきなのか？それとも、別のバグリストに入れるべきなのか？もしバグがバックログにあるのなら、プロダクトオーナーが優先順位をつけるのか、それとも、自動的に最重要項目になるのか？別のバグ修正スプリントをするべきなのか？