データモデリングなきアジャイル開発は危ういか？：An Agile Way：オルタナティブ・ブログ
尊敬するDOAの先輩である、渡辺さんがこう書いている。 「データモデルなきアジャイル」の危うさ、より その種のシステム（※引用者補記：販売管理システムや生産管理システムといった基幹系業務支援システム）をアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。 それに対して、稲見さんがこんなコメントをしている。 アジャイル開発と言っても色々で、最近流行りの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 と ARC(Agile/Ruby/Cloud) について：An Agile Way：オルタナティブ・ブログ
5/12 クラウドEXPOのIIJさんのブースにて、「今、なぜアジャイルが注目されるのか～クラウド環境での素早いスタートアップ～」と題してお話させていただきました。 いつものアジャイルのWhyの話、プロセス視点の話のあとに、新ネタとして Eric Ries さんのLean Startup の話を入れました。そして、その基盤として、ARC(Agile/Ruby/Could)につなげました。（今、Ericさんはなんと、ボルチモアで開催されている Railsconf のキーノーターとして話しているのですね！） いくつかキーとなるスライドを紹介します。 これは、下にScrumのループを示し、その上に「？」を描いています。「製品バックログはどこから来て、出荷可能ソフトウェアはどこへいくの？」という問いに答えようとしています。 ここはScrum的にいうと、「プロダクトオーナーの仕事」なんですが、ここは
チケット管理システムをつかってみよう！：An Agile Way：オルタナティブ・ブログ
チケット管理システム、使っていますか？ 小川 明彦さん、阪井 誠さんによる、 「Redmineによるタスクマネジメント実践技法」 が出版されました。trac, Jira, redmine などなど、ちまたには多くの優秀なチケット管理システム(BTS, ITS)があります。もし、チケット管理システムをまだ導入していないプロジェクトがあったら、この機会に導入を検討してはいかがでしょう。Excelでタスク管理などをやっている場合ではありません！ 例えば「ソースコード管理システム」は、現代の必須インフラですね。SubversionやGitなどの版管理システムは、プロジェクトでもっとも大切な資産である「ソースコード」を全員で共有し、時間に沿って記録し変更を管理します。今はこれなしでは、ソフトウェア開発のプロジェクトは成り立たないでしょう。そして、現代のプロジェクトに必須なインフラをもう１つあげるとし
『JUnit の歴史とテスティングの未来(Kent Beckインタビュー)』を訳します。：An Agile Way：オルタナティブ・ブログ
"Software Engineering Radio" という PodCast の Kent Beck のインタビューがとても面白かったので、要点を日本語訳したい。 http://www.se-radio.net/2010/09/episode-167-the-history-of-junit-and-the-future-of-testing-with-kent-beck/ 1時間くらいのインタビューなので、一人で全部やるのは辛い。。。と思い、リレー形式でこれを訳するプロジェクトを @urimaro さんと（勝手に）立ち上げました！参加したい人は、ぼくか@urimaroさんがこの PodCast を訳したブログや日記に、参加意思表明のコメントをください。基本、先着でまわしたいと思います。 ではここから。正確に訳しているのではなくて、ポイントを日本語にしていきたいと思います。インタビュー
Lean Software and Systems Conference 2010 in Atlanta：An Agile Way：オルタナティブ・ブログ
アトランタで、リーン・ソフトウェア・アンド・システムズ・カンファレンス(Lean Software and Systems Conference)2010 が開催されています。 とても行きたかったのですが、今回はいけなったので、ちょっと起こっていることの概要を。プログラムはこちら。 http://atlanta2010.leanssc.org/agenda/ この LSSC というコンセプトは、もちろんソフトウェア開発の文脈ではアジャイルからはじまっていますが、より、Lean 運動の影響を強く受けており、工学との融合、マネジメント・リーダーシップとの融合、ソフトウェアとシステムの融合、を目指しています。Leanは、医療、建築、製品開発、の分野で現在とてもホットな領域で、さまざまな産業界が注目しているムーブメント。ソフトウェア開発では、Mary Poppendieck が先導を切ってアジャイ
AgileJapan2010 野中郁次郎先生の基調講演について：An Agile Way：オルタナティブ・ブログ
アジャイルジャパン2010で、野中郁次郎先生の講演について、少しまとめて書いてみます。野中先生を呼びたいと思った動機は前回お伝えしたとおりです。 この資料で、最初の２ページは、打ち合わせで「ここは僕からは言えないので紹介してほしい」といわれた部分で、平鍋から、先生の影響力、ということで紹介させてもらった部分です。でも、すごいですね。世界的に知られている。ちなみにドラッカーがリストには入っていませんが、現在生きている人、ということで入っていないようです。講演では、ドラッカーの奥さんが９０代で週二回テニスをしている、ということをあげて、「やっぱり女性の方が強いんだ」、と笑っておっしゃっていました。 一番最近出版した本が、「Managing Flow」という本で、私も一冊頂きました。中には日本の経営のいろんな会社名が出てきます。この本も、英語でまず書いて、日本語をその後で出版する、というスタイル
IPA/SEC 非ウォーターフォール研究会の成果：An Agile Way：オルタナティブ・ブログ
IPA/SEC から、「非ウォーターフォール研究会」の成果が発表されています。 こちらから、エグゼクティブサマリがダウンロードできます。 http://sec.ipa.go.jp/reports/20100330a/20100330a_3.pdf (PDF 698KB) 私もこの研究会に参加していました。研究会は、NEC、富士通、日立、新日鉄ソリューションズといった日本の大手SIer、それに楽天、DeNAといったWebサービスを生業の中心とする企業、それから、一（いち）の大槻さんや豆蔵の羽生田さんのようなコンサルタント、永和システムマネジメントの私のような現場支援や受託開発をしている会社、「ソフトウェア最前線－ウォーターフォールは間違っている」の前川先生、松島先生のような大学の先生、それに座長の松本先生、にIPA/SECの研究員の方々をふくめ、いろんな立場の方が参加していたものです。 最
「測定できないものは制御できない｣は誤りだった。-- by Tom Demarco：An Agile Way：オルタナティブ・ブログ
ソフトウェア工学の祖の一人である、トム・デマルコが、最近IEEE Software 誌に、過去のソフトウェア・メトリクス賛美を悔い改める記事を書いている。 「ソフトウェア工学」というコンセプト－その時が来た、そして、その時は去った。http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r 1982年に、デマルコは有名な「計測できないものは制御できない」という一文から始まる、『品質と生産性を重視したソフトウェア開発プロジェクト技法』という名著を書いている。このドグマは、ソフトウェア工学の考え方に強く根ざしている。むしろ、すべての「工学」という活動は、科学や経験から得た知見を使って自然現象をコントロールし、人間の役に立てることをその定義としており、そこでは測定を元にしたコントロールという概念はその中核にあ
設計からコーディングまでの「距離」：An Agile Way：オルタナティブ・ブログ
私の立場は「コーディングは設計（の一部）だ」(by Jack Reeves)である。ここでは、コーディング以前のラフな設計（例えばUMLのクラス図やシーケンス図レベルのアイディア、それがホワイトボードに描かれていようが、紙であろうが、JUDEであろうが、日本語であろうが）を、ここでは設計と呼ぼう。 設計とコーディングの距離が増えれば増えるほど、ムダが増える。私の主張は、できるだけ、１つの関連部分の設計とコーディングは、「一人の人」が「少しずつ」行ったほうがよい、ということだ。昔見た「詳細設計書」という細かい実装の詳細を日本語である人が書き、それを見て別の人がコードを書く、ということは避けたい。ここでの距離とは、 頭脳間距離。 時間的距離。 の２つ。 頭脳的距離は、物理的に書く人の頭脳の距離だ。1人の人が設計からコーディングまでを含めて担当すれば、この距離は0だ、別の頭脳が担当するならば同じ
「要求は変化する。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
google video でオブジェクト倶楽部の動画公開：An Agile Way：オルタナティブ・ブログ
昨年１２月のオブジェクト倶楽部クリスマスイベントの動画をアップしました。 「ソーシャルチェンジ～世界の変化はあなたから」（平鍋健児） http://video.google.com/videoplay?docid=-7257264183783738026 今回、手元カメラ（書画カメラ）で絵を描きながら、「ソフトウェアは壮大な伝言ゲーム」ということを伝えてみました（※時間のない方は、１１分後くらいから見てください）。 他にも、 安井さん「ソフトウェア冶具」 http://video.google.com/videoplay?docid=-4683716686357753198 水越「マインドマップ」 http://video.google.com/videoplay?docid=7155483878277820392 などもあります。水越さんは、大きなホワイトボードにマインドマップを書きなが
ユースケース重要！（not 図、but 記述)：An Agile Way：オルタナティブ・ブログ
ユースケースは、やはり重要なのである。とはいっても、「ユースケース図」ではなく、「ユースケース記述」の方だ。 ユースケース図は、機能名を楕円で囲っただけだ！ と喝破したのは、「ユーザ中心設計(UCD)」のひがさんだが、ユースケースは、図ではなくて、シナリオにこそ、真価がある。図を書くと、ついつい構造化したくなり、include や extend を使ってどんどんどんどん深くなってしまう。そっちの方に行ってはいけない。 ユースケース記述を、充実すべきだ。その粒度、フォーマット、項目を最新の注意で設計しよう。細かな画面仕様やフィールド仕様でなく、まずは、「意図」が伝わるように。 最近のJUDEは、「ユースケース記述」をすっごい充実している。とくに、記述のフォーマットをカスタマイズできる。これで、独自の記述様式ができると共に、あらかじめフォーマットとして、RUP形式、アリスタコバーン形式が用意し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
