BT

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

寄稿

Topics

地域を選ぶ

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

  • 不満を言わないイテレーション

    完璧なソフトウェア開発プロジェクトがないのと同様、プロジェクトを運営する組織も完璧ということはありえない。もし、読者の関わっているソフトウェアプロジェクトの状況が悪化するとチームメンバーは不満を言い出すだろうか?それとも、立て直すためのアクションを取り始めるか?

  • 中国でのスクラム導入の話

    InfoQ China の編集者Jacky Li氏による最近の調査で、中国のスクラム導入のまったく異なる5つの事例が比較された。これには、成功した実施例も、失敗した例も含まれている。Jacky氏は、各プロジェクトに同じ質問をして、まったく異なる回答を得た。サンプルが少ないとはいえ、スクラムによる改善が成功を確実にするものではないことを指摘する興味深い比較である。

  • Article: 複数のアジャイルチームでのバージョン管理

    このレポートでは複数のチームが動いているアジャイル環境において、どのようにバージョン管理を行えばいいかを説明します。このスキームは"Scrum and XP from the Trenches(InfoQのミニブック)に出てきた企業で私たちが新しく採用した方法です

  • 複数のチーム開発向けアジャイルバージョン管理

    バージョン管理を厳密におこなうことがないので、すべてのチームのアジリティが激しく危険にさらされている。自由にリファクタリングをおこなう能力、安全に実験する能力、エラーから迅速に回復する能力は、安全網なしで構成されている。多くのアジャイル提議者は、バージョン管理を中心となる実務と位置づけている。

  • 管理者達へ:チームがコミュニケーションスキルを学習できるよう手助けせよ

    アジャイルの「自己組織化チーム」パラダイムは、チームメンバに新しいスキルを要求する。かつてプロジェクトマネージャに期待していたスキル ― 対人スキルだ。チームが自己組織化する為に、コミュニケーションとコラボレーションの新しいやり方を学習する手助けという重要な役割を、管理者は演じることができる。しかし、どこから手をつければいいのだろうか?

  • Article: 高い生産性を生み出すソフトウェア開発の秘伝

    何について学ぶのか?お互いのこと、テクノロジ、ドメイン、顧客など、すべてについてである。速く学習するチームは成功する。チームのパフォーマンスを妨げる目に見えない「学習ボトルネック」について詳しく知りたいのなら続けて読んでほしい。

  • Article: コーディング標準のためのガバナンスの自動化を実現する

    Mark Figley氏がコーディング標準とベストプラクティスの実施をビルドプロセスの一部として自動化する方法について説明しています。

  • アジャイルプロジェクトのファシリテートでは、燃え尽き症候群は避けられないのか?

    グループ・ファシリテーションのリストにのっている興味深いスレッドの中で、Jerome Passmore氏は、どのようにしてファシリテータの燃え尽き症候群に取り組み、予防するかという議論を始めた。燃え尽き症候群は現実の問題であり、そして自分に忍び寄ってきた時に判断できるように熟考することが解決の1つの鍵であるという点で、この議論に応じた人たちの意見はおおむね同じであった。

  • ディベート: アジャイルへの転換の成功率, 救いか?痛みか?

    Khanna氏の「アジャイルへの転換の成功率に関して、誰かメトリックス(基準となる数値)を持っていますか?」というメールを受け、Kent Beck氏、Ron Jeffries氏、Alistair Cockburn氏、Chet Hendrickson氏を含む多くのソフトウェア業界のエキスパート達が議論に加わり、このような統計値を策定することによる価値とリスクについて議論を行った。

  • 「ITゼネコンをぶっつぶせ」JJUGクロスコミュニティカンファレンスの見所をご紹介

    4月30日にJJUG(日本Javaユーザグループ)の総会兼春のカンファレンスである「クロスコミュニティカンファレンス」が開催される。ここではその見所を紹介する。

  • アジャイル組織の管理者の役割は何か?

    組織がアジャイル開発を導入しており、管理者たちが新たなロールを見つけようとしている。導入前に、おそらくアジャイル管理は仕様の作成およびタスクのアサインに関与していた。チームが自己管理されている今、ストーリー(スペックではなく)は、製品所有者からもたらされる。それでは、管理は何をするのか?

  • レトロスペクティブの第一(忘れられた?)ルール:やり遂げること

    非常に経験の浅いアジャイルチームでさえ、「Retrospective」という言葉を明確に理解している。しかし、悲しいことに、チームが実際に最後までやり遂げるような改善をおこなうために使用されないと、レトロスペクティブは無駄な努力になる可能性があることが、多くの場合見落とされている。 Gordon Pask Awardの受賞歴のあるJim Shore氏が、レトロスペクティブを最大限に活用する方法についてアドバイスをし、アジャイルハートビートでのアクティビティーの究極の場所を教えている。

  • 事務局よりお知らせ:記事内のリンクの修正を致しました

    先日より一部記事内で貼られているリンクの不具合がありましたが、修正が終わりましたので連絡致します。

  • Article: 反復的で自動化された、継続的なパフォーマンステスト

    アプリケーションのパフ���ーマンスを考えたとき、我々はアプリケーションが完成に近づくまでは、パフォーマンスのテストを滅多に行いません。我々が機能テストで行ってきた、反復、自動化、継続という教えをパフォーマンスについても同様に適用できるでしょうか?

  • Mingle 2.0のプレビュー

    4月15日、ThoughtworksがMingle 2.0をリリース予定である。初回のリリースから9ケ月ぶりのことである。InfoQは製品管理者であるAdam Monago氏にインタビューをし、その新機能について話を伺った。

BT