日本のアジャイル１０年、人々とコミュニティの私的物語：An Agile Way：オルタナティブ・ブログ
日本のアジャイル１０年、人々とコミュニティの私的物語 平鍋健児 （※）この記事は、2011年に書籍『Ultimate Agile Stories』に寄稿したものを転載しています。執筆時点で、『Ultimate Agile Stories - Iteration 2』が刊行されています。(2012/8/15) ぼくが初めてアジャイル、というか、XP、そうエクストリームプログラミングについて知ったのは、2000年の初めだった。ふと目について注文した洋書『Extreme Programming: Explained』がamazon.comから届き、それを週末に読んだのだ。このときに、どんな電流が走ったかは、多くの人の前で語ってきたが、Kent Beck という人物がとんでもなく明快に、そして極端に、人に喜ばれるソフトウェア開発、という視点でプログラミング活動を中心おいて4つの価値と12個のプラ
スクラムの原典を読み解く(4)：An Agile Way：オルタナティブ・ブログ
開発フェーズを重複させる 開発フェーズを重複させることで、メンバーは専門分野を超えてプロジェクト全体に責任感をもつようになる。 オリジナルでは... 自己組織化されたチームは独自のリズムを作り出す。開発と製造では、もともとスケジュールの考え方が異なっているのに、それが一体となって全体のゴールを目指すことになる。Type Aのように行程を逐次通過する手法（リレーアプローチ）では、前工程の要求事項がすべて満たされて始めて次の工程に移る。次行程へと移るチェックポイント毎にゲートを設けてリスクをコントロールする仕組みだ。しかし、この手法は上流で全体の自由度を過度に奪ってしまい、決定が後戻りができない欠点がある。また、ある行程で障害に出会うと流れが止まってしまい、そこがボトルネックになって全体の進行を阻んでしまうこともある。 一方、行程が重なり合ったType BやType Cのような手法（ラグビーア
朝会（デイリー・スクラム、スタンドアップ・ミーティング）：An Agile Way：オルタナティブ・ブログ
アジャイル開発では、チームの状況を共有するミーティングを毎朝行う。これを、デイリー・スクラム、と呼ぶ。短時間で立ったまま行うことを習慣化することが多く、スタンドアップ･ミーティング、と呼ぶこともある。（※前者はスクラム、後者はXPからの用語） チームは、現在のプロジェクトの状況を壁を使って見える化し、チームで共有する。現在の状況を示すタスクボードや、かんばん、バーンダウンチャート（進捗を示すグラフ）、そのほかの貼り物をする。このような場所で行うと、朝会の伝達効率がいい。 各自が短く次のこと（３つ）を報告する。 昨日やったこと 今日やること 障害となっていること アジャイル開発では、コードを継続的にインテグレーション（結合）して常にテストが通る状態に保つ。同様に、毎朝、チーム自身もインテグレーションし、みんなの頭の中と行動を結合し、最新の動ける状態に保つ。 日本では、朝会、と言う言葉がよく使
「測定できないものは制御できない｣は誤りだった。-- by Tom Demarco：An Agile Way：オルタナティブ・ブログ
ソフトウェア工学の祖の一人である、トム・デマルコが、最近IEEE Software 誌に、過去のソフトウェア・メトリクス賛美を悔い改める記事を書いている。 「ソフトウェア工学」というコンセプト－その時が来た、そして、その時は去った。http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r 1982年に、デマルコは有名な「計測できないものは制御できない」という一文から始まる、『品質と生産性を重視したソフトウェア開発プロジェクト技法』という名著を書いている。このドグマは、ソフトウェア工学の考え方に強く根ざしている。むしろ、すべての「工学」という活動は、科学や経験から得た知見を使って自然現象をコントロールし、人間の役に立てることをその定義としており、そこでは測定を元にしたコントロールという概念はその中核にあ
Ed Yourdon の『ソフトウェア工学で大切な１０の考え方』を訳しました。：An Agile Way：オルタナティブ・ブログ
先日、尊敬するエドワード・ヨードン博士が「Top 10 Software Engineering Concept」という文書の公開した、とtwitter でつぶやいていたので、「訳してもいいですか？」と聞いて、5分でOKをもらった。なんというインターネット時代だろう。 slideshare で見る PDFをダウンロード 原文を見る ヨードン博士の動機は、 不況時代に突入し、今後デスマーチが一気に増えるであろう。でも、ソフトウェア工学の大切な考え方は、そんなに昔から変わっていないんだ。新しい世代は、すごいよ、学生はみんなIMで会話して、Facebookで繋がっている。COBOLプログラマがまだ存在しているなんてことは知らないんだ。でも、ソフトウェア工学の大事なことは、なんども新しい世代が、同じ事実を発見し、過去の重要な論文や書籍にぶち当たる。ここで１０個上げて、フリー文書にしておくので、共有
設計からコーディングまでの「距離」：An Agile Way：オルタナティブ・ブログ
私の立場は「コーディングは設計（の一部）だ」(by Jack Reeves)である。ここでは、コーディング以前のラフな設計（例えばUMLのクラス図やシーケンス図レベルのアイディア、それがホワイトボードに描かれていようが、紙であろうが、JUDEであろうが、日本語であろうが）を、ここでは設計と呼ぼう。 設計とコーディングの距離が増えれば増えるほど、ムダが増える。私の主張は、できるだけ、１つの関連部分の設計とコーディングは、「一人の人」が「少しずつ」行ったほうがよい、ということだ。昔見た「詳細設計書」という細かい実装の詳細を日本語である人が書き、それを見て別の人がコードを書く、ということは避けたい。ここでの距離とは、 頭脳間距離。 時間的距離。 の２つ。 頭脳的距離は、物理的に書く人の頭脳の距離だ。1人の人が設計からコーディングまでを含めて担当すれば、この距離は0だ、別の頭脳が担当するならば同じ
ソフトウェア設計で大切なこと(1/2)：An Agile Way：オルタナティブ・ブログ
明けましておめでとうございます。 去年は少し、アジャイル・アジャイル言い過ぎた気がしており、今年はもう少し大切なことの範囲をエンジニアリングに回帰して、再度言おうと思っています。 オブジェクト指向やテスト技法をはじめとするソフトウェア工学の知識とスキルは、ソフトウェア開発に携わる人には絶対必要なもので、その上で、プロジェクトマネジメント手法としてのアジャイルがある。 ということは、もういちどちゃんと言っておこう。そう思った動機は、James Shore の「Art of Agile Development」を訳したこと。そして、それはXPの本だったこと。ここ３年くらいXPという言葉はAgile界では下火になっていて、AgileといえばScrumという風潮だったのが、「エンジニアリングの無いScrumは所詮うまく行かない」、というJames Shoreの当然な一撃があった。InfoQの日本語
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
