「アジャイル開発に関する書籍等を数冊読んで、知識やスキルの補強と向上を図ります！」の3冊目です！
読んだのは「エンタープライズアジャイル開発実践ガイド」です。
基本的なことから導入・開発・運用まで章立てでわかりやすく説明されていそうだったので、手に取ってみました。
400ページ近くありサイズも大きく割とゴツめの本ですが、早速読んでみたいと思います！
いつものように、私が特に勉強になったと思った内容と個人的な感想を、備忘録としてまとめています。
Introduction
キーワード
- エンタープライズ（大規模な企業や法人）にとって、守破離の守は従来の開発手法であり、破はアジャイル開発を導入すること、と解釈してみる。
- ソフトウェアのビジネス価値を高めるに、デプロイの迅速性と頻度を高める。
- リソース効率性よりもフロー効率性（機能の開発着手からリリースまでの時間）を重視する。
- アジャイル開発はチームメンバーがフラットな関係性であるがゆえに、自己組織化が求められる。
- プロダクトオーナー、開発チーム、スクラムマスターもフラットな関係性である。
感想
アジャイル開発（ならびにスクラム）の基礎的な内容が背景から解説されていたので、良い復習になりました！
過去に別の書籍やウェブサイトを読んだときにはそこまで重要とは思わなかった箇所を、今回読んで重要だなと思ったり、座学での勉強と業務での実践を繰り返すことで自分自身が変化しているなと感じました。
日々の努力はなかなか目に見えづらいですが、これからも勉強は継続していきます^^
Chapter1 チームを作る
キーワード
- プロダクトオーナーは、他の業務と兼任はせずにプロダクトオーナーの仕事に専念できることが理想である。
- 開発チームとして、メンバーが相互にサポートしたり、苦手な作業を担当することをポジティブに捉える組織文化が重要である。
- 開発チーム内で役職や年次などの違いを意識させないような工夫が求められる。
- 開発チーム内にサブチームを作らない。
- コンピュータやネットワークなどの作業環境を整備する。
感想
アジャイル開発の理想、従来の開発の課題、対処方法の3点が解説されていて、なるほどなと思いながら読みました。
私自身が従来の開発手法や過去の経験を引きずっているので、上のキーワードを意識したいです。特に、過去の案件では機能や役割でチームを分けるのが通常だったので、その辺りの意識改変が個人的に重要になりそうだと感じています。
作業環境は割と軽視されがちな印象ですが、私も非常に大切だと考えています。過去にも、
- キャビネットやサイドデスクの代わりにダンボールが割り当てられた
- 他者に誤って削除された権限の復活に1ヶ月近くかかった
- 貸与されたPCが故障している
- 貸与された機器が汚すぎてそもそも触りたくない
など挙げれば枚挙に暇がないです笑
Chapter2 開発の準備
キーワード
- 「開発するソフトウェア」と「ソフトウェアの作り方」の方針の変更を許容する。
- あとから方針を見直すことを前提に、最初の方針を決定する。
- チームメンバー全員が方針を理解して納得することを重視する。
- 開発者は全員がどの要件でもどの工程でも担当できる状態を目指す。
- 方針決定後にアサインされたメンバーに対しては、理由も含めて方針を丁寧に説明する。
- プロダクトバックログアイテムには、要件・機能・価値・受入条件・優先順位の情報を含む。
- プロダクトバックログアイテムの中には、優先順位が低いために実装されないアイテムが存在する可能性がある。
- ソフトウェアのビジネス価値は、開発者が考えた機能をすべて実装しているかではなく、ユーザが満足するかで決まる。
- スプリント0として、開発のリハーサル期間を確保する。
感想
今でも、プロダクトバックログに実装されずに後回しにされ続けているアイテムがあると若干の気持ち悪さを感じます。それは、まだ私がアジャイル開発に慣れきっていないからなのでしょう。
その都度、アジャイルソフトウェア開発宣言と、その背後にある原則を読み返して、自分の中に価値観を定着させていければと思います！
合わせて、ソフトウェアのビジネス価値がユーザの判断に委ねられているという点も、頭での理解だけではなく腹落ちさせていきたいです。
Chapter3 開発
キーワード
- スプリントゴールの観点は特に決められておらず、ユーザ目線の機能的なゴールでも、チーム目線のプロセス的なゴールでも良い。
- そのため、ソースコード更新後30分以内にリリースできるようにする、というプロセス的なゴールもOK！
- プランニングは、タイムボックスをオーバーしたとしても、作業計画を立てる方を優先する。
- スキルと経験が最も少ないメンバーに合わせて詳細化することがポイントである。
- マイクロサービスアーキテクチャなどを採用し、仕様変更の影響範囲を明確かつ限定的にする。
- 計画時点で判明している要件の範囲で必要十分な設計をする。
- 他システムとの連携が必要な場合は、他システムの状況や他システムを開発するチームの開発スタイルを考慮して、必要に応じてモックなどを活用した開発やテストを計画する。
- デイリースクラムでは、作業計画の見直しが必要かまで判断する。
- デプロイとリリースのタイミングを空けることで、デプロイで発見された問題に対処する時間を設けることができる。
- バックログアイテムの見積もりは、開発が進むに従って何度も実施して、精度を高める。
- Gitに慣れてきたら、git-flowなどを参考にしてフローを見直してみるのも良い。
感想
普段の業務では意識せずに実行していることでも、改めて文章で記載されると、もっと知りたい・勉強したいと思うことがたくさん出てきますね！
アーキテクチャに関しては、より良い実装方法や設計、方式があるのではないかと、日々思っています。この書籍を読み終わったら、アーキテクチャ関連の書籍も読んでみたいと思います。
Gitも当たり前のように利用していますが、実はあまり実施したことがない操作もありますし、おそらくほぼ知らない機能もあると思います。また、git-flow等については勉強したことがありません。書籍の後半にあり構成管理の章でGitについて解説されているようなので、そこで理解を深めたいです。
Chapter4 評価と改善
キーワード
- ソフトウェアのビジネス価値を計測するためのメトリックスを収集するための仕組みを、あらかじめソフトウェアに実装する。
- ソフトウェアは更新しないとビジネス価値が下がる傾向にあるので、継続的に評価する。
- 「改善」をネガティブに捉えている組織は、アジャイル開発を導入する際に考え方を変える必要がある。
- 組織の評価として、まずはビジネス価値が実現できているか、次にデプロイに関する指標（コミットからデプロイまでの時間やデプロイの頻度）、続いてプロセスや環境やコミュニケーションに関する評価、などがある。
- 問題が生じた際には問題解決のために開発を止められるように、組織としてルール化するなどの工夫をする。
- 開発チームの評価として、ベロシティ至上主義に陥らないように留意する。
- ベロシティは見積もりとリリース計画を立てる際の目安であり、チーム固有であり、相対見積値を元にした数値である。
- ベロシティが一定だから開発チームが成長していないと判断することや、他チームとベロシティを比較することは避ける。
- ビジネス価値、デプロイに関する指標、イテレーションの計画の達成度などで評価する。
- 開発チームの改善がうまく機能しない場合、プロダクトオーナー・開発チーム・ステークホルダーなどの間の信頼関係に問題があるケースが多い。
- これらに問題があると、問題の見える化がされづらい。
- 改善では上手くいったことにも着目する。上手くいったことを意図的にできるようにしたり、他のメンバーもできるようにしたりすることで、チームがより良くなる。
- KPT以外にも、Sailboat RetrospectiveやYWTという手法もある。
感想
個人的な課題として、改善をネガティブに捉えがちなことや、振り返りの時に自分の良かった点をあげられないことがあると思っています。
過去の経験から、「改善が必要であるということは、現状が無価値ゆえの結論であり、現状は否定されるべきもの」や「たとえ成功したことがあったとしても、失敗が少しでもあれば帳消しである」という価値観にまみれていることが原因ですね。
これも考え方を変えることで、少しずつ慣らしていきたいです。
以上
