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
画面設計とか外部設計とか、もうやめようよに対し色々意見をいただいた。感謝。 要点繰り返し 自分は「画面の見本を使ってフィーチャを抽出する」というやり方に反対はしてない。 ただし、その「見本」が妙に具体的かつ詳細になってくると、本来フィーチャではないものまでフィーチャとして取り出してしまい、後続の工数が膨れちゃうよ、ということを警告しているのである。 「妙に具体的かつ詳細な見本」ってのは、世の人がいう「画面設計書」でしょ？ なのでそんなのはやめちゃえ、ということ。 以下、頂いた意見に対しての感想などを。 家やマンションに例えない 「家やマンションは最初に完成像をみてもらい納得してもらう必要がある。システム開発も同じだ。」みたいな意見があった。 画面の見本があれば完成像を想像しやすくはなるけど、実際に動く見本があれば想像する必要はなくなる。 むしろ、操作することで「紙芝居」ではわからなかった要
画面設計とか外部設計とか、もうやめようよ - 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頁を読むと「特徴」がい
Agileによる再構築 - masayang's diary
「レガシーシステムとは？」と訊かれたら、自分は迷わず「Agileで作られてないシステム」と答える。 Java(servlet直呼び出し)で書かれた古いシステムをRailsで書き直したことがあるけど、非常にコンパクトなコードになってしまった。むしろ周囲が「これで旧システムと互換性あるの？」と心配したくらいである。 で、同じような案件がないか調べていたら次の短論文を発見。 An Agile Approach to a Legacy System(PDF、英語) 例によって無断適当に邦訳。長文注意。 An Agile Approach to a Legacy System Chris Stevenson and Andy Pols 概要: 本稿では小規模かつ自発的に形成されたXPチームがいかにしてぐちゃぐちゃな問題を抱えたシステムをきれいにしていったかを解説する。我々はレガシーアプリケーションを
RailsConf 2008まとめ(簡易版) - masayang's diary
参加分のみまとめ 聞き取り調査したベンダのまとめは別途 2008/5/29(Tutorial) Refactoring Your Rails Application リファクタリングの「つぼ」を解説するTutorial サンプルプロジェクトが配布され各自Hands-onで学ぶはずであったが、無線LANの容量不足や各人のRails環境差などで座学中心に 資料 スライド(PDF) 読み物(PDF) 実習用コード(zip形式)←2008/6/5追加 資料(2008/6/19追加) Rails Refactoring Catalog from the tutorial Refactoring Your Rails App tutorial slides Refactoring Your Rails App example app from the tutorial 印象に残った事 コントローラはで
北米Agile開発普及度合い - masayang's diary
Forrester Research社のEnterprise Agile Adoption In 2007という調査報告書を入手した ちょいとびっくりしたのは北米でのAgile普及度合い いわゆる「エンタープライズ」と呼ばれる規模の企業のうち、26%が既にAgileを使っている 過去の数値は、2005年が14%、2006年が17%。 2007年は普及に加速がかかっている 企業の規模で見ると、大きな企業ほどAgile活用が進んでいる Global2000(従業員２万人以上)の34% 5000-19999人規模だと28% 1000-4999人規模だと21% 分野別では以下の通り 35% 金融・保険 31% サービス 29% 電力・ガス・建設 23% メディア 21% 製造 21% 小売り 20% 公共 どうでも良いこと 単純に日本と比較するのはあまり意味がない 内製と外注を巧みに使い分ける米国
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
