プロダクトオーナー研修 2日目感想
昨日に引き続きプロダクトオーナー研修2日目 色々良かったが、中でも勘違いしていた部分を正すことができて、有意義だった
これまでしていた勘違い
アジャイル開発は仕様は最低限しか決めない。INVESTを満たすユーザーストーリーだけを決めて、どういう画面、機能で実現するかは開発者に任せられている。ドキュメントはあくまで最低限で不明点は会話で解決する。プロダクトバックログの役割の一つとしても会話を自然に促すというものがある
正しいこと
スプリントバックログに入ってREADY状態(エンジニアが着手可能)になるものはデザイン含んだ仕様、受け入れ条件、完了条件が明記されている。 ここにあるストーリー、タスクはPOと意思疎通なしで進められることが理想でもし会話が必要になったら、それはPO、チームのリファインメントが甘かったということ
勘違いの原因
プロダクトバックログとスプリントバックログを混同していた。確かにあいまいな状態で会話により進めていくのはあっているが、それはスプリント対象外のタスクにおいてのみ 「仕様が全部決まらないと作れないとか、これだとウォーターフォールじゃん」と思うかもしれないが、アジャイルの真髄は全体像が決まりきっていなくても、ビジョンを分解して部分的に進めて積み上げられるところにある
POのセンス
アジャイルの真髄はビジョンの分解と積み上げ。分解してどうやって積み上げてプロダクトを作っていくかがPOのセンスが問われると思った
- ユーザーにとって最も価値のある機能、MVPは何か
- フィーチャー、エピック、ストーリーは構造的にユーザーストーリーマッピングで整理されているか
- インターフェイスを意識して、各機能の依存は十分に考えられているか
内容のサマリー
プロダクトバックログ、スプリントバックログ、READYの定義は上でも書いたとおり あと細かいが - チームにデザイナーがいる場合:デザイン完了してREADY状態 - ミドルウェアやサードパーティ何使うかの選定:Howの部分なのでチームメンバーがやる
あとPOの手前に事業としてマネタイズ、KPIどうするというプロセスがあるが、そこはビジネスアナリストが専門でやる。誰がスクラム的に担当になるかわかっていなかったのでスッキリした。
dailyScrumはとりあえず進捗が見えづらい時、意思疎通で問題が起きている時のカンフル剤、あととりあえずアジャイルだしやってみるかというのでこれまでやってきたが、理想的なのはオールブラックスのハカ。士気を上げてチームでゴールに突進するという意思を統一すること。これまでdaily割とのそのそやること多かったのでここは反省。。。
プランニングポーカーやる時にPOは加わってはいけない、あくまで仕様、要件を説明する係。あと細かすぎる資料、ドキュメントが増えるとポイントは上がる傾向にあるので注意
- プロダクトビジョン
- コンポーネントゴール
- フィーチャー
- エピック
- ストーリー
の順に分解されていく。直近の部分は細くして、未来の部分は割と適当にビジョンだけだったりする。 またスクラムの最初でとりあえずざっくりエピックにポイントをPOの独断でふってポイントの全量を出す。 大体わかると思うが、超あてずっぽう。とはいえ仮説でも出すことが重要 大体3イテレーションくらいやるとズレがわかってくる。そこで再度見直しを行って、正確なバーンダウンチャートが見えてくる。
アジャイルとウォーターフォールの違いは色々あるがしっくりきた表現は計画に対する誠実さ。ウォータフォールはあたかも未来が正確に見積もれているふりをする。 ただスクラムが全面的にいいというわけではなく、結構組織を選ぶ。導入が大変というのもあるし、スクラムに必要な正直、誠実、透明、イノベーションへの意思を持っていないとうまくいかない。
内容はかなり満足 ただプロダクトを考えてチームでユーザーストーリーマッピングしてみようという割と大きめのワークがあったが正直微妙だった
参考
研修のスライドの中で紹介があって、ただただ最高だった
超いい
— 田野 晴彦 (@hikoharu06) 2018年3月23日
内容的には1週間スプリントでサングラスの店頭での写真撮って比較するアプリを作るというものフラッシュモブならぬフラッシュビルド、エンジニア、デザイナーが1週間サングラス店にPC置いて現場でプロトタイピング、インタビューをやっていくhttps://t.co/FVkcRa8YBo
プロダクトオーナー研修 1日目感想
Sierでなんちゃってアジャイルやったり、スタートアップにアジャイルプロセス導入したり、アジャイルサムライ一通り読んでみたり スクラムとは結構3年くらい付き合ってきたものの、どちらかというと現場の叩き上げで学んできたので一度整理したかった。
というわけでこれ行ってきた
先に前提としてPO,SMの役割について
プロダクトオーナーとは
プロダクトのWhatを扱うもの。Howには決して言及しない。チームメンバーに任せる。 半分の時間は顧客、ステークホルダーと過ごして、半分の時間はチームと一緒に過ごす。 プロダクトマネージャーとの違いは諸説あるが、Scrum Inc曰く本質は同じで、より「プロダクトの全責任はあなたにあるよ」というオーナーシップを意識してPOと呼ぶ
スクラムマスターとは
プロセスを管理する。チームの幸福度、ベロシティの向上が責務 プロダクトオーナーとは基本的に対立する立場となる。POの機能要求をスクラムマスターは管理しなくてはいけない
内容のサマリー
序盤はアジャイル語る上で欠かせないウォーターフォール叩きから入る。計画から逸脱しない前提でやってるけど現実そんなことはおきないという感じ。 新しかったのは化学工場の例え。「工場で行っている化学反応はリアルタイムで微妙に調整しないとコントロールできない。失敗すると爆発してしまう。最初から全部予測なんて無理だろ」と妙に説得力あった。
アジャイル行う上で重要なものは
- 勇気
- 集中
- コミット
- 尊敬
- 公開
の5つ。 中でも難しい(特に日本では)のは勇気と公開。 これは日本人の謙虚さ、礼儀という性質の副作用。プロセスの透明性、検査によってアジャイルは実現されるが、上記を欠くと遅延、成果物の品質問題を正直にレポートできない、チームの自己組織化が損なわれる あと日本は根回ししすぎ、これはPOが責任取る覚悟が足りていないから。全部決めて、責任取るべき。別に失敗してもクビにならないんだから、もっとリスクを取るべきと
あと大切なのはスクラムをスクラムするという考え方、いわゆるカイゼンというやつ。スクラムやる以上ベロシティを上げるために全力を尽くさなくてはいけない。具体的には以下が有効
- カイゼン:振り返りをして改善できるポイントは次のスプリントの再優先事項として扱う
- やり方:集中というやつ。マルチタスク状態にならないように
- 幸福度:メンバー全員が役割、チームに幸せを感じて働けるように
違和感感じた部分
違和感感じた部分は大体共通していて、いわゆる理想と現実のギャップというやつ
PO,SMの役割分担:メンバーとは明確に必要なスキルが分かれているものの、ぶっちゃけ優秀なメンバーを経験してPOになるケースがほとんどだと思う。POがシニアエンジニア、メンバーは新卒とかの構図も普通に多いはず。PO的にはHowに言及したいし、組織としてもPOにSM的役割、またメンバーのマネジメントを求めている時にどうすればいいのか
ベロシティの向上:ソフトウェア開発は労働集約なので、基本メンバーが最初から十分なスキルを持っている前提であれば、ベロシティがそんな劇的に上がるイメージはない。上げるとすれば時間か人を増やす。ベロシティはものさしでこなせるタスクの量を決めるもの。SMが使うチームを守るための指標で、それをどういうやり取りで上げていくのかイメージできない
メンバーの意識:アカデミックなスクラムではメンバーにタスクがアサインされることはない。メンバーはバックログから勝手に必要なタスクを取っていく。ただ実際には期限、アサインを明確にしないと進まないということからSM権限、あるいは合議でアサインが決まっている。メンバーにそこまでアグレッシブさを求めるのもなと。。。
総じて - 役割全員が十分なスキル、スクラム知識を持っている - なおかつチームに対するビジネス側の圧力がほとんどない(POが十分なスキルを持っているということかもしれないが) - メンバー全員のモチベーションがメチャクチャ高い。労働時間が完全に固定されているか、眼中にない。
という現実にはなかなか揃わない条件が揃った時に成立する部分に違和感を感じた。 ただ仮にこれらが実現できなくても、スクラムのメリットは十分だと思う