アジャイル導入コンサルタントという名前でスクラムだけを導入しようとする人は死ねばいいのにと思った - 水まんじゅう2
この文章中で表現されるアジャイルとはアジャイルソフトウェア開発宣言に沿ったものとします。 なぜか定期的にアジャイル開発をしようとしている人を食い物にしようとしている人のお話を聞くので。 タイトルですべてです。それ以上のことはない。 スクラムはアジャイルな開発を実現するためのプラクティスではあるけれども、スクラムをしてもアジャイルになるわけではないという事実。 それだけなのですが。 今まで見たり聞いたりしてきたアジャイルの失敗例 突き詰めると以下の二つではないかと思っています。 設計ができない 失敗ができない 設計ができない アジャイルだから設計書を作らなくてもよいよね。という人たちはいまだにいるらしい。 設計書という体裁では不要の場合もありますが、設計は必要です。 思いつく限り書き上げると以下の通り。 プロダクトオーナー(お客さん)との合意形成のため 全体で何を作るのかを明確化するため 必
アジャイル開発のインパクトを定量化する
本記事では、アジャイル開発の生産性を効果的に把握するための指針を専門家の視点から解説する。 アジャイル開発手法はIT業界にしっかりと根を下ろしている。このプラクティスは当初、ウォーターフォール型の開発手法を置き換える斬新な開発方法論として世に登場した。その後、製品化までの期間の短縮や、開発費の低減、顧客の期待に沿える高品質なソフトウェアの構築が可能になる点を買われ、従来手法に取って代わるようになった。そして、ソフトウェア需要の増加とともに、規模の小さい新興企業から大企業に至るまでの多種多様な企業で、数多くの開発チームがアジャイル開発手法を採用するようになってきている。 アジャイル開発手法は、社内におけるさまざまな規模のソフトウェア開発プロジェクトに適用できる一方で、そういったプロジェクトの可視性を得るために、マネジメントはいまだに最適な方法を模索し続けている。しかし大企業の場合、実際にプロ
『リーン開発の本質』のあとがき。日本のアジャイルをつくりたい。：An Agile Way：オルタナティブ・ブログ
わけあって『リーン開発の本質』を再読しています。る。日本の中でアジャイル開発を、できるだけ管理者の言葉として伝えたかった本です。この本は本当にたくさんの人に読んでほしいなぁ。ここに、そのあとがき、として書いた文章を掲載します。 最後に書いた、 多くの間違った標準化が、「人は本来怠け者でありしっかり働かせるために規則を作らなければならない」とか｢人は交換可能である｣というメンタリティから発している。もし、組織の文化や方針の中心にこのような考え方があると、もしくは多くの管理者がこのように考えているならば、「決して」リーン活動は成功しない。そうではなく、「人の持つ工夫のモチベーションを活かす」こと、「一人ひとりの人を育てる」ことこそ、マネジメントの中心となるべきだ。「人」の要素はプロセスの中心である。ここをやり間違えてはならない。 日本のソフトウエア業界が、人の持つ知恵と力を大切にしながら、高品
CHANGE ACTION
イベント&発表資料 [資料公開]アジャイル×強いチーム＝成果 #agilejapan #agilesendai 2013年6月3日 , 0 ayaya1024 2013年5月24日に開催されたAgile Japan 2013 仙台サテライトで登壇させていただきました。ご参加いただいた皆様、ありがとうございました。 仙台サテライトの今年のテーマは、『アジャイル×○○＝成果』です。 […] Agile, agilejapan, agilesendai, Scrum 書評 わかりやすいアジャイル開発の教科書から学ぶ、価値あるソフトウェアづくり 2013年4月13日 , 0 ayaya1024 価値を描くためのゴールをつねに意識し続けること ゴールを実現するために、プロジェクトメンバーとお客様の心を一つに同期させ、協調できるリズムを作り出すこと 自分たちが世に送り出すソフトウェアと、自分を含めたメ
「アジャイルの現状と未来、次に来るもの。～リーン開発への展望～」Agile Japan 2010基調講演から
「アジャイルの現状と未来、次に来るもの。～リーン開発への展望～」Agile Japan 2010基調講演から アジャイル開発手法として知られるXPやスクラムは、国内で徐々に浸透し始めています。しかしアジャイルをさらに推し進めて企業レベルでアジャイルを活用したり、あるいは企業自身がビジネスをアジャイルに回すためにはどうすればよいのでしょうか。 4月9日と10日の2日間開催されたイベント「Agile Japan 2010」。2日目の基調講演に登壇したAlan Shalloway氏は「アジャイルの現状と未来、次に来るもの。〜リーン開発への展望〜」（What Is Next In the Agile World）と題し、企業をマネジメントする視点からのアジャイルについて講演を行いました。 Shalloway氏の講演は、アジャイルについてよく言われる「プロジェクトではうまくいくが、会社レベルで展開し
Scrum Gathering Tokyo 2013 パネルのノート：An Agile Way：オルタナティブ・ブログ
資本主義が生き残れるのか、イノベーションがそれを延命するか、社会主義が再度別の形で現れるのか、という大きな話から、「原節子がイディア（理想、プラトン）で女房を見ると（実践、案外うまくやっている）」という冗句まで、とても楽しい時間でした。先生の言葉とアジャイルをつないでみます。 暗黙知： 朝会、デモ、場作り、見える化、ペアプログラミング サイエンスからアートへ： ソフトウェア工学からアジャイルへ SECIの回転： インテレション（スプリント） プラトンかアリストテレスか： 理論か実践か（まず実践ありき） 思いを持つこと： プロダクトオーナーの仕事、ビジョンを描くこと 共同主観を作る： 全員同室、リアルタイムで文書でなく 暗黙知を形式知にする： ふりかえりでKPTで言葉にする
プロジェクト向きのアジャイル開発手法：DSDM - Always All Ways
DSDMって聞いたことありますよね？そうそう、アジャイル開発手法の一覧みたいな表には必ず含まれているけど、XPやScrumと違って実はあまりその実態を知らないやつです（笑）。もちろん私も聞いたことはある程度で、ちゃんとした知識は持ち合わせていません。（そういう意味だとCrystal、FDD、ASDとかみんなそんな感じですけど。） DSDM: Dynamic Systems Development Method 少し前の記事ですが、DSDMについて面白い記事を見つけたので紹介しておきます。 » DSDM is Agile’s Best Kept Secret? » Agile Scout タイトルを見た時には、昨日のブログ・エントリで紹介したSteve Denningの"The Best-Kept Management Secret On The Planet: Agile"にインスパイアさ
経営にとってのアジャイル（または最近のSteve Denningの記事がツボにはまるという話） - Always All Ways
このブログでも今まで、アジャイル開発におけるマネジメントやマネージャーの役割について何回か取り上げてきました。が、今までのはそれでもまだ、どちらかというと「現場より」のマネジメントの話でした。（会社の役職で言えば課長から部長くらいのイメージですかね。） で、もう少し上のいわゆる役員以上くらいをイメージした時に、どうやってアジャイル開発を説明していくかとか売り込んでいくか、あるいはその層をどうやって味方にしていくかという課題に関して、最近のSteve Denningが書いているものが結構ツボにはまる内容なので、注目記事をいくつかセレクトして簡単にご紹介しておきたいと思います。 地球上で最も守られている経営の秘法：アジャイル まず、割と新しいところで最もインパクトのあった記事がこちらです。 The Best-Kept Management Secret On The Planet: Agile
社会的必然性としてのアジャイル - Always All Ways
今朝、巷でちょっと盛り上がっていたやつに私も乗っかっておきます（笑）。 # 最初は乗っかるつもりはなかったのですが、読めば読むほど味わい深いので、私なりの解釈や思うところを書き記しておきたいと思った次第です。 # 元記事の著者お二人の意図に反した解釈を勝手にしている部分もあるかもしれませんが、あくまで私なりの解釈とそれらについての個人的見解とご理解くださいね。 元記事ふたつ ウォーターフォールのほうが楽だという話 - 勘と経験と読経 ウォーターフォールの方が楽ですか？ | Ryuzee.com 著者のお二人は個人的にもお付き合いがありどちらも尊敬している人です。ユーモアまじりの記事の中でそれぞれの視点や考え方が出ていて興味深く読みました。 まず、両記事を読んで私が感じたのは、（おそらくお二方も承知の上で敢えて書かれているのだと思いますが） 「どちらが楽か」というのは、PMやコーチとしてメン
アジャイルって組織論ですよね（DevLOVE2012ご報告） - arclamp
2012年12月15－16日に開催されたDevLOVE2012で「どうしたら良いシステムが作れるのか」というタイトルで講演をさせていただきました。 Devlove2012 どうしたら良いシステムが作れるのか from yusuke suzuki アーキテクチャとマネジメントについての講演は2年ぐらい前からしていますが、そこで考えてきたことをギュっとまとめたので相当密度の高い内容になっています。予想通り時間も足りず、ちょっと最後が駆け足で申し訳なかったです。前半部分とかを丁寧に見たい方は過去記事を漁ってもらうとよいかも。 この資料を作るにあたって1960年代からのIT技術とマネジメント手法の歴史を見直していたのですが、組織論や科学（認知学/複雑系など）の流れとの絡み合いは非常に面白かったです。 その中で「アジャイルって組織論なんだな」と当たり前の事実に（いまさら）気づけけました。スクラムのJ
アジャイル開発モデルは準委任契約を結べば良いという誤解 - 勘と経験と読経
最初に注意書きを。本エントリは法務面で専門家ではない私が個人として意見見解を述べているものであり内容を保証するものではない(他のエントリもそうなのだけれども)。アジャイル開発に関する諸契約については専門家(自組織の法務部門等)に確認していただきたい。なんとなく本邦のIT業界には「アジャイル開発モデルは準委任契約を結べば良いという誤解」があるような気がしている。今年、IPAから『日本におけるアジャイル開発に適した契約モデル案』などが出てきているので、それを改めて読みながら論点を整理したいと思った次第。 請負、準委任 いろいろ整理する前提として、請負、準委任というものについて簡単に整理しておく。私の理解が誤っている可能性もあるのでお気づきの点があれば指摘いただきたい。たぶんポイントは「民法上(契約法)」と「労働者派遣法」の2つのスタンダードがあるという事だ。 民法上(契約法)の「請負、準委任」
第3回 「攻めるテスター」がアジャイル開発の品質を保証する
第3回 「攻めるテスター」がアジャイル開発の品質を保証する カナダ ドラゴンファイアー創立者 ジャネット・グレゴリー氏に聞く 迅速かつ柔軟な開発を目指したアジャイル開発手法を採用する企業が増えている。この連載では、アジャイル開発を主導する「賢者」に開発の極意を聞く。今回は、アジャイル品質プロセスのコンサルティングや研修サービスを提供するカナダのドラゴンファイアーの創立者であるジャネット・グレゴリー氏に、アジャイル開発におけるテストの勘所を聞く。 グレゴリー氏のインタビューに入る前に、アジャイル開発のテストについて簡単に説明しておこう。アジャイル開発におけるテストは、従来型開発のテストと意味合いが異なる。従来型開発のテストは通常、要求・要件に適合しているかどうかを検証することを目的とする。これに対し、アジャイルのテストは「ビジネス価値を最大化しているか」を検証することを最大の目的としている。
データモデリングなきアジャイル開発は危ういか？：An Agile Way：オルタナティブ・ブログ
尊敬するDOAの先輩である、渡辺さんがこう書いている。 「データモデルなきアジャイル」の危うさ、より その種のシステム（※引用者補記：販売管理システムや生産管理システムといった基幹系業務支援システム）をアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。 それに対して、稲見さんがこんなコメントをしている。 アジャイル開発と言っても色々で、最近流行りのScrumという手法は、開発の中身に関しては何も言及していません。ですが、私の知っているある人達
アジャイルの「ライトウィング」と「レフトウィング」：An Agile Way：オルタナティブ・ブログ
アジャイルの認知が進むにつれて、アジャイルという言葉がどんどん広がっている。アジャイル、という言葉の中にはいろんな要素が入っていることが分かる。もっと大きなものは、CI（継続的インテグレーション）を中核とする技術的なプラクティス群と、スクラムプロセスフレームワークのような、人と人との会話のプロトコルと協働関係を作るしかけだろう。自分の現状を、アジャイルに変えるためには、どうしたらよいだろう？ "最近、「アジャイル」といっても中にいろんな要素があるために、「あなたのアジャイルは何のことを言っていますか？」と聞くことからはじめないと、話がかみ合わない"、と、Agile2012帰りのかわぐちさんと話していて、そのときに、かわぐちさんが描いた絵（たぶんどこかにある４象限の図）がいまひとつ自分にしっくりこなくて、私が描いて見た絵がこの絵だ。 あなたが、現状の開発現場を「アジャイル」に変えたい、と考え
But...Self-Organization Is Not Enough: 自己組織化チームに関する誤解とマネージャの役割 - Always All Ways
アジャイル開発の文脈において、自己組織化されたチームという概念がよく出てきます。これはアジャイルなマネジメントを考える上でポイントとなる一つの大きな概念である半面、誤解（時によっては過大評価）されていたり、またそれが故にマネージャの役割が過小評価されているようなことも起きているのではないかと思います。 "But...Self-Organization Is Not Enough"というのはこのブログでも再三取り上げているJurgen Appeloの"Management 3.0"の第８章のある一節の見出しになっているフレーズです。この書籍では、第６章（The Basics of Self-Organization）でも１章を割いてSelf-Organizationの理論的背景や類似概念との比較などがされており、とても参考になります。このエントリでは、そこから私がポイントと思うところを適宜抜
稟議書でアジャイル開発と技術的負債を説明するのに適していそうな講演資料 - IEEE Computer Society, IEEE Software主催のイベントから：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
稟議書でアジャイル開発と技術的負債を説明するのに適していそうな講演資料 - IEEE Computer Society, IEEE Software主催のイベントから IEEE Computer Society, IEEE SoftwareによるSoftware Expert Summit 2012というイベントが2012年6月26日にロンドンで開催されました。基調講演、講演、パネルディスカッションというオーソドックスな構成です。プログラムの詳細は、こちらで公開されています。 当日の資料の一部が最近公開されたようで、興味があったものの参加できなかったので資料を眺めていました。私が気になったのはアジャイル開発と技術的負債を説明する2つの講演資料でした。アジャイル開発のほうは不確定な状況への対応を中心に紹介されています。技術的負債のほうは負債によるコスト増と負債を解消するための対応コストの双方
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルちゃん登場！スクラムによるアジャイル開発研修プログラムを始めます！
アジャイルへの移行を支援するため人事やマネージャ何ができるか
Agile Conference Retrospectiveに参加しました。 | 薄まる自分
アジャイルの流儀で英語に挑戦！