- Amazon.co.jp ・本 (220ページ)
- / ISBN・EAN: 9784274066948
作品紹介・あらすじ
アジャイルの核心となるプラクティスについての、包括的かつ焦点の定まった簡潔な要約。特定のアジャイルな方法論を押し付けるのでなく、いろいろな方法論に共通するプラクティスを結びつけ、首尾一貫した全体像を描き出している。
感想・レビュー・書評
-
とても良い本でした。
ソフトウェア開発にたずさわる読者に、「アジャイルであること」とは何なのかを理解させ、アジャイルプラクティスの試行を大いに助けてくれる本です。
アジャイル(Agile)とは、直訳すると「機敏である」ということ。
ソフトウェア開発において、最終的な製品の仕様が開発段階であらかじめ完璧に決まっているなんてことはあり得ないんだから、当然完璧な要求仕様やスケジュールなんか最初から組めるわけない。エクセルで開発スケジュールを作り、スケジュールが変化するたびに(スケジュールは当然変化する)エクセルのスケジュールをちまちま編集する、そんな馬鹿げたことに無駄な時間と労力を費やすよりも、とにかく作ろうとするソフトウェアをモジュール単位に分割して、何かしら設計してみて、コーディングして、コンパイルして、テストして・・・のサイクルを機敏に繰り返して素敵な製品を作って進化させていこうよ、という設計姿勢が「アジャイルであること」らしいです。
開発段階では仕様が確定していないので、素敵な製品の定義というのもこの時点では曖昧です。アジャイル開発は、その曖昧さを解消するために、ソフトウェア開発者にユーザーと常に接することを求めます。作った(あるいはテスト中の)ソフトウェアをユーザーに見せ、ユーザーからのフィードバックを反映し、より良いアイデアを能動的にユーザーに提案し、再テストする。この繰り返しが、ユーザーにとっての素敵な製品とは何かを定義づけていくプロセスであり、この繰り返しのプロセスを設計者がアジャイルに(機敏に)できる環境を構築することが、アジャイル開発の肝であるようです。それは例えば、分割したモジュールのコンパイルが容易であるとか、自宅からでもモジュールのチェックイン/アウトができてどこにいてもソフトウェアが作れる環境にあるとか、競合(同モジュールをチームの複数人が同時に編集しようとする)が発生しにくい仕組みやチームワークを構築する、といったことです。
チームワークの重要さもよく述べられていました。現代のアプリケーションの規模を見たときに、そのソフトウェア開発をひとりで行うケースというのは現実的でなく、ソフトウェア開発は常にチームで進められるものであるから、そのチームワークは大切であるとのことです。その有効な方法として例えば、短いスタンドアップミーティングをチーム内で毎日実施して開発者同士の進捗を確認するとともに交流を深めたり、ひとりひとりがチームにとってのメンターになる意識を持って自分の知識をチームと共有する機会を設けたり、といったことです。自分の知識は思わぬところで他人の役に立つことがあるから、とにかくメモ書きでもブログでもなんでもいいから残して共有しておくと良く、またそれを継続するためには自分自身が常に勉強する意欲と他人から教えを請う姿勢が常に求められるので、結果として自分もチームメンバーも互いに向上し合える、というのが「メンターになる」ことのメリットだそうです。(実際、「アジャイル開発」という言葉を全く知らなかった僕がこの本を読むことになったのも、チームの先輩から教えてもらったことがきっかけでした。)
最後に、ソフトウェア開発における「設計」について述べられた文章が印象的でしたので、ご紹介します。
『設計とは、直面している問題それぞれに固有の解決策である。現場でそのまま使えるほど詳細に事前設計することは難しい。最初の段階では、まだ問題の背景も十分わかっていないし、フィードバックもほとんどない。設計は時とともに進化するのだ。アプリケーションの実態(そして実装)を無視して、新しい機能や機能の強化を設計することはできない。(著書より抜粋)』詳細をみるコメント0件をすべて表示 -
ソフトウェア開発をアジャイルに行うための習慣が45書かれている。 今まさにアジャイルにプロジェクトを進めている自分にとって、実に納得の内容だったり、頭ではわかっていても全然できていないことがあったりで、もやもやしていたところがある程度スッキリできてとてもよかった。 各プラクティスの冒頭には「悪魔の囁き」があり、よくありがちなアンチパターンがあり、終わりにはアンチパターンに対応する「天使の助言」がある。これらもよくまとまっててとても参考になった。 アジャイルな開発は個々の相乗効果を高めることを常に意識しておかないとダメだな、ということを再認識できた。変なプライド(がもしあれば)は捨てて謙虚にいかないとね。 タイトルは「アジャイルプラクティス」となっているけど、アジャイルでないプロジェクトでも実践すべきプラクティスがいくつか書かれているので、ソフトウェアエンジニアは必読の一冊だと思う。
-
ソフトウェア開発における一種の態度である「アジャイル」のバイブルとでも呼べる一冊.経験豊富なプログラマである著者たちの実体験から引き出された,往々にしてプログラマたちの手から離れ怪物と化してしまうソフトウェア開発をいかに制御するかというノウハウ,心構えが述べられている.
一読した上での最初の印象は,こういったソフトウェア開発の新しい態度を導入するための最大の障害は,同じプログラマの同僚やマネージャであろうということ.アジャイルなソフトウェアの本質は,「変化を恐れない」という態度にあるが,この変化を恐れないという態度を受け入れるのは人間にとって容易なことではないと思われる.アジャイルな態度に出発するには,そういった頑迷固陋な同僚を啓蒙するような力が必要になってくるが,それはもう本書のスコープとは異なったものであろう.
そんな職場はさっさと辞めろ,というのが本書にはある.よりよい環境のためにリスクを取って今の環境から抜け出るのもアジャイルな態度なのだろう. -
アジャイルの考え方が、具体例を交えながら書かれてて、とても分かり易くよい入門書。
アジャイルの考え方は、システム開発だけでなく、小規模のチームで何かをやる時にも当てはまる。そういう人たちが読んでも気づきがあると思う。 -
あとはこれを実践して行くだけですね!
-
つまみ食い可能なプラクティス集。
現場や状況に合わせてピックアップ、実践しながらブラッシュアップ、と地道にやっていくための足がかり。
相反するプラクティスなんかも普通に掲載されているので、結局は自分たちで実践して選んでいくしか正解はない。 -
再読、実体験が増えていくと納得感が増す。キーセンテンス並べるだけで、自問自答するのに役立つ。バランス大事。
-
一通り読んだけどひとつも覚えていない。
-
アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
-
よみやすい。もやもやしていたアジャイルを明確かしてくれた本。活かせそう!