わかりやすいアジャイル開発の教科書 の商品レビュー

前川直也,西河誠,細谷泰夫【著】

2013/08/20

メーカーの方が書いているだけあって、メーカーで働く自分にはとてもわかりやすい例が多い。
アジャイルの目的は「価値」の最大化(p.33)
「アジャイル開発をやること」が目的になったら失敗(p.62)
「いま、いらないでしょ？」(p.106)←ミドルだと一概にこうも言えない。
アジャイルではコードを共同所有して、役割を固定化しないことが大切(p.131)
バグレゴ(p.151)

2013/07/03

タイトル通り、わかりやすくてさくさく読める。

目的、導入、実践・継続、本質と一通りのことが網羅されている。
また、TDDやリファクタリングについても具体的なコード付で解説されており、正に教科書のような内容。

ワークショップでのアクティビティの紹介やファシリテータのためのノウハウについて解説されている点が他ではあまり見かけず、個人的にためになった。

2013/05/11

・丁寧で分かりやすい。概念、理論、現場への導入・定着含めて、一通り網羅されている。

・第１章、第２章は表現がやや周りくどい。もう少し、エッセンスを端的に表現できる気がした。

・第３章は良かった。想い（input）から価値（output）を描き、カタチにする流れ・その具体的な手法がイメージしやすく書かれている。KPTやTDD、見える化の具体例（ソフトウェアかんばん、ニコカレ）など参考になった。

2013/04/30

　アジャイルは「考え方」「姿勢」であり、「手法」として捉えると失敗するということがよく分かった。かつては要求はほぼ決まっており仕様の変化もあまりなかったが、要求が曖昧であり仕様も大きく変化するのが現在のソフトウェア開発の状況である。また、ユーザの使用感も重要な要素であり、その手直しも非常に多い。そういう状況であるにもかかわらず、開発する側が変わらないというのはやはりおかしく、アジャイルという考え方を導入するのは理にかなっていると言える。とはいうものの「変化を嫌う」風土は根強く、特にマイコンではその傾向があるように思う。しかし、マイコンこそアジャイルを適用すべき領域であるように感じた。マイコンは一度製品として出荷されるとアップデートが困難であり、また実際に動作させてみないとどのような結果になるのかわからないという側面もある。そのため頻繁に仕様変更が発生するが、細かくタイムボックスを設定することで顧客、開発側双方で柔軟な対応ができるのではないかと思う。
　本書はアジャイル開発の教科書名乗っているだけあり、プラクティスの解説も充実しているが、特に「テスト駆動」と「リファクタリング」の解説は非常に丁寧で充実している。これはアジャイル開発の根幹ともいえるプラクティスであると同時に誤解を招きやすいプラクティスでもあるからではないかと思う。誤解を招きやすいといえばドキュメント作成もその一つであり、それについても「何故作らないか」に加え、「どんなドキュメントを作るか」を取り上げている。
　アジャイル開発は強力であるものの誤解も多い開発手法である。その誤解を解き、どのように導入すればよいのかを知る手がかりになる1冊である。

2013/04/29

アジャイルを導入したあとに陥りやすい問題に関して、多様な視点から解説してくれている。
「Smiling Adventure」や「4章 アジャイルを現場に定着させよう」は、いいね、いいね、頷きながら一行一行納得しながら読んだ。
アジャイルサムライと同様に他人に薦める書籍だなぁ。

引用
--
アジャイルは手順の定義ではない
ソフトウェア開発をよりよくするために、顧客、マネージャ、開発チーム全員が、なにを重視すべきかを共有し、製品やシステムのビジネス価値を最大化させるために、最も合理的なチームのつくり方や開発の進め方を考えるためののフレームワークをまとめたものです。

ソフトウェア工学で、人の作業のばらつきを一旦視野にいれずに、工学としてとらえていたものを、「ソフトウェア開発と人の作業である」という視点をもう一度取り戻しているのがアジャイルだといえます。

人中心、価値中心で進めていくアジャイルは、ソフトウェア開発での要求開発、要求定義、プロジェクト計画、進捗、設計、開発、リリースなどの開発でのプロセスも、人中心、価値中心で進める事が重要項目となります。そのため、あらゆるパスのコミュニケーションを大事にします。

2013/03/28

やっと、手元にきました。読み始めましたが、自分の中でモヤモヤしていた何故なのか、何が課題なのかという点がうまく説明されているので、目から鱗です。
まだ、途中なので何度も読んで見たいです。