アジャイル開発を学ぶためにこれまでいくつかの書籍を読んできた。
その中で学んだ知識には、現場で活かせるものもあれば活かしきれないものも合った。活かしきれない理由の一つに、アジャイル開発を進める上での前提となる組織との違いが制約となっていた、というものがある。
MoreEffectiveAgileではそんなアジャイル開発における理想と現実のギャップを埋めるためのヒントが多く紹介されていた。序盤で本書は、うまくいくことが実証されているプラクティスに焦点を合わせている。と書かれている通り、有名なTipsであってもバッサリ評価されていて、非常に気持が良かった。
アジャイル開発の書籍ではなんとなく開発プロセスに焦点が当てられていることが多い気がしていて、PMのアウトプットが課題になっている自分のチームではどうしたものかと悩んでいた。この点に関しても、この書籍では要求整理のプロセスが課題になりがちであるというスタンスでアイディアを紹介していて、ものすごく刺さった。
今までアジャイル開発に挑戦しようとしたけど上手く定着しなかったという人や組織にとっては、次の一冊として手に取ると鱗だろうなという感想。自分ももっと早くに読んでおけばよかったと少し後悔している。
そんなわけで、最近読んでいた本は内容が重複していたりして物足りないことが多かったが、MoreEffectiveAgileは読んだことで自身のレベルが一気に上ったこと実感できる書籍だった。
Memo
- Cynefinフレームワーク
- 検査と適応を重視する
- まずはじめに、シンプルなスクラム開発を厳格に運用するところから初めて見るのがオススメ
- テストも一つの専門知識
- ビジネスマインドセットを持った開発者がプロダクトオーナーの変わりにはならないが、無能なプロダクトオーナーの埋め合わせにはなる
- たまにPdMにならないか誘われるのだが、それなりの立ち回りはできたとしても良いPdMになれるイメージが沸かない。自分がそのように感じる理由は、こういった話を感覚的に理解しているからなのだと思った。
- フィードバックループをタイトにするために、必要ならコミュニケーションのパターンを増やす
- 学習のための投資をしても辞められるリスクと同じくらいに、学習しない人が辞めないリスクを考えるべき
- EQを向上させて、様々な相手との付き合い方を理解するべき。それが苦手なソフトウェアエンジニアだからこそ、学ぶことで大きな武器になる
- ビジネス側と開発側が、技術的負債とビジネスベネフィットについて会話をしたほうが良い。双方がそれらを理解しないまま進めることが、適切な意思決定の妨げになる
- 大規模プロジェクトでは、小規模プロジェクトに比べてドキュメントが重要になる。口頭での情報共有が難しい。
- プラクティスコミュニティを作る。
- 技術的な勉強会をやるのなら、プロジェクト内で定期的に勉強会をやるべきでは?それが情報共有を促し、自ら成長する自己組織化されたチームを作ることに繋がるかも
- ストーリーポイント0の手戻り作業を作ることで、ベロシティに反映して改善するきっかけを作ることができる
- 間違いを許す ≠ 間違いを無視する。学習に生かしてプロセスを見直す
- 規制産業などで文書化が重視されるプロジェクトでは、アジャイルを取り入れる境界線の調整を試みる。要求整理まではシーケンシャルに、その後の詳細はアジャイルに進めることで良い結果になることもある。
- そうすべきということではなく、そういうアプローチもあるということ。
