InfoQ ホームページ 顧客要求 に関するすべてのコンテンツ
-
リーンスタートアップによる製品開発中の方向転換
リーンスタートアップでは、様々なタイプの方向転換があり得る。リーンスタートアップは製品開発中にこのまま続行するか方向転換するかを決めるのに役に立つのだ。それぞれの方向転換に独自の目的があり使い方がある。いつどのように方向転換すればいいのだろうか。辞めた方がいいと判断しなければならないこともあるのだろうか。
-
プライオリティゲームでバックログから無駄なものを取り除く
プライオリティゲームとは、巨大なバックログを管理可能にするためのエクササイズだ。Michael Franken氏はこれをGOTO Amsterdam 2013で実演した。彼は顧客が使わないものを作らないことで、いかにスクラムが必要なものに集中してムダを取り除くのに役立つかを説明した。
-
教育系テクノロジのスタートアップ企業に学ぶ
教育系テクノロジ(educational technology, EdTech) は発展を続けている。そしてスタートアップ(新興)企業は，アプリケーションやクリエイティブコモンズのコンテンツで市場に参入しようとしている。GOTO Amsterdam 2013カンファレンスでは講演者たちの教育およびゲーム体験，EdTechスタートアップに相応しいものの見つけ方などが公開された。
-
IRQA - システム開発プロジェクトのための要件定義ソリューション
Visure Solutionsは要件の定義と管理のためのソリューション(RDM)であるIRQAを発表した。専門のツールを使い、しっかりとしたプロセスで要件定義を行うことは製品やソリューション開発の質を保証する上で重要だ。
-
デザイン、プランニング、アーキテクチャツールに対するJolt Award 2011
1990年からDr. DobbのJolt Product Excellence Awardsは、5部門でのソフトウエア産業の代表に毎年授与される。10月26日Jolt審議会は、“デザイン、プランニング、アーキテクチャツール”でカテゴリの2011年のアワードをアナウンスした具体的には、Paradigm for UML、Restructure 101、Requirements Center 2010がJoltの殿堂に追加された。
-
Team Foundation Server 11 のアプリケーションライフサイクル管理
Team Foundation Server 11 には，アプリケーションライフサイクル管理の分野で多くの機能が追加されている。注目すべきなのはイタレーション／スプリントおよびリソース割り当てに関するサポート向上，サードパーティ製テストフレームワークのサポート，能力面で大きく改善された依存性グラフなどだ。
-
EclipseベースのRequirement Modeling Frameworkへの提案がリリース
最近、Requirements Modeling Framework (RMF)への提案が正式にeclipse.org��らリリースされた。意図は、EMFモデルと基本的なツール形式でこれらのモデルを編集するために、OMG ReqIF標準の最低でも１つのクリーンルーム実装を持つことである。
-
ソフトウェアアーキテクチャに関する新刊
ソフトウェアアーキテクチャはソフトウェア技術者にとって重要なトピックのひとつである。ソフトウェア開発プロジェクトの失敗の大部分が不適切な設計を原因とするものだからだ。だからアーキテクチャ上の問題の理論と実際について学ぶのは重要なことだ。最近出版された，あるいは近々出版予定の興味深い新書が大いに役立つだろう。
-
収縮の価値
ITとアジャイルの熱狂的な支持者のひとりであるMike Burrows氏はKanbandevグループである議論を始めた。このグループはコミュニティを展開/収縮パターンの探索に連れ出している。氏の始めた議論はInfoQの他の記事で紹介した。その記事では要求を細かく砕いて展開する方が、砕いたものを再度まとめることよりも価値があると考える実践者たちの見方を紹介した。しかし、多くの人がこのパターンは両方とも便利だと思っている。
-
まとめ直し(collapse) の価値
アジャイル手法では，機能を小さなユーザストーリに分解(“展開”)することを推奨している。しかし，コードが完成した後は，これらを元の機能にまとめ直すべきなのか，それとも全体を１つのユニットとして扱う方がよいのだろうか？ まとめ直し(collapse) に利点があるとすれば，それはどのようなものだろう？
-
アジャイル契約
ほとんどのソフトウェア契約は，固定的なスコープ/コスト/スケジュールという，ウォーターフォール方式のアプローチを念頭において書かれています。 この記事では，アジャイルソフトウェアプロジェクトの契約を記述する方法についてのアドバイスを提供します。以下、RSS feed / longer summary (max 400 chars)です。 従来のウォーターフォールモデル手法，すなわち要件を定義し，サプライヤが価格を提示して，両者が法的拘束力を伴う契約書にサインする，というやり方は，企業が何かを購入する場合にはとても都合のよいものです。しかしこの方法で記述された契約書には，アジャイルアプローチを使った開発に必要な自由がほとんどありません。この記事では，サプライヤと顧客がアジャイル開発の契約を締結するために利用可能な，４つの異なったモデルを検証しています。
-
リーンやアジャイルの契約書の書き方
アジャイルやリーンのプロジェクトは従来のプロジェクトとは違う。ではこれらのプロジェクトの契約はリーンやアジャイルの概念をサポートしているだろうか。それとも邪魔になっているか。この記事ではリーンやアジャイルプロジェクトの効率的な契約書の書き方についていくつかのヒントを紹介する。
-
Agile 2011で実際の顧客から聞く
Agile 2011での「顧客と一緒に働く」ステージは、アジャイルチームの顧客から話や報告を求めている。このステージは、顧客のコミュニティとアジャイル開発チームとの関わりを研究する。非技術的な機能と同様に、アジャイル開発チームそのものにも焦点を当てている。この記事では、ステージの企画者が質問に答え、実際の顧客に訴える。
-
-
誰がこのユーザストーリーを欲しているのか？
誰の利益になるのか簡単には言えないユーザストーリーがある。誰がこのユーザストーリーを欲しているのか表現できないとき、標準的な「... として、.... が欲しい。それは ... のためだ」というユーザストーリーのテンプレートをどうやって埋めればよいのか？