日経ITProの記事にケチつけておく - masayang's diary
日経ITPro: アジャイルはウォーターフォールよりも難しい 何を持って簡単・困難を定義するのかがわからないけど、「アジャイルはウォーターフォールよりもごまかすのが難しい」というのであれば、その通りだろう。 そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。 そもそも大規模プロジェクトを想定して生まれた手法は存在しないわけで。 ウォーターフォールは他に選択肢がなかったために大規模に適用されてきたけど、それが適切だったかはなんとも言えない。失敗しても他に選択肢がないんだから「ウォータフォールが悪い」って言えなかったしね。 ただ、最近は大規模でのAgile事例は増えてきている。日本ではまだ少ない、というところでしょ。 「要求の増加に歯止めが利きにくいアジャイル」というのも変だよね。 当初の一欄に
マイクロソフトにおけるアジャイル開発はこんな風に進められている － Publickey
マイクロソフトの代表的なソフトウェアは、数千人を超える開発者、数十万のソースコードファイル、数千回ものビルドを繰り返して開発される大規模なものだといわれています。 マイクロソフトのエバンジェリスト長沢智治氏は、こうした大規模な開発プロジェクトがマイクロソフト社内でどのように行われているのか、プロジェクトチームの組成から実施計画、進捗管理、バグレポートなど、その裏側を紹介するセッションをいくつかのイベントで行っています。 そこで明かされている内容は、パッケージソフトの開発だけでなく、SIerでの開発プロジェクトでも参考になる部分が多いと思われ、いつかレポート記事として紹介したいと思っていました。 今回、以前に行われたセッションビデオの存在を長沢氏ご本人から教えていただいたので、開発プロセスに関する部分にフォーカスした記事としてまとめました。 記事での内容は主に、「Microsoft Tech
アジャイルコーチングで学んだ78のこと
みなさんこんにちは。@ryuzeeです。 78 Things I Have Learned in 6 Years of Agile Coachingの記事が素晴らしいので、78個の項目を意訳にてご紹介します。 「私が6年間のアジャイルコーチングで学んだこと」というテーマでアジャイルに関する経験談がまとめられています。 アジャイルについて説明させてくれるように頼む人の数＝アジャイルメンタルモデルの数±2分散した開発では各サイトのチームごとに愛とスクラムマスターが必要だフットボールテーブルはあなたの最良のアジャイルなツールのうちの1つかもしれない地理的分散はタイムゾーンの違い以上の問題がある。その場合はインフラのサポートが必要だローカルのイベントやオンラインのメーリングリストやカンファレンスやカジュアルな集まり等を通じてアジャイルコミュニティに精力的に関わることには十分な価値がある。プロダクト
翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約
以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ
イテレーティブでインクリメンタルな技術書の作り方
オブジェクト倶楽部2007クリスマスイベント ライトニングトークス（オーム社） 編集からアジャイル編集者へRead less
テーブル設計は実装の後に！：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 「みんなが言ってる」は技術者が口にする言葉じゃないと書いてきました。 私が言ってることで、「みんな」とはおそらく真逆のことがあります。 それは「テーブル設計を（ユーザーインターフェイスの）実装の後に！」ということです。 「そんなことができるわけがない」とバカにされますが、そういう決め付けは思考停止ですよね？ ともかく、眉に唾塗っていただいてけっこうですので、続きを読んでください。 一般的なシステムにおいて、一番手戻りが大きい（波及する箇所が多い）仕様変更はテーブル変更を伴うものです。下手糞な設計で、他に悪影響を与えるのもテーブル設計です。 逆に、テーブル設計が美しく合理的にできていれば、他の工程は非常に楽になります。 では、仕様変更を防ぎ、美しく合理的なテーブル
JJUG CCC にて「『JavaからRubyへ』・アンド・ナウ」と「YET ANOTHER GREEN IT」のセッションに登壇させていただきました - t-wada の日記（旧）
本日は、日本 Java ユーザグループ主催の「クロスコミュニティカンファレンス」通称「JJUG CCC」で登壇させていただきました。 まず、会場でお聞きくださった皆様に感謝いたします。ありがとうございました。私(たち)の講演から何かを掴んで持ち帰ることが出来ましたら幸いです。 今回登壇したきっかけは、ひがさんとヨシオリからのオファーです。ふたりから誘って頂いたおかげで、Java のカンファレンスで主に Ruby のことを喋るという不思議な体験をしたことになります。今日は私は都合二つのセッションで登壇させていただきました。 『JavaからRubyへ』・アンド・ナウ 一つめのセッションは、「『JavaからRubyへ』・アンド・ナウ」というタイトルで、書籍『JavaからRubyへ』を話のとっかかりに、いろいろなことを鼎談形式で話させていただきました。モデレータは高井さんで、かくたにさんがメインで
InfoQ: 複数のアジャイルチームでのバージョン管理
複数のチームが動いているアジャイル環境では、以下の目的を実現するバージョン管理モデルが必要になります。 フェイルファースト フェイルファーストとはコードのコンフリクトや統合での問題を可能なかぎり早期に発見することです 大きな問題を数回のタイミングで修正するよりも、小さな問題を何度も修正していく方が賢明です 常にリリース可能 どんなに悪いスプリント（イテレーション）だったとしても、その成果物は何かしらリリース可能なものでないといけません シンプル このスキームはチームのメンバ全員に毎日使われることになるので、ルールや定型作業は明確かつシンプルでないといけません 紙1枚にまとめた要約図（壁張り用） この図を見て分からないことがあっても構いません。この先を読んでください。 この図を見て分からないことがなくても、この先を読んでください。 この要約図はPDFでもダウンロードできます(DL) バージョ
【レポート】JavaWorld Day 2007 - アジャイル開発の伝道師が明かす、プロジェクト成功の秘訣 (1) アジャイル開発に対する9つの誤解 | エンタープライズ | マイコミジャーナル
米IBM Practice Leader Agile DevelopmentのScott W.Ambler氏 19日、東京都千代田区において、IDGジャパン主催の技術カンファレンス「JavaWorld Day 2007」が開催された。JavaWorld Dayは、昨年末まで定期刊行されていたJavaWorld誌の内容をライブで技術者へ伝えることを目的として始まった技術カンファレンス。同誌が休刊になった現在も、継続して開催されている。 7回目を迎えた今年のJavaWorld Dayでは、「The Agile Modeling(邦訳:アジャイルモデリング)」などの著書で知られるScott W.Ambler氏をはじめ、国内外の著名なエンジニアによる10のセッションが設けられた。ここでは、同カンファレンスの中からScott W.Ambler氏の基調講演を取り上げ、その模様をお伝えしよう。 アジャ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
masuidrive on rails » Blog Archive » アジャイルな環境作り - そんなに急いでどこへ行く