迷ったら狩野さん！...狩野分析法による優先度付け - masayangの日記（ピスト通勤他
追記 id:discypusさんから、狩野分析法の出典に関するコメントをいただきました。 狩野法って、 狩野 紀昭 氏 http://www.sangakuplaza.jp/page/134499 の http://www.yahoo-vi.co.jp/method/b10.html の手法かと 思うのですが、合ってますでしょうか？ まさにこれですね。http://www.yahoo-vi.co.jp/method/b10.html にある日本語のほうがすっきりしてます。 お詫び 分析用配列に誤りがありました。修正してあります。 要旨 先日受講したScrum Product Owner Trainingで印象に残った分析法を紹介。 Agile開発では「優先度順に要件（フィーチャ）を開発していく」のが基本だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的
iPadを絶賛していた人達はなんだったんだ？ - masayang's diary
というわけで某社の提供でiPad 3G/32GBを入手した。今日で5日目だが、普段使うアプリケーションはiPodとKindle for iPadに集約されつつある。家ではMacBook Proがあるし、移動中はG2使えばほとんど用は足りる。 個別のアプリケーションではiPadのほうが圧倒的に素晴らしい。UIはよくできている。Flipboardなんてのは最高にしびれた。*1 Kindle for iPadも、画面に反射する天井の光さえ気にしなければオリジナルKindleを凌駕した出来ではなかろうか。*2 だけど、そうやって褒められるのは「アプリケーションを通して情報を受け入れて、そこでおしまい」という人達だけだと思うんよ。 WSJ WSJのiPadアプリケーションで面白い記事を見つけた。是非これをTwitterでみんなに教えたい。こんな時にどうすればよいか？ ToolsメニューからEmail
Agileが根付かないもう一つの理由 - masayang's diary
「プロジェクト失敗率とリスク」の続き。 id:suikyojinさんからトラックバックをいただいた。 大規模Agileの失敗率は驚異的に低い? そもそも、大規模プロジェクトの失敗率って、ものすごく高くて、70%とか80%とかいった数字を見たことがある。基準が同じとはかぎらないので、断定できないが……。 そうなのです。「失敗」の定義は意外と難しい。随分前に訳した「失敗とは何か」では CHAOSレポートによれば、成功するプロジェクトの割合はたったの34%だそうな。 Standish GroupのCHAOS reportは、長年に渡ってドブに捨てられてきた何十億ドルにもなるIT関係プロジェクトの話を延々と述べている。34％の成功率っていうのは実は改善された数値で、2001年の調査では28％だったんだな。 とのこと。失敗率66%。ただし、この記事でMartin Fowler氏は 納期が遅れたとか予
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
Controllerは薄く作る - masayang's diary
教育的ビデオ コントローラを太らせてはいけない ということ
Marketceteraを使ったオンライン証券取引システムを開設しよう♪ - masayang's diary
http://d.hatena.ne.jp/masayang/20071128/1196293880 に引っ越ししました。
Man-Bear-Pigと叫び続けるとノーベル平和賞がもらえる(そして科学的に地球温暖化を証明しても１２万ドルしかもらえない) - masayang's diary
アル・ゴア氏のノーベル平和賞受賞には、正直たまげた。日本での評判は知らないが、当地での彼の映画「Inconvenient Truth」はボコボコな評価が多かったのでノーベル賞受賞は本当にびっくり。そしたら、産経に「ゴア氏映画に科学的間違い」なんて記事がでている。 元記事 BBCのGore climate film's 'nine errors'が元記事。 公立学校における科学の授業で「Inconvenient Truth」を見せることに「内容が政治的に偏っている」と反対した学校理事が国に対して裁判をおこした ロンドン高等裁判所は同映画を学校で見せるにあたり「９つの科学的間違いについて生徒達に議論させる」という条件を課した 元記事には、その「科学的誤り」について３つだけ解説されている。 Mr Gore's assertion that a sea-level rise of up to 20
外部と内部を分けることの弊害 - masayang's diary
COBOL屋の呪縛に、ちょいと補足。 COBOL屋の呪縛ではフラグの話を書いたけど、フラグ以外の属性でプログラムの挙動を制御するのもCOBOL屋さん以来の伝統かも。極端に簡単な例で説明。 user = User.find(id) do_something_for_admin if user.category == 'admin' do_something_for_manager if user.category == 'manager' 継承を使えばif文は不要になる。それだけテストが減る。（この例は簡単すぎてテストの減らしようがないけど...）[*1] class Admin < User def do_something # do_something_for_admin end end class Manager < User def do_something # do_somethi
COBOL屋の呪縛 - masayang's diary
今回の日本出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 本物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低２件は増える。 入れ子になれば、４件、８件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チワワ＋シベリアンハスキー混血 - masayang's diary