InfoQ ホームページ アジャイル技術 に関するすべてのコンテンツ
-
技術的負債を貨幣化する
ほとんどのアジャイルチームが，技術的負債(Techninal Dept) は悪いものである，という考えを持っている。金銭的な負債と同じように利子負担を伴なうからだ。技術的負債の利子はソフトウェアを維持・拡張するために要する余分な労力，という形で支払われる。アジャイル実践者たちの多くが技術的負債を可能な限り早く返済するよう勧めているが，それを定量的に把握するための貨幣化(monetize)を実現できているアジャイルチームは稀である。
-
アジャイル ドキュメンテーション：その明確さは？
アジャイルのコミュニティにおいて，ドキュメントは明らかなテーマであっただろうか？ どれ位の量のドキュメントを作る必要があるのだろう？ 必要なものは？ 不要なものは？ 従来の開発プロセスのドキュメントをアジャイルに移行する方法は？ アジャイルコミュニティにおいてドキュメントは，明確な定義に欠けている分野なのだ。
-
US Scrum Gathering 2010 "ディ―プドライブ”の日として開始
3月8日月曜日、Orlando州で The 2010 US Scrum Gatheringが開幕し "ディープダイブ"による学び、コラボレーション、前向きなディベートが盛り込まれた素晴らしい一日が始まった。
-
「邪魔をしない」ことを要望するチームメンバ
多くの開発者は、孤立して作業をしたがるが、それは多少の時間であり、決して常時というわけではない。XPでは、「洞穴と共通の部屋(Caves and Commons)」と呼ばれる部屋の配置を推奨している。共通のエリアは、浸透性のあるコミュニケーションを最大化するように構成されている。洞窟は、個人的なメール、電話、クイック・スパイクなどを行うための孤立を推進することを意味する。ところが、チームメンバが、このような孤立した状態での作業を過度に要望することがある。
-
ストーリーポイントとは何か？必要ものなのか？
Michael de la Maza氏は、ストーリーポイントとは厳密には何なのか？という疑問を投げかけている。彼が答えを探したところ、「ストーリーポイントとは漠然とした時間単位を表すものだ」や「ストーリーポイントはスクラムチームが使っている任意の測定基準であり、1つのストーリーを実装するのに必要な労力を測るために使われる」など、いろいろな意見があることがわかった。
-
Agile と Scrumの重大な欠陥を明らかにする
ソフトウェア開発は、創造的なプロセスである、と知られている。 ソフトウェア開発の動的な環境が無視された、伝統的な方法論の失敗によって、Agile な方法論がかなり人気を得た。Agile 方法論、特に Scrumの採用が増えている。しかし、すべてが Agileでうまく行っているか？ Kai Gilb氏は、そう思っていない。彼は、 Agileには重大な欠陥があると言っている。
-
実験駆動開発 - ポストアジャイルの手法
TDDとBDDは現在広く使��れているソフトウエア開発技術だ。しかし、TDDやBDDを単に適用するだけではビジネス機会を逸したり、さらに悪いときにはビジネスにネガティブな影響を与えてしまう。TDDとBDDでは解決できないふたつの問題とは、どのようにアプリケーションの使いやすさを計測するのか、そして顧客からどのようにしてフィードバックを得るのか、ということだ。実験駆動開発(EDD)はこの問題を解決できるか。
-
ふりかえりを改善するためのルール
James Carr氏は最近、ふりかえりを改善するための5つのルールを公開した。これらのルールは、成功したものも失敗したものも含む、何百回にも及ぶふりかえりの経験に基づいている。
-
Pomodoro Technique 批判
: Pomodoro Technique は，本当に期待どおりのものだろうか？ 問題を細かく分析しすぎて，必要以上に複雑にしているのではないだろうか？ InfoQ では Mario Fusco 氏による Pomodoro Technique への批判を，読者のみなさんにもご紹介する。
-
バーンダウンチャートを解読する
バーンダウンチャート</a>はアジャイルチームにおいて最も有用な情報ラジエーターの一つであると考えられている。それは、残された片づけるべき作業の量（y軸）と時間（x軸）のグラフィカルな表現である。興味深い点はバーンダウンチャートの分析によって、チームがどのように活動しているか、そして、何をすればさらに改善することができるのかについて複数の指針が明らかになることである。
-
ペア・プログラミングの実際の効果
Stuart Wray氏は、チーム環境でペア・プログラミングの実際の効果について分析する記事を執筆し、ペア・プログラミングの効率の改善に適用可能な4つのメカニズムを特定しており、さらに、それらのメカニズムが、製品品質の改善をもたらす理由についても分析している。
-
デイリースタンドアップのコツ - まとめ
デイリースタンドアップが長い日次進捗報告以外の何ものでもなくなり、メンバに無視され始めるという話はよく耳にする。これを始めとしたスタンドアップの落とし穴を避けるために、どのようなテクニックがあるだろうか？
-
継続的デプロイのプラクティス
継続的デプロイは、リーン開発の"仕掛排除"運動で最近注目されている。多くの人が、これについて興味を持ち、価値のある目標を見出している一方、これが実際どのように達成されたかをなかなか可視化できていない。Ash Maurya氏は会社で起こった自身の経験を説明することで、このギャップを埋めようとしている。
-
アジャイルの"ルール"を"ガイドライン"に変えられるか？
一般的にルールとは，ある行動に関して定義された基準のことをいう。ルールには従わねばならない。法律の非公式な呼び方が "ルール" である，と言い換えてもよいだろう。これに対してガイドラインとは，決められた手順に従うことによって，特定のプロセスを合理化する目的のものだ。定義上は，ガイドラインは義務ではない。アジャイルチームはルールを語るべきだろうか，それともガイドラインで十分なのだろうか？
-
リーン＋リアルオプション＝複雑さとリスクの低減
リアルオプションとは、金融オプション数学に基づく意思決定プロセスである。これは通称「白本」とよばれるExtreme Progamming Explainedにおいて、Kent Beck氏が1999年に言及しているものだ。近年ではアジャイル主義者たちがリアルオプションがアジャイルとどのように交わるのかについて調査してきた。現在はChris Matts氏とOlav Maasson氏が、特にリーンソフトウェアコミュニティに対して発言している。リアルオプションを採用することでリーン開発が改善するというのだ。