「測定できないものは制御できない｣は誤りだった。-- by Tom Demarco：An Agile Way：オルタナティブ・ブログ
ソフトウェア工学の祖の一人である、トム・デマルコが、最近IEEE Software 誌に、過去のソフトウェア・メトリクス賛美を悔い改める記事を書いている。 「ソフトウェア工学」というコンセプト－その時が来た、そして、その時は去った。http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r 1982年に、デマルコは有名な「計測できないものは制御できない」という一文から始まる、『品質と生産性を重視したソフトウェア開発プロジェクト技法』という名著を書いている。このドグマは、ソフトウェア工学の考え方に強く根ざしている。むしろ、すべての「工学」という活動は、科学や経験から得た知見を使って自然現象をコントロールし、人間の役に立てることをその定義としており、そこでは測定を元にしたコントロールという概念はその中核にあ
ソフトウェア技術者のための英語（2: 多読、多聴）：An Agile Way：オルタナティブ・ブログ
【英語をたくさん読み聞きすること】 まずは、最初の「英語をたくさん読み聞きすること」という壁だが、あたりまえ、と思うかもしれない。これを強調したいのは、周りの多くの日本人が英語で作文したり発話したりして失敗している例をみると、英語で表現するときに、 内容を思いつく ⇒ 英語の単語に訳す ⇒ 文法を使って組み立てる とやっている風に見える。これは最後に出てきた文章を見ると「あぁ、これは伝わらないだろうな」というものになる。へたをすると、裏の日本語がすけてわかったりする。そうではなくて、伝わる英語で表現する手順は、 内容を思いつく ⇒ 過去に聞いた同じような文を思い出す ⇒ それを一部変えて文を組み立てる となる。 つまり、「過去に聞いた同じような文を思い出す」のが肝で、これはたくさんの英語に触れることが絶対的に必要な根拠だ。ぼく自身も、初めて使う動詞や初めて使う文章パターンは、まず伝わる確率
Scott Ambler と ソフトウェア開発のメタファについて話をした。：An Agile Way：オルタナティブ・ブログ
IBM の中でテクニカル的にアジャイルについての発言をしているのは Scott Ambler です。今日は彼と話すことができました。Agile@Scale のBofです。 BOFは４人でしたので、ひざを突き合わせて話をしましたが、そのうち一人は、Agileというコンセプトに始めて出合った人。その人の、 「ソフトウェアは工学的に作るようにようやく進歩してきたのだ。Agileはその歴史を、人側に逆戻りさせようというのか？」 という質問に、 「昔、太陽は地球の周りを回っていると思われていた。しかし、回っていたのは地球だった。これがAgileのパラダイムシフト。もしかしたら、後何年か先に、宇宙の中心がみつかって、そこを中心に回っていることがまた発見されるかもしれない。ソフトウェア工学はまだ40年しか歴史がないのだから。」 といい答え。さらに、 「建築や土木をソフトウェアのメタファと捉えるのではなく
42歳の抱負。(現在のソフトウェア開発における３つの個人的課題）：An Agile Way：オルタナティブ・ブログ
先日、5/20で42歳になったので、抱負、というか今ぼくが課題に思っていること、考えていることをいくつかメモとして書いてみます。技術的なことと、ビジネス的なこと、そして人生についてのことがあります。 １．ソフトウェア工学 ソフトウェアアーキテクチャ、および開発方法論はまだまだ進歩過程にあるが、次の２つのことが最近分かってきており、今後より強く浸透していくのではないだろうか。 ・再利用性、という価値観と、変更容易性という価値観が独立し、これら２つの価値観は別個に発展する。オブジェクト指向をはじめとする設計手法は、再利用性という方向では組織・流通・資産化を含んだプロダクトライン、変更容易性という方向ではリファクタリング、テスト駆動、アジャイル、というそれぞれのプロセスを伴った方向に分化する。再利用性は、設計のみならず、知識の再利用がキーとなりパターンのようなコンテキスト情報を含んだ知識流通形態
CMMとAgileについて、Capers Jones の記事：An Agile Way：オルタナティブ・ブログ
アジャイルとCMMの比較記事です。 ■ Development Practices for Small Software Application http://www.stsc.hill.af.mil/crosstalk/2008/02/0802Jones.html Agile と CMM(or CMMI) の考え方の共通点として、 ソフトウェア要求は、常に変化する。 欠陥を修正するのは最もコストが高い。 高品質であることが、生産性と納期短縮につながる。 としていて、逆に異なる点として、 ドキュメントを書くことは二番目にコストが高い(Agile) 測定しなければ、継続的な改善は起こらない(CMM) を上げている。そして、1,000 FP の小さめのプロジェクトで、アジャイルチームとCMM 3 チームを統計して、 Agileの方が生産性(短時間あたりのFP）が高い。 Agileは欠陥潜在を下
ソフトウェア開発とフロントローディング：An Agile Way：オルタナティブ・ブログ
ハードウェア開発のフロントローディング、とソフトウェア開発におけるそれの平行概念を考察しています。 http://d.hatena.ne.jp/sakataakinori/20080129/1201620434 TPSのソフトウェア開発への現場適応を実践している坂田さんは、この概念をソフトウェアに持ち込むことについて、慎重に議論しています。 製造と設計が分離されたハードウェアにおいて、 製造時に発生するコストがライフサイクルコストを支配する製造時に発生するコストドライバは設計段階においてつくり込まれる。 フロントローディングとは、この原理に基づく考え方、源流管理の実現によって発生する負荷の前倒し現象です。また、この現象が原価企画の取組みによって制御可能性が高まるために、手法として取り扱われることが多い。というのが、本質だと考えています。 一方 ソフトウェアは、開発と製造が同時一体として進行
大野耐一の言葉：An Agile Way：オルタナティブ・ブログ
アメリカからきたから、やって見ようじゃだめだ。ニーズはあるのか？困っているのか？面子や物好きで導入してはだめ。ニーズを大事に。
ものづくり、の本質：An Agile Way：オルタナティブ・ブログ
いくつかブログやらメールやらを見ていて、今年の思いを固めている。「つくる」ことの本質は何だろう、それは、「おもう」ことと関係しているのではないか、というのが今年のテーマです。 本日のGrady Booch のブログのクオートより； If you want to build a ship, don't drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea. -- Saint-Exupery 船を作ろうと思ったら、人々に材料を集め、作業を分割し、指示を与えようとしてはならない。最初にすべきことは、果て無き広大な海への憧れを語ることだ。 -- サンテクジュペリ 昨日のAlistair Cockburn の
TPS と Agile(2) - 5S：An Agile Way：オルタナティブ・ブログ
TPS でいう 5S とは、「整理」、「整頓」、「清掃」、「清潔」、「躾」を言う。これは、ソフトウェア開発ではほとんど関係ない－－と考えている人が多い。しかし逆で、アジャイルのような持続可能な開発では非常に重要になる。 この５Sは、しっかり英語にもなっており（いくつか文献によってばらつきがあるが)、Maryの本では、Sort, Systemize, Shine, Standardize, Sustain である。要不要を区別し(Sort)、見つけやすく場所を移動し(Systemize)、いつでも使える状態に磨き(Shine)、誰でもわかるようにし(Standardize)、それをキープするルールを作る(Sustain)。 Kent Schnaith がより具体的にこの5Sを、ソフトウェア開発で例示したものを、Mary Poppendieck は本の中で紹介している。 1. 整理(Sort)
TRICHORDで仕事を見える化しよう！：An Agile Way：オルタナティブ・ブログ
チェンジビジョンで開発しているツール、TRICHORD（トライコード）は、アジャイル開発を支援するツールだが、「タイムボックス管理」という視点で見るとかなりいろいろな適用場所がある。 TRICHORDのTRIは「３」という意味で、「トキ(time)」「コト(thing)」「ヒト(team)」の調和を目指している。トキは、タイムボックスで、「プロジェクト」「リリース」「イテレーション」という３階層でブレークダウン。そして、コトも「フィーチャ」「ストーリー」「タスク」という３階層でブレークダウンし、それをタイムボックスに入れる。そして、ヒトが、タスクにサインアップし、タスクの状態（ToDo/Doing/DONE）をチームで共有する。－－－これだけ。本当に「これだけ」、なのだ。 例えば、写真はチェンジビジョンのマーケティング担当者が、「セミナー開催」というプロジェクトの、「セミナーの告知と募集」
Sustainable Software - 継続可能なソフトウェア：An Agile Way：オルタナティブ・ブログ
継続可能なソフトウェア(sustainable software) というキーワードで、現在のソフトウェアを取り巻く技術や考え方を統合したいと思っています。以下に、メモ。 何がソフトウェアの品質の中心となるか。 ・保守性(EoM)＝テスト可能性(EoT)＋変更容易性(EoC) http://blogs.itmedia.co.jp/hiranabe/2005/08/post_353b.html このための技術がオブジェクト指向（部品再利用やコード再利用ではない）、という位置づけ。テストしやすい設計、リファクタリングしやすい設計にすること。そのために、言語要素として継承・カプセル化・ポリモフィズムを使う。さらに原則として、DMP(問題領域概念とのダイレクトマッピング）、SRP（問題領域の変更を閉じ込める）などを使う。また、シンプルで愚直な設計をよしとする。 また、プロセスとしてはアジャイルなも
全体は詳細に先行するか？あるいは、「作り出す」ことの中心について。：An Agile Way：オルタナティブ・ブログ
結城さんの、「ソフトウェアは、私たちの想像よりもずっと複雑」を読んで。 http://www.hyuki.com/d/200606.html#i20060616093839 本を書く、という行為の中で結城さんが至った一つの結論は、執筆活動は章立てや理論的なブレークダウンで進んでいくのではなく、「具体的な本文を書き出す」ことが、必要だ、ということ。以下、引用。 本全体のテーマを決める。つぎに各章の内容を考える。全部の内容が決まったら、さらに詳細な内容を考え、節ごとにブレークダウンする。全体の節が出来たところで、いよいよ本文を書き始める。こんな風に、まっすぐな流れで詳細化が進み、その結果として最後に完成する――というふうには進まないのです。 本全体のテーマを決め、各章の内容を考える。まあここまではよい。その次の有効な一手は、「さらに詳細な内容を考える」ことではなく、「本文をいきなり書いてみる」
よい「進捗報告」とは？：An Agile Way：オルタナティブ・ブログ
XPのメーリングリストより。Kent Beckが Burndown チャートについてコメントしている。 「報告」の原則は、 Honest - 正直であること。事実をまげないこと。 Effective - うまく伝わること。 Responsive - 反応的であること。プロジェクトのフィードバックループに組み込まれていること。 詳細で大量な報告、とか、全く報告がない、はダメの典型。バーンダウンチャートは、人のビジュアルな思考を引き寄せ、短時間で全体感があり、効果的に情報を伝える力があるから。決して、「都合の悪い詳細を隠す」ためではない。 XPメーリングリスト：http://groups.yahoo.com/group/extremeprogramming/message/120292?l=1
TRICHORD システム開発の状況の見える化ツール(^_^)：An Agile Way：オルタナティブ・ブログ
THICHORD(トライコード)の version 0.1 を発表します。自由にダウンロードできますので、どうぞ、みなさん開発へのフィードバックにご参加ください。http://trichord.change-vision.com/ これは、カテゴリとしては、SDLC(Software Development Life Cycle)ツール、となるでしょうか、でも基本的には、もっとシンプルな「状況の見える化」ツールです。 これまで、ソフトウェア進捗管理のツールといえば、「管理」のツール、仕方ないが、使えといわれるので使わざるをいえないツール、という印象が強いのではないでしょうか。TRICHORDは、 仕方なく使うツール、から、使いたいから使うツール にしたい。つまり、エンジニアが、必要だと思うから、導入するツール。 例えば、JUnit というシンプルなテスティングツールがある。これは、プログラ
書籍『プロジェクトを成功させる 現場リーダーの「技術」』：An Agile Way：オルタナティブ・ブログ
ぼくと何度もプロジェクトを共にした永和システムの岡島幸男さんの本がでました。 IT業界の混乱は、形式的なプロジェクトマネジメント手法や開発技術では乗り切れない。そこには、人間力のあるリーダーが必要である。本書には、「才能」としてのリーダーではなく、彼が現場での「悩み」から後天的に得た「技術」、そして「勇気」のエキスが生の言葉で書かれている。 プロジェクトを成功させる 現場リーダーの「技術」 http://www.amazon.co.jp/exec/obidos/ASIN/4797333502/xpjp-22 この本を読むと、彼と関わったプロジェクトのさまざまな記憶、深夜の議論や、成功の美酒、失敗の辛酒を思い出します。 また、プロジェクトファシリテーションのいくつかの「見える化」実践について、詳細に書かれたはじめての日本語の本ということになると思う。「アクションかんばん」、「朝会」、「ペア○
要のもの・こと分析～仕事の本質ってなんだっけ？(^_^)：An Agile Way：オルタナティブ・ブログ
最近富士通の方に「要のもの・こと」という言い方を聞き、そこから検索して中村善太郎さんの『シンプルな仕事の構想法』という本を読んでみた。 すごいなー、トヨタ生産方式に代表されるような「ムダどり」の発想を、抽象化して捉えている。これは、GTDやらアジャイルやら、リーン思考やらプロジェクトファシリテーションやら、ユースケースやらというものをインスタンスとして扱えるような思考の枠組みじゃないだろうか。 仕事とは、「行わねばならないこと」を「体や頭を使って行うこと」 であり、さらに、 「行わねばならないこと」とは、「もの」を「始めの状態」から「終わりの状態」に変える「こと」 である。そこには「要（かなめ）の変化」があり、あとはすべて贅肉だ。仕事を分析して「要のもの・こと」に焦点を合わせ、排除（Eliminate）、結合（Combine）、シンプル化（Simplify）を検討する。そもそも、仕事に要が
ユーザ要望の聞き取り方を学ぶー究極の目的とは？：An Agile Way：オルタナティブ・ブログ
ユーザ要望の聞き取りをする場合、利用者や利用場面を聞くことは重要だ。しかし、もっとも重要なことはなんだろう？それは、そのシステムを作る目的は何か、だ。要求開発でも言われているように、「正しくない要求を正しく実装しても意味がない」。そのシステムを作る目的をはっきりさせることが、要求を聞き取る場合に最も重要なことだと思う。 目的はいくつかある、というかもしれない。では、究極の目的はなんだろう。それを聞き出す、魔法の質問がある。 作ろうと思った動機はなんですか？ この質問は、ぼくが家をたてるときにミサワホーム福井支店の営業、大野尊言さんに聞かれて、感動したものだ。ぼくは家を建てるときに、自分でラフなRFPを書いて数社に提案をお願いしようとした。他のハウスメーカーや工務店が、予算、間取り、和洋、などを聞いてきたのに対して、大野さんは、この質問をした。「家を建てようと思った動機はなんですか？」 ぼく
テスト駆動経営：An Agile Way：オルタナティブ・ブログ
Joshua Kerievskyは、Industrial XP のプラクティスとして、ユニットテスト、受け入れテスト、に加えて、さらに上位の「経営テスト」を入れている。企業のIT投資においては、その効果が本当に得られたか、という評価を行なう必要があり、これをもITシステム開発の上位レベルからテストとして記述しよう、というアイディアである。「正しくない」システムをいくら「正しく」作ってもしょうがない。満たされるべきビジネスゴールから、ITシステムの仕様は導き出されなくてはならない（これは、要求開発の標語でもある www.openthology.org ）。 以下は、アップル社のiTunesに関する経営テストである。 アップル社のiTunes経営テスト この新しいサービスは、公開後の最初の一ヶ月で少なくとも１００万本のダウンロードを記録すること。 ビジネスゴールを「テスト」によって記述している
EoTとユニットテスト：An Agile Way：オルタナティブ・ブログ
ここでのテストは、開発者テスト、の中の、ユニットテストの話。XPとTDDの文脈において、設計を駆動するテストについてです。（※最近、テスト、と言う言葉を慎重に使わないと、いろんな他の方面から誤解を招く、ということを知って、文脈を特定しておきます。^^;;） テスト容易性(EoT=Ease of Testing)が重要な設計品質である、ということを以前書いた。もう少し具体的な根拠を書きたい。 ユニットテストをたくさん作るということは、設計に対してどんな意味を持っているのだろう？物理的にいうと、「プログラムのエントリーポイントを増やしている」ということになる。 エントリーポイントとは、プログラムのスタート地点である。通常であれば、プログラムはmainという名前の決まったエントリーポイントから呼び出され、多くのモジュールを通過して終了する。しかし、ユニットテストを導入することによって、多くのテス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Niko-Niko Calendar ポータルサイト開始(^_^)：An Agile Way：オルタナティブ・ブログ