Agile2010 Day One - masayang's diary
本日はワークショップやチュートリアル中心の日。コマ数が多い中、Organization & Enterprisesを「持続可能な範囲で*1」聞いてきた。 目次 How Agile Taught IBM about New Leadership Competencies Agility@Scale - Experiences from the Trenches at IBM Rational Beyond Scope, Schedule, and Cost: Optimizing Value How Agile Taught IBM about New Leadership Competencies 現在はPitney Bowes社の国際技術担当副社長をのSue McKinney女史による「大企業のAgile化に求められる指導者の資質」に関する発表。彼女は去年まではIBMにて「世界各支社のI
古い発想の経営トップ - masayang's diary
ITPro: 若い時にプログラムを書こう，必ず人生の豊かさにつながる 経営トップから「ウォーターフォール型開発」「分業制度」という発想が抜けないから、こういう「昭和時代体質」が延々と生き残ることになる。 悲劇といえば悲劇。 古い発想のままでいるということが理解できてないあたりは、喜劇的ですらある。 私どもの過去の開発実績の平均値を取ると、機能拡張のような案件を除く、ごく普通の開発の場合、開発工数の比率は、要件定義と設計が3、製造が4、試験（テスト）が3です。 今言っているのは、もっと自動化を進めて、4から2まできた製造のところをもう半分減らして1にしたい、ということ。そうすると3、4、3が3、1、1ぐらいでいけるのではないか。合計で5ですから半減、つまり倍速達成となる。 Agile化でフェーズ分割＋分業のオーバーヘッドをなくせば全体で4、下手したら2で済むかもしれない、なんてことは異次元の
国が口出しする事かね？ - masayang's diary
こんな本を発見。 ITシステム契約 締結の手順とポイント 作者: 日経ソリューションビジネス出版社/メーカー: 日経BP社発売日: 2008/11/06メディア: 単行本購入: 1人 クリック: 26回この商品を含むブログ (3件) を見る 中身はこんな感じらしい。 ITシステム契約締結の手順とポイント 第1章 本書の構成とシステム開発契約の重要性 第2章 システム基本契約書逐条解説 第3章 重要事項説明書の使い方 A 要件定義支援及びパッケージソフトウェア候補選定支援業務契約（カスタマイズモデル） B パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル） C パッケージソフトウェア選定支援及び要件定義支援業務契約（オプションモデル） D 外部設計支援業務契約 E ソフトウェア設計・制作業務契約 F 構築・設定業務契約 G データ移行支援業務契約 H 運用テスト支援
特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayang's diary
Agile開発に限らないが、システム*1業界用語ってカタカナ*2表記が多すぎる。 「いや、元々が舶来なので日本語では微妙に表現できないのですよ」という人もいるかもしれない。 でも、この「カタカナ表記のまま」ってのが意思決定者の判断を誤らせたり、新規参入者に対する壁を高くしたりしている可能性は排除できないのではないかな。 今日、この後打ち合わせが入ってるプロジェクト*3もFeature、Story、Scenarioがごっちゃになりかけている。 なんとかわかりやすく表現できないかと悩み中。 以下、自分の案。名訳があったら、是非教えていただきたい。 Feature=特徴 自分は今までFeatureを「機能」と紹介してきた。 同じ「機能」でも開発者が対象にするのはFunctionで、利用者が対象にするのはFeatureですよ、と説明してきた。 でも、安井さんと角谷さんの本29頁を読むと「特徴」がい
「まだ６０回しか稲作したことがない」という含蓄ある言葉 - masayang's diary
昨日は旧友たちと錦糸町のホルモン焼き屋で飲む。 一人は自営業の傍ら、稲作をしているおっさん。 今年で稲作6年めだとか。 以下、印象に残ったお話。 最初は手探り状態。近所の農家に指導をしてもらった。 「おいしい」米を作れる技術を持っているのは70歳の世代まで。 その後継者になるべき世代(たぶん、うちらの世代)は農政と農協のおかげでボロボロ。 その70歳のおじいちゃんが「自分はまだ稲作を６０回しかしたことがない。だからよくわからない。」と言ったそうな。 含蓄ある言葉だな、と思った... 確かに米は年一回しかとれない。 しかも気象条件は毎年必ず変わる。 そういう中で試行錯誤できる回数は、一生のうち数十回。 こんな技術はマニュアル化など到底できない。 習い(あるいは盗み)、伝えていくしかない。 実践(プラクティス)あるのみ。 システム開発も似たような所はあるよね。 一生のうちに経験できるプロジェク
プロジェクト失敗率とリスク - masayang's diary
DDJにてScott Ambler氏がThe Distributed Agile Teamという記事を発表している。大規模分散Agile開発に関するお話。 詳しくはそちらを読んでもらうことにして、ここでは大規模Agileのプロジェクト成功率に関してちょいとコメント。記事にもあるけど 大規模Agile全体での成功率...78% 開発チームが一カ所に集まっている場合の成功率...83% 開発チームが近距離分散している場合の成功率...72% 開発チームが遠距離分散している場合の成功率...60% という統計が出ている。 この数字をみて「失敗率が20%以上もあるのなら、Agileはダメだな」と思った人は...考え直してほしい。 優先度の高いフィーチャから開発していくAgileでは、プロジェクトの成否が比較的早い段階で判明する。場合によっては一ヶ月で「だめだこりゃ」となるかもしれない。 早期に失敗
Agileが根付かないもう一つの理由 - masayang's diary
「プロジェクト失敗率とリスク」の続き。 id:suikyojinさんからトラックバックをいただいた。 大規模Agileの失敗率は驚異的に低い? そもそも、大規模プロジェクトの失敗率って、ものすごく高くて、70%とか80%とかいった数字を見たことがある。基準が同じとはかぎらないので、断定できないが……。 そうなのです。「失敗」の定義は意外と難しい。随分前に訳した「失敗とは何か」では CHAOSレポートによれば、成功するプロジェクトの割合はたったの34%だそうな。 Standish GroupのCHAOS reportは、長年に渡ってドブに捨てられてきた何十億ドルにもなるIT関係プロジェクトの話を延々と述べている。34％の成功率っていうのは実は改善された数値で、2001年の調査では28％だったんだな。 とのこと。失敗率66%。ただし、この記事でMartin Fowler氏は 納期が遅れたとか予
Agile開発は難しいか？ - masayang's diary
Silencejokerさんのコメント Agileによる開発手法って最近よく聞きますがなかなかむずかしそうです。 Agile開発啓蒙活動でよく聞くのが「難しそうだ」という意見。 でも「難しい」にもいくつか種類がある。 発想の転換が難しい 始めるのに必要な基礎能力が高くて難しい 習得の過程が難しい 習得の到達点が高くて難しい 習得しても、実践するのが政治的に難しい まだあるかな？ ま、こんなもんにしておこう。 発想の転換が難しい これはあるかもしれない。 「設計しないと実装できない」みたいな固定概念を、実は設計も実装もできない人達に捨ててもらうのは容易ではない。 「ソフトウェアに於ける設計とは実装そのもの也」と言っても禅問答にしか聞こえない人達は少なくない。 始めるのに必要な基礎能力が高くて難しい これは「プログラミングをしてみよう」という志を持ってる人なら問題ないのでは？ 習得の過程が難し
Investigative Tester (調査型テスト担当者) - masayang's diary
開発チームとテストチーム(QA: 品質保証)とを分けるかどうかというのはAgileコミュニティの中でもよく議論になる。 "Craftsmanship over Crap!" と叫んだBob Martinは品質保証を他人に任せることに大反対。 が、GDD(Geographically Distributed Development: 地域分散開発)に関して話してくれたScott Amblerは面白い考え方を提示してくれた Investigative Tester ある程度規模が大きくなり、複数チームで開発を進めることになっても、テストを記述するのは開発者。これは原則。*1 ただし、Investigative Tester(調査型テスト担当者)を用意するのは悪いことではない。 調査型テスト担当者は開発者が見落としているテストを探し、実行する。 バッファオーバーフローとか トラップされてないエラ
腐ったデータ構造が生む損失 - masayang's diary
先日参加したAgile2008で、Scott Ambler氏が何度も強調していた話。 Poor data quality problems result in a loss of over $600 Billion annually in the United States. 腐ったデータ構造が生む損失は米国だけで年間6000億ドルに達する。 6000億ドル＝60兆円強 結構な金額ではある... Scott Amblerの話は、おそらく下記記事が元になっていると思われる。 Data Warehousing Special Report: Data quality and the bottom line The Data Warehousing Institute (TDWI) estimates that poor quality customer data costs U.S. busi
COBOL屋の呪縛 - masayang's diary
今回の日本出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 本物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低２件は増える。 入れ子になれば、４件、８件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調
Agile2008 2日目 - masayang's diary
自分にとっては初日みたいなものだけど、簡単なまとめ。 Agile at Scale: What it takes on the right-hand of the chasm Scott Ambler親分による講演 今はIBM Rationalで働いているのね... なんでも、IBM内部では500人規模のAgile開発が進んでいるとか。 ある程度規模がでかくなってきたら、下記にコストをかける必要がでてくるそうな。 Upfrontのプロジェクト計画やモデリング Investigativeなテスト専任担当(与えられた手順でテストするのではなく、与えられたコードを「破る」ことに専念。かなり専門色の濃い仕事。) 印象に残った: 「クズなコードをいくらWrapしても、クズ。Wrapしやすいコードは最初からWrapする必要なし。」→CORBAとかSOAとかのことね。 自己紹介で「俺は世界中のシステムイ
Craftsmanship over Crap! - masayang's diary
Agile2008で一番印象に残った言葉... Craftsmanship over Crap! 「役立たずより職人主義」とでも訳せるか。 Bob Martin氏が「Agile第五の価値」として提案した言葉。 Bob Martinは過去から一貫して「責任を放棄するような仕事の投げ方」を批判してきた。特に彼はQA Team(品質保証チーム)の存在がもたらす弊害を「これでもか」というくらい、批判してきた。開発者とQA Teamが対立し、仕事がしっくりと回らなくなる状態が「Crap」(クソ)であり、それを解決するのが「Craftsmanship」(職人主義)。 Bob Martinって、もう結構な歳だよ。1970年から開発やってるそうだから、50後半〜60前半というところか。そういう人が語る「やっぱり職人主義」という言葉には、ずしんと来る重みがある。
Agile2008 - masayang's diary
あらためて番組表を見ているが...規模がでかすぎる。 最大40以上のセッションが同時進行！ まじめに情報収集するのなら、一社から4〜5人は参加しないと... いや、それでも無理があるか。
和風Agile? Part-2 - masayang's diary
和風Agile?の続き ウォーターフォール開発に慣れ親しんだマネージャ達にAgileを売り込むときによく指摘されるのが「最初に要件も予算も確定させないAgileのやり方はおかしい」ということ。 で、「じゃぁ、ウォーターフォールで最初に『確定』させた要件や予算が正しかった事がどれくらいありましたか？」と聞いてみると、「実はそれほど正確ではない。」という答が多いのも事実。 しかも要件抜けが発覚するのがUAT段階なら良い方で、本番稼働後に発覚する事例も珍しくない。そして不思議な事に、こういう「抜け」は要件定義段階の度重なるレビューでは発覚しない。ものすごく丁寧な業務フロー図やらなんやらを描いているのに、だ。 「だからこそ、要件抜けなどに対処しやすいAgileがいいのでは？」と売り込むと、「いや、それは困る」という答。どうやらこういうことらしい。 発注元の立場では、まず最初に予算総額を確定させる必
和風Agile? - masayang's diary
今回出張でも日本のお客さんにAgile開発を営業中。今日の活動を通じて実感したこと...和風Agileの必要性。 フィーチャ記述の手段 契約 フィーチャ記述の手段 米国だとレストラン(ファーストフードは除外)のメニューが文字だけで写真なし、というのは珍しくない。 日本だとメニューの脇に写真が載ってるのは珍しくない。下手すると、蝋細工で作った三次元模型まで用意されている。 一方、米国のレストランでは注文した料理が気に入らなければ、交換ないしは返品を要求できるし、事前に味見させてくれるところもある。 日本のレストランで「注文した料理が気に入らないから交換ないしは返品」というのは、なかなか難しい。[*1] こうして考えると、文章中心でフィーチャやストーリを記述する米国式は日本には根づきにくいのかな、と思った。最終形ではないけど、出来上がりを想像できる図表（画面見本や画面遷移図、業務フロー図など）
Herokuに感動＆そして暗くなる - masayang's diary
RailsConf 2008まとめ・企業編・簡易版で紹介したHerokuを使ってみた。 Herokuとは？ SaaSとして提供されるRails統合開発環境。提供されるのは以下の通り。ba Rails DB リポジトリ エディタ rakeコンソール画面 その他 利用者はブラウザさえあれば、Railsアプリケーションを開発できる。 Heroku自体はAmazon EC2上で動いている。 完成したRailsアプリをEC2上にデプロイするのも簡単らしい（未確認） アカウント入手方法 ベータ版のアカウント申込画面 自分は即日でアカウントをもらえた 使ってみる ブラウザからログインすると、自分用の管理画面が表示される。 CREATE APPボタンをクリックすると、railsプロジェクトが用意される。 あとは普通にRailsアプリケーションを開発すれば良い。 画面右上の ＞＞ ボタンをクリックすれば、即
迷ったら狩野さん！...狩野分析法による優先度付け - 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開発では「優先度順に要件（フィーチャ）を開発していく」のが基本だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マイケルジャクソン - masayang's diary
SCRUM開発のよい読み物(英語、PDF) - masayang's diary