via 野口さん ありがとうございます！
アジャイルジャパン2012 東京サテライトでアジャイル入門セッションを発表させて頂きました。前回につづき、今回はメインとなる『変化を生み出すプラクティス編』を補足させて頂きます。資料はSlideShareとSpeaker Deckで公開中です。
変化を起こすためのプラクティス
準備ができたならばあとはやるだけです。今回の発表で紹介させていただいたプラクティスは
- 問題に適用してみてうまくいくことが多い
- コーチ後にも残って続けられることが多い
ものです。実際にやっていることは単純なことなのですが、やりながら学ぶことでいろいろと気がつくんでしょうかねぇ。
最初に紹介するのは『チームのポリシーを決める』です。個々数年チームリーダーをやらせてもらっているので「チームを作る」ことをよく考えます。アジャイルコーチとしてのサポートするときは、自分のチームごと移動して共同作業するようにしているので、共同作業プロジェクトと実プロジェクトという2つのインセプションデッキを毎回作らなければなりません。
前回のエントリの準備で用意したビジョンを下に、チームで集まってゴールを確認します（だいたい1時間でできる）。インセプションデッキだけでなくすごい会議を使って役割分担や計画まで作るときもあります。
そしてキャッチコピーを作り、Wikiやタスクボードの近くに貼り付け、いつでも目に入るようにします。意見がぶつかった時などにこのキャッチコピーを元に判断する場合もあります。
次に紹介したいのが『レポートラインをスマートにする』です。短い朝礼やふりかえりにより、コミュニケーションミスを極限まで減らしていきます。会話をうながしながらチーム内で改善のサイクルを作っていきます。
写真は最近使っていたタスクボードなのですが、これまではタスクの状態しか管理できておらず、「来たものをこなす」みたいになってしまっていたので、Jeff PattonのCSPO研修で教えてもらった「ユーザーストーリーマッピング」を改良して使っています。ユーザーストーリーマッピングは、本来はワークフローを作ってタスク分解する形なのですが、一つのサービスだけを担当することが少ないので、自分のチームにあったやりかたになってしまっています。
大きく分けると上の写真のような役割を持っています。上部はポリシーを決めた時につくったものをクレドとして貼りつけるなどして、朝礼時に目に入るようにします。
「物語とタスク」部分はビジネス側の要件を整理する場所です。プロダクトバックログをXY軸でならべています。タスクをうまく回すのはファーストステージでしかなく、ビジネスに貢献する意識を持つにはビジネスサイドの要求を見える化し、エンジニアに意識してもらう必要があると考えています。
つまり、タスクをうまく消化してもいいサービスができるとは限らないため、ビジネスとの共通言語で書かれた要求をストーリー仕立てにし（赤い付箋）、それら一つ一つを技術を持って解決するためにタスク分割する・・・という流れが見えるように作っています。このタスク分割をするときには、スクラムで言うとプロダクトオーナーの役割を持つ人を交え、会話によってストーリーの行間をタスクによって埋めていきます。
準備が整ったタスクは、イテレーション（スプリント）ごとにTODOにまるごと移動し、チーム内で状態を確認します。一部だけ完了してもデリバリできないため価値につながりません。よって、タスクはできるだけ完結したタスク（リーンスタートアップだとMVP）に仕上げてDONEさせていきます。DONEになった付箋はすべて捨てます。必要な情報はソースコードやコミットログ、Wikiというデータとして残します。
左から右に流れるバリューストリーム全体像をこのタスクボードで確認し、最後には「動くソフトウェア」が残ります。
最後に紹介するのは『開発のお作法をスマートにする』です。誰でも簡単に開発を開始できるようにし、誰でも簡単にリリースできるようにすることで開発スピードを最大限にします。手段としては、ミニマムサイズで構築されたOSイメージをくばったり、Capistranoを使って手順を自動化することで、だれでも同じ環境で同じ作業ができるようにします。
この図もAgile Conference 2011で知ったものですが、リリース自動化はとても効果の大きいプラクティスです。開発がアジャイルになることでソースコードもどんどん増えていきます。ソースが増えるということはバグや技術的な負債も増える可能性があるということになり、これらを放置するとデリバリスピードは減速し、ユーザからの信頼も下がってしまいます。
「なにもしない」「リプレイスで何とかする」「スケールアップなどにコストをかけ続ける」といった選択はあまりよくないと紹介されており、とくにリプレイスに関しては、その間にキャッシュが入ってこないため、資金がショートしてしまう高リスクを持っています。そうならないように、デリバリ回数や時間を計測しながら、改善のきっかけを意識していくことが大切なのでしょう。
*
今回は『変化を生み出すプラクティス編』と称しまして、いくつかの事例を共有させて頂きました。次回は最後になりますが『小さな変化、大きな渦編』を予定しています。
はじめてのアジャイル – Agile in a nutshell
