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

  • SBクリエイティブ
3.90
  • (15)
  • (10)
  • (10)
  • (3)
  • (1)
本棚登録 : 133
レビュー : 16
  • 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などの活動を行ってきたが、他人からのフィードバックプロセスが不十分であったのではないか?その辺りをアジャイル開発は、プロセス内に上手く取り込んでいる気がした。
    また、人重視の考えから、ファシリテーションとの関連が、書かれていたことも興味深かった。そう言った意味でも、様々なヒントが載っているので、オススメです。

全16件中 1 - 10件を表示

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

前川直也の作品

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

有効な左矢印 無効な左矢印
エリック・リース
有効な右矢印 無効な右矢印

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

ツイートする