画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
「大規模開発」と「大規模な開発」 - masayang's diary
Agile開発の話をすると、ほぼ必ず出てくるのが「うちらは大規模開発だから。Agileなんて無理でしょ。」という指摘。 「あ〜そうですか〜 大変ですね〜」と頷きながら、「本当は『大規模開発』と『大規模な開発』を履き違えているんだろこの野郎」と心の中では思っているのであった。 Slashdot: Hello World? That's easy!より引用: public interface MessageStrategy { public void sendMessage(); } public abstract class AbstractStrategyFactory { public abstract MessageStrategy createStrategy(MessageBody mb); } public class MessageBody { Object payload;
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
