アジャイル開発の反対はウォーターフォール開発じゃなくて「おまかせ」だと思う - 思っているよりもずっとずっと人生は短い。
メモ。 アジャイルとウォーターフォールを対比させるのは違和感があった。ので、少し考えてみた。 アジャイルソフトウェア開発宣言にある「包括的なドキュメント」とか「契約交渉」とか「計画に従う」とかと、「対話」「顧客との協調」「変化への対応」とかは、わりとばらばらなお題目が並んでいるように見える。少なくともこれがMECEだと思う人はいないと思う。 ばらばら並んでいる項目の共通点、類似点は何か。それはたぶん、「顧客」と「開発者」という2つのロールを仮定して、そのロールの人同士の間でのコミュニケーションコストを最大化する（という言い方が悪ければ「最大限許容する」と言い換えてもいい）というものだろう。文書や契約や計画は、あらかじめ（多少はコストをかけて）まとめておけば、それ以降のコミュニケーションは省略できる（ような気になる）、というものだろう。ツール・プロセスも同様だ。一方で、個人や対話、顧客との協
スクラム道.01 に参加してきました - nsgcの日記
スクラム道 と呼ばれる、 スクラムを中心にアジャイルを探究する会に参加してきました。 http://kokucheese.com/event/index/4739/ 初回の今回は、テーマは「ふりかえり」で、 話し手は [twitter:@nawoto]さんによる「KPT is harmful」というお題。 harmful な理由 意見が出ない Problem ばかりになる Problem出すと怒られる Try書くの難しい Try出すと、自分にふられるので出せない 現実的なTryが出せるProblemしか出さない etcl...etc... といった、書物やWebの記事等ではさらっと、 "こうすれば良いよ"とやり方が記されているのだけど、 いざやってみると難しいなー となってしまう「ふりかえり」の定番である「KPT」。 講演はここまでで、皆さんどうなの? という問いかけと共に、 スクラム実践
CEDEC事前インタビュー：アジャイルで大規模開発？ スクラムを使ったゲーム開発の可能性とは
CEDEC事前インタビュー：アジャイルで大規模開発？ スクラムを使ったゲーム開発の可能性とは 編集部：aueki ゲームリパブリック技術部部長 田中宏幸氏 コンピュータというものが世に現れて以降，プログラム開発は常に重要な課題だった。現状のコンピュータの祖となるEDSACが登場して60年あまり，パソコンが登場して35年あまり，ゲーム機だとファミコンが登場して27年，その間に数多くのハードウェアが登場してきたものの，より重要だったのはどんなソフトウェアが動くかであったといえるだろう。産業としては，まだ数十年の歴史しか持たない分野ではあるが，ソフトウェア開発で方法論の蓄積は進んでおり，いかに効率を上げていくかという学問が「ソフトウェア工学」として成立している。 そのなかの一つに「アジャイル開発」と総称されるものがある。 「アジャイル」は「AGILE＝俊敏な」，という意味。RPGのパラメータで「
Pivotal Tracker: はじめかた
Pivotal Trackerをプロジェクトで使うにあたっては、アジャイル開発手法の知識が多少はあると役にたちます。エクストリームプログラミング(XP)であれば、このXPの入門記事をはじめとして、数多くの良質な記事をオンラインで見つけることができます。 ダッシュボードPivotal Trackerにログインすると、まず最初に表示されるのは自分の ダッシュボード(Dashboard)です。このページには、あなたが参加している全てのプロジェクト、最近の活動、Pivotal Trackerからの重要なお知らせが表示されます。 プロジェクトに招待されていれば、プロジェクト一覧にそのプロジェクトが表示されます。プロジェクトのリンクをクリックすると、そのプロジェクトのストーリーを表示します。新しいプロジェクトの作成は簡単です。ダッシュボードで"Create Project"ボタンをクリックし、プロジェ
age += 1: PMカンファレンス2010 Winterで講演しました, Developers Summit 2010: 2日目, おとうさんへえをかいたよおたんじょうびおめでとう, 卓人の部屋 - 第3回 ゲスト: 中埜博さん - 角谷HTML化計画(2010-02-19)
■1 PMカンファレンス2010 Winterで講演しました 「プログラマ35歳定年説」とかいうのがあるらしいので、今日から35歳だから私もスーツを着てPMカンファレンス2010 Winterでアジャイルとか見積りとか計画とかの講演をしました。以下、背景画像集です: Agile Estimating and PlanningView more presentations from Shintaro Kakutani. 内容を詰め込み過ぎたり(もう1トピック削るべきだったのだけれど、その判断を結局くだせなかった)、講演直前の機材トラブに出鼻をくじかれて会場の空気を変えられないまま時間切れとなってしまったりと、反省点も多いのですが、普段お話しさせてもらっているオーディエンスとは違った場所で話す機会をいただけるというのはとても貴重なことだと心得ております。 世界をつなぎ、世界を変えるには、その世
【ＪＲ脱線事故４年】自分が設計の一端を担った電車だった 弟を亡くした石井努さん (1/2ページ) - MSN産経ニュース
【ＪＲ脱線事故４年】自分が設計の一端を担った電車だった 弟を亡くした石井努さん (1/2ページ) 2009.4.25 11:52 自分が設計の一端を担った電車に乗り、たった一人の弟が事故に遭った。神戸市北区のシステムエンジニア、石井勝さん＝当時（３７）＝を亡くした兄、努さん（４４）は、遺族代表として述べた慰霊の言葉で、この事実を初めて公表した。４年間の空白を埋めるように、努さんはひと言ずつ、切々と語った。 「その日も今も、私にとって最も大切なことは、どうして死んだのか、だれのせいで死んだのかというのではなく、弟が死んだという事実だけです」。努さんは「慰霊のことば」をこう切り出した。 努さんはかつて、車両床下に取りつける装置の設計に携わっていた。脱線事故後、マンションに激突した通勤電車が、自分のかかわった２０７系だったことを思いだし、ＪＲ西日本で遺族を担当する社員から、図面のコピーを取り寄
Manifesto for Software Craftmanship（ソフトウェア職人マニフェスト）にサインしよう：An Agile Way：オルタナティブ・ブログ
最近、アジャイル開発を「繰り返し型」の形として採用するのはいいが、そこで実際に開発活動をする人たちのスキルに、再度焦点が当たっている。つまり、プロジェクト管理手法としてのみアジャイルを取り入れても、破綻する、ということだ。ソフトウェア開発技術は、匠の技であり、この技術は職人の技だ。この議論は、 James Shore の「アジャイルの衰退と凋落」 Brian Marick の「What's missing from the Agile Manifesto」 Uncle Bob Martin の「Craftmanship over Crap」 などからの流れなのだが、ついに、「ソフトウェア職人宣言」が出現した。以下に、訳文とそのURLを書いておくので、同意する人は、サインをしよう！ ソフトウェア職人宣言(原文： http://manifesto.softwarecraftsmanship.o
「ふりかえり」が失敗する８つの理由：An Agile Way：オルタナティブ・ブログ
「アジャイルレトロスペクティブ」の著者、イースターダービーのStickymindsの短い記事です。 「ふりかえり」が失敗する８つの理由 Eight Reasons Retrospectives Fail ぼくは Retrospectives を「ふりかえり」、と訳している。オブジェクト倶楽部のプロジェクトファシリテーションのページに、天野さんが、日本語の「ふりかえりガイド」(PDF)もかいている。 簡単にまとめると、 「ふりかえり」が失敗する８つの理由 １．準備不足。 ⇒アジェンダをしっかり用意すること。 ２．焦点があいまい。 ⇒前回のイテレーションの改善に集中。 ３．データが集まっていない。 ⇒何かを変えようとするまえに、「実際に何が起きていたか」を話す。 ４．１人か２人が会議全体の会話を独占してしまう。 ⇒ペアにしたり、グループを作ったりして話あうアクティビティを持つ。 ５．自分たちで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Agile66 - 新人研修でガチアジャイル
【資料公開】テストについて考える