こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
マーチン・ファウラー氏が語る、21世紀のソフトウェアデザインとしてのアジャイル開発（前編）。Agile Conference tokyo 2011 － Publickey
アジャイル開発に関する論客の一人マーチン・ファウラー氏は、7月20日にテクノロジックアートが主催したイベント「Agile Conference tokyo 2011」で「21世紀のソフトウェアデザイン」をテーマに基調講演を行いました。 ファウラー氏の基調講演の様子を紹介しましょう。 アジャイル開発の意味が希薄化している ThoughtWorksのマーチン・ファウラー氏。 アジャイルソフトウェア開発宣言から10年がたち、そのあいだいろんな人が伝えていくうちに当初の意味の希薄化（Semantic Diffusion）が起きてしまったと思う。私の役割は、最初の意味を思い出してもらうことだ。 要件の安定性に依存するのは不健全だ まずは「予想的な計画（Predictive Plannning）」と「適応的な計画（Adaptive Plannning）」について。 土木や建築に由来するのが「計画駆動開
マーチン・ファウラー氏が語る、21世紀のソフトウェアデザインとしてのアジャイル開発（後編）。Agile Conference tokyo 2011
アジャイル開発に関する論客の一人マーチン・ファウラー氏は、7月20日にテクノロジックアートが主催したイベント「Agile Conference tokyo 2011」で「21世紀のソフトウェアデザイン」をテーマに基調講演を行いました。 前編に続いて、ファウラー氏の基調講演の様子を紹介しましょう。 （本記事は「マーチン・ファウラー氏が語る、、21世紀のソフトウェアデザインとしてのアジャイル開発（前編）。Agile Conference tokyo 2011」の続きです） 継続的インテグレーション アジャイル開発の中で重要な「継続的インテグレーション」と「継続的デリバリ」について話そう。まずは継続的インテグレーション。 複数のプログラマが集まって開発しているソフトウェアでは、それぞれのプログラマのコードをマージする作業に苦労する現場を多く見てきた。 あるソフトウェアプロダクトに二人のプログラマ
「ふりかえり」が失敗する８つの理由：An Agile Way：オルタナティブ・ブログ
「アジャイルレトロスペクティブ」の著者、イースターダービーのStickymindsの短い記事です。 「ふりかえり」が失敗する８つの理由 Eight Reasons Retrospectives Fail ぼくは Retrospectives を「ふりかえり」、と訳している。オブジェクト倶楽部のプロジェクトファシリテーションのページに、天野さんが、日本語の「ふりかえりガイド」(PDF)もかいている。 簡単にまとめると、 「ふりかえり」が失敗する８つの理由 １．準備不足。 ⇒アジェンダをしっかり用意すること。 ２．焦点があいまい。 ⇒前回のイテレーションの改善に集中。 ３．データが集まっていない。 ⇒何かを変えようとするまえに、「実際に何が起きていたか」を話す。 ４．１人か２人が会議全体の会話を独占してしまう。 ⇒ペアにしたり、グループを作ったりして話あうアクティビティを持つ。 ５．自分たちで
アジャイル開発のスプリント管理を楽しく。node.js/WebSocketによるタスクボード·scrumblr MOONGIFT
scrumblrはスクラム開発のタスクボードをnode.jsで実現するソフトウェア。 scrumblrはnode.js/JavaScript製のオープンソース・ソフトウェア。アジャイル開発手法の一つであるスクラム開発。スプリントと呼ばれる日程単位の中で決められた機能を作り込み、テストし、最終的に製品に組み込む所まで繰り返し行っていく。 並べた所 やるべき作業と、それが完了するまでのステップを適切に管理する必要があるのだが、その時に使われるのがタスクボードだ。通常、ホワイトボードやコルクボードを使って管理されるが、今回はデジタルで管理するscrumblrを紹介しよう。 scrumblrはnode.jsを使い、WebSocketを使って構築されている。そのため反映がリアルタイムに行われるのが特徴だ。機能としてはボードを垂直に分断する機能（幾つでも可能）、付箋紙を貼付ける機能と動かす機能となって
アジャイルは二度死ぬ(Agile Only Live Twice)その１：トム・デマルコ氏の蹉跌とその誤謬 | AnyProjecTa! プロジェクト・マネジメントに関する情報ポータル
Home » headline, プロジェクト・マネジメントを考える。 アジャイルは二度死ぬ(Agile Only Live Twice)その１：トム・デマルコ氏の蹉跌とその誤謬 アジャイルの隆盛 WEBの世界の中で、日々ITに関する情報を集めていると、アジャイル開発がシステム開発の完全なる主流になった気になってしまいます。偏った情報収集をしているせいだ、といわれればそれまでですが、WEB/ベンチャー業界・SIer業界・企業IT部門/IT子会社界・オープンソース界全てを通じて、Blogなどで声の大きい方々は多かれ少なかれ『アジャイル』という考えに肩入れしているように感じられます。 当然、世の中の流れが全てそうなっているかというと、そういうわけでは無さそうです。WEB/ベンチャー業界や、オープンソース界では、ほぼメインストリームとなっていると思いますが、SIer業界・企業IT部門/IT子会
なぜ依然としてウォーターフォールが残っているのか？ - レベルエンター山本大のブログ
マネージメントに携わるようになってウォーターフォールにも理があると思うことが多い。（もちろん最適解ではないが。） ウォーターフォール・反復に次ぐ、実践的な開発プロセスを検討したいとずっと思ってる。そんな検討をしていこうと思う。 ということで、語りつくされてはいるが「アジャイルかウォーターフォールか？」から考える。 アジャイルかウォーターフォールか？ アジャイルプロセスが提唱されてから既に数年、業界の多くの著名人がアジャイルを推奨し、多くの書籍が揃う。 アジャイルの考え方は、ウォーターフォールプロセスによる開発で「仕様変更」と「コストオーバー」、「スケジュールオーバー」に苦しめられてきた開発者達の、怨念にも似た声から生み出されたものだ。 エンジニアの視点から考えると理想的な開発の進め方のように思う。 しかしながら、やはり実際の開発現場は依然として、ウォーターフォール式の開発プロセスを採用する
ちょっとづつアジャイルへ - レベルエンター山本大のブログ
久々にプロジェクトに参画して「変更に対して柔軟」であることの意義を強く感じる。 それも、実装レベルの柔軟性が開発全体の柔軟性につながるということを強く感じるのだ。 例えば今回参画したプロジェクトで実装上で取り入れた柔軟性の１つとして、 ViewベースのDB設計がある。 全体に影響があると思われた仕様変更が Viewの内側の変更に納めたことで １人日程度の作業で済んだという例が毎日のようにあった。 柔軟な設計をするには、柔軟な実装を知っていなければならない。 進め方での柔軟性 私は、 要件定義→設計 →単体テスト→実装→仕様変更→単体テスト →結合テスト→システムテストの流れこそが、日本での現実的なアジャイルの姿だと思う。 「イテレーションのように、初めからやり直す」 というタイプの繰り返しではなく。だ。 そもそも、ウォーターフォールの問題点である 「変更を認めない」という流れになるのは実装
ユニットテストの方法論 - レベルエンター山本大のブログ
ひがさんの意見！さすが！目から鱗の提案だ！ ひがやすを blog ■極力ユニットテストを書かずに品質を確保する方法 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 http://d.hatena.n
プログラミングファースト開発でのRDB設計 - レベルエンター山本大のブログ
ひがさんの提唱する「プログラミングファースト開発」で困難だと思われるのはDB設計だ。 本家ブログのコメント欄でも言及されてる。 要件定義は、プログラムファースト設計の前に行うということでいいと思いますが、DB設計は、作りながら変わっていくと思うので、プログラムファースト設計と同時にするのがよい(しかない)と思っています。 http://d.hatena.ne.jp/higayasuo/20080501/1209636051 ツールでリファクタリング機能が、いかに整ったとしても RDBのリファクタリングがアプリケーションに及ぼす影響は計り知れない。 SQLServerは、機能が豊富でRDBMS的にかなり融通が利くほうだが、 機能だけでDBのリファクタリングが可能かといえば、まったくそうではない。 開発途中では、列や値の業務的な意味づけが変わることも多々ある。 また、DBのリファクタリングは開
自動テストとデイリービルドの組み合わせは最強！ - レベルエンター山本大のブログ
自動テストとデイリービルドを組み合わせることの超絶な威力を感じてる。 しかし、開発の中に上手く自動テストを組み込めていないプロジェクトは多い。 デイリーでテストコードを流しておくと、修正による副作用を最低でも1日以内に発見することができるようになる。 影響を恐れずに修正ができるため、大胆なリファクタリングも可能だし、仕様変更にとても強くなる。 結合テスト以降は、特に強力で自分の作っていないプログラムでの修正や操作が自分のプログラムに影響を与えることがある。 それを知らせてくれる仕組みがあるということが安心感は絶大だ。 そもそもテストコードを作ると、コーディング時やデバッグ時に起動ポイントとして使える。 Web画面を起動しなくていいぶん楽にコーディング・デバッグできる。 「じゃあ、Web画面からの入力テストはどうするんだ？」とか 私も昔は思っていたけど、画面入力のテストなんかは無理に自動化し
データベースのアジャイル開発を実現する8のプラクティス - レベルエンター山本大のブログ
アジャイルな開発に欠かせない割りに、あまり言及されていなかったのが データベースのアジャイル開発です。 今、私の参画しているプロジェクトで、データベースに関するアジャイルな開発の方法を模索していました。 現在実践していて効果のあるプラクティスをまとめます。 1.データベース作成ツールのVSS管理 「スキーマ定義クエリ」と、移行に必要な「初期データCSV」および「移行クエリ」、「移行プログラム」は、管理ツール（VSS）にチェックインされていて、だれでも修正が可能です。 スキーマ定義クエリだけでなく、「移行データ」についてもVSSで管理しているのがポイントです。 マスタなどのデータは、業務の設計に応じて変わるものですし、移行プログラムも実装チームやテストチームが柔軟に修正できたほうが便利です。 データは、単体テスト用データとしても利用できます。 2.データベースのデイリービルド データベースの
Agileが根付かないもう一つの理由 - masayang's diary
「プロジェクト失敗率とリスク」の続き。 id:suikyojinさんからトラックバックをいただいた。 大規模Agileの失敗率は驚異的に低い? そもそも、大規模プロジェクトの失敗率って、ものすごく高くて、70%とか80%とかいった数字を見たことがある。基準が同じとはかぎらないので、断定できないが……。 そうなのです。「失敗」の定義は意外と難しい。随分前に訳した「失敗とは何か」では CHAOSレポートによれば、成功するプロジェクトの割合はたったの34%だそうな。 Standish GroupのCHAOS reportは、長年に渡ってドブに捨てられてきた何十億ドルにもなるIT関係プロジェクトの話を延々と述べている。34％の成功率っていうのは実は改善された数値で、2001年の調査では28％だったんだな。 とのこと。失敗率66%。ただし、この記事でMartin Fowler氏は 納期が遅れたとか予
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
効果的にアジャイルをやるための仕事場