画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayang's diary
Agile開発に限らないが、システム*1業界用語ってカタカナ*2表記が多すぎる。 「いや、元々が舶来なので日本語では微妙に表現できないのですよ」という人もいるかもしれない。 でも、この「カタカナ表記のまま」ってのが意思決定者の判断を誤らせたり、新規参入者に対する壁を高くしたりしている可能性は排除できないのではないかな。 今日、この後打ち合わせが入ってるプロジェクト*3もFeature、Story、Scenarioがごっちゃになりかけている。 なんとかわかりやすく表現できないかと悩み中。 以下、自分の案。名訳があったら、是非教えていただきたい。 Feature=特徴 自分は今までFeatureを「機能」と紹介してきた。 同じ「機能」でも開発者が対象にするのはFunctionで、利用者が対象にするのはFeatureですよ、と説明してきた。 でも、安井さんと角谷さんの本29頁を読むと「特徴」がい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
タグ一覧Hudson
