BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ Agile に関するすべてのコンテンツ

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

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

  • デマルコ、ソフトウエアエンジニアリングの40年間を振り返る

    NATOのソフトウエアエンジニアリング会議から40年経ち、トム・デマルコはソフトウエアエンジニアリングの信念の進化において、自身が支持したメトリクス指向の方法論が、"変革を起こすこと。世界を変えるソフトウエアを作ること。"を目的にする現実の開発現場では、本当は邪魔になっていたのではないかと、振り返った。それとも、彼の当初の助言はやはり有効なのだろうか。彼自身は、"有効ではなかった"と、Software Engineering誌の"時代はやって来て、そして過ぎ去ってしまったのか"と題した記事で書いている。

  • アジャイルの導入: プロジェクトは飛び込み、企業は徐々に踏み込む

    アジャイルの導入は徐々に「新しいことをやってみる」方法がよいのか、すべてを賭けて「頭から飛び込む」アプローチがよいのかという激しい論争が数多くある。Johanna Rothman氏は、プロジェクトは全部飛び込み、企業は徐々に進めるべきだと言う。

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

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

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

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

  • テストを分類する

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

  • Google Waveプレビューが9月30日に公開 - この先どうなっていく��

    Google Wave Previewの一般ユーザへの公開が9月30日に始まることを受け、Wave APIのテクニカルリーダーDouwe Osinga氏は、彼のチームが今後の方向性に沿った作業に取り組んでいることをWave Google Groupに投稿した。

  • ソフトウェアの負債には多額の費用がかかる

    “Continued Delivery of High Values as Systems Age”(システムの年数を重ねながら、高い価値を提供し続ける)という最近の記事において、 Chris Sterling氏がソフトウェアの負債の概念について論じている。“ソフトウェアの負債は、長年にわたってシステムの変わりやすい性質を軽視し、急いで完成させることに注目し続けるときに蓄積していくものだ。”ソフトウェアの負債は技術的負債以上のものであり、価値を提供する能力に影響する様々な面を含む。

  • マネジメントはどうやってアジャイル開発に貢献するか

    Accunoteの新しいCOOに任命されたMark Balabanian氏は、マネージャやマネジメントがScrumチームを支援するにはどうしたらいいのか、と問いかけている。彼はScrumについての本を読み終わって、次に何をしたらいいか知りたがっていた。Cory Foy氏、John Galvin氏、Peter Stevens氏、Lysaa Adkins氏、そしてMicheal Spayd氏が助言をしている。

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

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

  • ソフトウェア開発における7つのムダを見る

    リーンソフトウェア開発の基本は、ムダの最小化を追求することである。トヨタ生産方式は、製造業の7つの代表的なムダを公表し、その後、この7つのムダは Poppendieck夫妻によって、われわれソフトウェア開発業界に適用された。Jack Mulinsky氏は、agilesoftwaredevelopmentにて、これらのムダを紹介する一連の記事を最近投稿した。

  • 価値とベロシティ、そしてバリューベロシティの比較

    多くのアジャイルチームでは'価値'とチームの'ベロシティ'は正比例すると、暗黙的に前提している。幾つかのケースにおいては本当にそう見られる。しかしながら、多くの場合はチームのベロシティが本当に価値を提供できたかはほとんど示されない。

  • CodePlexのWikiエンジンがオープンソース化

    Microsoftのオープンソースサイト、CodePlexからWikiレンダリングエンジンがAPIとしてオープンソースになりました

  • アジャイルが「チームの5つの機能障害」に取り組む

    ITマネージメント・ソリューションの大手プロバイダにおける部長である、Tathagat Varma氏は、アジャイルの生産性改善がチームワークの改善に繋がるのではないか、と思った。彼は、アジャイルの価値と実践をPatrick Lencioniのビジネス物語「チームの5つの機能障害」と対比させて、分析している。

  • EUソフトウェア責任訴訟-半数はユニットテストが対処法だという

    Typemockの調査によると、52%の.NET開発者がユニットテストは会社がEUソフトウェア責任法案による訴訟を避けるのに一役買うと思っている。これはどういうことか?

BT