2014年3月の発表資料 2014年7月の資料 => http://www.slideshare.net/hiroosak/ca-36830962
2014年3月の発表資料 2014年7月の資料 => http://www.slideshare.net/hiroosak/ca-36830962
「アジャイル」という言葉が一人歩きしてしまっていて、たまに話をしていても通じないときがあります。 それくらいアジャイルという言葉が広く知られるようになったんだと思う一方で、かえって話が通じなくて、もどかしく感じることもあります。だからといって、そこで「正しいアジャイルとは」みたいな議論をしたい訳でもないのです。 広まれば広まるほど、そういった言葉の認識の齟齬が出るのは仕方ないですね。その正しい定義みたいなところを追求するのもナンセンスなので、そんなつもりはないですが、ただ自分がどう考えているかについては書いておいても良いかな、と考えました。ここは私のブログですしね。 そこで、この記事では、私の考えるアジャイル開発の本質について、そしてウォーターフォールとの違いについて書きました。 アジャイル開発では機能を全部つくらない これまで私の中で、アジャイルと言えば当たり前の前提がありました。それは
鈴木雄介さんが、「アジャイルがダメだと思う7つの理由」というすごいブログを書いてくれたので、がんばって返答を書いてみる。どこかでディスカッションできるといいなぁ。 1. 全体スケジュールにコミットできない コミットメントって何だろう。コミットメントは約束なのか。約束であったら、破った場合のペナルティも受け入れるのか?受け入れたところでバッファが巨大になるだけではないのか?そして、そのバッファは見えないところで食い尽くされる。 全体を見えずに計画したところでうまくいくはずはない。アジャイルがタイムボックスで計画、実施を行うからといって、全体を計画しないわけではない。むしろ積極的にやるべきである。 全体を計画する上では、なるべく漏れがないように、実施可能なように最大限の努力をする。ただ、それに時間を掛けすぎるのは無駄だ。そして、神ならぬ人間が計画するのであるから、以下を認めなければならない。
1.全体スケジュールにコミットできない アジャイルはタイムボックス型(一定期間で棚卸しをして、それを繰り返す)のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ
NTTデータ、NTTデータユニバーシティ、楽天は2012年11月2日、アジャイル開発人材育成プログラムを共同で作成すると発表した。2012年12月よりNTTデータグループおよび楽天グループの社員向けに、同プログラムを利用した研修を開始する。 具体的には、アジャイル開発の代表的な手法の一つ「Scrum開発手法」での意思決定責任者である「プロダクトオーナー」育成のための研修コースを作成する。NTTデータと楽天が研修コンテンツの作成を、NTTデータユニバーシティが研修サービスの運営を担当する。 NTTデータグループおよび楽天グループの、主に新規サービス企画立案に携わる社員を対象とする。2012年度はNTTデータグループと楽天グループであわせて60人、2013年度には180人の社員への研修実施を目指す。 NTTデータグループは2012年5月より若手リーダー層を対象とした、アジャイル開発プロセスの研
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい!どの口がアジャイル出来るって言ってるねん!」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを10年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか?」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
去年の今ごろにアジャイルサムライの出版エントリを書いて、気がつけば早くも一年がたってました。 本当に多くの人に手に取っていただいてありがとうございます。 特に今も各地でアジャイルサムライ道場(読書会)が開催されているのは、僕達も想像にしてなかったし、本当に嬉しく感じています。 https://github.com/agile-samurai-ja/support/wiki/AgilesamuraiDojo 久々に出版時に書いたエントリを読み返してみました。 http://d.hatena.ne.jp/nawoto/20110713/1310575967 僕が監訳していた時に学んだ事をフィードバックしていきたいや、あちこちにお邪魔して皆さんと話していきたいと書いてました。 個人的には、まだまだちゃんと活動できていないなと思う反面、何かちょっとぐらいはきたんじゃないかと思いました。 ちょっと検
反復型vsウォーターフォールを新人教育で教えるときに、 あるゲームで体感してもらったんだが、現実にあるあると言える面白い結果になった。 結論から言うと、反復開発は速くはないということがわかった。 題材は、伝言ゲームである。 ■基本ルール ・5−6人で1チームを作り、最後尾の人がマジックと紙を持つ。 ・講師が先頭の人だけに絵を見せる。絵は以下のようなものだ。 ・先頭の人は、自分が伝言している間だけは何度でも講師の絵を見に来ることができる。 ・言葉だけを使った伝言ゲームによって順番に1人1人回して行く。 ・最後の人が紙に書き出しす。 ・制限時間は15分 ■ウォーターフォールバージョン 基本ルールに加えて以下をルールとする。 ・伝言のフローは1回だけ。1回で伝えきること。 ■反復型バージョン 基本ルールに加えて以下をルールとする。 ・伝言のフローは何回行っても構わない。 ・ただし、先頭の人を起点
ここ最近の「アジャイル」という言葉の使われ方に違和感を感じています。 年々システム開発のプロジェクトは、短納期化と低コスト化の流れが進んでおり、それによってリスクが増して且つ利益の出にくい状況になりつつあり、多くのシステム開発を請け負うシステムインテグレータは様々な取り組みを進めています。 そして、その一つとして期待されているのが「速い・安い」を実現する「アジャイル開発」だと言うわけです。もはや、まるでファストフードです。 大手システムインテグレータが集まってアジャイル検定を始めるようです。一部引用します。 アジャイル検定の本格運用に向けた、アジャイルソフトウエア開発技術者検定試験準備委員会を設立 近年、ソフトウエア開発では、厳しい経済不況などの影響を受け、ユーザーの要件を確実に、高品質に、より短期間で提供することが求められています。このような環境の下で、注目されているのがアジャイル開発手
永和システムマネジメントさんのご厚意により、去る 3 月に Agile Japan 2012 での基調講演を提供するために来日された Jonathan Rasmusson さんに対するインタビューを実施させて頂きました。 Jonathan さんは、「アジャイルサムライ」というアジャイル開発の入門書の著者です。 「アジャイルサムライ」は日本で空前のブームを巻き起こしており、現在日本の各地で勉強会(道場)が開催されています。 インタビューでは、以下の 4 つの分野に渡り、Jonathan さんに質問をしました。 1. Jonathanさんのこれまでの経歴 2. アジャイル開発一般 3. アジャイルサムライ 4. プライベートな生活 今月と来月の 2 回に渡り、Jonathan さんへの突撃インタビューの結果をお届けします。 1. Jonathanさんのこれまでの経歴について -- 今日は、イン
アジャイルソフトウェア開発はキャズムを超えたと言われてもピンと来てなかったけど、本当に超えたと僕が実感でき日も近いのではないかと思う@HIROCASTERでございませう。 「キャズム」という意味は、先進的な人と一般的な人との間にある隔壁のことです。 つまり、一部で活発になってきているアジャイルソフトウェア開発が一般的になってきているということ。 システムインテグレータ大手のNTTデータが下記の発表をしたことについて、思うことを書いておきたい。 若手リーダー層を対象としたアジャイル開発研修を開始 会社としての姿勢 これまで欧米を中心に普及してきたアジャイル開発は、米国IT企業のソフトウエア開発における採用率で30%を超えるなど、欧米では最も利用されている開発手法となっています。昨今では、日本国内でも、Webサービス業界やゲーム開発業界などを中心に多くの開発事例が見られるようになってきましたが
Agile Samurai Dojo Gathering 2012に参加して、著者のJonathanによる基調講演を聞いて、人生に一度くらい本を書いてみたくなった人へ。 当日のサムライ戦記(アジャイル開発実践者による経験談)を聞いて、共感した人、勇気をもらった人、明日から実践できるノウハウをもらった人、あなたの経験を伝えてみませんか? Jonathanはスターバックスで150杯のコーヒーを飲んで、2年間でアジャイルサムライを書き上げたそうです。同じ事をするのはなかなか難しいですね。ですから、この150杯のコーヒーを3杯ぐらいにみんなでわけて、1冊の本を書きませんか? “1つのテーマで、ひとりが2ページから3ページ書いて、1冊の本にする。” あの会場に約140名ものアジャイルソフトウェア開発に興味を持った人が集まりました。きっと、一人一人が勇気やノウハウを貰ったはずです。その気持ちを、日本全
クラウド上でRubyを使って開発し、成果物はオープンソースとして公開。開発プロセスにはアジャイル開発を採用し、毎日スタンドアップミーティングを実施。まるでベンチャー企業が新サービスを開発するようなスタイルを採用しているのが、英国政府のポータル「Gov.uk」の開発チーム。 Welcome to GOV.UK Beta (Test) - simpler, clearer, faster access to UK government services and information Gov.ukは、英国政府の情報とサービスを利用するためのポータルサイトとして開発が進んでおり、現在β版が公開されています。 グーグルのプロジェクトのようにGov.ukは作られている Gov.ukがどのように開発されているのか、ブログGovernment Digital Serviceにポストされたエントリ「Int
Fulcrumはストーリーベースのアジャイル開発にマッチしたプロジェクト管理システム。 FulcrumはRuby on Rails製のオープンソース・ソフトウェア。アジャイル開発において用いられるユーザストーリー。利点としては機能をユーザ視点で捉えることで、実装されるべき機能が明確になりイテレーションが終わった段階できちんとできているか確認がしやすいことだ。 4つの枠が特徴 そのため通常のタスク管理に比べると大ざっぱに見えてしまい、逆に細かな進捗が見づらくなってしまう場合もあるようだ。そんな状態を解決するには、最適なプロジェクト管理を導入することにあるだろう。今回紹介するのはFulcrumだ。 Fulcrumはストーリーベースのタスク管理を実現する、アジャイル開発向けのプロジェクト管理だ。完了したストーリー、作業上、バックログ、Chilly Bin(終わらなかったタスクを放り込んでおく場所
日経ITPro: アジャイルはウォーターフォールよりも難しい 何を持って簡単・困難を定義するのかがわからないけど、「アジャイルはウォーターフォールよりもごまかすのが難しい」というのであれば、その通りだろう。 そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。 そもそも大規模プロジェクトを想定して生まれた手法は存在しないわけで。 ウォーターフォールは他に選択肢がなかったために大規模に適用されてきたけど、それが適切だったかはなんとも言えない。失敗しても他に選択肢がないんだから「ウォータフォールが悪い」って言えなかったしね。 ただ、最近は大規模でのAgile事例は増えてきている。日本ではまだ少ない、というところでしょ。 「要求の増加に歯止めが利きにくいアジャイル」というのも変だよね。 当初の一欄に
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー!古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数%程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問 日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海
複数のチームが動いているアジャイル環境では、以下の目的を実現するバージョン管理モデルが必要になります。 フェイルファースト フェイルファーストとはコードのコンフリクトや統合での問題を可能なかぎり早期に発見することです 大きな問題を数回のタイミングで修正するよりも、小さな問題を何度も修正していく方が賢明です 常にリリース可能 どんなに悪いスプリント(イテレーション)だったとしても、その成果物は何かしらリリース可能なものでないといけません シンプル このスキームはチームのメンバ全員に毎日使われることになるので、ルールや定型作業は明確かつシンプルでないといけません 紙1枚にまとめた要約図(壁張り用) この図を見て分からないことがあっても構いません。この先を読んでください。 この図を見て分からないことがなくても、この先を読んでください。 この要約図はPDFでもダウンロードできます(DL) バージョ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く