「ウォータフォールは何のメリットも無い」のラジオ番組の公開 - メソッド屋のブログおかげさまでたくさん読んでいただいたブログですが、この内容について聞いてみたいということで先日アジャイルラジオという番組の収録を行いました。 simplearchitect.hatenablog.com 前半、後半になっています。私の意図していることなどについて、自分の声でお話しさせていただきました。 よかったらお楽しみください。 agileradio.github.io agileradio.github.io
日本でアジャイルが流行らない理由 - @ledsun blog
ポジション的なもの 個人的に、アジャイルは「（あんまり未来や遠くのことを考えるのをやめて）目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは？ と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ
アジャイルの破綻―原因、そして新たな提案 | POSTD
2001年、17人のメンバーによって アジャイル宣言 が発表されました。私はその立案者そして著者の1人であることに誇りを感じます。この出来事は、何かをする上でより良い方法を導き出すことへの期待、そしてソフトウェアを開発することで世界をより良くするといった、私自身の活力の源となり、極めて重要なターニング・ポイントとなりました。 あれから14年が経ち、私たちは行き先を見失っています。”アジャイル”という言葉はスローガン化してしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまったとすら言えます。2～3のソフトウェア開発のプラクティスを、不十分に生半可に試みるといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重ねるといった、口先だけのアジャイルの 狂信者 がたくさんいるのです。 更にひどいのは、アジャイル開発手法その
転職して感じたウォーターフォール文化とアジャイル文化の違いについて - 達人プログラマーを目指して
今月から新しい会社に転職して、あっという間に半月が過ぎてしまいました。いろいろな会社の規則や、開発環境、フレームワーク、仕事の進め方など、とにかくたくさんのことを短期間で詰め込む必要があり、もともと想定していたことではありますが自分としてはかなりたいへんでした。 やはり、自分としては、外資系の会社で英語でのコミュニケーションが必要となるということが、最も気がかりなことでした。実際、初日の歓迎ランチはいきなり名前もわからない多くの外国人に囲まれる状況でしたし、電話会議を使って中国やアメリカのチームと一緒に行う日々の進捗ミーティングも英語で行われています。自分としては、特に、リスニングが苦手ということもあり、いまだに完全に会話についていくのが困難なところはありますが、同僚やマネージャーもみんなすごく親切に教えてくれるので安心しました。私は新しい環境に慣れるのに結構時間がかかる方なので、まだまだ
ストーリーベースのアジャイル開発に。Railsのプロジェクト管理·Fulcrum MOONGIFT
Fulcrumはストーリーベースのアジャイル開発にマッチしたプロジェクト管理システム。 FulcrumはRuby on Rails製のオープンソース・ソフトウェア。アジャイル開発において用いられるユーザストーリー。利点としては機能をユーザ視点で捉えることで、実装されるべき機能が明確になりイテレーションが終わった段階できちんとできているか確認がしやすいことだ。 4つの枠が特徴 そのため通常のタスク管理に比べると大ざっぱに見えてしまい、逆に細かな進捗が見づらくなってしまう場合もあるようだ。そんな状態を解決するには、最適なプロジェクト管理を導入することにあるだろう。今回紹介するのはFulcrumだ。 Fulcrumはストーリーベースのタスク管理を実現する、アジャイル開発向けのプロジェクト管理だ。完了したストーリー、作業上、バックログ、Chilly Bin（終わらなかったタスクを放り込んでおく場所
「アジャイル開発」って何がいいの？--アジャイル開発を実案件に生かすための基礎知識
柏木雅之、山下博之 （IPA SEC エンタプライズ系プロジェクト） 2011-05-25 12:00 皆さんは「アジャイル開発」と聞くとどんなイメージを思い浮かべるでしょうか。語源となっている英語の“agile”を辞書で引くと「俊敏な、迅速な」という意味が載っています。そのとおり、刻々と変化する市場の要求、顧客の要求に迅速に対応していくというのが基本的なアジャイル開発のあり方です。 本連載では3回に渡り、アジャイル開発の採用を検討している方々に対して、その基本的な事項を解説していきたいと思っています。本連載によってアジャイル開発への理解を深めていただくきっかけになれば幸いです。 「ウォーターフォール型」の限界 アジャイル開発の説明に入る前に、「ウォーターフォール型開発」について見ていきましょう。 システム開発には納期が伴います。開発サイドは決められた期間内に要求通りの機能を実現し、顧客に
Redmineでアジャイルチームのスピードやパワーを見える化する
burndown chart via kakutani アジャイルなチームを目指す。私がチーム運営を始めたときのポリシーでした。どうやって作業をこなすだけから、アウトプットへの価値へとシフトしていくか？チームの方向を示すためにも、様々なメトリクスやKPIを見える化する必要がありました。 通常のプロジェクト管理方法だと、ガントチャートでロードマップを設定、進捗の状態を管理。WBSなどを作ってそれぞれのタスクを管理・・・といった形が一般的なのでしょうか。しかし、それではワクワクしない。そんな中、常に改善を心がけ、私が試して行き着いた方法を紹介させていただこうとおもいます。 唯一生き残ったプラグイン バーンダウンやタスクボードなど、Redmineのプラグインで様々な見える化をしましたが、ずっとそれを使うことはしませんでした。その中で、最終的に生き残ったのがパーキングロットチャートです。なぜ、これ
アジャイルな見積りと計画づくり：第1部：問題とゴール「１章 計画の目的」まとめ - 基本へ帰ろう
最近は「アジャイルな見積りと計画づくり」を読んでいる。100ページくらい読んで、本に線は引いたけど、いまいち整理出来ていないので、以前読んだ場所を整理していこうと思った。 高校生くらいのころ、好きな本が１冊あって何回も読んでいた。その本には「読んだ本は、自分なりにまとめて読み返せるようにした方が良い」と書いてあった覚えがある。それをやってみよう。 今日は【第1部：問題とゴール「１章 計画の目的」】の理解することにした。ページ数はP25〜P35で10ページ。 目次 計画の目的 なぜ見積りや計画づくりが必要なのか？ リスクを軽減する 不確実性を減らす 意思決定を支援する 信頼を確立する 情報を伝達する 良い計画とはなにか？ アジャイルな「計画づくり」とは？ まとめ 計画の目的 見積りと計画づくりをアジャイルにする手法を紹介していくにあたっては、計画づくりの目的を理解することが重要だ 計画は投資
アジャイル・ブームの再来
はじめに "アジャイル"という言葉が、ソフトウエア開発現場において、広く知られています。皆さんも1度は耳にしたことがあると思います。 筆者は、開発者として、新人時代、社外常駐時代、プロジェクト・リーダー時代に、アジャイル開発に携わりました。本連載では、これらの経験から得たアジャイルの知見を示します。 第1回では、アジャイルの経緯と現状など、事前に知っておくべき内容を説明します。2000年代前半に立ち上がったアジャイルが「試行錯誤の時代」を経て再び注目されるようになった要因について解説します。 アジャイルに共通する4つの価値と12の原則 あらためて、アジャイルとは何かをおさらいします。 アジャイルとは、いくつかのソフトウエア開発手法の総称です。数多くのアジャイル開発手法が存在します。以下は、具体的なアジャイル開発手法の例です。 Agile Modeling Agile Unified Pro
テスト自動化について5分で分かるまとめ
みなさんこんにちは。@ryuzeeです。 テスト自動化について簡単に教えてほしいと言われることが多いので、以下にまとめました。 テスト自動化/テスト駆動開発についてXPのプラクティスの中で、最も単体で導入しやすいプラクティスの１つであるこのプラクティスのみで１冊の本が書けるくらい奥が深い基本的な方法失敗するテストを書くできる限り早く、テストがパスするような最小限のコード本体を書くリファクタリングをする適用範囲通常では、独立性の高いクラスやファンクションへの適用が良いGUIや分散オブジェクト、自動生成されたコード、DBのスキーマに関するテストは導入が難しい既存システムにおいて、テストが準備されていない場合に、部分的に導入するのは難易度が高い。したがって新規プロジェクトの初期から導入することが望ましい問題点開発者が仕様を誤解していた場合、誤解に基づくテストコードが作成されるため、誤解の検知は保
日経ITProの記事にケチつけておく - masayang's diary
日経ITPro: アジャイルはウォーターフォールよりも難しい 何を持って簡単・困難を定義するのかがわからないけど、「アジャイルはウォーターフォールよりもごまかすのが難しい」というのであれば、その通りだろう。 そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。 そもそも大規模プロジェクトを想定して生まれた手法は存在しないわけで。 ウォーターフォールは他に選択肢がなかったために大規模に適用されてきたけど、それが適切だったかはなんとも言えない。失敗しても他に選択肢がないんだから「ウォータフォールが悪い」って言えなかったしね。 ただ、最近は大規模でのAgile事例は増えてきている。日本ではまだ少ない、というところでしょ。 「要求の増加に歯止めが利きにくいアジャイル」というのも変だよね。 当初の一欄に
ObjectClub - アジャイル勘違い集
やる気さえあればできるというのは、ある意味では正しいのですが、盲目にそう信じてしまうと痛い目を見ることになるでしょう。 アジャイルな手法は、変化に対応したり、コミュニケーションをとったり、改善を模索したりという行動を要求します。 そうした行動が苦手な人や嫌いな人は、アジャイル手法が苦痛になってしまうかもしれません。 さらにそういう人はアジャイル手法に対して意識的・無意識的に抵抗して、チーム全体の足を引っ張ることさえあります。 アジャイルに向いた人もいれば、重厚な方法論に向いた人もいます。向き不向きを考えてメンバーを集めるか、 メンバーが固定しているプロジェクトではそのメンバーに向いたやり方を考えたりしましょう。それがプロジェクト成功の早道です。
そもそもアジャイルって何だろう？
Q:あなたは以下のどの理由でアジャイルではないのでしょうか？以下から１つ以上選んでください。 a デイリースタンドアップミーティングしていないb ペアプログラミングをしていないc TDDをしていないd 象徴となるような人を雇用していないe スクラムマスターがいないf イテレーション計画ミーティングをしていないg インデックスカードを使っていない 答えはHで、上のどれでも無いです。 プラクティスは「アジャイルであることを助ける」ための道具であって、それ以上ではありません。 アジリティの意味するところは、頻繁に継続的に顧客のニーズにあった高品質なソフトウェアを届けることができる、ということに他ならないのです。 以下いくつかよくある例や思ったことの補足をしておきます。 RedmineとかTracとかJIRAとかRTCとかTFSみたいなWeb系のアジャイル支援ツール使っている＝アジャイルである、と
マイクロソフトにおけるアジャイル開発はこんな風に進められている － Publickey
マイクロソフトの代表的なソフトウェアは、数千人を超える開発者、数十万のソースコードファイル、数千回ものビルドを繰り返して開発される大規模なものだといわれています。 マイクロソフトのエバンジェリスト長沢智治氏は、こうした大規模な開発プロジェクトがマイクロソフト社内でどのように行われているのか、プロジェクトチームの組成から実施計画、進捗管理、バグレポートなど、その裏側を紹介するセッションをいくつかのイベントで行っています。 そこで明かされている内容は、パッケージソフトの開発だけでなく、SIerでの開発プロジェクトでも参考になる部分が多いと思われ、いつかレポート記事として紹介したいと思っていました。 今回、以前に行われたセッションビデオの存在を長沢氏ご本人から教えていただいたので、開発プロセスに関する部分にフォーカスした記事としてまとめました。 記事での内容は主に、「Microsoft Tech
[コラム] Bent Jensen 来日: アジャイル開発に適した契約 ～ ハイブリッド契約の例 - TDD.NET
先月、 デンマークの BestBrains 社からの視察団が来日されていました。 同社 Director である Bent Jensen 氏のプレゼンからハイブリッド契約方式を少しご紹介します。 BestBrains 社はアジャイル開発のコンサルティングをやっている会社で、 日本のアジャイル開発の現状や製造業を視察するために何度も来日しています。 [2008年] ITmedia オルタナティブ・ブログ: An Agile Way: BestBrains がデンマークから Change Vision に来社 [2009年] fkino diary(2009-08-24): Agile2009セッション紹介 Thursday AM編 ～ "Experiments with Agile Contracts in the Real World" そして今年、 2010年は 4月の第3週から 4週に
![[コラム] Bent Jensen 来日: アジャイル開発に適した契約 ～ ハイブリッド契約の例 - TDD.NET](https://cdn-ak-scissors.b.st-hatena.com/image/square/49580a5f674aa36f66a331dbb78ab28d3dc57e33/height=288;version=1;width=512/http%3A%2F%2Fbluewatersoft.cocolog-nifty.com%2Fphotos%2Funcategorized%2F2010%2F05%2F06%2F20100506_agilecontract01a.png)
私がアジャイルで嫌いな10のこと
みなさんこんにちは。@ryuzeeです。 10 Things I Hate About Agile Development!が良い記事なので、引用・意訳にてご紹介します。 アジャイルに関する誤解がよく分かると思いますので、くれぐれも真似しないようにしてください。 ただデイリースタンドアップミーティングをやっているだけで、「アジャイルをやっている」と言うこと。 別にそれは「アジャイルをやっている」わけではない。 これ以外にアジャイルを実践するためにもっと大事なことがある「アジャイル」の頭文字のAが大文字か小文字かを気にすること。 先頭を大文字で書いたらクールじゃないって言ってるのかな？ 本当の意味での違いは、「アジャイルメソッド」と「アジャイルである」という違いなのだ。 多くの人はたぶんこの微妙な違いを分かっていない。 みんながこの大文字と小文字の違いでもめるようなことは、私にはしゃくに障る
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルサムライの次に読む技術書
その一方で、ウォーターフォールの現場にて開発者が出来ること
アジャイルのまずい考え方
Agile in 30mins - 30分でだいたいわかるアジャイル開発
