「アジャイルサムライ−達人開発者への道」を読みました。
購入履歴をみたら、2020/10/24に購入していたので1年近く積んでた計算になりますが、 近頃業務でチーム開発の進め方について悩んだりすることが増えたので、改めて手に取ってみました。
アジャイル開発の定義から始まって、アジャイル開発がどういうものか・現場にどうやって適用するのかを、アジャイルマスターである”マスター・センセイ”に教えてもらいながら学んでいく形式になっています。
以下いくつか気になったトピックと感想。
見積もりの問題
不確実性コーンを引き合いに出し、プロジェクトの初期段階での見積もりは最大で４倍にもずれる可能性があるから、正確な見積もりなんて無理って話がされています。
アジャイル界隈では割と知られているのですが、見積もりが何故ずれるかという説明の1つに不確実性コーンというものがあります。ざっくり説明するとプロジェクトの初期段階では不確定要素が多いので見積もりには4倍くらいの誤差があり、プロジェクトの進行とともに不確実な部分が少なくなってきて誤差は収束に向かうという話です。(出典 : 不確実性コーンの話)
私も業務で見積もりを求められるたびに「いや正味分からんよ」と思っていたので、「そうそう！」って頷きながら読めました。
見積もりなんて無理なんだからもうみんな見積もり求めんのやめよって感じなのですが、実際の現場では予算管理などの都合上、見積もりを出すという作業は避けることができない場面が多いのもまた事実です。
「まだ仕様の決まってないシステムを、まだ誰にやってもらうか決めてないチームで、まだどうするかわからないテクノロジを使って、来年までに構築する予定だから、見積もり出して」
なんてPMから言われたら、豆腐の角で殴りたくもなりますよね。
まあここまで極端な例はそうそうお目にかからないですが、見積もりという行為は開発者である以上なかなか避けては通れないのかなと残念ながら思っています。
だからこそ重要なのは、 ソフトウェア開発の複雑さを開発者だけでなくプロジェクト参加者みんなが理解し、「正確な見積もりなんて不可」という認識を持つことなんでしょうね。
群衆の叡智
”みんなの意見は案外正しい”ってやつです。
本書では、見積もりはできるだけメンバー全員の意見が反映されたものがよく、そのためのツールとしてプランニングポーカーが紹介されています。
スプリントの最初にタスク見積もりをしていると結構あるのが、経験のある開発者が言った見積もりがそのまま採用されるってケースなんですよね。議論ベースでの見積もりをしている場合は、自然とそうなってしまうケースが多いと思います。
「まあ経験のある人が言うならそれが正しいのかな」と納得できる場合もあるのですが、やはり誰か特定の人の意見がチーム全体のものとして認識される雰囲気は危険です。属人的になり他メンバーの積極性が損なわれます。
プランニングポーカーを使用すると、仕組み的に全メンバーの意見が表に出るので特定のメンバーの意見に偏る可能性が減らせるからいいですよね。
私は普段の業務において、時間がなくてメンバーが集まれない時などは１人で見積もりを行って他メンバーには事後報告、などとしていることが結構あったので、気をつけようと姿勢を正しました。
あと開発に直接関係ないのですが、群衆の叡智の話で、「一人の専門家よりも多数の素人の意見が正しくなる」というのがあって興味深かったです。
直感的には専門家の言うことの方が正しいのかなと思うし、テレビやネット記事など見ても専門家が多数の素人の意見を斬って警鐘を鳴らすみたいな構図を見ることが多いのですが、群衆の叡智によるとそれはNOってことなんですよね。
最近はコロナ関連で専門家vs世論みたいなケースをよく見るので、なんか見方が変わるなと思いました。
ふりかえりの流儀
スプリントレトロスペクティブに対しての心構えについて書かれています。
レトロスペクティブでたまに(結構？笑)見るのが、誰かが誰かを詰めている場面です。
まあ重大なポカをした時とかは仕方ないかなと思いますが、あんまりみたくない光景ですし、チームの雰囲気やひいては生産性にまで悪影響を及ぼします。
本書では、スプリント振り返りMTGは魔女狩りではない、という言い方をしています。
たとえどんな問題があったとしても、メンバー全員が最善を尽くしたと信じる姿勢が大事とのことです。
優しい世界ですね〜。。現実もこうでなきゃですね。
また、場をあたためる話題からするといいよとも書かれてました。
いきなり、「今回のスプリントの進捗は？」って聞いてもなんか詰問されているようで息苦しいですよね。なんか機械的ですし。
「うまくやれたことは？」とか「〜さんのあれはよかった、これはよかった」とか、よかったことの話題から入れると、レトロスペクティブ全体の雰囲気が良くなりますし、結果的に意味のあるMTGになるようです。
おわりに
あ、あとアジャイル開発のトピック以外にも、”マスター・センセイ”が随所で書籍をおすすめしてくれるのですが、出てくる書籍が往年の名著とされているものばかりでよかったです。重い腰を上げて読んでみようと思い早速いくつかポチりました。
- テスト駆動開発
- ドメイン駆動設計
- レガシーコード改善ガイド
- リファクタリング プログラムの品質改善テクニック
アジャイル開発のやり方って、チームごとに違うし、メンバーごとにも違うし、各人が各々の考え方を持っているので、何が正解かわからなくなるのですが、本書を読むことによって自分の考え方が整理された気がしました。
だから、プラクティスに囚われすぎちゃだめだ。この本から使えそうなものを選んだら、それを君の現場の性質と状況に馴染むようにするんだ。もしもこの先、自分のやり方が「アジャイルの道」に沿っているかどうかの自信がなくなったら、悩んでないでこう自問すればいい。 ・毎週、価値ある成果を届けられているか？ ・たゆまぬ改善のための努力を惜しまず続けているか？ この２つの問いへの答えが「イエス」なら、君はアジャイルだ。 (出典 : アジャイルサムライ -達人開発者への道)
amazon.co.jp