読者です 読者をやめる 読者になる 読者になる

Always All Ways

Apologies, Glances and Messed Up Chances

Requirements Development

書籍:"IMPACT MAPPING"

引き続き、最近読んだ書籍から。今日のお題は、Gojko Adzic氏の[www.amazon.co.jp/dp/0955683645:title="IMPACT MAPPING"]です。これは80ページほどの薄い本で、それほど難しいことが書かれているわけでもありません。 実は、そのエッセンス的なことは以下の…

プロダクト合気道(Product Aikido)

CPA GlobalのHead of Product Development FlowであるBob Marshall氏(twitterのアカウントで、 @flowchainsenseiと呼んだ方が馴染み深いかもしれません)が、CPA GlobalのProduct Developmentのマニュアルを公開しました。そのタイトルが"Product Aikido"で…

ハイブリッド型プロジェクトでのBAの身の処し方

昔のブログで、アジャイルなプロジェクトやチームにおけるBA(Business Analyst)の役割についてのいくつかの参考資料のまとめエントリを書いていました。 Always All Ways: [IT] AgileにおけるBusiness Analyst そこでピックアップした資料群は、どちらかと…

要求開発を語るときの心地悪さとその原因

id:kent4989さんのエントリに反応しつつ、また少し要求開発界(?)を盛り上げてみましょうか。 元エントリは、こちら↓ 要求開発のホームグラウンドについての考察 - 勘と経験と読経この中で彼は、要求開発の適用範囲は限られており以下のような領域がその「…

Scrumを教えるのに最適なフレームワークはScrum

Tobias Mayer氏が、「スクラムのワークショップにおける5つの『やってはいけない』」みたいなブログ・エントリを書いています。せっかくなので、その5つを見出しのみ抜粋してみると、 Don't plan the whole workshop. Don't ask questions you already kno…

ローカル・ナレッジを参照点として複雑適応系とダンスする要求開発

今朝の id:kent4989 氏のエントリにインスパイアされて、まとまりがないものの思うところを書いてみたいと思います。 元記事はこちら↓ ローカルな知としての要求開発 - 勘と経験と読経まず最初に断っておきたいのは、氏が言わんとしていることはだいたい理解…

「要求開発の心」を活かすポイント

【おことわり】 この記事は、もともとエンジニア向けフリーペーパー"EM WEST"の連載記事「現場での要求開発のはじめ方」の第2回として書き下ろしたドラフトです。EM WEST Vol.3(だっけ?)の発行がまだ先になりそうなので、現時点でブログの方で番外編とし…

旧ブログのアーカイブ(アジャイル編)

はてなブログに移行する前の過去ブログについては、サイドバーのリンクから閲覧可能になっていますが、古い記事の一覧性が弱く、また記事内容も種々雑多なものが混在しているため、改めて、アジャイル関連のエントリについて主なものを抜粋してリンクのリス…

Business ValueとCustomer Value

アジャイル開発に限らず、システム開発やそれ以前のビジネス戦略の話なども含めて、いろんな場面で「ビジネス価値」(Business Value)という言葉が出てきます。要求開発宣言でも「情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネ…

BABOKのAgile Extensionが生む(かもしれない)誤解

Modern Analystのサイトに"3 misconceptions I would like to see removed from the Agile Extension to the BABOK®"という記事が掲載されていました。 ざっと斜め読みしたところ、この記事の筆者は、Agile Extensionのもたらす価値については認めながらも、…

Agile Requirementsと「実施可能要件」

アジャイル開発で仕様をどこまで詰めるのか、あるいはどの程度詳細にドキュメント化すべきなのかというのは、よく議論になるポイントです。シンプル なWebアプリケーションなどであれば、カードや付箋に記述されたユーザーストーリーと受入条件で十分かもし…