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