GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ITとアジャイルの熱狂的な支持者のひとりであるMike Burrows氏はKanbandevグループである議論を始めた。このグループはコミュニティを展開/収縮パターンの探索に連れ出している。氏の始めた議論はInfoQの他の記事で紹介した。その記事では要求を細かく砕いて展開する方が、砕いたものを再度まとめることよりも価値があると考える実践者たちの見方を紹介した。しかし、多くの人がこのパターンは両方とも便利だと思っている。
ほとんどのソフトウェア契約は,固定的なスコープ/コスト/スケジュールという,ウォーターフォール方式のアプローチを念頭において書かれています。 この記事では,アジャイルソフトウェアプロジェクトの契約を記述する方法についてのアドバイスを提供します。以下、RSS feed / longer summary (max 400 chars)です。 従来のウォーターフォールモデル手法,すなわち要件を定義し,サプライヤが価格を提示して,両者が法的拘束力を伴う契約書にサインする,というやり方は,企業が何かを購入する場合にはとても都合のよいものです。しかしこの方法で記述された契約書には,アジャイルアプローチを使った開発に必要な自由がほとんどありません。この記事では,サプライヤと顧客がアジャイル開発の契約を締結するために利用可能な,4つの異なったモデルを検証しています。
アジャイルやリーンのプロジェクトは従来のプロジェクトとは違う。ではこれらのプロジェクトの契約はリーンやアジャイルの概念をサポートしているだろうか。それとも邪魔になっているか。この記事ではリーンやアジャイルプロジェクトの効率的な契約書の書き方についていくつかのヒントを紹介する。
Agile 2011での「顧客と一緒に働く」ステージは、アジャイルチームの顧客から話や報告を求めている。このステージは、顧客のコミュニティとアジャイル開発チームとの関わりを研究する。非技術的な機能と同様に、アジャイル開発チームそのものにも焦点を当てている。この記事では、ステージの企画者が質問に答え、実際の顧客に訴える。

従来のウォーターフォールモデル手法,すなわち要件を定義し,サプライヤが価格を提示して,両者が法的拘束力を伴う契約書にサインする,というやり方は,企業が何かを購入する場合にはとても都合のよいものです。しかしこの方法で記述された契約書には,アジャイルアプローチを使った開発に必要な自由がほとんどありません。この記事では,サプライヤと顧客がアジャイル開発の契約を締結するために利用可能な,4つの異なったモデルを検証しています。

多くのアジャイルソフトウェア開発プラクティスの文献にあるものと、アジャイルチームが実際に直面するものにはギャップがある。このギャップを埋めるべく、その役割と価値を担い、状況を変えていくことが、アジャイルなプロジェクトにおけるアナリストの役割だ。この記事では、ありがちな状況として、開発チーム寄りではなく業務寄りになるような場合でも、ビジネスアナリストはアジャイルなチームワークと実用的な連携を行うことができる、ということを主張していく。

コンサルタントとして働くことの最大の喜びの一つはいろいろなアイディアを試してみてからことが上手くいくように自分が一番好きな方法を適用することができることです。この記事では私が効果的だと思うユーザ・ストーリーの(開発工数)見積もりテクニックの詳細について述べています。

ビジネス領域の深い理解を反映したドメインモデルを設計するための、ヴィジョンとアプローチです。この本は、Eric Evans氏の「Domain Driven Design」の主要点を短く読みやすく要約しました。