アジャイル開発マネジメントクイックガイド の商品レビュー
アジャイル開発マネジメントクイックガイド 他著：高畠 勇人 他著：渡辺 裕 監：長瀬 嘉秀 オンプレでのウォータフォールから、クラウド上でアジャイル開発 アジャイル開発のメリットは、ユーザの要件を即座にソフトウエアに反映できること アジャイル開発の品質管理 テストを自動ビル...
アジャイル開発マネジメントクイックガイド 他著：高畠 勇人 他著：渡辺 裕 監：長瀬 嘉秀 オンプレでのウォータフォールから、クラウド上でアジャイル開発 アジャイル開発のメリットは、ユーザの要件を即座にソフトウエアに反映できること アジャイル開発の品質管理 テストを自動ビルドに組込み、ビルドからテストまで自動で行えるようにしていきます。 こうすることでソフトウエアに変更があっても、自動的に品質が担保されます アジャイル開発は１週間や２週間といった非常に短いサイクルで開発を何度も繰り返します ・リリース頻度 ・ビジネスとのかかわり ・投下資本の早期回収 アジャイル開発では、無駄な機能を作りこまなくてもいい 反復開発 ・工程別に反復繰り返す ・機能別に反復繰り返す ⇒本来よく使われる機能から探索的に開発する 具体的なストーリーの管理 ・ストーリーリストという一覧表を作成します ・ユーザと粒度の調整を行う ・イテレーションに割り当て ・開発順序はユーザと一緒に決める ・会議体の運営 何をつくるか（イテレーション計画会議）、イテレーションの評価（イテレーションレビュー会議） アジャイルでもドキュメントは重要、アジャイルでも計画は立てるし、要求定義もしっかり行う モノづくりの方法 ・計画駆動から、進化的設計 ・回帰テストの自動化 ・テスト駆動開発 ・リファクタリング 自律性を発揮させる方法 ⇒ＰＤＣＡサイクル アジャイル開発手法の導入 ・クラウドサービスの活用 スケラビリティの向上 サーバ集約によるＴＯＣの向上 ・設計開発手法の変更 クラウド上でＰＯＣ，デモで仕様をすぐ確認できる テストマーケティング ・適切なツールの活用 コードインスペクション CheckStyle FindBigs ビルド、デプロイツール Ant,Maven テストツール Jnit ＣＩツール Maven,Jenkins バージョン管理 Subversion,Git プロジェクト管理 Redmine 目次 はじめに １章 日本におけるソフトウェア開発の課題 1-1 日本のソフトウエア開発の実態 1-2 開発工程別の職種とプログラマ 1-3 ソフトウエア開発体制の変化 1-4 アジャイル開発手法のメリット 1-5 本章のまとめ ２章 アジャイル開発手法とは 2-1 反復でビジネスリスクを制御する 2-2 ビジネス視点で小さな開発を積み重ねる 2-3 改善こそが本質である ３章 アジャイル開発手法導入のポイント 3-1 アジャイル開発手法導入のポイント 3-2 クラウドでアジャイル開発をしよう 3-3 これからの設計開発の進め方 3-4 アジャイル開発を支えるツール ４章 アジャイル開発の実際 4-1 アジャイル開発の始め方 4-2 要件調整と進捗管理 4-3 開発プロジェクトの進め方 4-4 実際の開発の様子 4-5 アジャイル開発を円滑に進めるために 索引 おわりに プロフィール ISBN：9784774156101 出版社：技術評論社 判型：A5 ページ数：192ページ 定価：2480円（本体） 発行年月日：2013年04月25日初版第1版発行
Posted by
アジャイル開発の概要をつかむために。ビジネス観点の手法であり、生産性を目的にしないなど、旧来のやりかたしかしらない人には不思議だろうが、ユーザーが納得したものをつくるというのが根本だと思う。
Posted by
2017年12月20日読了。アジャイル開発のマネジメントのコツ・従来型開発からの発想切替の必要性などを具体例を挙げて解説する本。平易な解説書、従来型開発が一律に悪いわけではないが「ユーザーが要件を全て把握しており」「開発者に完全なスキルがあり」「仕様書にすべて記載されている」状態...
2017年12月20日読了。アジャイル開発のマネジメントのコツ・従来型開発からの発想切替の必要性などを具体例を挙げて解説する本。平易な解説書、従来型開発が一律に悪いわけではないが「ユーザーが要件を全て把握しており」「開発者に完全なスキルがあり」「仕様書にすべて記載されている」状態が前提となる従来型開発がよほど小規模の案件でなければ現実的でないのは経験の通り、ユーザーも開発者も経験を積みながら開発するためにはアジャイルのスタイルがより適している（と、いうか現実的）であり、バージョン管理ソフトウェアやネットワークの発達などの技術がそれを可能にしている、ということなのだな。失敗すると分かっていて従来型開発に資源を突っ込むのも愚かなことだが、開発現場が変われるかどうか。
Posted by
アジャイル開発について、 振り返りも踏まえて読んでみましたが、 少しツールに寄りすぎた内容になっていて、 以前読んだ本ほど参考にはならなかった。 マネジメントについても期待された内容ではなく、 やはりツールの話に特化されたような内容で、 正直いまいち感はぬぐえなかった。 【勉...
アジャイル開発について、 振り返りも踏まえて読んでみましたが、 少しツールに寄りすぎた内容になっていて、 以前読んだ本ほど参考にはならなかった。 マネジメントについても期待された内容ではなく、 やはりツールの話に特化されたような内容で、 正直いまいち感はぬぐえなかった。 【勉強になったこと】 ・アジャイル開発では、ユーザーと開発者が 離れていては成功に繋がらない。 お互いに業務・システムの視点から、 同じ課題に対する解決策を議論出来るような 体制にならないと上手くはいかない。 →日本企業の大半は上記問題を抱えてしまっており、 だからこそ失敗プロジェクトが生まれていると 個人的には感じます。丸投げは止めよう。 ・アジャイルソフトウェア開発宣言 プロセスやツールより、個人との対話を 包括的なドキュメントより、動くソフトウェアを 契約交渉より、顧客との協調を 計画に従うことより、変化への対応を 上記を実施出来る体制を作るためには、 自発的に動ける耐性が揃っていないと、 上手くはいかない。 個人的にはSIerでは上手くいかないと思う。 ・ユーザーストーリーを作って優先順位を決めたら、 その粒度を調整すること。 これにより、作業期間の均一化を目指す。 →言葉で言うと簡単だが、実践は非常に困難。 線を引かない組織でざっくばらんに話せないと ほぼ失敗する。 ・上流で品質を作りこむという鉄則はあるものの、 上流で作りこむことは現実的には難しい。 実際、自分が言いたいことをモノを見ずに具体化 することは極めて難しいし、開発側もユーザーの 意図を完全にくみ取ることは出来ない。 アジャイルは上記のような問題を解消するための 一役を担っている。
Posted by
アジャイル開発の空気感とツールの関連性はなんとなくわかった。 こんなやり方、保険のお客さんじゃ無理じゃん！と思ってたら、最後のサンプルが保険で代理店でモバイルとな。 確かにまずは動くもの見せて判断してもらい、改善していくってのは今の時代に即してますが、ホントだとドキュメント作成に...
アジャイル開発の空気感とツールの関連性はなんとなくわかった。 こんなやり方、保険のお客さんじゃ無理じゃん！と思ってたら、最後のサンプルが保険で代理店でモバイルとな。 確かにまずは動くもの見せて判断してもらい、改善していくってのは今の時代に即してますが、ホントだとドキュメント作成に時間とられるよねー。二ヶ月でリリースってのはお客側にも意識変えてもらわないと無理だよね。悩ましい。 しかし、世界はこのスピードでやってます。さて、どうする？とお客に聞きたい。「うちは、まだ」って言うんだろうな。僕らが上を変えていかないと。
Posted by
アジャイル開発の考え方は分かるものの、ではどうすれば導入できるのか？というところが抜け落ちており、「さあ、アジャイル開発を始めよう」と言われても導入できるようにはなっていない。また、「はじめに」では既存のやり方に組み込んでいくことが大切であると述べているが、その組み込み方の説明...
アジャイル開発の考え方は分かるものの、ではどうすれば導入できるのか？というところが抜け落ちており、「さあ、アジャイル開発を始めよう」と言われても導入できるようにはなっていない。また、「はじめに」では既存のやり方に組み込んでいくことが大切であると述べているが、その組み込み方の説明がないのも不親切である。 既存のV字モデルとの比較でアジャイルの優位性を示すやり方はアジャイルを導入しようとするときの説得材料としては秀逸であり、著者らがおそらくこの方法で説得をしてきたのだろうということが覗える。一方で導入事例は分散開発しかなく、アジャイルは分散開発にしか使えない、という誤解を招きかねない。個人的には社内で使うツールの開発こそアジャイル開発を導入すべきだと思っている。社内ツールはとにかく要求が二転三転し、納期も比較的短いことが多い。まさにアジャイル開発にうってつけの場面である。 アジャイル開発を円滑に進めるために必要なものとして、著者らは「自動化」であるとしているが本当にそれが必要なのだろうか？確かに自動化も重要な要素ではあるが、真に重要なのはコミュニケーションのはずである。「アジャイルソフトウェア開発宣言」が発表されたのは2001年である。当時は今ほど支援ツールが豊富だったわけではない。それでもアジャイル開発ができたのはなぜか？それは、宣言に謳われている「プロセスやツールよりも個人と対話を」、「契約交渉よりも顧客との強協調を」に尽きる。宣言は4項目あるが、そのうち2つがコミュニケーションに類するものであることからもコミュニケーションが重要であることがわかる。それを「円滑に進めるために必要なものは自動化」と本文を締めくくっているようでは、著者らはアジャイル開発の本質を理解していない、と言わざるを得ない。
Posted by
- ネタバレ
※このレビューにはネタバレを含みます
アジャイル開発について、非常に分かりやすかったです。 ⇒字が多くなくてさくさく読めて、すんなり頭に入ってきました。 初心者や、これからの人に理解してもらうために読ませてみたい。 ４章は簡単そうに説明されているけれど、 実際にやろうとするといろいろ大変ですね。 アジャイルの説明としては分かりやすかったです。 個々のリアルな作業の細部には、いろいろ罠が待っています。（＾＾；
Posted by
- ネタバレ
※このレビューにはネタバレを含みます
日本人が日本人のために書いた本で、かつ、日本の過去から現在までのソフトウェア業界を把握されており、肚落ちしやすく、とても読みやすい。 また、タイトルにあるようにマネジメントの立場にある人に読んで欲しい本。もしくは、それらの人を説得したい開発者が読むと良いだろう。 -引用- 従来はドキュメントや計画による形式化によってリスクを制御しようとしていました。しかし、ビジネスリスク管理を本気で考えたら、計画や契約だけではなく人の要素についても真剣に考える必要がでてきたのです。そういった相対的な価値観のバランス感覚が、アジャイル開発手法を理解し、上手に活用する上でとても大切です。アジャイル開発とは、従来からの価値観の転換をもたらす開発手法なのです。 ビジネスの不確実性を考えた時、ビジネスが軌道修正を容易にできることがより重要視されます。ソフトウェア開発の世界では多少非効率だったとしても、頻繁にアウトプットをビジネス側に提供し探索的な小さな意思決定を積み重ねる進め方のほうが、最終的に効率が良くなるのです。 アジャイル開発の目的は、ユーザーにビジネスの意思決定機会を頻繁に提供することです。そのためには、意思決定に有用な小さな成果物をイテレーションの都度、提供することが大切です。
Posted by
- 1