InfoQ: ビジネス価値を見積もる
原文(投稿日：2010/01/04)へのリンク 従来のアジャイル開発では優先順位をつけるとき、ビジネス価値の低いユーザストーリーよりもビジネス価値の高いユーザストーリーを優先して実装するようにする。このやり方はシンプルだが、うまく実装できるかどうかはビジネス価値を評価する仕組みがあるかどうかにかかっている。 Pascal Van Cauwenberghe氏は最近、ビジネス価値を定義する方法について説明している。この方法は"ビジネス価値モデリング"と呼ばれ、役に立つかもしれない。 ユーザストーリーのビジネス価値はどうやって見積もる? いや見積もれない。と題した記事で氏が警告しているのは、ユーザストーリーが前提にあり、そのユーザストーリーのビジネス価値を評価する、という想定には根本的な欠陥がある、ということだ。そして、より優れた出発点として次の質問を考えることからはじめることを提案している。す
Scrumチームの個々のメンバに対する報償
原文(投稿日：2009/11/30)へのリンク LinkedInのAgile Allianceグループで最近、Reeju Srivastava氏の次の疑問から議論が始まった。 “Scrumチームの個々のメンバに報償と評価を与えるべきでしょうか?” この疑問に対して、活発な議論がわき起こり、賛成や反対の意見が提出された。 議論の一部を下記に挙げる。 賛成: 共産主義者は共同農業という概念を実践しようとしました。この枠組みでは個々人の間に優劣はありません。そして言うまでもなく、この実践は失敗に終わりました。 競争的な報償制度は良くないと人々が言うとき、やや極端な視点から考えているのが常です。つまり、競争とは勝者が総取りのゼロサムゲームであるという視点です。しかし、現実におこっている状況の中では、これは事実ではありません。 ほとんどのチームの環境では、そのチームの動的な側面はナッシュ均衡(映画"
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルの衰退と凋落を止めるために内側を見つめる
developerscafe.jp