InfoQ ホームページ アジャイル技術 に関するすべてのコンテンツ
-
ソフトスキル(Soft Skill)が最も重要 - アジャイル・ボストン・オープンスペース報告
アジャイル・ボストン・ユーザグループ(Agile Boston user group) は先週，OpenSpace カンファレンスを終日開催した。セッションのひとつは，自分および／または自チームの組織に所属する，他グループに対する影響力行使に関するものだった。セッションの参加者たちは，それぞれ異なる状況と問題について理解し合い，事態を改善するための複数の戦略を見出すことができた。そしてその中に，アジャイルのプラクティスは含まれていない。
-
繰り返しタスクはアジャイルの臭い？
ストーリーを水平方向のタスクに分割することは「アジャイルの臭い」か？これはスクラム/アジャイル計画会議によく見られ、チームの顧客価値へのフォーカスを損なう悪習なのか？代わりに提案されているのはどんなことなのか？
-
How to Audit an Agile Team
アジャイルプロジェクトのステークホルダが，チームが採用しているアジャイルのプロセスと実践の効果を測定するために，経験豊富なアジャイルコーチの援助を求めるのはよくあることだ。その意図は欠点を埋めて，チームをより効率的にすることにある。Scott Killen 氏は最近，Yahoo の Scrum Development グループ に アジャイルチームの監査方法 に関するスレッドを立ち上げた。
-
Maven, Ant, Rake: JRuby 1.5 の構成管理強化
4月末に予定されている1.5へのバージョンアップに向けて、JRubyプロジェクトはJavaとRubyの相互運用性を改善し続けている。これによって、Ruby開発者はJavaプラットフォームの利点をもっと強力に利用できるようになる。一方でJava開発者は既存のプロジェクトにRubyのツールを利用する利点を見つけるようになるだろう。
-
Toyota がウォーターフォールを使っている？
リーン(Lean)ソフトウェア開発はリーン生産方式にその着想を得ている。中でも Toyota がこの分野で，先駆者として行った活動の影響が大きい。その Toyota のソフトウェア開発部門が旧来型のウォーターフォールを使用していて，リーンソフトウェア開発では初期段階にある，と聞けば誰しも驚くだろう。
-
技術的負債を貨幣化する
ほとんどのアジャイルチームが，技術的負債(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軸）のグラフィカルな表現である。興味深い点はバーンダウンチャートの分析によって、チームがどのように活動しているか、そして、何をすればさらに改善することができるのかについて複数の指針が明らかになることである。