Agile2009四日目 - masayang's diary
The Kanban Game 永和システムズの安井さんによる講演。 "Kanban Game"を通じて、カンバン方式のプロジェクト計画管理を学ぼう、という企画。 いわゆる「スクラム板」よりも全体の見通しがよくなり、「これは使える」と実感した。 教材や遊び方はこちらにあるよ→安井さんのサイト The Dawning of the Age of Experience バンケットでの基調講演。 User Interface「設計」をもとにAgileの価値を考えるという内容。 細かい話はそのうち書くかもしれないし、書かないかもしれない。 でもJared M. Spool氏が指摘した企業文化の話はするどかった。 うまくいっている企業は、決して「核となる」部分を外注(Outsourcing)しない うまくいってない企業は、得てして企業文化を統一したがり、方法論に走る。そして、その方法論でうまくいかな
Agile2009三日目 - masayang's diary
本日聞いてきたお話 Scaling Scrum with Feature Teams 大規模SCRUMの話。 日本にも支社があるOdd-eによる発表。 「どんなに大規模になっても、Product Backlogは一つにまとめよ」 「The Product Ownerはどんなに大規模でも一人」 一人しかいなくて、しかも他の仕事が忙しいProduct Ownerが、膨大な量のProduct Backlogをどう管理するのか？ 一方、開発は複数チームに分けざるを得ない。 どういう根拠で開発チームを分けるのか？ 「大雑把な設計をし」「そのサブシステム単位で分ける」のが古典的な考え方。 だが、この段階での設計は非常に粗い。 その粗い設計を元にチーム分割する時点で、将来に向けての問題を埋め込むことになる。 そして問題が発覚する時点で手遅れ。まずいチーム構成のまま進むことになる。 Product Bac
Agile2009二日目 - masayang's diary
本日聞いてきたお話。 基調講演: I Come to Bury Agile, �Not to Praise It(PowerPoint資料) シェークスピアを読んでないと理解できない題名。 当然俺はなんのことかわからなかった。 「Agileを葬る」といっても、もうAgileが終わりということではない。 「Agileが普通になる」という宣言。 How the FBI learned to catch bad guys one iteration at a time 政府系受託開発のお話。 日本でいうSI屋さん。 お客はFBI。 FBIにおけるシステム開発の失敗事例は色々有名らしい。 そのFBIシステム部門がAgile開発を受け入れることで体質が変わりつつある、というお話。 二週間の周回開発。 計画ポーカー採用。 ペアプログラミング。 継続的統合。 一方で、CMMI Level-3は満たしてい
投資と負債は違うよ(2) - masayang's diary
売り切れました: そりゃ投資と負債は違う id:shivashantiさんからトラックバックをいただいた。 １億円かけてシステムつくれば１億の投資。 運用保守に年間１５００万円で耐用年数５年なら７５００万の負債。 システム導入は投資の結果として負債が手元に残る。 だから導入による効用は投資額＋負債総額を上回るように計画しなくてはならない。 開発費1億円のシステムを5%で5年かけて償却していくと、月額212万7135円 運用保守費年間1500万円=月額125万円 つまり、このシステム投資は月当たり337万7135円以上の付加価値を生まないと「投資に見合った収益がでない」、ということになる。 まあ、普通なら「月に400万円の付加価値を生むシステムを作ろう。そのための投資は月に337万7135円だから、毎月63万円弱の利益が出る」と判断するから、投資に踏み切れるわけで。 で、その開発費分は積んで
迷ったら狩野さん！...狩野分析法による優先度付け - 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開発では「優先度順に要件（フィーチャ）を開発していく」のが基本だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的
アジャイルのレイヤ 〜 アジャイルを整理し直して理解する - kuranukiの日記
【アジャイル】という言葉は、システム開発の世界ではかなり一般的な言葉になりつつあります。大手のSIerの経営者までが当たり前のように使うようになったことは、ある意味で感慨深いものです。しかし、言葉としてメジャーになりつつある一方で、その言葉の本当の実体を理解しないで誤解したまま使っているケースが多くあるように思います。アジャイルで開発すれば「速い・安い・旨い」が手に入るという誤解や、プログラミング工程だけで使う手法だという誤解、朝会やふりかえりをすることがアジャイルだという誤解、などなど。どれも、完全な誤解という訳ではなく、あながち間違いでもないところが、さらなる混乱を産んでいるように感じます。 最近では、アジャイルの事例も多く出てきたように思いますが、それらの事例も具体的にどういったことを実践したからアジャイルだったかと問われるとそこに明確な答えは無いように思えます。アジャイルとは何か、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ふりかえりを改善するための秘訣
masuidrive on rails » Blog Archive » アジャイルな環境作り - そんなに急いでどこへ行く