タグ

ブックマーク / blogs.itmedia.co.jp/hiranabe (19)

  • 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 ピンク "

    Agilistas on twitter:An Agile Way:オルタナティブ・ブログ
  • 書籍紹介『ThoughtWorks アンソロジー』:An Agile Way:オルタナティブ・ブログ

    『ThoughtWorksアンソロジー ~ アジャイルとオブジェクト指向によるソフトウェアイノベーション』 このは、あのマーチンファウラーが「チーフサイエンティスト」という肩書きで在籍するThoughtWorks社の社員が綴ったエッセー集です。この会社は、SIとコンサルティングを生業としていて、そういう意味でぼくが在籍する「永和システムマネジメント」と近いビジネスモデルの会社です。さらにアジャイルとオブジェクト指向に傾倒していて、それでソフトウェア開発ビジネス変えよう、現場のソフトウェア開発を良くしよう、という活動をエンジニア「おのおのが」している、という点でも、永和システムマネジメントと非常に近い感覚を持っています。さらに言うと、Ruby好きが多い、と言う点でも・・・。(ただ、ワールドワイドに展開している、という点で負けています。) さて、このは内容が技術からマネジメントまで多岐にわ

    書籍紹介『ThoughtWorks アンソロジー』:An Agile Way:オルタナティブ・ブログ
  • 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とのインタビューを紹介して、CTOの苦悩を共有しようというセッションをやっていました。 Pressure and Performance: The CTO's Dilemma これまでのアジャイルでは語られることのなかった、上級役員やCTOという存在が、企業

    Agile2008 まとめ(2 - 繋がった人):An Agile Way:オルタナティブ・ブログ
  • Agile2008 まとめ(3 - 自分の活動):An Agile Way:オルタナティブ・ブログ

    ぼくの今年のテーマは、「日からよい考えを輸出すること」。オリジナリティの高いものをこのAgile2008で紹介したい。 私が今回受け持ったセッションは、この3つ Learning Kaizen from Toyota [ with Mind Maps] New Car Development in Toyota Exploring User Stories through Mind Mapping 最初のは、去年やったものを再度。これはブログで報告済み。そして、二番目のセッションは、元トヨタのCE、片山さんのデブサミでの新車開発のマネジメントの発表を託していただき、それを英訳して発表するものだ。これは、InfoQで公開されている。http://www.infoq.com/presentations/Toyota-Kenji-Hiranabe また、この2つは、アンコール上映となった。多く

    Agile2008 まとめ(3 - 自分の活動):An Agile Way:オルタナティブ・ブログ
  • Agile2008 まとめ(4 - パーティ!):An Agile Way:オルタナティブ・ブログ

    Agileは、ソフトウェア開発という活動を、「人と人との関係性」という視点から解体して再構築したものだといえる。ソーシャル性、社交、ということが決定的に重要なんだ。 その観点からも、毎回、最終日にはパーティが行われる。ここで、今回もっともぼくにとって大きなことが2つ起こる。 1つは、「Gordon Pask Award」という賞を頂いたこと。過去には、Jim Shore や J.B. Rainsberger、Jeff Patton なんかの大御所がもらっている。基的には、「あまり知られていないが、コミュニティへの貢献が大きい人」を選ぶ。そして、その人に、年間2回、世界のカンファレンスに言って話すための旅費が用意される。Gordon Pask という人自身、ほとんど知られていない。しかし、彼のソーシャルな貢献が他の有名な科学者に影響を与えた、という事実からこの賞が作られている(Brian

    Agile2008 まとめ(4 - パーティ!):An Agile Way:オルタナティブ・ブログ
  • Agile2008, Robert C. Martin's keynote:An Agile Way:オルタナティブ・ブログ

    Robert C. Martin(a.k.a Uncle Bob) が、最終日のバンケットで行った、パワフルなスピーチ。これだけでも、すごいパフォーマンスだった。正確には伝えきれないが、ちょっとだけ。 5つの元素(Quintessence) 最終日の Robert C. Martin の夕会でのキーノートは、第つの元素(Quintesense)、と題されたトークだ。The fifth Element を探す話。彼の話を聞いたことがある人なら分かると思うが、とにかく、「人間アクション漫画」のように顔と体を動かしながら話す。内容は全部は覚えていないが、覚えている分だけ、再現してみる。 第五の元素、とは、アジャイルの4つの価値、 プロセスとツールよりも個人と対話に. 包括的なドキュメントよりも動くソフトウェアに. 契約交渉よりも顧客との協調に. 計画に沿うことよりも変化に対応することに. 価値

    Agile2008, Robert C. Martin's keynote:An Agile Way:オルタナティブ・ブログ
    bobbyjam99
    bobbyjam99 2008/08/21
    "「手を洗ってきれいなコードを書こう、プロフェショナルならば。」"
  • Agile2008 まとめ(1 - 技術的な方向性):An Agile Way:オルタナティブ・ブログ

    今年の Agile2008 を自分なりにまとめてみる。 まず、技術的にもっとも「革新的」に思えたのは、Agile UX(User Experience)とKanban(かんばん)だ。この2つは、他の領域からアジャイルを発見した(あるいは、アジャイルが発見したのかもしれない)。この2つをここで紹介する。 Agile UX UI(User Interface)よりもう1つ上の領域、使っていて気持ちいいと感じる「おもてなし」の感覚がUX。UCD(User Centered Design)や、ユーザのエクスペリエンスを作っていく活動は、アジャイルと出合って大きく発展すると思う。そもそも、机上のデザインでソフトウェアのエクスペリエンスは作れないからだ。使う人と作る人の対話の場が必要で、それをプラクティスとして受け入れられるのが、アジャイル開発の1つの可能性だ。というのが、アランクーパー(VB の父で

    Agile2008 まとめ(1 - 技術的な方向性):An Agile Way:オルタナティブ・ブログ
    bobbyjam99
    bobbyjam99 2008/08/21
    UX(User Experience)は面白い発想.
  • Agile2008, Gordon Pask Award:An Agile Way:オルタナティブ・ブログ

    トロントで開かれている Agile2008 ですが、最終日には毎年、Gorden Pask Award の授賞式があります。この賞は、年に二人だけ、「あまり知られていないがAgileに重要な貢献をした人」を、「多数の人の意見を元に」選ぶそうです。受賞理由は、 アジャイルを日で普及活動している。多くの翻訳がある。 かんばんのコンセプトを、チームを超えて拡大している。 マインドマップをアジャイル開発に取り入れるという新しい考えを示した。 よい考えを、国境を越えて流通させる活動に地道に取り組んでいる ということです。とてもうれしくてないてしまった。受賞スピーチの様子を、懸田さんが録画してくれました。

    Agile2008, Gordon Pask Award:An Agile Way:オルタナティブ・ブログ
    bobbyjam99
    bobbyjam99 2008/08/13
    おめでとうございます!!
  • Agile2008 -- Learning Kaizen from Toyota [ with Mind Maps ]:An Agile Way:オルタナティブ・ブログ

    Agile2008 にきています。最初のセッションが終わりました。TPSを取り入れるときに、多くの組織でコンフリクトがあります。現状を変えることに対する抵抗。このセッションでは、流れ作業から、「屋台」型に作業方式を変えることと、ウォーターフォールからアジャイルに開発を変えることの共通性を、マインドマップで探りました。 みんな積極に参加してくれて、セッションは成功でした。英語でセッションを行うのはとても勇気と練習が必要です。ようやく慣れてきたのか、このセッションではかなりうまく場をファシリテートできたと思います。

    Agile2008 -- Learning Kaizen from Toyota [ with Mind Maps ]:An Agile Way:オルタナティブ・ブログ
  • オブジェクト倶楽部2008夏イベント(感謝):An Agile Way:オルタナティブ・ブログ

    昨日は、10回目を向かえる、オブジェクト倶楽部夏イベントでした。参加された方、どうもありがとうございました。 この写真は、会場の前の道案内をする自分です(毎年恒例)。このイベントは、当初オブジェクト指向の技術発信が目的だったのですが、今では、技術者のみなさんを「つなげる」イベントとなりました。旬な話題と場を提供すること、ワークショップなど手を動かして知らない人とコミュニケーションすることを積極的にやるのが特徴になっています。今年も、電子工作やファシリテーショングラフィックス、アジャイル開発ブートキャンプなどを取り入れました。 ぼくとしては、今回聴いた講演を通して、「相手の立場でものを見る」という発見がありました。これは主催側が意図したものではなくて、自分の中で鳴ったベル。すべてのことは、「自分」という世界でたった一人の人間が認識するものなのですが、同時に、必ず「相手」がいてそこで意味が起こ

    オブジェクト倶楽部2008夏イベント(感謝):An Agile Way:オルタナティブ・ブログ
  • Ivar Jacobson、Process ではない、Practice が大切だ。:An Agile Way:オルタナティブ・ブログ

    RSDC のレポート。 Rational の雄、Ivar Jacobson のセミナーです。彼はもちろん、UseCaseの発明者であり、UMLの定義に参加した1人として有名です。彼は今、Process を捨て、Practiceベースのソフトウェア開発の定義に取り組んでいるようです。 Enough Process, Let's Do Practices! 彼は、過去、3回プロセスの定義に関わっていますが(Objectory, RUP)、もうやらない、と宣言。それは、人々がプロセスが嫌いだから。今、ソフトウェア開発で重要なのはモチベーションであり、「やりたくない」ことを現場に持ち込むのは罪だから。プロセスではなく、プラクティス(実践項目)をチョイスして、プロセスを組み立てる方向です。UMLの意味論で言うと、プロセスを「クラス」、プラクティスを「クラスの要素」という関係でなく、プロセスを「パッケ

    Ivar Jacobson、Process ではない、Practice が大切だ。:An Agile Way:オルタナティブ・ブログ
    bobbyjam99
    bobbyjam99 2008/06/10
    Ivar Jacobsonがプロセス作るのアキタ!!と公言したっていう話.
  • Scott Ambler と ソフトウェア開発のメタファについて話をした。:An Agile Way:オルタナティブ・ブログ

    IBM の中でテクニカル的にアジャイルについての発言をしているのは Scott Ambler です。今日は彼と話すことができました。Agile@Scale のBofです。 BOFは4人でしたので、ひざを突き合わせて話をしましたが、そのうち一人は、Agileというコンセプトに始めて出合った人。その人の、 「ソフトウェアは工学的に作るようにようやく進歩してきたのだ。Agileはその歴史を、人側に逆戻りさせようというのか?」 という質問に、 「昔、太陽は地球の周りを回っていると思われていた。しかし、回っていたのは地球だった。これがAgileのパラダイムシフト。もしかしたら、後何年か先に、宇宙の中心がみつかって、そこを中心に回っていることがまた発見されるかもしれない。ソフトウェア工学はまだ40年しか歴史がないのだから。」 といい答え。さらに、 「建築や土木をソフトウェアのメタファと捉えるのではなく

    Scott Ambler と ソフトウェア開発のメタファについて話をした。:An Agile Way:オルタナティブ・ブログ
    bobbyjam99
    bobbyjam99 2008/06/04
    Scott Amblerのメタファっぷりにちびった.⇒"建築や土木をソフトウェアのメタファと捉えるのではなく、今一番近いのは、映画を撮る、というモデル"
  • 「要求は変化する。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

    「要求は変化する。Boehm は間違っていた、と DeMarco が暴いた。」というYourdon のブログ:An Agile Way:オルタナティブ・ブログ
    bobbyjam99
    bobbyjam99 2008/05/21
    合っているけど,顧客も絡むから徐々にだろうなぁ.⇒"ぼくらも、いまの産業構造の中で「契約がこうだからできない」ということを言わずに、原則論から考えて、構造自体を変えて行くことをしないか?"
  • 「ふりかえり」が失敗する8つの理由:An Agile Way:オルタナティブ・ブログ

    アジャイルレトロスペクティブ」の著者、イースターダービーのStickymindsの短い記事です。 「ふりかえり」が失敗する8つの理由 Eight Reasons Retrospectives Fail ぼくは Retrospectives を「ふりかえり」、と訳している。オブジェクト倶楽部のプロジェクトファシリテーションのページに、天野さんが、日語の「ふりかえりガイド」(PDF)もかいている。 簡単にまとめると、 「ふりかえり」が失敗する8つの理由 1.準備不足。 ⇒アジェンダをしっかり用意すること。 2.焦点があいまい。 ⇒前回のイテレーションの改善に集中。 3.データが集まっていない。 ⇒何かを変えようとするまえに、「実際に何が起きていたか」を話す。 4.1人か2人が会議全体の会話を独占してしまう。 ⇒ペアにしたり、グループを作ったりして話あうアクティビティを持つ。 5.自分たちで

    「ふりかえり」が失敗する8つの理由:An Agile Way:オルタナティブ・ブログ
  • Scaling Agile ... ソフトウェア開発をスケールさせる(大規模対応):An Agile Way:オルタナティブ・ブログ

    Agile開発はどうしても少人数での開発が多い。スタンドアップミーティングができる人数、つまり1ダースが1つの目安。また、ウォーターフォールなら大規模が成功するか、というと、ぼくはウォーターフォールの大規模開発で成功例を見たことがない。当にソフトウェア開発はスケールさせられるのだろうか、という疑問もある。 ソフトウェア開発をスケールさせるにはどうしたらよいのだろうか。 別のドメインの似た例として、Webのサーバー側のシステムをスケールさせるには、2つの考え方がある。 ・scale up ... 1マシンのCPUやメモリ、バス性能などをアップさせて、システムのパフォーマンスを上げる。 ・scale out ... マシンの数を増やして、システムのパフォーマンスを上げる。 scale up には限界がある。その時点のテクノロジの限界があるから。逆に scale out 作戦が成功するようなア

    Scaling Agile ... ソフトウェア開発をスケールさせる(大規模対応):An Agile Way:オルタナティブ・ブログ
    bobbyjam99
    bobbyjam99 2008/05/20
    スケールアウトは難しいからスケールアップするしかないよねって話.
  • 《本》「リーン開発の本質」予約できます。:An Agile Way:オルタナティブ・ブログ

    リーン開発の質 ソフトウエア開発に生かす7つの原則 http://www.amazon.co.jp/exec/obidos/ASIN/482228350X/xpjp-22 ついに、amazonで予約可能です!私は監訳を担当していますが、今回も、前作に劣らずとてもよい。前作を読んでいない人には、前作を飛ばしてこのをお勧めします。以下、監訳者としてのあとがきの一部です。。。 ■「アジャイル」と「トヨタ生産方式」の出会いが「リーン開発の質」である ソフトウエア開発の一手法である「アジャイル」と、日の工場の生産方式に起源をもつ「トヨタ生産方式」。一見まったく違う2つの分野をクロスオーバーする新しい流れが起こっている。それが、書の主題である「リーン開発」である。 「アジャイル」は、日では2000年ごろから、ソフトウエア開発現場のリーダー、プログラマーをはじめとする、最新オブジェクト指向

    《本》「リーン開発の本質」予約できます。:An Agile Way:オルタナティブ・ブログ
    bobbyjam99
    bobbyjam99 2008/02/13
    リーン開発の解説あり
  • Agile と Waterfall の適材適所:An Agile Way:オルタナティブ・ブログ

    シャノンの情報定理によると、50%の確率の未来を確定させることの価値は大きい。成功確率0%のプロジェクトをやるのは意味がなく、100%のプロジェクトをやることはまったく簡単だ。 ウォーターフォールとアジャイルがどんなときに有効か、と考えると、100%に近く安定して結果が出せそうな時、はウォーターフォールで、未来が予見しにくいときはアジャイルで、というのが筋が合いそうに思う。それを、「成功確率」、「再現可能性」という軸に乗せてみた。ウォーターフォールは、製造に近いモデルなんだな。計画通りやることが正解であり、情報が事前に十分集まっている状態(Prepare Before Doing)。アジャイルは、そもそもうまく行くかどうか分からないから、少しずつ進んで、情報を仕入れながらやっていこう(Learning By Doing)、というスタンス。 アジャイルのやり方がうまくようになったのは、リファ

    Agile と Waterfall の適材適所:An Agile Way:オルタナティブ・ブログ
    bobbyjam99
    bobbyjam99 2008/02/13
    この棲み分けで合ってるけど、安定して結果を出せることなんてあるのかな・・・⇒"100%に近く安定して結果が出せそうな時、はウォーターフォールで、未来が予見しにくいときはアジャイルで、というのが筋が合いそう"
  • 自分たちのよいところを認識することからはじめる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=アプリシアティブ・インクワイアリ(

    自分たちのよいところを認識することからはじめるXP:An Agile Way:オルタナティブ・ブログ
  • テスト駆動開発のテストは、テストか?―TDD から BDD へ - An Agile Way [ITmedia オルタナティブ・ブログ]

    アジャイル開発の中の1つのプラクティスである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さんの「テス

    テスト駆動開発のテストは、テストか?―TDD から BDD へ - An Agile Way [ITmedia オルタナティブ・ブログ]
  • 1