なぜ Agile Japan 2013 の基調講演に James Grenning さんを呼びたかったか：An Agile Way：オルタナティブ・ブログ
Agile Japan 2013 が 5/24 に決まりました。みなさん、予定を空けて置いてください。 http://www.agilejapan.org/ さて、今回の基調講演の一人は、James Grenning さん、アジャイル宣言にサインした一人です。私が James さんをぜひ今回呼びたかったのには、理由があります。 日本には、エンタープライズ系の開発とほぼ同じくらい、組込みソフトウェア開発があります。日本の中でアジャイルがしっかり根を下ろすためには、日本のエンジニアの約半分を占める、組込み系ソフトウェアエンジニアに、アジャイルのメリットを示す必要があるのです。 アジャイルは速さを求めるだけではなく、品質を高める新しい設計のあり方をも示しています。その１つがTDD（テスト駆動開発）です。 Jamesさんは、このテスト駆動開発を組み込みC言語で行うという、 「Test-Driven
アジャイルの「ライトウィング」と「レフトウィング」：An Agile Way：オルタナティブ・ブログ
アジャイルの認知が進むにつれて、アジャイルという言葉がどんどん広がっている。アジャイル、という言葉の中にはいろんな要素が入っていることが分かる。もっと大きなものは、CI（継続的インテグレーション）を中核とする技術的なプラクティス群と、スクラムプロセスフレームワークのような、人と人との会話のプロトコルと協働関係を作るしかけだろう。自分の現状を、アジャイルに変えるためには、どうしたらよいだろう？ "最近、「アジャイル」といっても中にいろんな要素があるために、「あなたのアジャイルは何のことを言っていますか？」と聞くことからはじめないと、話がかみ合わない"、と、Agile2012帰りのかわぐちさんと話していて、そのときに、かわぐちさんが描いた絵（たぶんどこかにある４象限の図）がいまひとつ自分にしっくりこなくて、私が描いて見た絵がこの絵だ。 あなたが、現状の開発現場を「アジャイル」に変えたい、と考え
日本のアジャイル１０年、人々とコミュニティの私的物語：An Agile Way：オルタナティブ・ブログ
日本のアジャイル１０年、人々とコミュニティの私的物語 平鍋健児 （※）この記事は、2011年に書籍『Ultimate Agile Stories』に寄稿したものを転載しています。執筆時点で、『Ultimate Agile Stories - Iteration 2』が刊行されています。(2012/8/15) ぼくが初めてアジャイル、というか、XP、そうエクストリームプログラミングについて知ったのは、2000年の初めだった。ふと目について注文した洋書『Extreme Programming: Explained』がamazon.comから届き、それを週末に読んだのだ。このときに、どんな電流が走ったかは、多くの人の前で語ってきたが、Kent Beck という人物がとんでもなく明快に、そして極端に、人に喜ばれるソフトウェア開発、という視点でプログラミング活動を中心おいて4つの価値と12個のプラ
XP祭り2010で講演しました。：An Agile Way：オルタナティブ・ブログ
毎年9月の第一土曜日に行われるという、「XP祭り」に参加してきました。毎年楽しいのですが、今年は、200名以上の参加。会場のみなさんに手を挙げてもらったら、初めての参加が７割くらい、というとてもうれしい状況です。 アジャイルの最近の話をしようと思ったのですが、やっぱり、「XPへの愛」があふれてきて、現在の自分の生活スタイルに大きな影響をあたえた、XPとアジャイルの関係もお話しました。 それから、初めて、Kanban について少々テクニカルな話をしました。ウォーターフォールとスクラムとカンバンを、ケーデンス（リズム）とWIP（在庫、仕掛）、キュー理論（Lead Time短縮）の観点から少し解説しました。 実はKanbanは、「まずやっていることを見える化することから始める」という意味で、プロジェクトファシリテーション（PF）とも通じるところがある手法です。日本でも取り入れやすく、これを起爆剤
《本》受託開発の極意：An Agile Way：オルタナティブ・ブログ
「受託開発の極意～変化はあなたから始まる」 岡島さんの本が出版されました。この本には、ぼくも推薦の言葉を贈らせてもらった。 「・プロフェッショナルな仕事をしたいですか？・楽しく仕事をしたいですか？本書はこの２つの問いに同時にYesと答えるための本です。それには、受託開発現場の考え方を変えること、やり方を変えること、そのすべてに先立ってあなた自身が変わること。本書の読者が、お客さまから「あなたがいてくれたから成功できた」、後輩から、「先輩と仕事ができてよかった」と言ってもらえる、そんな現場が日本に増えることを願います。」 中身は本当に強くしっかりと、みずみずしく生々しく、思いと教訓からの学びがかかれていて、僕自身も読んでいて胸が熱くなった。要件ヒアリングのこつ、見積もり、丸投げされても前進する、運用が最上流、お客さまとの信頼関係も保守する、ナレッジとマインドの伝承、チーム優先、組織を変える難
An Agile Way > LuRuJu on Rails -- JUDE で描いた図がそのまま Rails で動く! : ITmedia オルタナティブ・ブログ
野村さんが実装している、LuRuJu on Rails がリリースされています。 LuRuJu は、Ruby から JUDE API を呼び出す糊フレームワークなんですが、"LuRuJu on Rails"は、さらにすごいです。 JUDE のモデル(*.jude ファイル)を Rails に配備するだけで、そのまま、動きます。コード変換する必要もなく、JUDEで描いたモデル図が、そのまま Rails で動くのです。 すごいコンセプト！ぜひお試しください。 http://luruju.com/luruju-on-rails/overview 以下、概要を抜粋します。 RAILS_ROOT/app/model配下にJUDEファイルを配置するだけで、JUDEで記述したクラス図内の各クラスが、そのままRubyOnRailsのモデル(MVCのM)として動作します。クラス間のリレーション(1対1,1対
自分たちのよいところを認識することからはじめる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=アプリシアティブ・インクワイアリ(
LuRuJu -- JUDE と Ruby on Rails をつなぐJRubyで書かれたライブラリ：An Agile Way：オルタナティブ・ブログ
LuRuJu来ました！ 長年仲良くしているフリーエンジニアである野村周平さん（通称ばんちょー）が、JUDEとRoRをつなぐライブラリ、LuRuJuを開発しています。 http://luruju.com/ 引用： LuRuJuとは、UMLモデリングツールJUDEのモデルデータをオブジェクト指向スクリプト言語Rubyで操作する為のライブラリです。また、JUDEとWebフレームワークRuby on Railsとの連携もめざしています。 LuRuJuの語源 LuRuJuとはLube between Ruby and JUDEの略。JUDEとRuby,Ruby on Railsとの間の潤滑油の役割を果したいということで、この名前を付けました。設計と実装、ビジネスとITとの潤滑油になれれば、、という願いもこめています。 かっこいいです。ばんちょーは、前職時代から、常に新しいことにチャレンジ、周囲に影響
RubyKaigi2007 での Dave Thomas 基調講演 - An Agile Way [ITmedia オルタナティブ・ブログ]
ぼくは、Rubyistではありませんが、このコミュニティにはたくさん知り合いがいます。1998年にDDJ記事のためにオブジェクト指向スクリプティング言語を調べているときに、前田修吾さんのdemi（RubyのJavaブリッジ）を見ましたし、256倍極道編の助田さんや、神戸の列車事故で亡くなられた石井勝さんとも、2000年くらいからXPを通して出会っており、長い Social なお付き合いがありました。 また、今回のRubyKaigi2007の基調講演のDaveはAgileとRubyをつなぐ役割を果たしており、1999年に彼は『達人プログラマー』(Pragmatic Programmers)を書き、その後すぐに、『プログラミングRuby 達人プログラマーガイド』(Programming Ruby : The Pragmatic Programmer's Guide)を書いています。（このあたり
TPS と Agile(1) - Process と Meta-process, 遅延着手とENUF：An Agile Way：オルタナティブ・ブログ
昨年は、トヨタの方やトヨタ生産方式のコンサルタントの方（松井順一さん）と話す機会があり、とても刺激になった。松井さんが出された本、『職場の「カンバン方式」～トヨタ流改善術ストア管理』や、Mary Poppendieck の新刊、『Implementing Lean Software Development』を読みながら、再度、トヨタ生産方式とアジャイル開発について考えて行くことが、今年の一つの僕の活動になりそうな予感がしている。 というわけで、「TPSとAgile」を開始します（不定期です）。 最初にことわっておきたいが、TPS（トヨタ生産方式）は生産に関する考え方であり、ソフトウェアのような開発活動にそのまま適用できる訳ではない。「生産」と「開発」は異なる活動であり、実際の実践項目（プラクティス）のレベルでは全く違うものだ。しかし、考え方の部分では、非常に共通するものがある。アジャイルで
Sustainable Software - 継続可能なソフトウェア：An Agile Way：オルタナティブ・ブログ
継続可能なソフトウェア(sustainable software) というキーワードで、現在のソフトウェアを取り巻く技術や考え方を統合したいと思っています。以下に、メモ。 何がソフトウェアの品質の中心となるか。 ・保守性(EoM)＝テスト可能性(EoT)＋変更容易性(EoC) http://blogs.itmedia.co.jp/hiranabe/2005/08/post_353b.html このための技術がオブジェクト指向（部品再利用やコード再利用ではない）、という位置づけ。テストしやすい設計、リファクタリングしやすい設計にすること。そのために、言語要素として継承・カプセル化・ポリモフィズムを使う。さらに原則として、DMP(問題領域概念とのダイレクトマッピング）、SRP（問題領域の変更を閉じ込める）などを使う。また、シンプルで愚直な設計をよしとする。 また、プロセスとしてはアジャイルなも
JUDE Pro/Community 3.0 のベータ版リリース開始：An Agile Way：オルタナティブ・ブログ
JUDE 3.0 のベータ版のダウンロードを開始しました（Community 版、および Pro版）。とにかく、皆さんの要望をベースに、使い勝手を改良していっていますので、ぜひ、使ってみてくださいね。 https://jude.change-vision.com/jude-web/index.html 今回、Community/Pro それぞれ目玉があります。Community ではAPIの無償公開、Proでは、UML2.0 とグループ開発です。それぞれのリリースノートから抜粋します。 :::::::::::::::::::::::::::::Community（無償版）::::::::::::::::::::::::::::: ・API公開 Community 版にも、APIを公開しました！これで、JavaプログラムからJUDEのデータが覗けるようになります。自分の作ったデータを取り出し
株式会社チェンジビジョンを設立しました。：An Agile Way：オルタナティブ・ブログ
本日、2/22(水)、株式会社チェンジビジョンを設立しました。（ずっと狙ってたんですよね、この日付。２２２だし、先勝なんです。） JUDEの販売を中心に、新製品TRICHORD（トライコード：プロジェクトの見える化ツール）を開発・販売してきます。TRICHORDは、オープンソースとして発表しますので、ご期待くださいね。 今日は市ヶ谷で記者発表会を開かせていただきましたが、２０名を超える記者の方々の参加を頂いて、ありがとうございました。 チェンジビジョン（ChangeVision）は、ダブルミーニングで、「変わるための見える化」であり、「革新へのビジョン」でもあります。日本がもともと生産革新の現場で強い、「見える化」の知恵を、もっとソフトウェア開発の現場に提案していきたい。それをソフトウェア開発革新だけではなく、「知的生産技術革新」、さらには「ワークスタイル革新」としてこの業界に提案していき
神様ルートクラスを嫌い、POJOを好む：An Agile Way：オルタナティブ・ブログ
ぼくがオブジェクト指向言語を勉強しはじめた90年ころは、「継承」という概念がとても流行っていて、継承によって「差分プログラミング」ができることがオブジェクト指向設計の再利用性の典型例のように言われていた。もちろん、こういう誤解は95年くらいには、みんなウソだと分かってきていた。 しかし、それでもときどき、 すべてのクラスの頂点のような「神様クラス」を作ってしまうことがある。 例えば、90年代の多くのC++オブジェクト指向データベースは、Persistenceのようなクラスを継承することで永続オブジェクトとなるクラスをマーキングしたり、あるベンダーのコレションクラスは、Objectというクラスを継承したクラスのオブジェクトのみがコレクションの要素となることができたり、という具合に。また、EJBも最近まではEntityBeanを継承することでEntityBeanの資格が得られるし、Servel
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（次に試してみたいこと）と名前が付けられている。全員参加のふりかえりミーティングを開き、そこで、今回のイテレ
テスト駆動開発のテストは、テストか？―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：オルタナティブ・ブログ
プロジェクトの場作り（ファシリテーション）を行い、チームメンバーの能力を１００％以上発揮させ、１＋１を２以上にする、新しい形のリーダーシップが必要だ。そのたの人材像について、考えている。株式会社ITイノベーションに伺ったとき、Harvard Business Review をパラパラと見ていたら、こんな文章が！ 人々に学び 人々と一緒に計画し 人々が持っているもので始め 人々が知っていることの上に築きなさい。 リーダーが真に優れていれば、 終わってみると 人々は口々にこういう 「自分たちの力でやり遂げた」と。 －老子 うーん、まさに、これが理想だ。。。 ITイノベーションの林衛さんには、前回のオブジェクト倶楽部で主賓講演を頂きました。今回は、「ザ・プロジェクトマネジャーズ」のインタビューを私が受けました。 http://topic.promane.com/iti/dtdisp.asp?en
テストの役割（進捗管理その２）：An Agile Way：オルタナティブ・ブログ
Alistair Cockburn は、ソフトウェア開発の「1個流し」(*1)と進捗管理について、おもしろい例を出している。次の問題を考えてみて欲しい。 ３０個の部屋がある豪邸を考える。この豪邸から、1ヵ月後に引越しをすることに決めた。全部屋を掃除し、捨てるものと運ぶものに分類し、ダンボール箱に詰めなければならない。どのように進捗を管理したら、１ヵ月というデッドラインを守れるか。 ウォーターフォール的計画： １．最初の1週間で全部屋の掃除を行なう ２．次の1週間で全部屋の捨てるものと運ぶものを分類し、ステッカーを家具や備品に貼る ３．次の1週間で全部屋のダンボール箱詰めを行なう ４．次の1週間で全部屋のチェックを行なう ５．４週間あるので、４週間後には全部屋のチェックまで終わる 1個流し的（アジャイル的）計画： １．日割りで、１日に１つの部屋を、掃除、分類、箱詰め、チェックまで終える ２．
テストの役割=進捗管理＋設計戦略：An Agile Way：オルタナティブ・ブログ
「EoM=EoC+EoT」を鍵概念として、良い設計とは何か、よいプロセスとは何か、を再定義しようとしている。今回は、テストの役割について再考する。 テストは設計とプロセスの両方の基本単位だ。まず、テストと進捗管理の話をしたい（テストとドキュメントの話、テストとコミュニケーションの話、テストと開発リズムの話、などと続く予定）。 みなさんは、進捗指標として何を使っているだろうか？「工程ごとに違うが、成果物の完成に対する到達度だ」という答えが一般的だと思う。しかし、「設計書９０％完成という報告が２週間続いている」というような進捗会議に参加したことはない？ （きっとあるはずだ。） ぼくが考える進捗管理の基本は、 の3点だ。先に述べた「設計書のページ数」という単位は、３つの条件をどれも満たしていない。すべての設計書を否定するつもりはないが、設計書は内部の中間生産物であることが多いし、１００％終了とい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
