アジャイル開発の反対はウォーターフォール開発じゃなくて「おまかせ」だと思う - 思っているよりもずっとずっと人生は短い。
メモ。 アジャイルとウォーターフォールを対比させるのは違和感があった。ので、少し考えてみた。 アジャイルソフトウェア開発宣言にある「包括的なドキュメント」とか「契約交渉」とか「計画に従う」とかと、「対話」「顧客との協調」「変化への対応」とかは、わりとばらばらなお題目が並んでいるように見える。少なくともこれがMECEだと思う人はいないと思う。 ばらばら並んでいる項目の共通点、類似点は何か。それはたぶん、「顧客」と「開発者」という2つのロールを仮定して、そのロールの人同士の間でのコミュニケーションコストを最大化する（という言い方が悪ければ「最大限許容する」と言い換えてもいい）というものだろう。文書や契約や計画は、あらかじめ（多少はコストをかけて）まとめておけば、それ以降のコミュニケーションは省略できる（ような気になる）、というものだろう。ツール・プロセスも同様だ。一方で、個人や対話、顧客との協
最近もらった本: アジャイルサムライ - steps to phantasien(2011-09-13)
いただきました. ありがとうございます. そして読んでいるうちに, どうも自分はアジャイルへの興味が失せていると気付いた. さいわい "アジャイルサムライ" は良く書かれており 感想はもうウェブ上にたくさんあるようなのでここでは保留し, かわりになぜ自分の関心が失せたのかを説明してみたいと思う. 理由はだいたい二つある気がする. ひとつはしょうもない理由: 私の参加しているプロジェクトはとても大きく, 独自の開発スタイルをもっている. したっぱの自分はそのやり方に口を出す気がなかなかおきない. 時差があり英語も苦手(これはほんと情けなくて泣ける)だからなおさら乗り気でない. 変える気がないものへの関心は薄れる. 二つ目はもう少しマシな理由. 件のプロジェクトはそこそこアジャイル風になっている. おおよそ time-boxed にリリースがあるし, 開発者の自動テストもある. リファクタリン
Cybozu Developers Conference 2010 無事終了 | TAKESAKO @ Yet another Cybozu Labs
先週の金曜日は、サイボウズ技術発表会2010秋「Cybozu Develepers Conference 2010」が開催され、 サイボウズ本社、サイボウズ総研、サイボウズ・ラボ、松山、上海、ベトナムの開発エンジニアが 一同に集まり、普段の研究開発の発表を行いました。 第1部 パネル展示 お昼過ぎからパネル設営の準備をはじめ、各所で普段行なっている研究開発成果のお披露目会という位置付けです。 開発部以外の営業の方にもお越しいただき、大変盛り上がったパネル展示となりました。 CTO賞：49カ国語言語判定ライブラリ まだ未公表のプロダクト・サービスの研究開発紹介もあったりしましたので、全部が公開できるものではありませんでしたが、 CTO賞として中谷さんの「49カ国語言語判定ライブラリ」が表彰されました。 このライブラリは既にオープンソースとして公開されています。 FYI: 自然言語処理勉強会で
社外常駐で学んだアジャイル開発
（1）今回の事例: 業務システムをWeb化で刷新 第2回では、新人のころに筆者がかかわった事例を取り上げ、「情報共有」の仕方と、「情報共有を通して、どのようにアジャイルの基礎的な内容を学んだのか」を説明しました。 前回の計画をチームで立てるというトピックで、「アジャイルでは、イテレーションを何度も継続して回す」ことを伝えました。ここで大切な点は、「ただ単に繰り返す」ことを意味しているわけではないということです。イテレーションで得られたフィードバックを、次のイテレーションでより良い活動ができるように生かすことが重要です。 今回は、この「フィードバックをもとに、より良くする（改善する）」ことに焦点を当て、筆者が社内SNS構築の次に参画したプロジェクトを取り上げます。まずは、今回の事例で取り組んだ「業務システム」について、簡単に紹介します。 筆者が所属するTISでは、プロジェクトが完了すると、プ
Java から Ruby へ：An Agile Way：オルタナティブ・ブログ
遅ればせながら、話題になっている、かくたにさんが訳している、Bruce Tate の本「JavaからRubyへ」を読んだ。 http://www.amazon.co.jp/JavaからRubyへ-―マネージャのための実践移行ガイド-Bruce-Tate/dp/4873113202 ぼく自身は、スクリプト言語好きなのだが、Rubyをほんの少ししか書いたことがない。でも、直感的にはかなり好きだと思う。closure みたいなものにびびっと来た時期もある。（後で気づいたのだが、ぼくは1998年にRubyのメーリングリストに短いプログラムを投稿していたりする。それに高橋さんがコメントをくれていたりもする。そしてその投稿は、matzが本を書くためにスクリプトを募集したものだったことが、今調べていて判明。このスクリプトは結局本には載らなかったのだろうと思うが。。。。 http://blade.naga
いいアジャイルと悪いアジャイル
スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見
軽量からアジャイルへ - 機械猫の日記
id:yamazaさんの日記になぜ「軽量言語（Lightweight Language）」というのかという疑問が投げかけられていた。軽量という意味は何か、というような疑問だと思うんですが、ふーむ。そういえば、同じような話をどこかで聞いたなぁ・・・あ、Agileか。笑 アジャイルも元々軽量プロセスと呼ばれていたけど、「軽量って何？」みたいな話になってアジャイルという言葉が誕生したのだった。であれば、今言語に対しても同じことが起きるんじゃないかなぁ。つまり、軽量言語ではなくアジャイル言語（？）に。 では、アジャイルって何か？というと、これはアジャイル宣言で明文化されていて、そのおアジャイル宣言の価値を共有するものがアジャイルなのだ（ですよね？汗）では、今一度ここでアジャイル宣言を振り返ってみる。 プロセスやツールよりも、個人と相互作用 包括的なドキュメントよりも、動作するソフトウェア 契約交
- クリスマスイベント
「オブジェクト指向」をソフトウェア開発に採用する事は、もはや特別な選択ではなくなっています。 しかし「オブジェクト指向」を採用するだけで、ソフトウェア開発の成功率は高くはなりません。 プロジェクトを成功させるためには、オブジェクト指向だけではなく、いくつかの「成功のカギ」が必要なのではないでしょうか。 「プロジェクト・マネジメント」、「開発プロセス」、「技術者の教育」、「顧客との意志疎通」、「ファシリテーション」などなど。 思いつくものはたくさんあります。 5回目を迎える今回のオブジェクト倶楽部イベントのテーマは、「プロジェクト成功させる7つのカギ」です。 成功のカギは、みなさん個々に異なるかもしれませんが、その「カギ」を参加者全員で共有していく事を目的としています。 ご参加いただいた皆さんが、成功へのカギ束をポケットに持ち帰る、そんなイベントを目指しています。 特に今回のイベントでは、み
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイル開発のキモはフィードバック！ － ＠IT