InfoQ ホームページ Agile に関するすべてのコンテンツ
-
一人のプロダクトオーナーという問題に対する解決策
プロダクトオーナーはスクラムで最も大変な役割のひとつだと言えるだろう。プロダクトオーナーは一人でプロジェクトの成功に責任を持ち、チームにビジョンを伝えることで開発活動をリードすることが期待されている。そして、チームが最大限のビジネス価値を生み出すのを支援することが期待されている。これは一人にたくさんのことを期待していないだろうか？
-
-
Tasktop 2.0がTask Federation と クロス－リポジトリの Agile Plannerをサポート
アプリケーション ライフサイクル管理 (ALM)コラボツール、Tasktop の最新バージョンは、Task Federation、クロス－リポジトリなアジャイル計画ツール、HPの Agile Acceleratorや SmartBear CodeCollaboratorのような他社のALMツールへのコネクターをサポートしている。 Tasktopチームは先週 Hudson CIツールとの統合を提供するバージョン2.0をリリースした。
-
-
-
プロダクトオーナーパターン
プロダクトオーナーの役割は、多くのオンライン・フォーラムやブログで定期的に議論されている。この役割の持つ課題と、そこに含まれるさまざまな責任は、議論やアドバイスが生み出される原因になってきた。最近、プロダクトオーナーという役割と、アジャイルプロジェクトの中でプロダクトオーナーが確実にやるべき重要な活動、さらにプロダクトオーナーとプロダクトマネージャの違いについて、いくつか議論がなされた。
-
Eclipse Mylyn 3.5でJenkinsが見える
リリースされたばかりのEclipse Mylyn 3.5には、タスク中心なビューの改善とBugzillaへの接続の追加がある。しかし最も大きな新フィーチャはJenkins/Hudsonのビルド状態が見えるのとテストの失敗を捉えて、ローカルにそれを再現できることである。
-
コミットメントとは何なのか
コミットメントはある行動を自分自身が引き受けることだと定義されている。スクラムではコミットメントは強い意味を持ち、スクラムの実践者はコミットメントを維持しなければ正真正銘のスクラムは成り立たないと言う。にもかかわらず、フォーラムにはコミットメントが遵守されないことについての質問があふれている。私たちはコミットメントの本当の意味を理解しているだろうか。
-
FireFox: Mozilla の望む新たな開発プロセス，Firefox 4, そしてロードマップ
Mozilla チームはリリースのスピードアップを図るため，Firefox の開発プロセスをスケジュール駆動に変更しようと考えている。数多くの改善を行った Firefox 4.0 が先日リリースされたが，ロードマップにはすでにバージョン5, 6, さらには 7 の概略プランが掲載されている。
-
-
アジャイルは幻滅の中にいるか
ガートナー社のハイプ曲線は新しい技術の成熟を表現する。新しい技術が表れたときの行き過ぎた熱狂やそれに続く幻滅を表現することができる。アジャイルの10周年を祝うなら、この10年は幻滅で締めくくられるべきなのか。
-
Googleの品質保証
以前はMicrosoftのアーキテクトを務め、現在はGoogleのテストエンジニアリングのディレクターであるJames Whittaker氏は“How to Break Software” シリーズで何冊かの著書がある。氏はGoogleがどのようにテストをしているかについて数回に渡って記事を書いた。Googleではテストは開発と共に行われ、テスターの数は比較的少ない。各製品は多くの人に触れられる前に一連のチャンネルで評価される。
-
-
NEC がユニファイド・コミュニケーション&コラボレーションのための新ソフトウェアアーキテクチャを発表
NEC corporation は先日の Enterpris Connect 2011 展示会で，リッチ・インターネットアプリケーションおよび IT アーキテクチャ指向の Unified Communication & Collaboration (UC&C) プラットフォーム・ソフトウェアアーキテクチャ を実演した。企業と顧客間のコラボレーションソリューションとしてリッチインターネットアプリケーションを使用する，仮想化プラットフォームである。
-
収縮の価値
ITとアジャイルの熱狂的な支持者のひとりであるMike Burrows氏はKanbandevグループである議論を始めた。このグループはコミュニティを展開/収縮パターンの探索に連れ出している。氏の始めた議論はInfoQの他の記事で紹介した。その記事では要求を細かく砕いて展開する方が、砕いたものを再度まとめることよりも価値があると考える実践者たちの見方を紹介した。しかし、多くの人がこのパターンは両方とも便利だと思っている。