5分で分かるアジャイルムーブメントの歴史 拡大版今回の「XP祭り in 関西」のテーマは「アジャイル15周年ふりかえり」。 ブログ記事『5分で分かるアジャイルムーブメントの歴史』 ( http://fkino.net/20141014.html ) を手がかりに、アジャイルムーブメントに関連する人や書籍に注目しながら、アジャイルムーブメントの歴史を辿ります。
Startupプログラマの為の新アジャイルマニュフェスト(Kent Beck: beyond agile programming) - Qiita
Startupプログラマの為の新アジャイルマニュフェスト(Kent Beck: beyond agile programming)agilelean はじめに Kent Beck氏がスタートアップのイベントに登壇し、素晴らしい講演をしたビデオを友人のタイムラインから見つけました。Startup Lessons Learnd: Kent Beck talks beyond agile programming アジャイルマニュフェストは10年が経過して、誰かの為にソフトウェアを作っていた時代から、スタートアップの時代に移行し、内容が一部古くなっていました。ところがこの講演でKentBeck氏は、それに対する素晴らしい回答をしてくれています。この内容が2010に行われているとは驚きです。 今回、このビデオを未熟なりにディクテーションして、適当ですが、日本語訳を作ってみました。本人に承認を取るつも
監訳者まえがき
「アジャイルソフトウェア開発の概要はわかったので、具体的な事例を知りたい」 アジャイル開発をテーマにした講演や研修に出かけていくと、この質問によく出会います。さまざまな立場の人たちと長らくこの問答を続けることで、わかってきたことがあります。それは、ひとくちに「事例」といっても、質問者が知りたいことは「プロジェクト実績」や「実際に起こった個々の出来事」に留まらないということです。この問いに込められている、質問者が本当に知りたいことを私なりに書き下せば次のような感じです。 日々のソフトウェア開発の現場で、 実際に起きる個々の出来事について、 アジャイル開発の知識を踏まえたうえで、 自分は都度、どのような意思決定を下していけばよいのか？ この質問の核心は「未体験のことへの不安」だと私は捉えています。リーン原則は開発プロセスについてのメンタルモデルであり、カンバンはワークフローの設計ツールです。ス
アジャイルを学ぶの巻 | いきあたりばったり
アジャイル・・あじゃいる・・agile・・ IT業界に身を置いてると意識せずとも聞こえてくるWord・・ 形容詞なのに、ちまたでは、動詞や名詞として使われがちです・・ そして勤めているSIerではアジャイルは禁止されています。 これまでアジャイルな開発(でも実態はそもそも最初から入札、請負契約というアジャイル風だった…)に手を出しては、もはや顧客の奴隷のようになり、赤字という顛末のPJが多かったからです (｡´Д⊂) ｳﾜｧｧｧﾝ このツイートが身に染みる、そんな状況です。 なのでスキーム変えられないうちは「禁止」という判断は正しい気がします。 最近とても勉強になってるんですが、ウォーターフォールのスキームの一部にアジャイルいれても赤字になるのです、黒字にしたいならスキーム変えないとだめなのよ — Yasuko Ohbaさん (@nay3) 2013年4月25日 でもやっぱり気になっていた
最強のIT系かあちゃんからたかしへのアドバイス
ぎゃばん -1.0 @ledsun たかしへ あなたの勤怠確認しました．こんなに残業が多い割に大して売上が上がってないのはどうしてですか？顧客との信頼関係の構築も甘いとと思います．来月からは頑張って下さい．ちなみに母さんは今月、10人月で作ったシステムを3000万で売ってきました。 2012-02-24 13:21:23 ぎゃばん -1.0 @ledsun たかしへ あなたの立てたスケジュール読みました。作成工数だけでバッファがありません。予想外の事態が起きた時はどうするのですか？残業でカバーですか？お客様が参加するイベントが入っていません。都度調整ですか？事前に提示していないと都合がつかなくても納期延長できませんが大丈夫ですか？ 2012-02-24 13:46:29 ぎゃばん -1.0 @ledsun たかしへ あなたの作った機能仕様書読みました。技術的面ではチャレンジグで素晴らしかっ
プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン
Sharing OptionsShare on Facebook, opens a new window
アジャイル開発の反対はウォーターフォール開発じゃなくて「おまかせ」だと思う - 思っているよりもずっとずっと人生は短い。
メモ。 アジャイルとウォーターフォールを対比させるのは違和感があった。ので、少し考えてみた。 アジャイルソフトウェア開発宣言にある「包括的なドキュメント」とか「契約交渉」とか「計画に従う」とかと、「対話」「顧客との協調」「変化への対応」とかは、わりとばらばらなお題目が並んでいるように見える。少なくともこれがMECEだと思う人はいないと思う。 ばらばら並んでいる項目の共通点、類似点は何か。それはたぶん、「顧客」と「開発者」という2つのロールを仮定して、そのロールの人同士の間でのコミュニケーションコストを最大化する（という言い方が悪ければ「最大限許容する」と言い換えてもいい）というものだろう。文書や契約や計画は、あらかじめ（多少はコストをかけて）まとめておけば、それ以降のコミュニケーションは省略できる（ような気になる）、というものだろう。ツール・プロセスも同様だ。一方で、個人や対話、顧客との協
アジャイル開発を、人はどのようにして学ぶのか。アジャイルの第一人者、平鍋さんに聞いた
「アジャイル開発は、実は本を読んで理解するのがとても難しい」。9月4日に、有志によるアジャイル開発のイベントの基調講演「アジャイル開発の現在・過去・未来」の中で、アジャイルの第一人者であるチェンジビジョン代表取締役社長の平鍋健児氏はこう発言しました。 本を読んで理解するのが難しいのだとすると、アジャイル開発はどのようにして学んでいくのがいいのでしょうか？ 平鍋さんが伝えようとしたことを詳しく聞くために、メールインタビューをしました。 自分で考えることが本質 先日のXP祭りで平鍋さんの講演を聞いたとき、「アジャイルは人づてに伝わっていく」という部分が印象に残りました。また、「アジャイルは、実は本を読んで理解するのがとても難しい」ともおっしゃっていました。とはいえ、アジャイル開発を本や講演などから学び始める人も多いはずです。そういう方々にアジャイルをどう学ぶのがいいのか、というアドバイスを届け
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
7462
大きなチーム、大きな仕事 ~ 大規模アジャイル開発のいま
クライアントの要望にこたえるWebサービス開発 ～「らせん型ワークフロー」のススメ～
オンラインゲーム開発におけるアジャイルなチームビルディングの具体的手法 20110906