BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アジャイル技術 に関するすべてのコンテンツ

  • いつイテレーション/スプリントをの延ばすか

    まさにスプリントが終わろうとしているとき、あなたは重要なストーリーが実現できないのに気付く。あなたはどうするか。スプリントの期間を延ばすか。バックログのなかにストーリーを戻すか。チームはいつもひとつのスプリント内でできることを過大評価していないか。どうすればよいだろう。

  • カンバン方式を適用する間違った理由と正しい理由

    カンバン方式の目的は各工程の間でWIP (Work-In-Process)、つまり在庫を最小にすることだ。それには、下流の工程が必要な部品だけ上流の工程が作るようにする。最近になってリーン方式とカンバン方式は一般的になってきた。多くの企業がカンバンボードを用意してWIPを抑制し、ムダを省いている。Michael Dubakov氏はカンバン方式を適用する間違った理由と正しい理由を調べた。

  • Pomodoro - 時間管理へのアジャイル的アプローチ

    Pomodoro Technique というパーソナルな時間管理手法が,アジャイル実践者の間で人気を獲得しつつある。Pomodoro には,アジャイルチームが使用するものによく似たプラクティスがいくつも含まれている。time-boxing,調査と順応(inspect-and- adapt)の繰り返し実施,ローテク志向のツール選択,継続可能なペースの維持に重点を置いている点,などだ。

  • PairWithUs:アジャイルソフトウェア開発のお手本動画が見られるサイト

    多くのプログラマにとってプログラミング技術を学ぶよく知られている方法として例から学ぶ方法がある。具体的にいえば、他の人がどうしているのか、観察することだ。Antony marcano氏とAndy Palmer氏の"PairWithUs"では観察するだけの素敵なサイトを公開している。

  • 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の前の日曜日に、年に1度のワークショップに集まった。そこでは以下のようなトピックが扱われた。様々なツールのライトニングトークデモ、 Cucumberの.NETへの移植、既存の機能テストツールの互換性についてスプレットシートを使った文書化、キャプチャ/プレイバックツールの限界。

  • XP祭り2009 ~XP10周年:ソフトウェア開発から日本が変わる~

    XP10周年の今年、日本でXPの啓蒙を担ってきたXPJUGがXP祭り2009~XP10周年:ソフトウェア開発から日本が変わる~と題してカンファレンスを09月19日早稲田大学にて開催する。

  • 'アジャイルの三角形'によるアジャイルのパフォーマンス測定

    伝統的なソフトウェア開発チームは,ソフトウェアの'鉄の三角形(Iron triangle)'の領域内で活動すると考えられている。この三角形の3つの辺は,スコープ,スケジュール,費用である。Jim Highsmith 氏は,この鉄の三角形がアジャイルチームの柔軟性に対して多くの制約を課すものだとして,それに代わるアジャイルの三角形(Agile Triangle)を提案した。

  • デプロイメントにおける最終責任時点を可能にする

    設計判断をするときに問われる興味深い質問がある。「これは正しい設計か?」ではなく「このアプローチはコミットメントを生み出すか」というものだ。 KanvanDev Yahoo!グループでは、こうした質問やうまい答えを実現するための様々なアプローチ、そこから得られる利点などについて議論がなされた。

  • Agileプロジェクトでどうやって知識を伝達する方法

    知識の伝達を特徴づけるのは、文脈についての理解を、1つの単位(個人や、チーム、部門、組織)からもう1つの単位へ転送することだ。Steve Bockman氏は一連の実験を行い、Agileプロジェクトで知識を伝える最適な方法を探り出そうとした。

  • テストを分類する

    単体テスト、機能テスト、システムテスト、結合テストの違いは何か?デベロッパテスト、ストーリーテスト、受入テストはどうだろう?テストのネーミングと分類に関してコンセンサスは形成されていないようだが、多くのアジャイル開発プロセスにおいてテストは中心的な役割を担っている。TDDディスカッショングループの議論ではこれらの分類が行われ、見通しを良くするよう試みられている。

  • 2タイプのアジャイル文書 ― 2種類しかない

    アジャイルマニフェストには、「動くソフトウェアが、どんな文書よりも理解しやすい」、とある。このおかげで、アジャイルプロジェクトでは、文書は、要らないと多くのチームに信じられるようになった。アジャイルを批判する人たちは、その方法論の弱点を示すのに、アジャイルの少ない文書を指摘する。 Eelco Gravendeel氏は、アジャイルには、たった2種類の文書しかない、と言う。

BT