Agileが根付かないもう一つの理由 - masayang's diary
「プロジェクト失敗率とリスク」の続き。 id:suikyojinさんからトラックバックをいただいた。 大規模Agileの失敗率は驚異的に低い? そもそも、大規模プロジェクトの失敗率って、ものすごく高くて、70%とか80%とかいった数字を見たことがある。基準が同じとはかぎらないので、断定できないが……。 そうなのです。「失敗」の定義は意外と難しい。随分前に訳した「失敗とは何か」では CHAOSレポートによれば、成功するプロジェクトの割合はたったの34%だそうな。 Standish GroupのCHAOS reportは、長年に渡ってドブに捨てられてきた何十億ドルにもなるIT関係プロジェクトの話を延々と述べている。34％の成功率っていうのは実は改善された数値で、2001年の調査では28％だったんだな。 とのこと。失敗率66%。ただし、この記事でMartin Fowler氏は 納期が遅れたとか予
WritingTestableCode - テストできるコードの書きかた
WritingTestableCode - テストできるコードの書きかた 目次 この文書について まずいのその1: コンストラクタがやりすぎ まずいのその2: 深い仲になってしまっている まずいのその3: 脆いグローバルな状態とかシングルトンとか まずいのその4: クラスがやりすぎ テストできるコードの書きかた この文書について "Guide: Writing Testable Code" の日本語訳です http://misko.hevery.com/code-reviewers-guide/ 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... TODO: 各 Flaw のリンク先も訳す Misko Hevery コードをベストな状態に保つために、 我々は Google でソフトウェアエンジニアに以下のようなをガイドを定期的に送っていた。このガイドを共有できてうれしいね。 この
アジャイル開発の恩恵とは - builder by ZDNet Japan
私は最近、IBMのRationalソフトウェアのアジャイル開発プラクティスリーダーであるScott Ambler氏に、アジャイル開発手法の利点について話を聞いた。 Ambler氏は、アジャイル開発がいくつかの従来の手法よりもなぜ優れているのかを説明してくれた。また、同氏はアジャイル開発に関する伝説を打ち砕いてくれ、いくつかの方法論について議論し、アジャイル開発へのスムーズな移行を行うためのアドバイスをくれた。 --アジャイルがいくつかの従来の手法よりも優れているのはなぜだと考えていますか。 アジャイル開発の主な恩恵は、品質、規律、ビジネス上の利害関係者と密に連絡を取りながら作業を進められること、定期的に機能するソフトウェアを提供できることなどに焦点を当てられることです。これは、単にわれわれが現実世界からベストプラクティスを取り入れたものであり、われわれは積極的にものごとを改善しようとしてい
RSpecを使ったテストコードを読もう
RSpecを使ったテストコードを読もう：Railsコードリーディング～scaffoldのその先へ～（2）（1/4 ページ） 優れたプログラマはコードを書くのと同じくらい、コードを読みこなせなくてはならない。優れたコードを読むことで、自身のスキルも上達するのだ（編集部） 第1回「コードリーディングを始めよう」では、Railsアプリケーションの基本であるCRUDのソースコードを読解しました。最低限の基本の動きということで、ディレクトリ構造の説明すら割愛していたので、今回はディレクトリ構造の解説から行います。その後、今回のメインテーマであるテストコードのコードリーディングに入っていきます。 ここで扱うテストコードというのは、Javaの世界でいうとJUnitを使ったテストコードと同じ粒度、つまり、単体テストに近い粒度のテストケースを動くプログラムで表したものになります。Javaの開発者にとってのJ
技術的負債(Technical Debt) - masayang's diary
先日参加したBayXP Meetingにて、座長のJeffreyがCruiseControl 2.8について「新たな付加価値はゼロだけど、リリースした」という話をしていた。Jeffryのブログ「CruiseControl 2.8 Released」を読むと、そのココロがわかる。 This release felt like we were paying off technical/hygiene debt at the same time, at least in a small way. Not major refactorings, just lots of small changes to make things better. 大規模なリファクタリングではないが、細かい変更をたくさん加えた。 「技術的負債(technical debt)」をちょっとだけど返済したようなもの。 技術的
1000Speakers@Sendai #1で話してきた - marsのメモ
誰かが言った「ブログを書くまでがセンスピだ」と。 1000speakers-sendaiView SlideShare presentation or Upload your own. (tags: 1000speakers)＃5枚目のスライドを人前で言えただけで，もう満足です。 ＃ホントウにありがとうございます。 10分枠に話をまとめるのはちょっと手強くて，マジメにCIのこと話してたら尺が足りなそうなのでネタに走りました。それでも言いたい事は大体言えたので良しとするか。 若干フォローを。 PHPでのHudsonの活用については，id:ssogabeさんがいろいろ書いてます。→[PHP] - ssogabeの日記 Hudsonの日本語のページはこちら。→Hudson - 日本語 最近，id:onozatyさんがSelenium AESのHudsonプラグインを公開してくれました。 id:c
DeclineAndFallOfAgile - アジャイルの衰退と凋落
DeclineAndFallOfAgile - アジャイルの衰退と凋落 目次 この文書について アジャイルの衰退と凋落 最近の状況 Scrum の役割 Scrum の誤用 君のやりかたは間違っている 真っ最中での失敗 アジャイルの衰退と凋落 この文書について "The Decline and Fall of Agile" の日本語訳です http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... James Shore アジャイル運動の衰退や凋落について話すのはおかしなことだ. 今やとても人気があるものなのだから. けれど本当のところ, ここ数年のアジャイル運動は、衰退の途にあると私は思う. 最近の状況 自分の商売がここ数年で変化していることに私は気がついた.
MyMy-MyCompany
MyMy-MyCompany アジャイル開発手法(XP, SCRUM, FDD) ソフトウェア職人気質(教育、人間性、創造性） トム・デマルコ著「ピープルウェア」、「ゆとりの法則」 Ｇ．Ｍ．ワインバーグ『ソフトウェア文化を創る』シリーズ４巻、「スーパーエンジニアへの道」 オブジェクト指向 TOC制約理論＆思考プロセス これらをキーワードにして、ソフトウェア開発＆管理を行うためのソリューションを提供します。 HOME | mymy分室(blog) ReadMe 「ザ・ゴール」から「クリティカルチェーン」まで、「ゆとりの法則」から「熊とワルツを」まで、「知識創造企業」から「ナレッジ・イネーブリング」までをひっくるめて、私なりに、スループット会計と制約理論（TOC）というパラダムシフトから、デスマーチ、アジャイル開発手法、xUnit、または、ピープルウェアという考え方、プロジェクト管理という方法
「要件定義にXPが生かせる」、XPユーザーグループ代表
反復型で進めるアジャイル（機敏な）開発手法のXP（eXtreme Programming）。その日本ユーザグループの倉貫義人氏が、ITサービス会社におけるXPの活用法「Enterprise XP（EXP）」を提唱している。XPとの違いなどについて、倉貫氏に聞いた。 ——EXPとは何ですか？ ユーザー企業が仕様を決め、ITサービス会社が実装するという、日本では一般的な受託開発現場でXPを活用するための工夫をまとめたものです。具体的には、契約を2段階で結び、最初の契約では要件定義に重きを置き、小さくても実際に動くシステムをリリースします。次の契約では、リリースしたシステムから得たフィードバックを加えながら、システムを追加・修整しながら規模を拡大していくのです。 第1段階では、システム・リリースを短期に繰り返せるXPにより、あやふやなユーザーの要求を固めます。要求が固まった後の第2段階は、XPで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hudson - 日本語 - Hudson Wiki
javaworld.jp
http://www.nskint.co.jp/technology/xp_report.html