翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約
以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ
7 things CIOs should know about agile development
Though it may surprise cynical IT managers to learn this, developers care passionately about the software they write. Managers want top-notch, bug-free applications delivered on time, which meet or exceed user expectations—and the people who build that software have the very same intention. How managers and developers achieve those goals, however, can be far different. The “old” school of software
ペアプロ相手のすごいところ - 毛のはえたようなもの
ペアプロ相手id:hayamizのすごいところをかいて感謝の代わりにしよう。 他にもプログラム関係で質問に答えてくれた人や学科の人もここに含まれます。 想定としては片方ががとてもできるプログラマで、片方が初心者という状況。ですから、職場や研究室にも当てはまるかもしれません。 「どんどん好きに書けばいいよ」と言ってくれる SVNでバージョン管理＆ソースコード共有をしている状況で。 当たり前ですが、私が書くよりも彼が記述する方が正確でデバッグする量が減ります。 プログラムを書くことに躊躇していたのですが、その時に一言。*1 ダメなコーディングにはツッコミを入れる 文法的な間違いからはじまって宗教的なとこについても。 if文/switch文の使い分けやreturnの位置、ポインタ変数の配置など。 先人のものを踏襲するのが習得には手っ取り早い。 あとはEmacsの環境・インデント位置なんかも合わせ
オフショア時代を乗り切る明確な要求仕様作成術
正確で明確な「要求仕様」を作成するのは非常に難しい。それがオフショア開発となればなおさらである。 開発技術の発展により，従来よりも変更に強く，速くシステムを作ることは可能になった。しかし，実物を作らずに「紙上」だけで仕様を正確に定義するのは，いまだにとても難しい。 システム化の対象業務も様々で，近年では経理システムのように定型なものは少なくなった。要求を出す側のユーザーでも，アプリケーションを作成して初めて仕様が見えてくるといったことはよくあることだ。 システムに対する業務的な要求が，時間の流れによって変わってしまうこともよくある。チェンジビジョン代表の平鍋健児氏は，このことをで「ムービングターゲット」，つまり動く標的という言葉で説明している。 オフショア開発の場合，それが顕著になる。日本人同士のように，電車で移動すれば顔を合わせられる位置にいても，仕様に対する意識の違いや，仕様そのものの
【XDev】「とりあえず作って，後から作り直せ」，Rubyのまつもと氏が語るエンタープライズ開発：ITpro
写真●「X-over Development Conference 2007」で講演する，まつもとゆきひろ氏 「結局のところ，顧客に何が必要かは，顧客にも開発者にも理解は不可能だ。そうならば，まずアプリケーションを作って，それを使ってもらい，顧客に合うように直すしかない。これからのエンタープライズ開発も，とにかく速く安く作って，直すことが重要になる」－－。プログラム言語「Ruby」の開発者であるまつもとゆきひろ氏は9月7日，ソフト開発をテーマにしたイベント「X-over Development Conference 2007」の講演でこう主張した。 まつもとゆきひろ氏の講演テーマは「Web 2.0時代のエンタープライズ開発」というもの。Web 2.0時代のアプリケーションは，「YouTube」に代表されるように，「仕組みそのものよりも，データがどれだけ集まっているかが生死を分けている」（ま
TRICHORDの背景 - (1)何故スケジュール管理が難しくなっているのか
はじめに 本稿では、昨今のスケジュール管理の難しい現状の問題を整理し、そこからTRICHORDの背景に流れる、時間を中心としたスケジュール管理の考え方を３回に分けてご紹介します。 ガントチャートの世界観 最近ガントチャートベースでのスケジュール管理がうまくいっていないプロジェクトが多くなってきています。それは決してＷＢＳの切り出し方が悪いとか、進捗管理が適切に行われていないという問題ではなく、そもそもガントチャートが表す情報やその前提となっているものが最近のプロジェクトの状況にそぐわなくなっている現実があるからです。それではガントチャートの世界観から見ていきましょう。 ガントチャートをベースにスケジュールをたてると自然に以下のような世界観が背景に存在すると考えています。 タスク間には依存関係があり依存されているものから先に手をつける タスクを実施するためには各々に応じたスキルが必要である
［動画］Ruby設計者まつもとゆきひろといろいろ語りたい － ＠IT情報マネジメント
プログラム言語Rubyとアジャイルソフトウェア開発の連携が生み出す新たな可能性を縦横無尽に語り合う。全6回シリーズの第1回。まつもとゆきひろ（ネットワーク応用通信研究所）がRubyの来歴を語り、平鍋健児（チェンジビジョン）がアジャイル開発とRubyの接点を模索する。角谷信太郎（永和システムマネジメント）が両者の橋渡しをする。 なぜ、「まつもとゆきひろ」か？ 「RailsによるアジャイルWebアプリケーション開発」は一風変わった書籍である。RubyによるWebアプリケーションフレームワーク、Ruby on Rails解説の決定版である本書は、書名に「アジャイル」を冠しながらも、本文では具体的なアジャイルソフトウェア開発手法への言及がほとんどない。その理由は「アジリティ（agileであること）はRailsの構造の一部」であり「フレームワーク自体にアジャイル宣言の原則を語らせるように」執筆したと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kent Beck氏 Implementation Patternsを語る
タスク単位ではなくストーリー単位で作業を行う
アジャイルとは誠実であること
管理者達へ：チームがコミュニケーションスキルを学習できるよう手助けせよ
新しいアジャイルコミュニティサイト登場
ベッドタイムユーザストーリー: カウボーイとおとぎ話
InfoQ: Cockburn氏テスティングを語る: 本物のプログラマにはガッツ(GUTs)がある
50人の開発者に聞きました: アジャイルについて、あなたのCIOに知ってもらいたいこと
ユーザストーリーの適正サイズ
50 Developers Answer: What Do You Want Your CIO to Know About Agile?
Article 212 at 07/10/17 16:55:13 From: noreply@objectclub.jp Subject: 【オブジェクト倶楽部： 2007-37号】
http://221.242.139.99/pukiwiki/pukiwiki.php?%5B%5B%B3%D1%C3%AB%2FReloaded%2FAgile%5D%5D
masuidrive on rails » Blog Archive » アジャイルな環境作り - そんなに急いでどこへ行く
