InfoQ ホームページ 顧客要求 に関するすべてのコンテンツ
-
ユーザストーリー完了後の再見積は精度向上に有効か？
Scrum Development メールリストの最近のスレッドで，Paul Battison 氏がひとつの質問を投げかけている。スプリントの終了後に完了したストーリーの再見積を行って，チームの速度 (Velocity) 評価に実際の成果を反映させることは適当だろうか，と問うものだ。
-
製品オーナーは、プラニング ポーカーの場に、どのように参加すべきか？
プランニングポーカーの間、製品オーナーは、各ストーリーを明確にする責任があるが、しかし、オーナーは、開発チームの見積りに不当な影響を及ぼそうとしては、ならない。
-
最初に可視化、後で作成
Computerworldの記事とウェビナーによるアナウンスの両方が、ビジネス アプリケーションの要求を可視的に把握するために、iRiseを使うことを特集したため、この成長する製品セグメントに注目を集まっている。
-
WPF 対 Silverlight: プロジ���クトに最適な技術を選ぶ
WPFを使う場合と Silverlightを使う場合について混乱がある。プロジェクトに合った技術を選ぶのは、アプリケーションの正確な要件と WPFとSilverlightの能力差に依存する。
-
実験駆動開発 - ポストアジャイルの手法
TDDとBDDは現在広く使われているソフトウエア開発技術だ。しかし、TDDやBDDを単に適用するだけではビジネス機会を逸したり、さらに悪いときにはビジネスにネガティブな影響を与えてしまう。TDDとBDDでは解決できないふたつの問題とは、どのようにアプリケーションの使いやすさを計測するのか、そして顧客からどのようにしてフィードバックを得るのか、ということだ。実験駆動開発(EDD)はこの問題を解決できるか。
-
リーン＋リアルオプション＝複雑さとリスクの低減
リアルオプションとは、金融オプション数学に基づく意思決定プロセスである。これは通称「白本」とよばれるExtreme Progamming Explainedにおいて、Kent Beck氏が1999年に言及しているものだ。近年ではアジャイル主義者たちがリアルオプションがアジャイルとどのように交わるのかについて調査してきた。現在はChris Matts氏とOlav Maasson氏が、特にリーンソフトウェアコミュニティに対して発言している。リアルオプションを採用することでリーン開発が改善するというのだ。
-
フォレスターがビジネス向けリーンに関する無料の調査報告を公開
フォレスターリサーチは来週のビジネス・テクノロジフォーラムに先んじて、アナリストによる調査報告”リーン、新たなるビジネス・テクノロジ規範”を無料で公開した。リーンをビジネス全体の規範として管理者向けに書かれており、ITへの影響にも触れている。”価値の創造と柔軟性の増加を忘れて、無駄の排除に没頭してはいけない”との注意もある。
-
デマルコ、ソフトウエアエンジニアリングの40年間を振り返る
NATOのソフトウエアエンジニアリング会議から40年経ち、トム・デマルコはソフトウエアエンジニアリングの信念の進化において、自身が支持したメトリクス指向の方法論が、"変革を起こすこと。世界を変えるソフトウエアを作ること。"を目的にする現実の開発現場では、本当は邪魔になっていたのではないかと、振り返った。それとも、彼の当初の助言はやはり有効なのだろうか。彼自身は、"有効ではなかった"と、Software Engineering誌の"時代はやって来て、そして過ぎ去ってしまったのか"と題した記事で書いている。
-
アジャイルを採用するためにRFPを使う
大組織や大プロジェクトではアジャイルではないパートナー/ベンダー/サプライヤーにアジャイルなチームが拘束される事を目にするのは珍しくない。結果として軋轢が起こり、エネルギーを無駄にする。その一方解決策は"よりよいチームを雇う"のように見えるかもしれない。Scott Ambler氏は問題の根を示し、RFPを作るよりもよい戦略を提供している。それはアジャイルなチームを引き込むことである。
-
SOAと見当違いの泥沼
ThoughtWorksのアーキテクトNeal Ford氏が自身のブログで3回にわたる記事を書いた。そこで氏はベンダがSOAを今日のように認知させてしまったことを批判している。
-
Scrumでの非機能的な要求の対処
非機能的な要求は、振る舞いよりもシステムの質を説明する。Scott Ambler氏は、Dr. Dobb氏のポータルの記事にある「Scrumの製品バックログの概念は、単純な機能的な要求には適切に動作するが、非機能的な要求やアーキテクチャ上の制約には足りない」ということを主張したとき、白熱した議論を巻き起こした。
-
ビジネス価値を基準に(バックログの)優先順位を付ける
ビジネス価値を基準に(バックログの)優先順位を付ける。Luke Hohmann氏は、バックログのどの項目から検討を始めるべきかについて定量的な判断を下す方法を述べている。
-
アジャイル開発における失敗事例
アジャイル開発者は成功体験を語るのは好きだが、失敗についてはなかなか口を開こうとしない。Robin Dymond氏はそこに切り込み、「あるスクラムプロジェクトの失敗」という記事を書いた。
-
新たなユーザストーリーフォーマットがビジネス価値を強調
アジャイル要求を捉える共通のフォーマットであるユーザストーリーは、ビジネス価値にもっとフォーカスしてもよいのではないか。ユーザストーリーを記述する従来のフォーマットは、「As a <type of user> I want <some functionality> so that <some benefit>」である。価値を中心とすると、「In order to <achieve some value>, as a <type of user>, I want <some functionality>」このようになるだろう。
-
議論: アーキテクチャの書き直しは避けるべきか?
ソフトウェアを新しい需要や要件に適合させることが困難になるほど、アーキテクチャを更新するためにソフトウェアを再構築するという誘惑は強くなる。その取り組みはむしろリスクが高く、適切な戦略を採用することが不可欠である。