なぜいま、アジャイルなのか？ トークライブ（録画）『わかりやすいアジャイル開発の教科書』（ソフトバンク クリエイティブ刊）の出版記念トークイベント（2013年4月19日開催）を録画でお届けします。 このイベントでは、同書籍の著者である3名のゲスト（前川直也さん、西河誠さん、細谷泰夫さん）をお迎えして、今なぜアジャイル開発が注目されているのか、といったテーマを皮切りに、約1時間のトークが繰り広げられました。 ※機械トラブルにより、10分45秒すぎ以降は、静止画＋音声にてお送りします。
情報処理推進機構：ソフトウェア・エンジニアリング ｢アジャイル型開発におけるプラクティス活用事例調査｣の報告書とリファレンスガイドを公開
2013年3月19日公開 独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター 概要 インターネット販売サイトやSNS(ソーシャルネットワークサービス)等のシステムでは、その構築において要件のすべてが明確にならなくても開発に着手し、要件の明確化や変更には開発と並行して対応します。それは、いかに早くサービスを提供するかに、ビジネスの命運がかかっているからです。 こうした要件の変化に柔軟に対応できる開発手法として、「アジャイル型開発」があります。これは、ビジネス上の優先度が高い順に、短いサイクルで機能単位の開発を繰り返す手法です。 このアジャイル型開発手法は自社開発（内製）が中心の米国で発展したものであり、要件を決めて外部に開発を委託することが多い等、受発注環境が異なる日本でアジャイル型開発を適用するのは難しいと考えられています(*1)。 「アジャイル型開発」には、
アジャイルがダメだと思う7つの理由 - arclamp
1.全体スケジュールにコミットできない アジャイルはタイムボックス型（一定期間で棚卸しをして、それを繰り返す）のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ
アジャイルをダメにしないためにすべきこと - arclamp
「アジャイルがダメだと思う7つの理由」をエントリしてから一週間が経ちました。まさかPublickeyにまとめが載るとは思いませんでしたよ。 内幕を正直に書くと、あの日の昼に「アジャイルも普及してきて妙に執着する人が増えたよね」と茶飲み話していており、それを「受託開発に真面目に取り組むマネージャーが、知り合いでアジャイルにハマった人に久しぶりに出会って『時代はアジャイル』と熱くねちねちと語られているうちに、どうにも納得できなくてキレた」という設定で書いたものです。刺激的な表現もあってお騒がせしました。 反応していただいたBlogは「アジャイルがダメだと思う7つの理由」に追記してあります。その他の反応ははてブでも見てもらえればと思います。 職業アジャイラーの皆様からは同意と反論が混ざった反応をいただいております。ご意見がある方は引き続きBlogで書いて頂ければ幸いです。あのエントリは仮想人格が
「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ
「アジャイルがダメだと思う7つの理由」という刺激的なタイトルのエントリを、先週木曜日、3月21日にグロースエクスパートナーズの鈴木雄介氏が公開してから、アジャイル開発に関する議論の波紋が広がっています。 おそらく、これだけさまざまなブログを通じてアジャイル開発の議論が活発化したことはこれまで国内ではなかったのではないでしょうか？ ここでは現時点での議論をまとめますが、興味のある方はぜひここを起点にそれぞれのエントリを読んでみていただきたいと思います。 発端は鈴木雄介氏（id:arclamp）のブログarclampにポストされた「アジャイルがダメだと思う7つの理由」というエントリ。以下がその7つの理由として挙げられたものです。 1.全体スケジュールにコミットできない 2.アーキテクチャ上の無駄が生じる 3.コーチって何だよ 4.変化ヲ抱擁スルために固定化している 5.実証主義的な説明に過ぎな
カンバンを導入する正しい理由5個
みなさんこんにちは。@ryuzeeです。 前回の投稿の続きです。 今度はMichael Dubakov氏が5 Right Reasons to Apply Kanbanということで、正しい導入理由5個について説明していますので、抜粋・意訳にてご紹介します。 カンバンを導入する正しい理由5個 1. いつでもリリースできるようにするスクラムやXPではイテレーションの途中でリリースすることはできない。 カンバンであればいつでもリリースできるかもしれない。 ユーザーストーリーの準備ができたたら、それをリリースする。 このような開発プロセスを作ることは挑戦的だろう。 このような開発プロセスでは、フィーチャー単位でソースコードレポジトリのブランチを管理し、頻繁にマージや結合やテストを行う必要がある。 ただこうすることで頻繁にリリースすることができるようになるのだ。 これはやってみる価値がある。 プロダ
Agile Conference tokyo 2011に参加してきた #agiletokyo - Diary of absj31
Agile Conference tokyo 2011 - イベントTOP 直前の台風6号が本土上陸、関東直撃か？と言った不安はありましたが、幸い台風は進路を反らし、関東にも上陸する事無く不安は取り除かれ、無事開催会場にも着く事が出来ました。 開催会場は周りを住宅街に囲まれたとても庶民的な(？)風景の中にある江東区文化センター。 Togetterまとめ Togetter - 「Agile Conference Tokyo 2011 まとめ（Ver.3000）」 Togetter - 「Agile Conference Tokyo 2011 マーティン・ファウラー氏の基調講演 #agiletokyo」 Togetter - 「Agile Conference Tokyo 2011 午後 Jez Humble氏の講演 #agiletokyo」 その他参戦レポート Agile Conferenc
オープンソースScrum支援ツールの機能比較
Comparing Open Source Agile Project Management Toolsより抜粋して適当訳。(スクリーンショットは引用元を参照のこと) 僕はAgiloで十分なんだけど、機能比較やスクリーンショットを見るとIceScrumもなかなか良さそう(今日インストールして触ってみたけど、こりゃだめだ。UIが日本人に向いてない)。有償の製品(Rational Team Concert)とかも比較したい。 ちなみに先日Certified Scrum Master研修に行ったんだけど、講師のお勧めはツールを使わないことらしい。ツールを使ってうまくいった事例を聞いたことがない、というのがその理由らしいんだけど、個人的には、だとすれば、講師が「俺だったらこう作る。それならうまくいくぜ！」みたいなのは言ってほしかった。どうやっても関係者が一堂に揃わない環境でやっているので、分散の弊
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スクラムマスタはフルタイムで行う役割か - スクラムマスタ宣言の結論は「YES 」