astah の最初の構想書発見。：An Agile Way：オルタナティブ・ブログ
今日はチェンジビジョンの6周年ですが、astahは実はもっと古く、1997の年末に最初の構想がかかれたようです。 Astahは昔の名前をJUDEといい、この名前が非常に長く使われていたのですが、ドイツの方からのフィードバックを真摯に受け止めて、改名しました。JUDEは、Java and UML Developers Environment の略でした。 そして、その前の名前をJOMTと言います。今でも、内部のパッケージ名には、jomtが使われています。 最初の名前JOMTは、JavaとOMTをつなぐツール、という意味です。今日、このツールの最初の「構想書」なるものを発掘しました！３ページにわたって、最初の「動機」や「仕様のポイント」がかかれたものです。今読んで思うのは、 Javaにハンパなくコミットしている。仕様書の最後に、JDK1.2 finalにあわせてリリースしたい、などと書いてる。
ChangeVision のクレド(^_^)：An Agile Way：オルタナティブ・ブログ
ぼくが社長をつとめる、チェンジビジョンで、クレドを作ろうとしています。 クレド(credo)は、最近ビジネス書などで有名になっていますが、リッツカールトンのスタッフが持っているという、自分たちの「信条」を書いたものです。実際にリッツカールトンのものを入手して見てみました。また、他にもクレドを運用している、上坂会計事務所、Ｔ＆Ｆカンパニー、スターロジックさんなども参考にしつつ。。。。自分たちで考えて、名刺入れに入れておけて、誇りに思えるものを工夫したい。 ぼくたちのクレドの目的は、情熱をもった個人が集まっている会社であることをみんなが誇りをもって確認できること。そして、その力が合わさって、さらに強い力を生み出すために、また、迷ったときの意思決定が個人レベルで行えるために。行動原則や価値観を共有することで、ひとつひとつ上司に相談しなくて、自分で判断してすばやい対応ができること。 第一版（校正中
PFの「かんばん」をポータブルに！(^o^)：An Agile Way：オルタナティブ・ブログ
PF(プロジェクトファシリテーション）の１つのプラクティスである、「かんばん」。最近よく講演をするのですが、よく聞く悩みが、「うちのチームには壁がありません…」 そこで、紹介したいのが、これ。 Kanban-nano ... (モバイルかんばん!) 普通は壁に貼るのだが、これをポータブルにする。めちゃめちゃおもしろいです。昨年末のオブジェクト倶楽部クリスマスイベントのライトニングトークスで、CCSの佐藤竜一さんが発表した、「形から入る『見栄っぱり』アジャイル開発講座」に出てくる、アイテムです。 かんばんを安定させるための、「まな板立て」の利用法に注目。こういうちょとしたディテールへの実用的な工夫が泣かせます。(※協力 CCS佐藤竜一) どこにでもかんばんを持ち出そう スーツにも、ベストマッチ。オフィスを颯爽と駆けろ
ユーザ要望の聞き取り方を学ぶー究極の目的とは？：An Agile Way：オルタナティブ・ブログ
ユーザ要望の聞き取りをする場合、利用者や利用場面を聞くことは重要だ。しかし、もっとも重要なことはなんだろう？それは、そのシステムを作る目的は何か、だ。要求開発でも言われているように、「正しくない要求を正しく実装しても意味がない」。そのシステムを作る目的をはっきりさせることが、要求を聞き取る場合に最も重要なことだと思う。 目的はいくつかある、というかもしれない。では、究極の目的はなんだろう。それを聞き出す、魔法の質問がある。 作ろうと思った動機はなんですか？ この質問は、ぼくが家をたてるときにミサワホーム福井支店の営業、大野尊言さんに聞かれて、感動したものだ。ぼくは家を建てるときに、自分でラフなRFPを書いて数社に提案をお願いしようとした。他のハウスメーカーや工務店が、予算、間取り、和洋、などを聞いてきたのに対して、大野さんは、この質問をした。「家を建てようと思った動機はなんですか？」 ぼく
KPTを使ったプロセス改善(2)：An Agile Way：オルタナティブ・ブログ
Issue … Problem の本質化。問題を見つめ、本質的「課題」としたもの。「５回のなぜ」などで到達できるもの。「アンチパターン」や「AntiPractices」では、root causeと呼ばれている。 Knowledge … Keep の結晶化。Keepの中には、ナレッジとして抽象化できるものがある。ナレッジの表現形式としては、「名前付け」がまず必要。そして、それを表現する形式としては、Pattern、新しいPractice、AntiPractice、Tips、FAQ、注意書きとして、壁に貼るなどが考えられる。 これを、KPTIRK（ケプターク）と言う名前でKPTの拡張として、Alistairに提案したところ、「日本人はカイゼン慣れしてるな～」という感想をもらった。 hiro さんのご要望にお答えして、KPTIRKのフォーマット例。まだ決まったものはない。 Keep->Knowl
KPTを使ったプロセス改善：An Agile Way：オルタナティブ・ブログ
ソフトウェア開発の繰り返し単位（イテレーション）ごとに、そのタイムボックスで行なったことを反省し、未来に生かせるように口に出してみる、という活動を行なう。これは、反省会、回顧、Retropective、Reflection、などと呼ばれる（ぼくは「ふりかえり」という言葉が好きだ）。 アジャイル開発ではこの「ふりかえり」が「KAIZEN加速装置」となる。 これを行なうときに使うフォーマットを写真に示した。ぼくはこれをKPT（ケプト）と呼ぶ（Keep/Problem/Try）。Alistair Cockburnから教えてもらったもので、ぼくはこのフォーマットのヘビーユーザー。 ホワイトボードが３つのセクションに分かれており、Keep（このまま続けること）、Problem（問題点）、Try（次に試してみたいこと）と名前が付けられている。全員参加のふりかえりミーティングを開き、そこで、今回のイテレ
パターン･ムーブメントからアジャイル・ムーブメントへ：An Agile Way：オルタナティブ・ブログ
ソフトウェアパターンとXPをはじめとするアジャイルムーブメントは共通点が多い。より正確には、ソーシャルな形（人脈）で歴史的連続性を持っているために、思想的に共通するのは当然だといえる。 パターンが建築家Christopher Alexander（以下C.A.）の思想を、Kent Beckがソフトウェアの世界に持ち込んだ、ということは有名である。1987年、最初にソフトウェアにパターンを持ち込んだのは Kent Beck と Ward Cunningham によるGUI設計に関するものだ。KentとWardはパターンコミュニティHillside Groupを発足させる。そこでパターンを収集する活動がPLoPと呼ばれるもので、現在も続いている。 このコミュニティでJim Coplien（通称Cope）が重要な働きをしている（彼は2001年沖縄のMensorePLoPにも来日している）。Cope
テスト駆動開発のテストは、テストか？―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：オルタナティブ・ブログ
「EoM=EoC+EoT」を鍵概念として、良い設計とは何か、よいプロセスとは何か、を再定義しようとしている。今回は、テストの役割について再考する。 テストは設計とプロセスの両方の基本単位だ。まず、テストと進捗管理の話をしたい（テストとドキュメントの話、テストとコミュニケーションの話、テストと開発リズムの話、などと続く予定）。 みなさんは、進捗指標として何を使っているだろうか？「工程ごとに違うが、成果物の完成に対する到達度だ」という答えが一般的だと思う。しかし、「設計書９０％完成という報告が２週間続いている」というような進捗会議に参加したことはない？ （きっとあるはずだ。） ぼくが考える進捗管理の基本は、 の3点だ。先に述べた「設計書のページ数」という単位は、３つの条件をどれも満たしていない。すべての設計書を否定するつもりはないが、設計書は内部の中間生産物であることが多いし、１００％終了とい
ナチュラルなコードとは？：An Agile Way：オルタナティブ・ブログ
題名は、音楽の話に聞こえるかもしれませんが、ソフトウェア開発の話です。 以前、咳さんが体験談として >「お前のコードはナチュラルでエレガントだ」 >と言われた時は うれしかったなあ と語ってくださったことから、ちょっと思い起こしてみました。「ナチュラルなコード」とはなんだろうか、ということを考えてみたい。ぼくは、何かの本かインタビューで読んだ、Ward Cunningham の言葉がとても強く印象に残っています。 ...(要約するとこんな感じ)... そのコードは、すばらしいコードだった。ソースリストをプリンタに出力すると、 それは、「どこからでも読み始めることができ、意図が明確だった」 ............................ 「どこからでも読み始めることができる」（！）というのは、オブジェクト指向のよいコードの特徴じゃないだろうか。 （以前、oosquare-ml だっ
「保守しやすい」ことが、良い設計(EoM = Ease of Maintenance)：An Agile Way：オルタナティブ・ブログ
前２回で、オブジェクト指向を「テスト容易性」と「変更容易性」を中心に再定義したい、という話をした。 従来オブジェクト指向の説明に使われている概念、およびそこから得られる（といわれている）再利用性という品質からではなく、 テスト容易性： EoT = Ease of Testing 変更容易性： EoC = Ease of Changing という２つの概念からが、（現代的な）オブジェクト指向設計の焦点であることを主張してきた。最後、なぜこの２つが必要なのか、というと、それは、メンテナンスのしやすさ（EoM=Ease of Maintenance）を高めるからだ。そして、このEoMこそが、2005年のソフトウェア開発の根本品質だ、と言い切ってまとめたい。 EoMの高い設計が、よいオブジェクト指向設計である。 ということである。今回は、前回書いた、EoT/EoCそして、このEoMについて、ソフト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
