わかりやすいアジャイル開発の教科書

  • 123人登録
  • 3.86評価
    • (13)
    • (10)
    • (9)
    • (3)
    • (1)
  • 17レビュー
  • SBクリエイティブ (2013年3月26日発売)
  • Amazon.co.jp ・本 (320ページ)
  • / ISBN・EAN: 9784797371284

この本を読んでいる人は、こんな本も本棚に登録しています。

有効な左矢印 無効な左矢印
デイル ドーテン
メアリー・ポッペ...
エリック・リース
有効な右矢印 無効な右矢印

わかりやすいアジャイル開発の教科書の感想・レビュー・書評

  • Wikipediaでアジャイル開発を調べたら、その次ぐらいには是非読んでおいた方がよい本。XPやSCRUMなどの本を読む前に本書を読んでおいたら、何のためにやるのかがよく理解できると思う。
    タイトルは教科書となっているが、実施例なども掲載されていて、テストによく出るところをまとめてくれた良い参考書のような感じで、分かりやすく楽しく勉強させてもらいました。

    最近アジャイル(スクラム)の勉強をしているが、分かってくれば分かってくるだけ、知らないこと(知りたいこと)が増えてくる気がする。この辺がアジャイルが人を惹き付ける部分でもあるし、本書でアジャイルと禅の考え方が近いとということかなと勝手に解釈してみました。勉強会が開催されるらしいので、本人に会えたら聞いてみよう。

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

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

  • 「アジャイル開発の教科書」の名前の通り、既存の開発と比較してアジャイル開発のメリットを挙げている点や、アジャイルという概念だけで理解するのが難しいことを前提として、どのような形で組織やチームに浸透させるか、ワークショップや日々の心がけなどにも書かれており、わかりやすいものだった。

    反面本質を説明する前にわかりやすさを示すために卑近な例を挙げて説明している箇所が、個人的には回りくどく蛇足に感じた。
    人によってはそれがあるのでわかりやすいという見解もあるかもしれないが、ただ読む分量が増えているだけという印象を持ってしまったため、☆3つと思いました。

  • 背中に青色シールを貼った図書のコーナーに並んでいます。

  • 日本のソフトウェア開発現場に向けてアジャイル開発を解説されている本です。
    この本の特徴としては、アジャイルな場を活性化させるためのワークショップが紹介されているところだと思います。ただ一方で、この本自体は堅苦しい感じで少し読みにくかったのが残念です。
    書かれている対象が同じでも「アジャイルサムライ」の方がノリがよくて読んでいてやってみようという気になりました。

  • コンサルに行って返答に困る質問の一つに「うちの開発は今V字モデルです。あきやまさんはウォーターフォールの人と聞いていますが、そろそろうちの開発もアジャイルに移るべきでしょうか?」というのがあります。

    ちょっと質問してみると、V字モデルではないことがすぐに分かるので、“ああ、アジャイルを導入したら魔法のようにコストが抑えられ、納期が短縮したうえで品質の高いソフトウェアが開発されると夢見ているんだな”と思います(心の中だけで口には出しません)。

    ま、そんなことは、ないわけで、これまで経験したことを話します。

    「開発者の技術力とモチベーションが大切です」とか「アジャイル憲章はいいですね」とかそういう話です。

    さて、本書はアジャイル開発を実践されている人が平易に書いた本です。読みやすいし、グッとくる記述もおおいです。

    でも、本ではなく講演で耳から聞いた方が良いと思いました。

  • 自分には分かりやすくなかった。共著とはいえ日本でアジャイルを進めてきた第一線の人たちが書いているし、書きぶりもかなり平易だ。なにより著者の熱い思いが伝わってくる。逆に熱い思いが先行してあれもこれも語ろうとし、全体のピントがぼやけて空回りしている感がある。わかりやすいアジャイル開発の教科書なら『アジャイルサムライ』か『SCRUM BOOT CAMP』がよいと思うが、本書の参考図書一覧になぜかこの二冊はない。

    おそらく著者自身がアジャイルを単なる開発技法ではなく、「ソフトウェアの価値を最大化させる考え方や姿勢」(p.269)とし、何らかの手順ではなく考えるためのフレームワークだ(p.10-12, 267)と考えているからだろう。したがって、明確に何らかの手順でこれがアジャイル開発です、と提示するものではない。とはいえ実際には、中身はXPとスクラムからいくつかトピックを持ってきている。アジャイル開発を特徴づける、タイムボックスからなるイテレーション、ストーリーカードなどを用いた詳細化しない要件定義、自己組織化するチーム、朝会の役割、ふりかえり(レトロスペクティヴ)の重要性などはもちろん語られている。これらは本書の大きな分量を占めているが、それが論点の中心なのだろうか。

    共著であるためかややまとまりを欠いていると感じる箇所もある。例えばノウハウについて長めに書かれている(p.13-26)が、いったい何が言いたくて、なぜ本書のここにあるのかほぼ意味不明だった。知識のSECIモデルのことが言いたいのだろうか。さらに、テスト駆動開発とリファクタリングについて、C#のコードを持ち出して分量をとって書かれているが、バランスを欠くように見える。リファクタリングは特に長い(p.171-194)。ちなみにリファクタリング対象になっているメソッド名"Calcurate"は"Calculate"に誤字修正すべきだ。実態を反映していないメソッド名や変数名を変更するのもリファクタリングの重要な要素だ。

    畢竟この本の使い方は、タイトルや著者たちの装いにあるようにアジャイル開発の第一歩としての教科書としてではなく、アジャイルを始めている人が疑問に突き当たった時にヒントを求める本としてだろう。そう見るとアジャイル開発という第一義からは外れているように見える、チームビルディングの第4章も生きてくる。チーム内のタスク進捗状況でなく、情緒面のコミュニケーションのために用いるニコニコカレンダー(p.147-150)なんてアイデア、バグが発生するたびにレゴを積み上げて解消したら壊すというバグの可視化のアイデア、レゴブロックを使ったり絵を描いたりというアジャイルプロジェクトの練習のアイデア(p.217-222)など、なるほど面白そうだと感じるものだった。そういったアイデアやTipsのレベルのものでは現場でよく考えられて揉まれている感があり、参考になる。

    最後に脇道に外れたことを二つ。「見える化」というバズワードは情報を可視化してその後のアクションを誘発することを目的としており、単なる可視化ではないという記述(p.140)を見かけた。使う人はそういう思いを込めているのだろうけど、この語は組成からして「見えるようにする」という意味であって「可視化」と変わらない。英訳したら結局はvisualizationだし。この破格で醜い単語(自動詞の可能動詞に「化」を付けるセンスのなさ)を字面からはほぼ同じ意味の「可視化」に取って代わって使うつもりにはなれない。もう一つは、他書についても書いたことだが、この本でも「適用」と「適応」を混同していて、「適用」であるべきところがすべて「適応」になっている(正しく「適応」である箇所もある)。この二つを混同する人、案外に多いな。

  • タイトルのとおり、アジャイル開発の入門書。

    悪くはない。が、同じ分野に「アジャイルサムライ―達人開発者への道」というぶっちぎりの名著があるので、相対的に高い評価を与えられない。よって☆3つ。

  • その名の通り、アジャイル開発の教科書である。著者の方々は実際に、アジャイル開発を行っており、そのノウハウについても記載されており、非常に参考になる。

    私自身は、プログラマからマネージャーへの移行中という状況で、かつ、いわゆるウォーターフォールしかやった事がなかったため、とても新鮮に写った。

    アジャイル開発は、ソフトウェア工学が否定してきたプロセスやツール重視の考えから、人間重視への方向転換、いわゆるルネサンス的な動きだと思う。結局、ソフトウェアが自動生成されない=人間が関わる、ことからコミュニケーションを密にとり、フィードバックを密にすることで、人間を成長させていかないと、生産性も品質も上げにくいという、現実があると思う。PMPなども、その辺を考え、個人を高めるPSPなどの活動を行ってきたが、他人からのフィードバックプロセスが不十分であったのではないか?その辺りをアジャイル開発は、プロセス内に上手く取り込んでいる気がした。
    また、人重視の考えから、ファシリテーションとの関連が、書かれていたことも興味深かった。そう言った意味でも、様々なヒントが載っているので、オススメです。

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

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

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

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

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

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

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

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

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


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

  • 読みやすかったし、Whyのその先にある"想い"を感じるような内容がすごく良かった。

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

全17件中 1 - 17件を表示

わかりやすいアジャイル開発の教科書を本棚に「いま読んでる」で登録しているひと

わかりやすいアジャイル開発の教科書を本棚に「読み終わった」で登録しているひと

わかりやすいアジャイル開発の教科書の作品紹介

より開発を楽しく、より価値の高いソフトウェアをつくる方法を学習。

わかりやすいアジャイル開発の教科書のKindle版

ツイートする