アジャイルの破綻―原因、そして新たな提案 | POSTD
2001年、17人のメンバーによって アジャイル宣言 が発表されました。私はその立案者そして著者の1人であることに誇りを感じます。この出来事は、何かをする上でより良い方法を導き出すことへの期待、そしてソフトウェアを開発することで世界をより良くするといった、私自身の活力の源となり、極めて重要なターニング・ポイントとなりました。 あれから14年が経ち、私たちは行き先を見失っています。”アジャイル”という言葉はスローガン化してしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまったとすら言えます。2～3のソフトウェア開発のプラクティスを、不十分に生半可に試みるといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重ねるといった、口先だけのアジャイルの 狂信者 がたくさんいるのです。 更にひどいのは、アジャイル開発手法その
○○したら受託開発が180°変わった(10分版)
以前XP祭りでLTしたものの10分版。 「せっかく作った物が喜んでもらえない」 「仕様だ、バグだ、の不毛な争い」 「振り回されて疲弊するエンジニア」 など、受託開発でうまくいかない局面は多くあるが、ある一つのことを意識的に行うようにしたら、自分たちの受託開発が180°変わった、という話。
アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで（前編）。QCon Tokyo 2014
アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで（前編）。QCon Tokyo 2014 スクラムのようなアジャイル開発手法を採用して開発をうまく回している現場も、最初からうまくいっていたわけではありません。現場ごとに試行錯誤を重ね、よりよい方法を模索する中で少しずつ改善が進んできているはずです。 4月30日に都内で開催されたイベント「QCon Tokyo 2014」では、サイバーエージェントのアメーバ事業部が混乱の中からどうやってスクラムを導入してきたのか、その経験とそこで得られた知見が語られています。セッションの内容をダイジェストで紹介しましょう。 Ameba流 Scrumを浸透させていく方法 サイバーエージェントの大﨑浩祟です。アメーバ事業本部コミュニティ事業部というところで、現在は24Logのシステム責任者をしています。
アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!
「アジャイル」という言葉が一人歩きしてしまっていて、たまに話をしていても通じないときがあります。 それくらいアジャイルという言葉が広く知られるようになったんだと思う一方で、かえって話が通じなくて、もどかしく感じることもあります。だからといって、そこで「正しいアジャイルとは」みたいな議論をしたい訳でもないのです。 広まれば広まるほど、そういった言葉の認識の齟齬が出るのは仕方ないですね。その正しい定義みたいなところを追求するのもナンセンスなので、そんなつもりはないですが、ただ自分がどう考えているかについては書いておいても良いかな、と考えました。ここは私のブログですしね。 そこで、この記事では、私の考えるアジャイル開発の本質について、そしてウォーターフォールとの違いについて書きました。 アジャイル開発では機能を全部つくらない これまで私の中で、アジャイルと言えば当たり前の前提がありました。それは
実践的な設計って、なんだろう？
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計Read less
迷ったら狩野さん！...狩野分析法による優先度付け - masayangの日記（ピスト通勤他
追記 id:discypusさんから、狩野分析法の出典に関するコメントをいただきました。 狩野法って、 狩野 紀昭 氏 http://www.sangakuplaza.jp/page/134499 の http://www.yahoo-vi.co.jp/method/b10.html の手法かと 思うのですが、合ってますでしょうか？ まさにこれですね。http://www.yahoo-vi.co.jp/method/b10.html にある日本語のほうがすっきりしてます。 お詫び 分析用配列に誤りがありました。修正してあります。 要旨 先日受講したScrum Product Owner Trainingで印象に残った分析法を紹介。 Agile開発では「優先度順に要件（フィーチャ）を開発していく」のが基本だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的
超高速開発はスクラッチ開発の3倍から10倍の開発効率が条件、競合するベンダ13社が利害を超えて「超高速開発コミュニティ」を設立
ソースコードの自動生成やカスタマイズ、ビジュアルプログラミングなど、スクラッチからプログラミングにより開発するよりも短期間で容易にシステム開発を実現するツールや開発手法を持つベンダが13社集まり、「超高速開発コミュニティ」を結成しました。 コミュニティが目指すのは、ユーザーに対してこれら「超高速開発」を名乗るツールの浸透をはかり、使ってもらうこと。「ユーザー企業がITをベンダに丸投げするシステム開発から脱却する道筋が描けるのではないかと期待している」（コミュニティ会長の関隆明氏）。また、これまでシステム開発に参入していなかった上流プロセスのコンサルタントがシステム開発に参入することなども期待しているとのこと。 コミュニティはこれからユーザー企業の参加を積極的に呼びかけ、当面200社の参加が目標。超高速開発を自社の強みにしたいと考えるSIerなどの参加も想定しています。 活動として予定されて
アジャイルがダメだと思う7つの理由 - arclamp
1.全体スケジュールにコミットできない アジャイルはタイムボックス型（一定期間で棚卸しをして、それを繰り返す）のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ
アジャイルがそんなにダメだと思わない7つの理由 - haradakiro's blog
鈴木雄介さんが、「アジャイルがダメだと思う7つの理由」というすごいブログを書いてくれたので、がんばって返答を書いてみる。どこかでディスカッションできるといいなぁ。 1. 全体スケジュールにコミットできない コミットメントって何だろう。コミットメントは約束なのか。約束であったら、破った場合のペナルティも受け入れるのか？受け入れたところでバッファが巨大になるだけではないのか？そして、そのバッファは見えないところで食い尽くされる。 全体を見えずに計画したところでうまくいくはずはない。アジャイルがタイムボックスで計画、実施を行うからといって、全体を計画しないわけではない。むしろ積極的にやるべきである。 全体を計画する上では、なるべく漏れがないように、実施可能なように最大限の努力をする。ただ、それに時間を掛けすぎるのは無駄だ。そして、神ならぬ人間が計画するのであるから、以下を認めなければならない。
アジャイルがダメなようでダメじゃないちょっとだけダメだと思う7つの理由 - @ledsun blog
素晴らしいエントリが立て続けに出ているので便乗します。 id:arclampさんのアジャイルがダメだと思う7つの理由 id:haradakiroさんのアジャイルがそんなにダメだと思わない7つの理由 1.全体スケジュールにコミットできない 主語を間違えやすいけど 経営者は顧客やVCと全体の計画にコミットしなきゃいけない の通りで全体スケジュールにコミットできるのはスポンサーだけなんです。開発者は「努力すること」しかコミットできません*1。 現実問題として、プロジェクトを上手くスタートするにはゴールをいつまでに何かって決める必要があります。アジャイル開発でも重視している。アジャイルサムライはインセプションデッキにかなりのページ数を割いています。 2. アーキテクチャ上の無駄が生じる アーキテクチャ設計を慎重に考えても元のビジネスモデルがウンコだったら役に立ちません。困ったことにビジネスモデルは
DeNA流Scrumとcommのチームビルディング
Scrum Alliance Regional Gathering Tokyo2013でDeNA貝瀬、高坂、坪田が発表した際の資料です。Read less
アジャイルコーチって何するの？
みなさんこんにちは。@ryuzeeです。 InfoQに“アジャイルコーチ” とは何か という記事があったので、アジャイルコーチとして活動している僕が普段どんなことをやっているのか説明したいと思います。 オンラインでのコミュニケーションTwitterやFacebook、そしてこのサイトからアジャイルに取り組んでいる方や、これから取り組みをはじめようとする方からよくご質問を頂きます。 コーチとしては、実践する上でどういうことに困っているかを色々と知ることができるので大変ありがたいです。 特に金銭のやりとりはありませんが、コーチとして責任をもった回答をする必要があると思っているので、文献や海外のサイトや海外の著名トレーナーの資料などを参照しつつ自分の見解も交えて回答させて頂いているつもりです。 質問は回答をうける側よりも、回答する側のトレーニングになると思っています。 質問頂いた内容は、一般化し
アジャイルプログラマーに必要なスキルセットのお話（Ultimate Agilist Tokyo) - メソッド屋のブログ
Ultimate Agilist Tokyo 昨日はUltimate Agilist Tokyoというイベントでしゃべてきました。@papandaの見事なスライドと講演、@kuranukiさんのセッションの死ぬほどの面白さと刺激、@haradahikoの講演のNo Bull Know How というセッションどれを見ても面白いものでした。 No-Bull Know-How この形式の発表ははじめて見たのですが、面白い。原田さんが、皆に向かって話をするのではなく、あくまで１人に対して、その１人の問題を解決する為の質問をするのをその他大勢で観察するというスタイルです。この形式のいいのは、コンテキストによるという話が要らなくなるので、より深い話が出来るところです。この短い時間のなかでいろんな気づきを匠に引き出す原田さんのテクはさすがです。にやりとしてしまいましたわ。 さて、このブログは私の講演の
『たのしい開発 スタートアップRuby』――なぜRubyistたちはあれほど楽しそうなのか：晴読雨読＠エンジニアライフ：エンジニアライフ
たのしい開発 スタートアップRuby 大場寧子、大場光一郎、五十嵐邦明、櫻井達生（著） 技術評論社 2012年7月 ISBN-10: 4774151661 ISBN-13: 978-4774151663 2604 円（税込） ■なぜRubyistに惹かれたのか Rubyへの心変わりは誰の影響だっただろうか。 業務と関係なければ、勉強しなくていいと思っていたはずだった。アジャイル系コミュニティに参加したしばらくあと、地域Rubyコミュニティに迷い込み、いつしか彼らと楽しくお酒を飲むようになっていた。 アジャイル系コミュニティの人々が仕事について・技術について話している姿は楽しそうだった。 彼らはRubyistでもあった。彼らの姿に惹かれ、僕もRubyを学び始めた。 そうして門を叩いた地域Rubyコミュニティの人々も、アジャイル系コミュニティと同様に、技術について話している姿は輝いていた。 そ
Shibu's Diary: アジャイルの「ア」は合気道の「ア」
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 taken by denisko under CC BY-NC-SA 今年はサンフランシスコにいて、かつ先月子供が生まれたばかりということもあって、日本にふらっと行ってXP祭り2012に参加することができないので、今年はビデオレターで出演することになりました。僕が考えるアジャイルの核について話をします。ビデオレターって反応がないから難しいですね。なにか間違ったことを言ってしまって(たぶん色々間違っている)も「あ、今間違えました」って気付けない。ビデオレター達人になるにはどうすればいいんでしょうね？手元のNikon D3100+NIKKOR 35mmでFull HDで動画を撮ってみたので、絵は綺麗に撮れたと思いますが、なんか声が小さそうなのでブログにも書きます。XP祭り参加する方
翻訳 アジャイル関連書籍ベスト100(2012年度版)
来年1月に行われるScrum Regional Gathering Tokyo 2013で基調講演をしていただく予定のJurgen Appelo氏による2012年度版のアジャイル関連書籍ベスト100に邦訳書籍の情報を加えました。書籍選びの参考までに。 なお、リストに入っていて本年新たに訳された本は、リーンスタートアップ、Clean Coder(@kdmsnrさん翻訳)、継続的デリバリー(和智さん、高木さん翻訳)、アジャイルなゲーム開発(@ebacky_jaさん翻訳)、アジャイルソフトウェアエンジニアリング(@tomohnさん監訳)だと思われます。Specification by Exampleとかは是非訳されると良いですねー。Management3.0は進んでいるという噂があるとかないとか。 それからJurgen氏といえば、How to Change the Worldという組織に関する短
スタートアップにおけるソフトウェア開発の無駄をなくす大事な３つの考えかた | Social Change!
資金も人も少ないスタートアップが大手企業に勝つためには、大手と同じことをしていては勝つことができません。大手にできないことをしてこそスタートアップは生き残ることが出来るはずです。もし仮に投資を受けて大手のような振る舞いをしたところで、そもそも基礎的な体力は違う訳で息切れしてしまうことは目に見えています。 大手企業とスタートアップの大きな違いは、大手企業は資金や人を沢山もちすぎているということです。それは正面から戦ったら強みになるでしょうが、新規事業においては弱点にもなりえるのです。 沢山の人や資金を動かすとしたら、必ず無駄が産まれます。長過ぎる会議や総花的な意見まとめなど大企業のオペレーションには多くの無駄があります。小さくて小回りの利くスタートアップが同じように振る舞う必要はありません。 ITを活用するスタートアップにおいて、ソフトウェアを作るという文脈の中でも、大手企業とは違う戦略を採
NTTデータのアジャイルは現場への警告であり、日本のソフトウェア産業の大きな1歩である | Act as Professional
アジャイルソフトウェア開発はキャズムを超えたと言われてもピンと来てなかったけど、本当に超えたと僕が実感でき日も近いのではないかと思う@HIROCASTERでございませう。 「キャズム」という意味は、先進的な人と一般的な人との間にある隔壁のことです。 つまり、一部で活発になってきているアジャイルソフトウェア開発が一般的になってきているということ。 システムインテグレータ大手のNTTデータが下記の発表をしたことについて、思うことを書いておきたい。 若手リーダー層を対象としたアジャイル開発研修を開始 会社としての姿勢これまで欧米を中心に普及してきたアジャイル開発は、米国IT企業のソフトウエア開発における採用率で30%を超えるなど、欧米では最も利用されている開発手法となっています。昨今では、日本国内でも、Webサービス業界やゲーム開発業界などを中心に多くの開発事例が見られるようになってきましたが、
システムを育てるカイゼン型開発のススメ〜SonicGardenでカイゼン型開発を行う理由 | Social Change!
日経SYSTEMS 2012年4月号の特集１が「システムを育てるカイゼン型開発のススメ」ということで、Part4に私も寄稿させて頂きました。ソニックガーデンが今のビジネスモデルを採用した理由について書きました。 「カイゼン型開発」という言葉は、2006年に私がブログで書いたのですが、ようやく時代が追いついてきたのかと感慨深いものがあります。そして、2012年の私たちは既にそこからさらに先に進んでいて、その答えとなる「納品のない受託開発」というビジネスモデルに辿り着いています。 実際に掲載された寄稿記事の方では割とコンパクトにまとめてもらいましたが、こちらではディレクターズカットということで元々に書いた原稿の方を公開します。もし、このブログよりもさっと読みたい場合は日経SYSTEMSを読んで頂くのが良いかと思います。 ソニックガーデンでは「納品のない受託開発」という少し変わったスタイルでの受
Agileな開発からAgileな組織へ #aj21 #b2
This document contains links and snippets of text on various Agile topics including Scrum, continuous delivery, iterative development, inspection and adaptation. It discusses priorities of satisfying customers through early and frequent delivery of valuable software. It also includes questions about release cycles and mentions that organizations tend to design systems that mirror their own communi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
