InfoQ ホームページ アジャイル技術 に関するすべてのコンテンツ
-
AtlassianがBuilderの後継機能Taskを搭載した最新のBambooをリリース
アジャイル開発の議論が継続的統合(CI)から継続的開発に移行するにつれ、CIサーバはビルドプロセス全体の自動化をさらに促進している。Atlassianは今日、Bamboo 3.1をリリースした。これにはTaskと呼ばれる新しい機能が搭載されている。Atlassianはこの機能で開発者の継続的開発を支援したいと思っている。
-
Jenkins，Hudson，そして Eclipse
Hudson を Eclipse 財団に移行する先日の提案に伴って，これが Jenkins と Hudson の再統合につながるのではないか，さらにはコードライセンスの EPL への変更があり得るのではないか，などの憶測が生まれている。Jenkins コミュニティとして Eclipse 財団への参加が望ましいかどうか，本日この後 Jenkins IRC チャネル上で議論が行われる予定だ。
-
Oracle，Hudson の Eclipse 財団への移行を提案
Oracle は Hudson プロジェクトを，商標権とドメイン名を含めて Eclipse 財団に譲渡する提案書を作成した。既存の後援企業 (Oracle と Sonatype) に加えて，他の参加企業も Hudson の独立組織およびプロセスへの移行を支持しており，同プロジェクトへのコミッタ増員を計画中である。
-
-
HudsonがHudson 2.0として復活
HudsonのHudson/Jenkinsフォーク以来最初の重要なリリースが行われ、今後OSGi/セマンティックなバージョニングに従う新しいバージョニングスキームが使われることになる。このリリースには、OSGiランタイム内での実行がより容易になる新しいJSR330依存性注入モデルが含まれ、特殊なHudsonアノテーションとの分離が実現されている。
-
ユーザーストーリーを分割する方法
アジャイル技法が十分に機能するようにユーザーストーリーを細分化することは、ほとんどの新しいアジャイルチームにとって困難である。アジャイルコミュニティのメンバーが、いくつかの記事を通してユーザーストーリーを効果的に分割する方法についてのガイダンスを提供している。
-
Google Guice 3.0を利用したアノテーション駆動による依存性注入
先月下旬Googleは、依存性注入（Dependency Injection、DI）デザインパターンを実装するJavaフレームワーク、Guice 3.0をリリースした。Guiceの裏にある動機は、決まり切ったファクトリを書く必要性を減らすことで、プログラマがDIコードを書くことを容易にすることである。この記事では、3.0の新機能について分析し、Guice 3.0がどのようにSpring DIをサポートしているかを見、さらに、（MiniGuiceとしても知られる）Guice 4.1を紹介する。
-
一人のプロダクトオーナーという問題に対する解決策
プロダクトオーナーはスクラムで最も大変な役割のひとつだと言えるだろう。プロダクトオーナーは一人でプロジェクトの成功に責任を持ち、チームにビジョンを伝えることで開発活動をリードすることが期待されている。そして、チームが最大限のビジネス価値を生み出すのを支援することが期待されている。これは一人にたくさんのことを期待していないだろうか？
-
-
Tasktop 2.0がTask Federation と クロス－リポジトリの Agile Plannerをサポート
アプリケーション ライフサイクル管理 (ALM)コラボツール、Tasktop の最新バージョンは、Task Federation、クロス－リポジトリなアジャイル計画ツール、HPの Agile Acceleratorや SmartBear CodeCollaboratorのような他社のALMツールへのコネクターをサポートしている。 Tasktopチームは先週 Hudson CIツールとの統合を提供するバージョン2.0をリリースした。
-
プロダクトオーナーパターン
プロダクトオーナーの役割は、多くのオンライン・フォーラムやブログで定期的に議論されている。この役割の持つ課題と、そこに含まれるさまざまな責任は、議論やアドバイスが生み出される原因になってきた。最近、プロダクトオーナーという役割と、アジャイルプロジェクトの中でプロダクトオーナーが確実にやるべき重要な活動、さらにプロダクトオーナーとプロダクトマネージャの違いについて、いくつか議論がなされた。
-
収縮の価値
ITとアジャイルの熱狂的な支持者のひとりであるMike Burrows氏はKanbandevグループである議論を始めた。このグループはコミュニティを展開/収縮パターンの探索に連れ出している。氏の始めた議論はInfoQの他の記事で紹介した。その記事では要求を細かく砕いて展開する方が、砕いたものを再度まとめることよりも価値があると考える実践者たちの見方を紹介した。しかし、多くの人がこのパターンは両方とも便利だと思っている。
-
まとめ直し(collapse) の価値
アジャイル手法では，機能を小さなユーザストーリに分解(“展開”)することを推奨している。しかし，コードが完成した後は，これらを元の機能にまとめ直すべきなのか，それとも全体を１つのユニットとして扱う方がよいのだろうか？ まとめ直し(collapse) に利点があるとすれば，それはどのようなものだろう？
-
『Agile Japan 2011』開催 ー広がる つながる 動き出すー
今年で3回目となる 「Agile Japan 2011」が開催される。今年のテーマ『広がる つながる 動き出す』のもと、 基調講演は "Fearless Change - 不安を乗り越えて組織改革を推進するには" と題し、 リンダ・ライジングによる講演が行われる。
-
アジャイルはパズルのピースでしかない
最近、いわゆるノキアの失墜とそもそもスクラムが組織を助けるかどうかについて、多くの見解が表明されている。トヨタが品質問題のために自動車のリコールをしたときも、同様の懸念と心配があがっていた。アジャイルは、製品開発の中心要因なのだろうか?