Agilistas on twitter：An Agile Way：オルタナティブ・ブログ
アジャイルの最新動向を知るため、および、英語の勉強に、ぼくがフォローしているアジャイル有名人の twitter id をリストしておきます。うれしいことに、全員と面識があり、Agile カンファレンスに行く度に彼らと会うのが楽しみ。（今年は行けなかったけど ;_;） ◆第一世代アジャイル推進者/オブジェクト指向やパターン界の重鎮でもある @jimhighsmith Jim Highsmith @unclebobmartin Uncle Bob Martin @TotherAlistair Alistair Cockburn @WardCunningham Ward Cunningham @KentBeck Kent Beck @JerryWeinberg Jerry Weinberg @marick Brian Marick @RonJeffries Ron Jeffries ピンク本 "
書籍紹介『ThoughtWorks アンソロジー』：An Agile Way：オルタナティブ・ブログ
『ThoughtWorksアンソロジー ～ アジャイルとオブジェクト指向によるソフトウェアイノベーション』 この本は、あのマーチンファウラーが「チーフサイエンティスト」という肩書きで在籍するThoughtWorks社の社員が綴ったエッセー集です。この会社は、SIとコンサルティングを生業としていて、そういう意味でぼくが在籍する「永和システムマネジメント」と近いビジネスモデルの会社です。さらにアジャイルとオブジェクト指向に傾倒していて、それでソフトウェア開発ビジネス変えよう、現場のソフトウェア開発を良くしよう、という活動をエンジニア「おのおのが」している、という点でも、永和システムマネジメントと非常に近い感覚を持っています。さらに言うと、Ruby好きが多い、と言う点でも・・・。（ただ、ワールドワイドに展開している、という点で負けています。） さて、この本は内容が技術からマネジメントまで多岐にわ
Agile2008 まとめ(2 - 繋がった人)：An Agile Way：オルタナティブ・ブログ
InfoQのFloydが、朝食会に招いてくれた。Floydとも初対面。とても若い実業家、というタイプで、落ち着いていてびっくり。 そこで、前から僕の記事を編集しているDebora Harman、『Agile Adoption Patterns』の Amr Elssamadisy と会う。 また、『Art of Agile Software Development』の James Shore とは一度会って挨拶したいと思っていた。木下さんと、二人で会いに行く。彼は、『アジャイルレトロスペクティブ』のDiana Larsen と企業のCTOとのインタビューを紹介して、ＣＴＯの苦悩を共有しようというセッションをやっていました。 Pressure and Performance: The CTO's Dilemma これまでのアジャイルでは語られることのなかった、上級役員やＣＴＯという存在が、企業
Agile2008 まとめ(3 - 自分の活動)：An Agile Way：オルタナティブ・ブログ
ぼくの今年のテーマは、「日本からよい考えを輸出すること」。オリジナリティの高いものをこのAgile2008で紹介したい。 私が今回受け持ったセッションは、この３つ Learning Kaizen from Toyota [ with Mind Maps] New Car Development in Toyota Exploring User Stories through Mind Mapping 最初のは、去年やったものを再度。これはブログで報告済み。そして、二番目のセッションは、元トヨタのＣＥ、片山さんのデブサミでの新車開発のマネジメントの発表を託していただき、それを英訳して発表するものだ。これは、InfoQで公開されている。http://www.infoq.com/presentations/Toyota-Kenji-Hiranabe また、この２つは、アンコール上映となった。多く
Agile2008 まとめ(4 - パーティ!)：An Agile Way：オルタナティブ・ブログ
Agileは、ソフトウェア開発という活動を、「人と人との関係性」という視点から解体して再構築したものだといえる。ソーシャル性、社交、ということが決定的に重要なんだ。 その観点からも、毎回、最終日にはパーティが行われる。ここで、今回もっともぼくにとって大きなことが２つ起こる。 １つは、「Gordon Pask Award」という賞を頂いたこと。過去には、Jim Shore や J.B. Rainsberger、Jeff Patton なんかの大御所がもらっている。基本的には、「あまり知られていないが、コミュニティへの貢献が大きい人」を選ぶ。そして、その人に、年間２回、世界のカンファレンスに言って話すための旅費が用意される。Gordon Pask という人自身、ほとんど知られていない。しかし、彼のソーシャルな貢献が他の有名な科学者に影響を与えた、という事実からこの賞が作られている（Brian
Agile2008, Robert C. Martin's keynote：An Agile Way：オルタナティブ・ブログ
Robert C. Martin(a.k.a Uncle Bob) が、最終日のバンケットで行った、パワフルなスピーチ。これだけでも、すごいパフォーマンスだった。正確には伝えきれないが、ちょっとだけ。 ５つの元素(Quintessence) 最終日の Robert C. Martin の夕食会でのキーノートは、第つの元素(Quintesense)、と題されたトークだ。The fifth Element を探す話。彼の話を聞いたことがある人なら分かると思うが、とにかく、「人間アクション漫画」のように顔と体を動かしながら話す。内容は全部は覚えていないが、覚えている分だけ、再現してみる。 第五の元素、とは、アジャイルの４つの価値、 プロセスとツールよりも個人と対話に． 包括的なドキュメントよりも動くソフトウェアに． 契約交渉よりも顧客との協調に． 計画に沿うことよりも変化に対応することに． 価値
Agile2008 まとめ(1 - 技術的な方向性)：An Agile Way：オルタナティブ・ブログ
今年の Agile2008 を自分なりにまとめてみる。 まず、技術的にもっとも「革新的」に思えたのは、Agile UX(User Experience)とKanban(かんばん)だ。この２つは、他の領域からアジャイルを発見した（あるいは、アジャイルが発見したのかもしれない）。この２つをここで紹介する。 Agile UX UI(User Interface)よりもう１つ上の領域、使っていて気持ちいいと感じる「おもてなし」の感覚がUX。UCD(User Centered Design)や、ユーザのエクスペリエンスを作っていく活動は、アジャイルと出合って大きく発展すると思う。そもそも、机上のデザインでソフトウェアのエクスペリエンスは作れないからだ。使う人と作る人の対話の場が必要で、それをプラクティスとして受け入れられるのが、アジャイル開発の１つの可能性だ。というのが、アランクーパー(VB の父で
Agile2008, Gordon Pask Award：An Agile Way：オルタナティブ・ブログ
トロントで開かれている Agile2008 ですが、最終日には毎年、Gorden Pask Award の授賞式があります。この賞は、年に二人だけ、「あまり知られていないがAgileに重要な貢献をした人」を、「多数の人の意見を元に」選ぶそうです。受賞理由は、 アジャイルを日本で普及活動している。多くの翻訳がある。 かんばんのコンセプトを、チームを超えて拡大している。 マインドマップをアジャイル開発に取り入れるという新しい考えを示した。 よい考えを、国境を越えて流通させる活動に地道に取り組んでいる ということです。とてもうれしくてないてしまった。受賞スピーチの様子を、懸田さんが録画してくれました。
オブジェクト倶楽部2008夏イベント（感謝）：An Agile Way：オルタナティブ・ブログ
昨日は、１０回目を向かえる、オブジェクト倶楽部夏イベントでした。参加された方、どうもありがとうございました。 この写真は、会場の前の道案内をする自分です（毎年恒例）。このイベントは、当初オブジェクト指向の技術発信が目的だったのですが、今では、技術者のみなさんを「つなげる」イベントとなりました。旬な話題と場を提供すること、ワークショップなど手を動かして知らない人とコミュニケーションすることを積極的にやるのが特徴になっています。今年も、電子工作やファシリテーショングラフィックス、アジャイル開発ブートキャンプなどを取り入れました。 ぼくとしては、今回聴いた講演を通して、「相手の立場でものを見る」という発見がありました。これは主催側が意図したものではなくて、自分の中で鳴ったベル。すべてのことは、「自分」という世界でたった一人の人間が認識するものなのですが、同時に、必ず「相手」がいてそこで意味が起こ
Ivar Jacobson、Process ではない、Practice が大切だ。：An Agile Way：オルタナティブ・ブログ
RSDC のレポート。 Rational の雄、Ivar Jacobson のセミナーです。彼はもちろん、UseCaseの発明者であり、UMLの定義に参加した１人として有名です。彼は今、Process を捨て、Practiceベースのソフトウェア開発の定義に取り組んでいるようです。 Enough Process, Let's Do Practices! 彼は、過去、３回プロセスの定義に関わっていますが（Objectory, RUP）、もうやらない、と宣言。それは、人々がプロセスが嫌いだから。今、ソフトウェア開発で重要なのはモチベーションであり、「やりたくない」ことを現場に持ち込むのは罪だから。プロセスではなく、プラクティス（実践項目）をチョイスして、プロセスを組み立てる方向です。UMLの意味論で言うと、プロセスを「クラス」、プラクティスを「クラスの要素」という関係でなく、プロセスを「パッケ
Scott Ambler と ソフトウェア開発のメタファについて話をした。：An Agile Way：オルタナティブ・ブログ
IBM の中でテクニカル的にアジャイルについての発言をしているのは Scott Ambler です。今日は彼と話すことができました。Agile@Scale のBofです。 BOFは４人でしたので、ひざを突き合わせて話をしましたが、そのうち一人は、Agileというコンセプトに始めて出合った人。その人の、 「ソフトウェアは工学的に作るようにようやく進歩してきたのだ。Agileはその歴史を、人側に逆戻りさせようというのか？」 という質問に、 「昔、太陽は地球の周りを回っていると思われていた。しかし、回っていたのは地球だった。これがAgileのパラダイムシフト。もしかしたら、後何年か先に、宇宙の中心がみつかって、そこを中心に回っていることがまた発見されるかもしれない。ソフトウェア工学はまだ40年しか歴史がないのだから。」 といい答え。さらに、 「建築や土木をソフトウェアのメタファと捉えるのではなく
「要求は変化する。Boehm は間違っていた、と DeMarco が暴いた。」というYourdon のブログ：An Agile Way：オルタナティブ・ブログ
「要求は変化する。Boehm は間違っていた、と DeMarco が暴いた。」というYourdon のブログ Mary Poppendieck の iPod からしいれた情報より。 （SPaMCAST:http://www.spamcast.libsyn.com/ のMaryの回をチェック。） 2007年5月ICSEで、ぼくらの世代にとてっての「ソフトウェア開発の先生」たちが集まったパネルディスカッションがミネアポリスにて開催されていた。参加者は、Fred Brooks, Jr., Tom DeMarco、Barry Boehm、Linda Rising、Tim Lister, Ed Yourdon. パネルの中で、「どうしてソフトウェア開発の人系の視点(people side)が、アジャイルという言葉で発見されるのにこんなにも時間がかかったのか。」という質問があった。すると、Tom De
「ふりかえり」が失敗する８つの理由：An Agile Way：オルタナティブ・ブログ
「アジャイルレトロスペクティブ」の著者、イースターダービーのStickymindsの短い記事です。 「ふりかえり」が失敗する８つの理由 Eight Reasons Retrospectives Fail ぼくは Retrospectives を「ふりかえり」、と訳している。オブジェクト倶楽部のプロジェクトファシリテーションのページに、天野さんが、日本語の「ふりかえりガイド」(PDF)もかいている。 簡単にまとめると、 「ふりかえり」が失敗する８つの理由 １．準備不足。 ⇒アジェンダをしっかり用意すること。 ２．焦点があいまい。 ⇒前回のイテレーションの改善に集中。 ３．データが集まっていない。 ⇒何かを変えようとするまえに、「実際に何が起きていたか」を話す。 ４．１人か２人が会議全体の会話を独占してしまう。 ⇒ペアにしたり、グループを作ったりして話あうアクティビティを持つ。 ５．自分たちで
Scaling Agile ... ソフトウェア開発をスケールさせる（大規模対応）：An Agile Way：オルタナティブ・ブログ
Agile開発はどうしても少人数での開発が多い。スタンドアップミーティングができる人数、つまり１ダースが１つの目安。また、ウォーターフォールなら大規模が成功するか、というと、ぼくはウォーターフォールの大規模開発で成功例を見たことがない。本当にソフトウェア開発はスケールさせられるのだろうか、という疑問もある。 ソフトウェア開発をスケールさせるにはどうしたらよいのだろうか。 別のドメインの似た例として、Webのサーバー側のシステムをスケールさせるには、２つの考え方がある。 ・scale up ... １マシンのCPUやメモリ、バス性能などをアップさせて、システムのパフォーマンスを上げる。 ・scale out ... マシンの数を増やして、システムのパフォーマンスを上げる。 scale up には限界がある。その時点のテクノロジの限界があるから。逆に scale out 作戦が成功するようなア
《本》「リーン開発の本質」予約できます。：An Agile Way：オルタナティブ・ブログ
リーン開発の本質 ソフトウエア開発に生かす7つの原則 http://www.amazon.co.jp/exec/obidos/ASIN/482228350X/xpjp-22 ついに、amazonで予約可能です！私は監訳を担当していますが、今回も、前作に劣らずとてもよい本。前作を読んでいない人には、前作を飛ばしてこの本をお勧めします。以下、監訳者としてのあとがきの一部です。。。 ■「アジャイル」と「トヨタ生産方式」の出会いが「リーン開発の本質」である ソフトウエア開発の一手法である「アジャイル」と、日本の工場の生産方式に起源をもつ「トヨタ生産方式」。一見まったく違う２つの分野をクロスオーバーする新しい流れが起こっている。それが、本書の主題である「リーン開発」である。 「アジャイル」は、日本では2000年ごろから、ソフトウエア開発現場のリーダー、プログラマーをはじめとする、最新オブジェクト指向
Agile と Waterfall の適材適所：An Agile Way：オルタナティブ・ブログ
シャノンの情報定理によると、50%の確率の未来を確定させることの価値は大きい。成功確率0%のプロジェクトをやるのは意味がなく、100%のプロジェクトをやることはまったく簡単だ。 ウォーターフォールとアジャイルがどんなときに有効か、と考えると、100%に近く安定して結果が出せそうな時、はウォーターフォールで、未来が予見しにくいときはアジャイルで、というのが筋が合いそうに思う。それを、「成功確率」、「再現可能性」という軸に乗せてみた。ウォーターフォールは、製造に近いモデルなんだな。計画通りやることが正解であり、情報が事前に十分集まっている状態(Prepare Before Doing)。アジャイルは、そもそもうまく行くかどうか分からないから、少しずつ進んで、情報を仕入れながらやっていこう(Learning By Doing)、というスタンス。 アジャイルのやり方がうまくようになったのは、リファ
自分たちのよいところを認識することからはじめるXP：An Agile Way：オルタナティブ・ブログ
ぼくが尊敬する、Kent Beck 氏が書いた最近の記事「Appreciating Your Way to XP」、を許可を得て日本語訳しました。 印刷用のPDFもこちらに容易しました。 自分たちの良いところを認識することからはじめるXP (出典：”Appreciating Your Way to XP”) http://www.threeriversinstitute.org/AppreciatingYourWayToXP.htm Kent Beck, Three Rivers Institute 訳: 平鍋健児 概要 「問題を認識してそれを解決する」という考え方は工学では常識的だが、別の手法として、「現在うまくいっていることの価値を認識(appreciate)することからはじめる」というアプローチには、変化を生み出す大きな力がある。この記事では、AI=アプリシアティブ・インクワイアリ(
テスト駆動開発のテストは、テストか？―TDD から BDD へ - An Agile Way [ITmedia オルタナティブ・ブログ]
アジャイル開発の中の１つのプラクティスであるTDD(Test Driven Development、テスト駆動開発)に使われるユニット・テスト、というものの役割について、よくテスト界の人との意見の相違がある。テストとしての完全性、や、品質保証についての考え方から見ると、テストとは呼べないのでは？ということ。 最近、アメリカテスト界の有名人であり、アジャイルコミュニティへの貢献も大きい、Brain Marick(www.testing.com/cgi-bin/blog) 氏とメールで話す機会があった。 アメリカでのコンセンサスは、TDDのテストはテストとしては二義的であり、一義的には、「設計ツール」だ これは、以前「テストの役割=進捗管理＋設計戦略」 blogs.itmedia.co.jp/hiranabe/2005/08/sd4__c05e.html で 紹介した、t-wadaさんの「テス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Agile2008 -- Learning Kaizen from Toyota [ with Mind Maps ]：An Agile Way：オルタナティブ・ブログ