「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey
日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数％程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問 日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海
アジャイル開発のボトルネック | Social Change!
「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」 システム開発で、顧客からこう言われた時、どうするか？ SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか
Agileが根付かないもう一つの理由 - masayang's diary
「プロジェクト失敗率とリスク」の続き。 id:suikyojinさんからトラックバックをいただいた。 大規模Agileの失敗率は驚異的に低い? そもそも、大規模プロジェクトの失敗率って、ものすごく高くて、70%とか80%とかいった数字を見たことがある。基準が同じとはかぎらないので、断定できないが……。 そうなのです。「失敗」の定義は意外と難しい。随分前に訳した「失敗とは何か」では CHAOSレポートによれば、成功するプロジェクトの割合はたったの34%だそうな。 Standish GroupのCHAOS reportは、長年に渡ってドブに捨てられてきた何十億ドルにもなるIT関係プロジェクトの話を延々と述べている。34％の成功率っていうのは実は改善された数値で、2001年の調査では28％だったんだな。 とのこと。失敗率66%。ただし、この記事でMartin Fowler氏は 納期が遅れたとか予
「作っては壊す」過程があってこそ良いものが作れる
iPhone用の「はてな人気エントリーリーダー」、そろそろ形になってきたのだが、作ってみていろいろと発見した部分もあったので、全面的にクラス構成を見直し、大幅に書き直した。 HTTPで通信をしているコードが二カ所に分かれていたので、それをDataOverHTTP/XMLOverHTTPという二つのクラスにまとめ（XMLOverHTTPはDataOverHTTPのサブクラス）、はてな独自のRSSフィードを読んでいるコードから一般的なRSSフィードを扱うコードをくくりだしてRSSFeed/RSSFeedLoaderという二つのクラスにまとめて、あとで別のアプリケーションで再利用することを可能にした。それに加えて、各種ローダーに非同期通信をさせる主体をController（HotEntryViewController）からModel側（HateneHotEntry）に移すことにより、難解になりが
アジャイルプラクティス - 達人プログラマに学ぶ現場開発者の習慣 : 小野和俊のブログ
『アジャイルプラクティス』読了。献本感謝。 本書はタイトルの通り、アジャイルな開発を進めていくためのプラクティスを45個集めた本で、序盤の1章から3章はアジャイル開発のための心がけについて述べられており、4章から9章ではより実践的なプラクティスが紹介されている。 すぐに開発の現場で活用できそうな実用性と、読んでいてついクスッと笑ってしまうようなユーモアとを兼ね備えている点において、同 "The Pragmatic Programmers" シリーズのアジャイルレトロスペクティブズとノリがよく似ており、読後の感想としては、良い意味でアメリカっぽい一冊だと思った。 アジャイルの心がけと実践とが、丁寧に推敲され(元ネタとしても、日本語訳の面でも)、さまざまな角度から紹介されている本書をお勧めしたいのは、次の二つの読者層である。 アジャイル開発は、チームのメンバー全員が開発プロセスの改善に積極的で
官僚制解体の一般的方法論としての「アジャイル」と「エクストリーム」 - アンカテ(Uncategorizable Blog)
「戦略的思考のなんとか」みたいな本は、ほとんど戦争の本ではなくてビジネスの本です。 軍事→ビジネス→その他の組織 という経路で導入された考え方のなんと多いことか。 そもそも、官僚制というやり方自体が、だいたいはこの経路で一般化したものでしょう。 形式的で恒常的な規則に基づいて運営される。 上意下達の指揮命令系統を持つ。 一定の資格・資質を持った者を採用し、組織への貢献度に応じて地位、報償が与えられる。 職務が専門的に分化され、各セクションが協力して組織を運営していく分業の形態をとる。 20世紀は「官僚制の世紀」です。ほとんどあらゆる組織がこの原則で運営され、この方法が社会の常識となっています。 もちろん、それは20世紀の環境ではうまくいったから広まったのですが、この限界と弊害もいろんな所に見られるようになっています。21世紀はこれを解体、止揚していくことが、社会のさまざまな局面において必要
要求開発とアジャイル開発(2)
最初の段階で要求のすべてをFIXすることなく，変化をダイナミックに抱擁しながら，かつ，その要求が意味あるものかを検証しながら要求開発をする方法はあるのでしょうか？ 今回はその可能性を考えてみたいと思います。さらに，アジャイル開発を別方向に発展させたビジョン開発に関しても言及します。 アジャイル開発を分類して考えてみる アジャイル開発を下記のようなケースで分類してみましょう。 新規プロジェクトとして企画/開発 保守開発（または開発プロジェクトの途中で変更/仕様追加を行うケース） アジャイル開発を使って要求自体を開発（ビジョン開発） それぞれのケースで要求開発がどのように使われるかを考えてみましょう。 1.新規プロジェクトとして企画/開発 このケースでは，これまで皆さんが見てきた「要求開発」がそのまま使えることがわかると思います。 少し話がそれますが，アジャイル開発のプロジェクト企画の極意は，
要求開発とアジャイル開発(1)
現在のシステム開発プロジェクトの状況を見ると，いわゆる生産管理，経理といった従来からある業務のシステム化といったプロジェクトに加えて，Webシステムに代表される，従来無かったような新業務に対するプロジェクトが増加しています。 そうした業務のシステム構築は要件を固めにくく，予想もしにくい状況にあります。また，ビジネスの変化に伴ってシステム自体も非常に変化が激しいという特徴を持つことが多いようです。 そのような現状において変化に強い「アジャイル開発」は非常に魅力的です。本稿では，顧客サイドからの視点で「アジャイル開発」を総括し，「アジャイル開発」を行うときの，「要求開発」の可能性を検討してみたいと思います。 アジャイル開発とは XP（eXtreme Programming）に代表される繰り返し型の開発方法論をさします。特徴としては現場サイド（プログラマ）から出てきた開発方法論であり，変化に柔軟
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
