Lean Startup リーンスタートアップ解説(2)：An Agile Way：オルタナティブ・ブログリーンスタートアップ概説の2回目です。今回は、5/23 にサンフランシスコで行われた、Startup Lessons Learned カンファレンス(sllconf) での、エリック・リースの基調講演を、日本語訳しました。 おそらく、最新の一番わかりやすい解説になるのではないかと思います。エリックに連絡をとって、日本語訳の許可をもらって、ここに公開します。 友人の関口さんとSkypeで話をしていたら、実際にこのカンファレンスに参加していた！とのこと。急遽、共訳をお願いしました。
Lean Startup と ARC(Agile/Ruby/Cloud) について：An Agile Way：オルタナティブ・ブログ
5/12 クラウドEXPOのIIJさんのブースにて、「今、なぜアジャイルが注目されるのか～クラウド環境での素早いスタートアップ～」と題してお話させていただきました。 いつものアジャイルのWhyの話、プロセス視点の話のあとに、新ネタとして Eric Ries さんのLean Startup の話を入れました。そして、その基盤として、ARC(Agile/Ruby/Could)につなげました。（今、Ericさんはなんと、ボルチモアで開催されている Railsconf のキーノーターとして話しているのですね！） いくつかキーとなるスライドを紹介します。 これは、下にScrumのループを示し、その上に「？」を描いています。「製品バックログはどこから来て、出荷可能ソフトウェアはどこへいくの？」という問いに答えようとしています。 ここはScrum的にいうと、「プロダクトオーナーの仕事」なんですが、ここは
End of Methodology (日本語訳)：An Agile Way：オルタナティブ・ブログ
アリスターコーバーンの新着記事『方法論の終焉』(End of methodology)の翻訳です。この翻訳は、twitterを使って数名で短時間で人力翻訳する、という実験プロジェクトでやってみました（末尾にその話）。 元記事は、こちら。http://alistair.cockburn.us/The+end+of+methodology アジャイル開発が「方法論」といった体裁からどんどんはなれ、「自分たちで自分たちやリ方を(Reflective=ふりかえり)どんどんよくしていく(Improvement=改善)そんな枠組み（Framework)」になっていったことに、一つの名前を与えようとしている。そんな話です。この名前自体（当然その日本語も）まだ良いものではなく、新しい名前がこれにつくことの前兆となる記事だと思っています。 方法論の終焉(End of Methodology) by Ali
Lean Startup リーンスタートアップ解説(1)：An Agile Way：オルタナティブ・ブログ
サンフランシスコ周辺で最近大きな話題になっている、リーンスタートアップ、について、簡単に導入解説したいと思います。 これによって、アジャイルは「既存の組織改革」という１つの出口から、「新しい起業の創業（スタートアップ）」という、もう１つの大きなビジネスホームグラウンドを見つけたように思います。 この資料は少し古くて、2009年に Eric Ries が Web2.0. Expo にて発表したものの一部です。オリジナルスライドはこちら。 「ウォーターフォール」、「アジャイル」、そして「リーンスタートアップ」、という３段階で説明していきましょう。 ウォーターフォール型の製品開発モデルでは、問題が既知で、解法も既知、という前提にたっています。計画したことが計画通りにうまくいけば、それでOKという世界観です。 ここでの進捗単位は、工程を１つ進む、ということ。となります。計画駆動の進め方です。 これ
x-dev で茂木さんと対談しました。：An Agile Way：オルタナティブ・ブログ
ぼくが株式会社チェンジビジョンを作ったときの夢は、「茂木さんのプロフェッショナルに呼ばれる」です。今日はその半分くらいが叶った気がした日でした。（写真は対談後、東京ドームホテル５F控え室にて） ぼくは、台風のお陰でタクシーにて10分遅れで会場に到着、なんと茂木さんをお待たせしてしまい、汗だくで走ってマラソン選手のように登場。そのまま、茂木さんのマシンガントークに押されながらも、応戦しました。普段の対談では、だいたいぼくはしゃべり負けないのですが、今回は７：３でしゃべり負けました！でも、茂木さんにWeb2.0的なものとはちがう、日本のソフトウェア開発業界もわかって頂けた気がしましたし、その上で、勇気をもらえる発言を引き出せたので、よかったと思います。 到着したとき、茂木さんは、「創造性＝体験×情熱意欲」という話をされていました。この部分はぼくは聞いていないのですが、「体験」の部分がさすが、茂
テスト駆動開発のテストは、テストか？―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さんの「テス
業務フローのリファクタリング：An Agile Way：オルタナティブ・ブログ
牛尾さんの記事「モデリング・リファクタリングのススメ」です。 http://itpro.nikkeibp.co.jp/article/Watcher/20070612/274464/ これはすごい。プログラミングレベルの概念である「リファクタリング」を、業務フローの記述に援用し、しかも、「不吉なにおい」と「リファクタリングカタログ」までついているではないですか！ 要求開発では、ITシステムの要求を獲得する過程を「収集」（そこにすでにあるものを拾ってくる）のではなく、「開発」（ビジネス価値から作り出すもの）と捕らえることで、システム開発が培ってきた手法を延長しようとしています。そして、今回、システム開発の手法の１つであるリファクタリングを、今回要求開発に延長しています。（それ以外にも、モデリングやUMLもシステム開発から持ち込んでいます） でも、私は、この記事のすばらしいところは、ナレッジを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
