Specification by Example is the winner of the 2012 Jolt Award for the best book. This book presents case studies (of over 50 projects) of how successful Lean and Agile teams design, develop, test and deliver software efficiently. Specification By Example is a must read for anyone serious about delivering software that matters. It is the result of a research on how teams all over the world specify,
この本は、近年注目を集めているソフトウェアの開発手法「アジャイル」とその1つである「スクラム」を体系的に、事例をまじえて平易に解説するものです。 さらに、スクラムはソフトウェア開発のみならず、組織や企業活動、企業経営全体にまで適用できることを示し、この手法を取り入れ、ビジネスと一体となってソフトウェアを開発する組織や、その組織に息を吹き込む、新しいタイプのリーダーシップ像について考え、日本企業のリーダーシップと競争力を高めるために必要な、知識創造プロセスの重要性を、あらためて力強く提言する形になっています。 今回は、ソフトウェア開発者はもちろん、ソフトウェア開発をマネジメントする層、ITを利用してビジネスを考える方々、にぜひ届けたい内容になっていて、「縦書き」で書いたものです。日本語ではじめから書かれたスクラムの本を、技術視点だけでなく、経営視点から書きたかった、そして、その視点は野中先生
ソフトウェア開発に「ふりかえり」を導入してチームを成功に導く! 書籍(紙版書籍): 2,400円 + 税 PDF版書籍データ: 1,920円 + 税 コンボパック: 3,600円 + 税
みなさんこんにちは。@ryuzeeです。 よくスクラムで初期見積りってどうやるの?って聞かれますので、思ったことをツラツラと書いておきます。 ちなみに見積りはあたらないので(もちろん当てる努力はしますし、当たった方がいいのは勿論ですが)、そのつもりで考えたほうが良いでしょう。 例えば競馬で一点買いして毎回的中すると思う幸せな人はあまりいませんが、一方で開発の見積りは毎回当たると考えちゃうのはどうかしてるということです。 1. 開発初期に全体を見積もるそもそも一発であたる見積りをするのは不可能であるのは不確実性コーンのグラフ等を見れば分かります。 だからといって見積りをしなくてよいわけではありません。 この時点では、分かっている要求をプロダクトバックログに落として、それぞれのプロダクトバックログアイテムをラフに見積もっておきます。 もしプロダクトバックログがないようであれば、そもそも何のため
ほぼ 3 年ぶりの連載再開です. 3 年前に今回の原稿を書き始めた際にちょっと気負い過ぎて筆が止まり, 忙しさにかまけているうちにあっという間に 3 年間が経ってしまいました. この 3 年間で, 日本ではアジャイル開発への関心がやや停滞していますが, 米国では驚くほど盛り上がっており, 今やウォーターフォール型開発を凌ごうという勢いです. 今年の 9 月に WCSQ (World Congress for Software Quality) という会議でアジャイル開発での設計の実践経験について発表するという機会を頂き, とにかくその発表内容に至るまでに考え, 実践したことを記事に書こうと気を取り直しました. 今回の記事では, ウォーターフォール型開発におけるモデリングの問題点を説明し, さらにアジャイル開発でモデリングを取り入れる 2 つのアプローチを紹介します. 1. ウォーターフォー
The Agile Modeling (AM) Method Effective Strategies for Modeling and Documentation The Agile Modeling Mission To share proven and effective strategies for modeling/mapping and documentation. What is Agile Modeling? Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation. Some important concepts: Model. A model is an abstraction that expresses important aspects
7/25に開催したMeetupで、当日ご参加頂いた、達人出版会の高橋さんより「アジャイルサムライ-達人開発者への道-」というタイトルの書籍を頂戴しました。 ※高橋さんありがとうございました! 本ブログで紹介する記事はどちらかというと「顧客開発モデル」に関連する記事が多く、アジャイル開発に関する情報を提供していなかったのですが、この本は一読して「これは絶対に必読だ!」と強く思いましたのでご紹介しようと思います。 「必読だ!」と思った理由は、本書に書かれていることはまさにリーンスタートアップの実践そのものであり、これから実践に移そうとするスタートアップにとっては、この書籍の内容を実践しさえすれば、リーンスタートアップの半分は実行可能なぐらいにピッタリなのです。 「アントレプレナーの教科書」または”Running Lean”と本書の2冊は、現時点で私の考えるリーンスタートアップ・バイブルです!(
アジャイルサムライ−達人開発者への道− 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未出版社/メーカー: オーム社発売日: 2011/07/16メディア: 単行本(ソフトカバー)購入: 42人 クリック: 1,991回この商品を含むブログ (253件) を見る@nawoto さんにレビューのお声がけをいただいた縁で、オーム社さまより献本いただきました。 読者の声でも書いて、昨日もツイートして、しつこいですが。。。 この本はアジャイルと名前がついていますが、ソフトウェア開発に携わる人(開発者、テスター、マネージャetc...)すべてに読んでもらいたい一冊です。 もちろん、ソフトウェア開発を始めたばかりの学生さんにもオススメです。第一線のソフトウェアエンジニアがどのようにソフトウェア開発をしているのかを知ることは、自分の能力を短期間に向上させることや、ソ
みなさんこんにちは。@ryuzeeです。 SlideShareを徘徊していたところ自動テストと手動テストに関する良いスライドがあったので、翻訳して公開します。 ライセンスはオリジナルに準じてCC BY-SA 3.0とします。 内容としては、僕自身も一貫して主張しているテスト自動化の必要性の話で、主に以下の観点で記載されています。 作業量とコスト再利用性ユニットテストによる良い設計への誘導手動テストのリスクリスクマネジメント書き方が若干極端な箇所もあると思いますが、全体としてはかなり分かりやすいのではないでしょうか。 なお、テストの自動化に際しては、必ずしも全てのテストを自動化「しなければならない」わけではありません。 スライドではROIの例があがっていますが、テストの自動化のコスト>手動コストの1回あたりのコスト×実行回数になる場合もあり得るので、ROIやテスト自動化によって得られる効果に
先日のエントリでもご紹介した通り、今まで国内では東京でしか開催されてこなかったScrum Alliance認定スクラムマスター研修が、今年は大阪でも開催される予定である。 ◆ 第一弾: 2010年3月18日、19日 http://www.scrumalliance.org/courses/20093676-certified-scrummaster ◆ 第二弾: 2010年6月17日、18日 http://www.scrumalliance.org/courses/20093678-certified-scrummaster 私自身、特に講師のBas Vodde氏やOdd-e社と特別な利害関係があるわけでもないが、せっかくなら大阪でも多くの人が受講し、西日本でも盛り上がって欲しいと思うし、今回だけでなく継続して開催されるようになればうれしいと思う。 そうは言っても、興味はあるけど…とさまざ
Agile Japan 2011 の基調講演のため、Linda Rising さんが来日予定です。基調講演は日本中のサテライト会場にも中継される予定です。 Linda さんは、企業組織の柔軟な変化について、コンサルティングやコーチングを行っています。その方法は、パターンランゲージを用いて、誰にでも実行可能な方法を記述していく、というアプローチです。コンピュータサイエンスのバックグラウンドを持ち、通信系の大企業で勤務した経歴をもっているせいか、その一人称の語り口、安易に切り捨てない包容力に驚かされます。 InfoQでのインタビュー (2008年) http://www.infoq.com/interviews/Linda-Rising-Fearless-Change "Fearless Change" という本は、彼女と、ビジネスマネジメント系のバックグラウンドを持つMary Lynn Ma
burndown chart via kakutani アジャイルなチームを目指す。私がチーム運営を始めたときのポリシーでした。どうやって作業をこなすだけから、アウトプットへの価値へとシフトしていくか?チームの方向を示すためにも、様々なメトリクスやKPIを見える化する必要がありました。 通常のプロジェクト管理方法だと、ガントチャートでロードマップを設定、進捗の状態を管理。WBSなどを作ってそれぞれのタスクを管理・・・といった形が一般的なのでしょうか。しかし、それではワクワクしない。そんな中、常に改善を心がけ、私が試して行き着いた方法を紹介させていただこうとおもいます。 唯一生き残ったプラグイン バーンダウンやタスクボードなど、Redmineのプラグインで様々な見える化をしましたが、ずっとそれを使うことはしませんでした。その中で、最終的に生き残ったのがパーキングロットチャートです。なぜ、これ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く