図解でわかるアジャイル・プロダクトマネジメント

図解でわかるアジャイル・プロジェクトマネジメント (SCC Books 389)

 現在作業してるPJがいわゆるアジャイル的な開発をしています。

今までウォーターフォール的な開発しか経験したことのなかった自分は

勝手が違い過ぎてかなり戸惑ってました笑。

これはいかんな、と思いブックオフで購入した次第です笑。

かなり新しい本なので、

割と最新の流れを図とかを使ってわかりやすくまとめてくれています。

（アジャイルのイテレーション？期間も本によって2週間だったりする

みたいですが、この本では4週間を基本とする、て書いてました。）

PJ手法の種類や、アジャイルの導入～といった感じで

多岐に渡ってアジャイルについて簡潔にまとめておりとても読みやすかったです。

以下感想＆まとめ。

アジャイルっていうのは簡単にいうと、

ウォーターフォールの進め方でいろいろ無茶苦茶だったところを

見直して（デスマーチ的な例え）、改善しよう！という流れで

うまれたものです。

一つの作業サイクル（だいたい4週間くらい）を決めて

それをPJ終了まで繰り返します(イテレーション)。

（今のPJでいうと要件定義、設計、製造、テスト、受け入れ、振り返りを

繰り返してます！）

イテレーション期間内で終わらせられる作業を基本として

バックログとよばれるやりたいことリストみたいなところから、

エピック（要件の集まり）を決めて、それをタスクに分解して取り組みます。

（イテレーション内で完了できる作業がベースになるので、

休出したりすることは基本的に認められない！喜）

で、xpとかスクラム開発とかっていうのはアジャイルの中の一つ

みたいな感じらしいです。

（パンクの中にハードコアとかエモとかあるみたいない感じ？）

読んでて驚いた点は以下。

アジャイルで優先されるのは、

・ドキュメントよりも動くソフトウェア

らしいです。

設計書の重要度は低い、ということですね。

今まで設計書命！でそれが正だったPJばかりだったので、

そこが面食らいましたね。（必要な要件だけがまとめられていればOKみたいです。）

あとメンバーに求められるのは

・対面の会話

・自主性をもつように動機づけされた個人　自己組織化

 結局チームは少ない人数だし、毎日顔合わせるし

何かあったときは直接話あいましょう！と。

それはどのPJでも同じですよね。

で、指示待ち人間だったり、向上心のない人だと

うまくいかないという。

これも大事ですが、PJ全員そういう人をそろえるのは難しいですね汗。

なので、そうじゃない人をいくら増やしても

炎上PJとかでよくあるけど何も状況は変わらないという…

顧客と開発チームの関係

・海外では顧客側がpmで指揮をとる。なので請負という考え方はないみたい

・丸投げでは成り立たない

・失敗事例　アジャイルへの理解不足

もともと海外で生まれた文化なので、

仕様を把握してる＝完成する納品物をどうしたいか、

っていうのを一番知ってるのはお客さんなんで、

お客さんが仕切るのが一番いいっすよね。

で、その逆でこういうの欲しい～って丸投げするスタイルだと

アジャイルは無理みたいですね。

やっぱり、運用コストがウォーターフォールよりかかるみたいなので

そういうのもわかったうえでやってくれるお客さんとじゃないと

成立しないみたいです。

（このあたりがかなり細かく触れられてました。）

あとは

・変更を抱擁する、通常手続きの中に組み込む

・変更を定常的な事象として捉える

・変更を受け入れるプロセスを日常的に続ける

仕様変更っていうのはどんなにガチガチに設計してもあとから出てくるものなんで、

だったら最初からそれありきで作業しよう、ということですね。

そのためにアジャイルがあるみたいな。

だらだら書きましたが、

いろいろ気づきが多かったです。

アジャイル初体験の人、興味ある人、これからやる人、PMに興味ある人

は是非一旦読んだ方がいいかなと思いました。

本にも書いてましたが、ウォーターフォールとの違いに最初は必ず戸惑う、

って書いてたので笑。

自社でやってる作業でPMごっこをさせてもらえているので

そこにも活かせるかな、と思いました。

ちなみに、後書きがとてもグッときたのでそこだけでも是非。

名著！