[音楽]成功するアジャイル開発第4回目今回はこのレトロスペクティブについての説明をしたいと思います早速ですけれども皆さん retrospective は実施されてますでしょうかスクラム開発において1スプリントサイクルの中の一番最後のイベントと位置付けられ
ているこのレトロスペクティブですけれども時間は二はあるんだけれどもその実態は形骸化してしまっていて行われていないとかそもそも時間枠すらもう省略してしまって
イベント自体を行っていないとかですねそういった状況に陥りやすいのがこのレトロスペクティブの特徴でもありますそれは一つはこのレトロスペクティブの価値をなかなか見出せないだったり指を感じないという状況が原因としてあったりします
ですので今回はこのレトロスプ retrospective をどのようにすれば良いかという2つの具体例を示しますのでこれをもとにみなさんのチームの状況に応じて泥ダクトの特性に応じてカスタマイズしてもらえればと思いますのレトロスペクティブはアジャイル開発の中での学習というパートになりますので
このレトロスペクティブを有効に使えるかどうかによってそのチームの生産性あるいはメンバーの成長プロダクト東力ひいてはビジネスの成功プロジェクトの成功そういったものに波及していきますので
有効に使えたことによる効果は非常に大きいですですので長期的に見てもこのべ飛ばすで腹部を有効にしておくというのは価値が非常に高いイベントになりますのでぜひ皆さん今から説明するものを取り入れて a参考にしてもらえればと思います
では早速ですけれども retrospective をスタートするにあたってどういった点から取り組めばいいかというのをまず説明していきますまずレトロスペクティブいうは順番的にはスプリントレビューで製品に対するレビューを
プロダクトオーナーあるいはユーザーから受けた後にスプリントの最後としてスプリントのイベントの最後として実施するものと今位置づけていますですのでこのスプリント全体を振り返ってどうだったかという視点で良い点
よくできた点成長した点は勝った店様はポジティブな点ですねと problem問題だった店失敗した店不安だった店そういったところを張り出していきますまずは15分方の時間をとって各メンバーに
両方記入してもらえます相談をせずにまずはメンバー1人で各々が考えたgood なテントプログラム等10%程度を書いてもらいますこの場合にメンバーに対する1つのルールを設けますそれは
3対1という割合ですねプログラム1つに対してグッとさん出すというルールですこれはなぜこのルールを課すかと言いますとこれはロサダラインと言いましてこのプログラム1位というのはいわば問題を書くということですから
ネガティブな内容になりますそれに対してぐっとポジティブな点を3以上出すということによって人間は心理的にニュートラルの心理になりますそれからいいこのネガティブなペンというのは心理的な影響がネガティブな影響が大きいんですねそれをニュートラルにするのに3以上必要だということになりますので
プロベルを1に対してぐっとさんを出すということをまずはチームメンバーのルールとして化してみてください中にをですね problem も思いつくんいくらでも思いつくんだけどgood 思いつかない
というメンバーがいるかと思います例えば具体的な例を挙げますとproblem にa さんが毎日0 d スクラムに来れないこれはプログラムだと書いたメンバーがいるとします
その場合はその problem に対してグッドはないのかという視点をスクラムますとそのメンバーに投げかけてみてください例えばですけれどもa さんが毎日デイリースクラムに来れないであればでも他のメンバーは毎日来てるんだよね
あるいは毎日これないと言っても本当に0日だったこれた日もあるんじゃないという形でできていることうまくいっている麺
それらもあるんじゃないかという投げかけですねをしてメンバーの視点を変えてみてください問題は人間の場合は機器とか不安とか恐怖に対しては簡単に反応しますこれ本能として反応するようになっていますしかしポジティブな面というのは実は
考え出さないと出てこないんですねですので問題をその事象の問題目にだけを見て捉えるのではなくてその事象の良い綿ポジティブな面こちらにも目を向けるというのは視点をぐっと全く違う面から見れるように変える必要がありますから
それをスクラムましたは訴えかけてみてくださいそれによって各メンバーは3対1というバランスで出してそれを皆さん前張り出してくださいと張り出していった中でメンバーたんで重複するものが出てくると思いますのでその重複したものを重ねるなり取り除くなりしていくと張り出したものは3対1にならない場合もあると思いますけれどもそれはそれで大丈夫
ですメンバー1メンバー1人のメンバーが3対1で出すというルールさえ守ってもらえれば大丈夫ですそしてこの good プログラムですけれどもこのプログラムの中から
具体的にどう改善すれば良いかというトライに落とし込むという作業をします例えばプログレボニー官僚の定義があいまいなままレビューを受けて失敗したと書いたメンバーがいるとします
この場合の官僚の条件が完了のの定義が曖昧なままレビューを受けたという状況に対してチームメンバーがどういう状況だったんだろうと話し合ったりしても ok ですその場合でどうすればトライになるかなどうすれば改善できるだろう
このプログレも修正できるだろうと考えますこの場合ドライにするときにこれをそのままこの例えば最後の失敗したというのを失敗しないようにするとかだとトライとしてはあまり効果のあるものになりません
まずドライは具体的な行動でアリー測定可能なものにしてくださいいわば第三者が見てもその行動をとったらその改善を試みてるなその改善がが前に進んだよなということを
わかるものを確認できるものにしないといけないのでこれをじゃあどういう形にすればとラインできるかということを考えますそれによってじゃ官僚の定義に不明瞭な点があれば即 bo に聞く
というこういったトライ王思いついたとしますしかしこれだとまだ測定が可能ではないですね
この場合だと二メールの点があればという if という状態と即病に効くという場合も即美容に効く本当に来たのかあるいは効かなかったのかこれは本人以外わからないですよね第三者から見て疑問に思った瞬間聞いているっていうことが判断できない確認ができないのでこれだと
まだトライとしては弱いですねこれをどういう形の捉えにすればこの問題を解決できると欄になるのかこれここで視点を変える発想を変えるということが必要になります
そのためにこの good をたくさん出しておくとより創造的にメンバーがなるきっかけになりますからどのようにしてトライにすればいいか一つの例ですけれども
このあいまいまあの曖昧なままレビューを受けてしまったであれば問題になるのはスプリントの一番最後のスプリントレビューで
官僚の定義が曖昧だったとわかることですねこれが本当の最悪のパターンですであればそれを回避する方法を考えてみますこれは団に持っていった時点で po レビューを受けるいわばスピンとレビューで初めてぴ太レビューを受けるのではなくてその前倒しにして
ダーンになった時点でも美容のレビューを受けてしまうという方法ですねそうすればこの po レビューのタイミングデーもし官僚の体が不明瞭なのであればわかりますそこで開発者と po の話し合いの中で完了の定義をより具体的なも詳細なものに修正を
すればいいであれば最後のスプリントレビューに間に合う可能性は上がりますといった形でこの problem をどういうトライにすればその問題を軽減できるのかあるいは回避できるのかこういう具体的な方法を考え
考えてここに貼り出しますお前はこのホワイトボードの関係上大きなものに書きましたけれども実際にはこういった小さな付箋で書くと思いますのでこれをここに書いたとしてですねトライとして
problem をどんどん校トライにしていきますそれによって次のスプリントで複数あるトライの中からどれかを選んで
スクランボードの上に貼ってこのトライを今日やるのかどうか今日やっているのかどうかあるいは昨日行ったのかどうかというのをデイリースクラムの中で走りデータが確認をしていく
これはあの前回のスクランボードの使い方の中ですね少し触れましたけれどもこのトライは実際に実施されてないとダメなのでじっしょさせるためには中銃を向けさせる必要がありますこのトライをやりなさいねというアテンションをかける
必要があるんですねですのでできればこれはここに張り出しぱなしではなくてスクラムボードの上に貼ってデイリースクラムのを開始時に星るデーターがこれやってますかこのトライやってますかこのトライうまくいってますかというのをアテンションをかけて習慣化していく
いうのをこのトライからうまく0スクランボードに移植していきますスクランボードに貼られたこのトライお魚また次のレトロスペクティブデーそのトライがもうまくいっているとチームのメンバーが意識せずと思う週間かついて自動的にできるようになっているというのであればそこでこのトライを
スクランボードに貼ったいものですね持ってきてキープに貼って次のスプリントでは別のトライを捉え実行しましょう行動に移しましょうという形で自分たちのチームのグレードを上げていくわけですね
そしてこのキープの領域をどんどん増やしていくことでチームが成長しているできていることが増えているという状態を可視化していきますどうしてもソフトウェア開発においてできてない点うまくいってない点不具合が出てしまったでグレードしてしまったユーザーに迷惑をかけた
そういった点がどうしても意識の中で注目されがちですするとついついマインドはネガティブになっていき発想力はどんどん狭まり視野も狭まり生産性を打ちます想像力も落ちますそういったたことを防ぐためにもこのキープとぐっとこれらを可視化しておいて
できてないところはあるかもしれないでもそれでもできているところもあるし4なく行っているところもある以前できなかったことができるチームになっているといったなるべく自分たちのマインドをニュートラルあるいはよりポジティブにしておくという一つの
ツールとして張り出しておくのが良いと思いますスクランボード同様に見えるところに張り出しておくことでチームは自分たちがやっていることが100点は取れていないかもしれないけれども80点を取れていると足りないに20店に対して議論することも重要ですけれどもできている80点から学ぶ
こともあるんじゃないかといった形でなるべく自分たちの創造性あるいはマインドをポジティブにしておくそういったことも今レトロスペクティブの中で一旦はマインドをリセットするあり上ポジティブにしておくというふうに使えるといいと思います
retrospective の一つの具体的なテクニックを説明しましたけれどもそれらを概念を少しここで説明していきたいとおもいます問題というのは目に見える症状あるいはへ
それをとらえることができる表面的な症状に過ぎませんですから例えば鼻が詰まるあるいは熱が出るあるいは席られるこういったものは症状ですよねそれに対してその症状を
問題として置き換えた場合にそれらの対処の方法としてそのまま対処しようとすると問題は根本的な解決を根本的な解決されないままになります問題が長引くわけですね
例えば鼻がつまっているとなった場合のその症状への対処としてはティッシュで鼻をかむとかであればその瞬間は鼻づまりが軽減されたり鼻づまりが解消しますけれども根本的な解決にはなりませんね問題をそのまま問題として解決しようとするとうまくいかないということが往々にしてあります
いわば根本的な原因が実は問題とはちいっ全く違った面にあるということはよくあるんですね先ほどの鼻詰まりの例でいけば根本的な原因は風邪なわけです体力が低下して免疫力が下がっているこれらが根本的な原因だったりしますのでそこに対処して取り除く
あり置き換えるそういったことを試みないと問題は長引いてしまうあるいは悪化してしまうということが起こりますその場合問題を問題として捉えるのではなくて違った視点で見るというアプローチとしこのポジティブな視点というのを導入しますそれと
問題ばかりを見て見ていた時に考えていた時には思いつかなかった別の面を見てみようとなると問題から少し離れますので距離をおきますので弾いて全体を見るというきっかけが生まれます
すると今まで気づかなかった見えてなかった根本的な原因これを発見する確率が上がりますそして根本的な原因がもしかするとこれじゃないかと発見できた場合は
それらに対しての解決解決案というのをリストアップしてみますそれだおすべて片っ端からやるわけにいきませんのでその中で緊急度が高く効果の高そうなものこれらを抽出して選出して
解決策として実施してみますこの場合も1回実施しただけではんなかなかうまくいかないということもありますしそもそも実施しようとしてるんだけれども実施がされなかったということもあると思います
そういう場合に実施がなされてその原因が取り除かれるまで反復をするということも必要に行ったりします反復をしたんだけどそれでも根本的な原因を取り除くことになっていない
解決ができていないとなれば解決案を修正するそしてまた新たな別の解決案から解決策を選出して実施をして反復をするということを行いますこれらが先ほど紹介したあの4つのますのボード
good problem トライキープこれらを書いて張り出していくというプロセスが実はこのような概念に基づいて行われることになりますですから
問題を問題のまま解決しようとするのではなくて新しい別の視点ポジティブな視点というのを申し込むことによって広い視野になり別の面から眺めるというきっかけこれをメンバーに与えることによってより有益な創造的な解決策というのを思いつくきっかけを与えるこれがいわば学習ですね
ですので retrospective では学習するという要素学習をしようとするのではなくて結果的に学習というプロセスを経ているという仕組みにするというのがretrospective を継続して運営していく中には有益にretrospective の価値を高め続けられることになると思います
ですからぜひレトロスペクティブをみなさんのチームの中でも形骸化させずにより良いものとして価値の高いものとして継続して実施できるようにしてみてくださいこのレトロスペクティブと
その他のモデルだったり管理するべきものをとどうつながっていくか最終的にはレトロスペクティブは先程説明したらこの箇所でしたけれども全てに対してretrospective をかけるというのが最終形態だと私は思っています
ですので一番初めチームがまだスクラムに慣れていないあるいはアジャイル開発に慣れていないという時からこれらすごくはこれがすべてをレトロスペクティブで実施するのはちょっとやり過ぎになりますけれども最終的にはretrospective の中でそれぞれ見て精査して修正していくということが
できるの目指すといいと思います先ほど説明したのはこの箇所でへ直近の最後に取り扱ったスプリントの中でどうだったかというのを振り返る場所になります
けれどもそれらはですねここで出た problem あるいはトライをこのリスク管理領域でリスク管理表の中にどんどん追加していきますリスク管理表の中でもうすでにすぐに対処しないといけないあるいは
問題としても顕在化してしまっているこういったものはこの妨害リストに入れて対処することにしますその中でもそれはプロダクトに関係あるものだプロダクトの機能としてあるいは製品の品質として対処する人があるあるいは機能として対処する人があるというのであればそれはプロダクトバックログに
入れていきますでこのリスク管理の中でリスクというのは表面化したものではなくてこれから起こる可能性があるものそれを全てひっくるめて管理するものですからまだ顕在化していないあるいはもうこれから出るかもしれない
そういったものをこのマップとしてまずは把握しておくそれらを管理品管理表の方に起こすということをやればいいと思うんですけれどもこれらはまた別の機会に説明したいと思いますそしてキープになったものは
リスク管理表の中で解決済みにできますので解決済みとするためにここからリスクあるように対して正更新をかけていきますそしてこのこちら側はリリースプランタイミングデー
行ったりしますけれどもこのプログラムとらえようて problem を出すタイミングでも実際にリリースに間に合うのかどうかあるいはリリースしようとしている機能に対して関係あるプログラムがどうかというものも見ていきますその場合はこちら側の
システム全体としてどうなのかこのユーザーストリームアップは要求に対してですからシステムの形として構造振る舞いも含めたモデリングから全体像を把握してそれらをリリースプランというフィルターを通じてプロブレムとして抽出するということもしていきます
そうすることによって直近のスプリントだけをフォーカスするというretrospective ではなくより広い意味で視野を広げた上でトータルとして自分たちがやろうとしていることはシステム全体として捉えた場合に回転策はあるのかあるいは問題は起こる可能性があるのかもうすでに起こっている問題は根本的な解決は
何なんだといった捉え方ができるようになればこのレトロスペクティブという価値はより高くなると思い