「測定できないものは制御できない｣は誤りだった。-- by Tom Demarco：An Agile Way：オルタナティブ・ブログ
ソフトウェア工学の祖の一人である、トム・デマルコが、最近IEEE Software 誌に、過去のソフトウェア・メトリクス賛美を悔い改める記事を書いている。 「ソフトウェア工学」というコンセプト－その時が来た、そして、その時は去った。http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r 1982年に、デマルコは有名な「計測できないものは制御できない」という一文から始まる、『品質と生産性を重視したソフトウェア開発プロジェクト技法』という名著を書いている。このドグマは、ソフトウェア工学の考え方に強く根ざしている。むしろ、すべての「工学」という活動は、科学や経験から得た知見を使って自然現象をコントロールし、人間の役に立てることをその定義としており、そこでは測定を元にしたコントロールという概念はその中核にあ
「ふりかえり」が失敗する８つの理由：An Agile Way：オルタナティブ・ブログ
「アジャイルレトロスペクティブ」の著者、イースターダービーのStickymindsの短い記事です。 「ふりかえり」が失敗する８つの理由 Eight Reasons Retrospectives Fail ぼくは Retrospectives を「ふりかえり」、と訳している。オブジェクト倶楽部のプロジェクトファシリテーションのページに、天野さんが、日本語の「ふりかえりガイド」(PDF)もかいている。 簡単にまとめると、 「ふりかえり」が失敗する８つの理由 １．準備不足。 ⇒アジェンダをしっかり用意すること。 ２．焦点があいまい。 ⇒前回のイテレーションの改善に集中。 ３．データが集まっていない。 ⇒何かを変えようとするまえに、「実際に何が起きていたか」を話す。 ４．１人か２人が会議全体の会話を独占してしまう。 ⇒ペアにしたり、グループを作ったりして話あうアクティビティを持つ。 ５．自分たちで
《本》「リーン開発の本質」予約できます。：An Agile Way：オルタナティブ・ブログ
リーン開発の本質 ソフトウエア開発に生かす7つの原則 http://www.amazon.co.jp/exec/obidos/ASIN/482228350X/xpjp-22 ついに、amazonで予約可能です！私は監訳を担当していますが、今回も、前作に劣らずとてもよい本。前作を読んでいない人には、前作を飛ばしてこの本をお勧めします。以下、監訳者としてのあとがきの一部です。。。 ■「アジャイル」と「トヨタ生産方式」の出会いが「リーン開発の本質」である ソフトウエア開発の一手法である「アジャイル」と、日本の工場の生産方式に起源をもつ「トヨタ生産方式」。一見まったく違う２つの分野をクロスオーバーする新しい流れが起こっている。それが、本書の主題である「リーン開発」である。 「アジャイル」は、日本では2000年ごろから、ソフトウエア開発現場のリーダー、プログラマーをはじめとする、最新オブジェクト指向
大野耐一の言葉：An Agile Way：オルタナティブ・ブログ
アメリカからきたから、やって見ようじゃだめだ。ニーズはあるのか？困っているのか？面子や物好きで導入してはだめ。ニーズを大事に。
闘う経営と共生する経営：An Agile Way：オルタナティブ・ブログ
企業経営、製品戦略の言葉のなかには、「闘い」の語彙が登場することがよくある。「打倒、○○」とか、「○○に負けるな」、「○○から崩せ」など。戦略という日本語がすでに闘いから来ている。経営を戦いとするメタファの中には、ある特定シェアを「取り合っている」、という意識があるのだろう。ゼロサムだ。そしてそのシェアを取ることが、企業のサバイバルだ。パイという言葉はシェアの円グラフから来ているのだろうが、パイを奪い合っている。この場合、競合他社との差別化、他社からの乗り換え戦略をとることになる。 もう１つの方向としては、パイ全体を増やす、というやり方がある。これは「共生」のメタファ。複数の企業で同じ考えを広げていく。特に若い市場などでは、パイ全体を増やすことの方がシェアを奪いあうよりも効果がある場合が多い。たとえば、UMLツール、という市場があった場合、まだUMLの普及自体が日本で遅れているため、UML
Product = Team(製品づくりはチームづくり) -- Jim McCarthy at SDBP2007：An Agile Way：オルタナティブ・ブログ
ボストンにて開催中の、SDBP 2007 にきています。昨日の基調講演は、「ソフトウェア開発のダイナミズム」(原著Dynamics of Software Development)で有名な、Jim McCarthy です。いつか見てみたい人だったので、偶然この機会に出会えてとてもうれしい。 彼のポイントは、「製品作りはチーム作りと同義である」ということ。製品は良いチームから生まれるし、悪いるいチームからは悪い製品しか生まれない（それぞれ、逆も真）。ビジョンを共有したチーム、の強さ、人のパワーについて、アクションを交えた語り口のとてもおもしろい講演でした。 講演中、会場を交えてこんな実験を。 「ビジョンを共有し、情熱あふれるチームに参加した経験がある人は起立してください。」 ⇒約８割が起立。 次に、「そのチームにいるとき、ビジョンを共有ていしないチームにいるときよりも、２倍よかった、と思う人
『ソフトウェア開発に役立つマインドマップ』本が出ます！：An Agile Way：オルタナティブ・ブログ
『ソフトウェア開発に役立つマインドマップ』という本を書きました。構想から1年以上もたってしまいましたが、ようやく形にすることができました。 http://www.amazon.co.jp/ASIN/dp/4822283143/xpjp-22 ぼくはマインドマップに始めて出会ったときに、そのインパクトと人間らしさ、自由さ、発想を広げる柔軟さに惹かれました。そして使ってみるうちに、こういう「楽しい」、「やわらかい」ものがもっとソフトウェア開発の中に使えないか、という思いにとりつかれるようになりました。 いろいろ試してみてうまく行くものを取捨選択し、この本の中に詰め込むことにしました。中にはちょっと実験的なものも含まれていますし、議事録テンプレートのように、すでに僕の中では定番になっているものもあります。これらを、使える形でみなさんに提供し、ソフトウェア開発現場をより明るく生産的な活動の場、とす
ものづくり、の本質：An Agile Way：オルタナティブ・ブログ
いくつかブログやらメールやらを見ていて、今年の思いを固めている。「つくる」ことの本質は何だろう、それは、「おもう」ことと関係しているのではないか、というのが今年のテーマです。 本日のGrady Booch のブログのクオートより； If you want to build a ship, don't drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea. -- Saint-Exupery 船を作ろうと思ったら、人々に材料を集め、作業を分割し、指示を与えようとしてはならない。最初にすべきことは、果て無き広大な海への憧れを語ることだ。 -- サンテクジュペリ 昨日のAlistair Cockburn の
TRICHORDで仕事を見える化しよう！：An Agile Way：オルタナティブ・ブログ
チェンジビジョンで開発しているツール、TRICHORD（トライコード）は、アジャイル開発を支援するツールだが、「タイムボックス管理」という視点で見るとかなりいろいろな適用場所がある。 TRICHORDのTRIは「３」という意味で、「トキ(time)」「コト(thing)」「ヒト(team)」の調和を目指している。トキは、タイムボックスで、「プロジェクト」「リリース」「イテレーション」という３階層でブレークダウン。そして、コトも「フィーチャ」「ストーリー」「タスク」という３階層でブレークダウンし、それをタイムボックスに入れる。そして、ヒトが、タスクにサインアップし、タスクの状態（ToDo/Doing/DONE）をチームで共有する。－－－これだけ。本当に「これだけ」、なのだ。 例えば、写真はチェンジビジョンのマーケティング担当者が、「セミナー開催」というプロジェクトの、「セミナーの告知と募集」
見える化、名前付け、の意味とは：An Agile Way：オルタナティブ・ブログ
プロジェクトファシリテーションの５原則は、 見える化 リズム 問題対私たちの構図 名前付け カイゼン である。 このうち、「見える化」と「名前づけ」について、「人間の理解とは」という方向から少し考えてみました。ちょっと哲学的・認知心理学的な考察になります。 * * * 概念＝名前のついたもの。私たちが頭の中で、あるいは、他者とのコミュニケーション に乗せてハンドリングできる単位。 モノ＝概念のうち、目に見えるもの。物理法則に従うもの。 名前づけ＝人間は、名前をつけることによってその対象物をはじめてはっきり認識できる。未概念の名称による概念化。輪郭の切り取り。言語操作対象化。 見える化＝見えないものを見えるようにする（モノ化する）ことによって、よりはっきりと実体の存在感を得ることができる。 以下、レファレンス： George Lakoff の主張： すべての
開発者にアジャイルを強制するのは、危険信号：An Agile Way：オルタナティブ・ブログ
開発者にアジャイルを強制するのは、危険信号だ（Imposing Agile Is A Very Red Flag）とマーチンファウラーが書いた。 http://martinfowler.com/bliki/AgileImposition.html 要約すると、 アジャイルを管理者が押し付けてはならない、それは、 「プロセスとツールよりも、個人と対話に価値を置く 」という価値にも反するし、その背後にある原則である、 「動機付けされた人たちを中心にプロジェクトを構成する。彼らに環境と支援を与え、彼らが仕事を成し遂げることを信じる」、そして、「最高のアーキテクチャ、要求、そして設計は、自己組織化されたチームから創発する」 にも反する。 というのだ。 チームは自発的にウォーターフォール型の方法を選ぶことだってできる。その場合、アジャイルではなくなるだろが、アジャイルはもともと万能ではないのだ。私は
TRICHORD システム開発の状況の見える化ツール(^_^)：An Agile Way：オルタナティブ・ブログ
THICHORD(トライコード)の version 0.1 を発表します。自由にダウンロードできますので、どうぞ、みなさん開発へのフィードバックにご参加ください。http://trichord.change-vision.com/ これは、カテゴリとしては、SDLC(Software Development Life Cycle)ツール、となるでしょうか、でも基本的には、もっとシンプルな「状況の見える化」ツールです。 これまで、ソフトウェア進捗管理のツールといえば、「管理」のツール、仕方ないが、使えといわれるので使わざるをいえないツール、という印象が強いのではないでしょうか。TRICHORDは、 仕方なく使うツール、から、使いたいから使うツール にしたい。つまり、エンジニアが、必要だと思うから、導入するツール。 例えば、JUnit というシンプルなテスティングツールがある。これは、プログラ
書籍『プロジェクトを成功させる 現場リーダーの「技術」』：An Agile Way：オルタナティブ・ブログ
ぼくと何度もプロジェクトを共にした永和システムの岡島幸男さんの本がでました。 IT業界の混乱は、形式的なプロジェクトマネジメント手法や開発技術では乗り切れない。そこには、人間力のあるリーダーが必要である。本書には、「才能」としてのリーダーではなく、彼が現場での「悩み」から後天的に得た「技術」、そして「勇気」のエキスが生の言葉で書かれている。 プロジェクトを成功させる 現場リーダーの「技術」 http://www.amazon.co.jp/exec/obidos/ASIN/4797333502/xpjp-22 この本を読むと、彼と関わったプロジェクトのさまざまな記憶、深夜の議論や、成功の美酒、失敗の辛酒を思い出します。 また、プロジェクトファシリテーションのいくつかの「見える化」実践について、詳細に書かれたはじめての日本語の本ということになると思う。「アクションかんばん」、「朝会」、「ペア○
KPTを使ったプロセス改善：An Agile Way：オルタナティブ・ブログ
ソフトウェア開発の繰り返し単位（イテレーション）ごとに、そのタイムボックスで行なったことを反省し、未来に生かせるように口に出してみる、という活動を行なう。これは、反省会、回顧、Retropective、Reflection、などと呼ばれる（ぼくは「ふりかえり」という言葉が好きだ）。 アジャイル開発ではこの「ふりかえり」が「KAIZEN加速装置」となる。 これを行なうときに使うフォーマットを写真に示した。ぼくはこれをKPT（ケプト）と呼ぶ（Keep/Problem/Try）。Alistair Cockburnから教えてもらったもので、ぼくはこのフォーマットのヘビーユーザー。 ホワイトボードが３つのセクションに分かれており、Keep（このまま続けること）、Problem（問題点）、Try（次に試してみたいこと）と名前が付けられている。全員参加のふりかえりミーティングを開き、そこで、今回のイテレ
マインドマップによる、ユーザ要望の聞き取り - An Agile Way
実際に、マインドマップを使って、顧客インタビューをやってみた。図書館の業務支援システムを題材に、本物の司書の方に、インタビュー。 最初に、聞きたいことの要点を、マインドマップで書いておき、その枝に聞いたことを追加していく。その枝（マインドマップ的には、BOI）は、 誰が使いますか？ どんな場面で使いますか？ 管理したいものは何ですか？ の３つである。そして、最後に宿題という枝を用意しておき、そのインタビューで出た宿題を追加する。この３つのBOIは、Who/When/What であると共に、 アクター ユースケース ドメインモデル になることを想定している。もちろん、完全にそうはならないが、ネタとして意識する。 マインドマップのコツとしては、最初から用意した質問の枝は、「下線」でなく「箱」をつかい、また「クリップ」アイコンで分かりやすくしている。宿題は、「おうち」アイコンである。このテンプレ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Agile Greatest Hits -- eラーニング：An Agile Way：オルタナティブ・ブログ
An Agile Way