「アジャイルがダメだと思う7つの理由」をエントリしてから一週間が経ちました。まさかPublickeyにまとめが載るとは思いませんでしたよ。 内幕を正直に書くと、あの日の昼に「アジャイルも普及してきて妙に執着する人が増えたよね」と茶飲み話していており、それを「受託開発に真面目に取り組むマネージャーが、知り合いでアジャイルにハマった人に久しぶりに出会って『時代はアジャイル』と熱くねちねちと語られているうちに、どうにも納得できなくてキレた」という設定で書いたものです。刺激的な表現もあってお騒がせしました。 反応していただいたBlogは「アジャイルがダメだと思う7つの理由」に追記してあります。その他の反応ははてブでも見てもらえればと思います。 職業アジャイラーの皆様からは同意と反論が混ざった反応をいただいております。ご意見がある方は引き続きBlogで書いて頂ければ幸いです。あのエントリは仮想人格が
以下、３部作の１本目です。 ウォーターフォール開発とアジャイルの本質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ 度々話題なる開発手法、ウォーターフォール開発（以下WF）とアジャイル。 それぞれの違いってなんだろうと思い、ちょっと本質について普段考えていることをまとめてみました。 ウォーターフォール開発の本質とはなにか？ システム開発を行った方なら一度は耳にすることがあるWF。 各開発工程を順序良くこなしていく開発手法となります。 イメージにすると以下のとおり。 さて、WFのよく言われる特徴を以下眺めてみたいと思います。 最初に一括して要件定義を行うので、仕様変更に弱い No。一括して要件定義を行うこと自体は、要件定義のやり方の問題です。一括
『アジャイルサムライ－達人開発者への道－』に続いて、アジャイル開発のバイブル的書籍『SCRUM BOOT CAMP』を読みました。SCRUMの実践的な知識を漫画をおりまぜながら、本当にわかりやすく書いている良本でした。これから何度も読み直して、アジャイルの習得に努めます！ ということで、今回は書籍を読む過程で集めたSCRUMやアジャイル開発に関するスライドやPDF、ブログ記事などをまとめていきます！ 🗽 アジャイル開発手法特論 From Agile-development-course-advanced-1-2 産業技術大学の2013年2Qの講義『アジャイル開発手法特論』の資料だそうです。SCRUM BOOT CAMPの著者の一人であるながせ☆みほさんの作です。ちなみにながせさんのブログ上に#6までの資料がアップされています。ほかのスライドもかなりのボリュームで読み応え抜群です！ 😀
短納期・低コストのソフトウエア開発プロセスとして注目を集める「アジャイル型プロセス」。取り組みが広がる一方で，アジャイル独特の考え方に疑問を抱くエンジニアも多い。本講座の目的は，アジャイルの基礎から具体的な実践手法までを理解してもらうことにある。Part1ではアジャイル登場の背景や狙いを解説する。 「それは要件定義書に記載されていません」。 システム開発の現場で，よく発せられるフレーズである。筆者自身，これまで何度このフレーズをユーザーに対して言ってきたことだろう。 情報システム開発に仕様の追加・変更は付き物であり，変更を要求するユーザー側にも，それなりの理由がある。もちろん対応できるものもあるが，予算や納期を考えると到底実現は不可能と思える追加要求も少なくない。 あまりに要求が理不尽なときは，要件定義書を“逃げ道”にして，追加開発を断ることもある。しかし，たいていの場合は冒頭の言葉を発し
アジャイル開発を日本風にアレンジしたプロセスをマネジメント・デザインパターンとして説明した記事があったのでメモ。 【参考】 ウォーターフォール開発とアジャイルの本質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ 【1】WF型開発とアジャイル開発には、それぞれの特徴があり、適用の問題点がある。 WF型開発は、仕様変更に弱く、無駄なドキュメントが多い。 アジャイル開発は、変化に強く、スピード重視で開発できるが、従来のプロセス手法と発想を変えないといけないので、実現しづらい。 上記の記事によれば、各プロセスの特徴は、「WFが形式知の作成を行うことで、開発体制と開発工程を管理する手法」「(アジャイル開発は)フォーカス管理の最適化」。 つまり、WF型開発
ウォーターフォール開発とアジャイルの本質 - プロマネブログ 以下、３部作の２本目です。 ウォーターフォール開発とアジャイルの本質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ 前回と今回のシリーズはカテゴリ プロジェクトマネジメント論にまとめてます。 単一の開発手法の限界からハイブリッド方式へ 前回、各開発手法は失敗プロジェクトの反省から、それぞれ本質となる改善要素を持つことを示しました。 ウォーターフォール開発（以下WF）であれば、形式知化。 アジャイル開発であれば、フォーカス分割。 これらは排反する概念ではなく、それぞれの利点を活かしてプロジェクト運営を行うことが、より効率的なプロジェクト運営につながると考えられます。 とはいえ、ハイブリ
ウォータースクラムフォールは「アジャイル風」 第15回アジャイルラジオによると、ウォータースクラムフォールと言うものがあり、ソフトウェア開発のプロセス全体はウォーターフォール（以下WF）で、製造工程だけスクラムで実施するプロセスがあるそうです。 この方法は上流で仕様を固定する、あるいは、一定の予備工数を取っておいて、仕様変更に対応するようです。製造工程は繰り返し開発なので、フレームワークやOSに想定していなかった問題が生じれば対応できると思われます。 しかし、それは製造時（コーディング＆単体テスト）のリスクであり、スコープは変更されないと思われます。予備工数がある場合は、その範囲で仕様変更に対応できますが、それは追加するだけで（交渉の余地があるものの）当初の仕様は全て実装されるのでしょう。 これを「アジャイル風」と言うらしいです。確かに私がUAS2で私が書いた「アジャイル風」と同じ様にアジ
![[#TiDD]ウォータースクラムフォールよりも五月雨WFの方が変化に強い！(かも) - ソフトウェアさかば](https://cdn-ak-scissors.b.st-hatena.com/image/square/78ea07849c11c8d6cedfecab7a00046a98019ac9/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttp%2Fsakaba.cocolog-nifty.com%2Fphotos%2Funcategorized%2F2013%2F02%2F24%2Fagilelikewf.png)
アジャイルがダメだらしい “全体スケジュールにコミットできない”とか“アーキテクチャ上の無駄が生じる”とかの理由でアジャイルがダメらしい。その上で、次の議論をなどと提言されているけれど、ちょっと違うことを思った。 プロジェクトマネージメントの界隈で生きているものとしては、実際、システム開発方法論なんてなんでもいい。プロジェクトが成功するためのやり方のヒントが欲しいだ。 誰かにアレがいい、コレがいいといわれたから鵜呑みにしてやるもんじゃない。プロジェクトを成功させたいからそのツールとして方法論を枠組みとして使うのであって、アジャイル(具体的にはスクラム)やウォーターフォールなんて空っぽで、現場で必要なのは空っぽの枠組みであるフレームワークを埋める実作業でのツールまでなければ、全く用を成さないんだ。 現実は厳しい 現実は厳しいよ。ウォーターフォールでもスクラムでも失敗するプロジェクトは失敗する
なぜアジャイルなのですか？改めて考察するウォーターフォールとの違いに参加してきました。 ウォーターフォール（以下WF）はよくDisらr・・・アジャイルと比較されます。 私もアジャイル開発を知るまでそうではない開発を経験したことがありますが、おそらくそれらはWF開発をしていたわけではなく、WFのようななにかに過ぎなかったと思います。 だから、ちゃんとしたWFについても勉強したいなーと考えていたのでとてもいい機会になりました。 株式会社ジャムズを経営されている玉牧 陽一さんのご講演のポイントをまとめます。 詳細については下記SlideShareをぜひご覧ください。 なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い WFの原点に関わる流れ 1970年 Managing the Development of Software Systems via Winston Royce W
ISACA大阪支部１０月度月例会でお話しさせていただいた内容です。 開催要項はこちら。 http://www.isaca-osaka.org/info/isacay1210.htmRead less
わたしはまだ本格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い（プロジェクトマネージャーの立場で、スクラムマスター的に推進）。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。 アジャイルの前のほうが楽だった？ 「第5回 TFSUG：ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。 http://kaorun55.hatenablog.jp/entry/2012/04/17/001312 第5回TFSUG WFからAgile
今週は、野中郁次郎氏とジェフ・サザーランド氏というアジャイル開発手法「スクラム」の生みの親2人が基調講演を行った歴史的イベント「Innovation Sprint 2011」のレポートを2本公開し、たくさんの方に記事を読んでもらうことができました。 スクラムの生みの親が語る、スクラムとはなにか？ たえず不安定で、自己組織化し、全員が多能工である ～ Innovation Sprint 2011（前編） 重要なテクノロジーは10名以下のチームで作られた ～ Innovation Sprint 2011（後編） この記事きっかけに「スクラム」に興味を持ったという読者もおられたようで、そんな方のために（かどうかは分かりませんが：-）、「Innovation Sprint 2011」の実行委員長だった川口恭伸氏が「10分でスクラム」というスライドを公開しました。
今回の記事では, プロジェクト管理に特化したアジャイル開発手法であるスクラムの概要を説明します. また, スクラムによる開発が成功する理由を説明するための理論的なバックボーンとして引用されている知識創造プロセスやコンテキストの概要を紹介します. さらに, 20 名程度の中規模開発チームにおいてスクラムを適用し, 開発に成功した事例を紹介し, その中で知識創造プロセスやコンテキストが生まれたのか否かについて考察します. 1. スクラムとは 1.1 スクラムの価値と理論的な基盤 スクラム [1] は, Ken Schwaber と Mike Beedle によって考案されたアジャイル開発手法です. スクラムという開発方法論の名称は, ラグビーのスクラムにちなんで名づけられたそうです. スクラムは、Schwaber らがいくつかの失敗プロジェクトを立て直す経験を通じて生み出されたとされています.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
