
ケーススタディ: CAS Software AGにおけるEclipse Rich Ajax Platform
このケーススタディではEclipse RAP(Rich Ajax Platform)がCAS PIAのアーキテクチャにどう適用されているかに焦点を当てます。CASがRAPを使う中で学んだ興味深い使い方を幾つか紹介します。そして彼らの製品の今後の方向性についても焦点を当てていきます。

このケーススタディではEclipse RAP(Rich Ajax Platform)がCAS PIAのアーキテクチャにどう適用されているかに焦点を当てます。CASがRAPを使う中で学んだ興味深い使い方を幾つか紹介します。そして彼らの製品の今後の方向性についても焦点を当てていきます。
スプリントの終わりでストーリーが一貫して「完了の定義」を満たさしているか?チームはプロダクトオーナーの手を縛っていないだろうか?
今月の終わりにあるEclipse Heliosの同時リリースに備え、今月の始めにEGitとJGitというEclipseとGitにちなんで名付けられたプロジェクトの0.8.1がリリースされた。EGitとJGit、どちらもNew and Notewothy(注目すべき新機能)が更新され、Eclipse Wikiにユーザから投稿されたものをベースにユーザガイドが作成された。そしてGitを使った事のない人へのイントロダクションも用意されている。
好みのブラウザのクイックサーチを使って「アジャイルソフトウェア開発」の最近の記事を探すと、アジャイルとは何かについて驚くべきほど多様に派生したアイディアが返されるだろう。これは良い事なのか?これは悪い事なのか?もしくは5/10(月)に書かれたこの記事は、空白を埋めているのだろうか?
前回のBundle.updateからたくさんのニュースがあった。SpringSource dm ServerはEclipseでひとつのEPLプロジェクトになった。OSGiとEquinoxの新しい本が出版された。OSGiエンタープライズエキスパートグループは完成に近づいている。WebSphereはApache Ariesを基にしたアルファをリリースした。NimbleがOSGiのランタイムを手助けし、ECFリモートサービスは今、完成した。
適切でアジャイルな計測とは何だろうか?もし伝統的な計測方法である、アーンドバリュー、労働時間、コード行数、テストによるコードカバレッジがアジャイルなプロジェクトにはあまり適さないのであれば、どういう方法があるのだろうか?よりよいアジャイルなメトリクスを選ぶ上で助けとなる、私たちが決められるルールは何だろうか?
アジャイルを成功させるためには、どのスキルが開発者に必要か、またどのプラクティスが組織に適用できるか、多くの議論が行われてきた。しかし、アジャイルを成功させるために本当に欠かすことのできない重要な心はなんだろうか。Mark Schumann氏はアジャイルの"本質的な要素"としてアジャイルの基底的なテクニックではなく、正確にいえばアジャイルの考え方と管理を共に位置づける事を提唱する。
多くのプログラマにとってプログラミング技術を学ぶよく知られている方法として例から学ぶ方法がある。具体的にいえば、他の人がどうしているのか、観察することだ。Antony marcano氏とAndy Palmer氏の"PairWithUs"では観察するだけの素敵なサイトを公開している。
この記事ではアップル vs マイクロソフトと題名をつけました。Pixelshellの共同設立者であるDmitry Fadeyev氏は、ウェブサイトのユーザビリティを学ぶため、アップルとマイクロソフトのウェブサイトをユーザビリティ環境という視点から比べ、アップルが勝者であるとしました。マイクロソフトのPMであるScott Barnes氏は、彼に賛同し、問題は様々なサブドメインで違った管理が行われているためだと示唆した。
多くのアジャイルチームでは'価値'とチームの'ベロシティ'は正比例すると、暗黙的に前提している。幾つかのケースにおいては本当にそう見られる。しかしながら、多くの場合はチームのベロシティが本当に価値を提供できたかはほとんど示されない。
大組織や大プロジェクトではアジャイルではないパートナー/ベンダー/サプライヤーにアジャイルなチームが拘束される事を目にするのは珍しくない。結果として軋轢が起こり、エネルギーを無駄にする。その一方解決策は"よりよいチームを雇う"のように見えるかもしれない。Scott Ambler氏は問題の根を示し、RFPを作るよりもよい戦略を提供している。それはアジャイルなチームを引き込むことである。