Upgrade to Pro — share decks privately, control downloads, hide ads and more …

アジャイル開発お悩み相談会_vol.4_Q&A

 アジャイル開発お悩み相談会_vol.4_Q&A

2024/1/24に開催したアジャイル開発お悩み相談会でいただいた質問と回答資料です

SHIFT_EVOLVE

January 24, 2024
Tweet

More Decks by SHIFT_EVOLVE

Other Decks in Technology

Transcript

  1. 当日出た質問 アジャイル開発 全般についての 感じている課題 があればご記載 ください 2024/01/24 ~PO 問題どうしてる?~ 回答

    アジャイル開発のガイド ライン( アジャイルガイド など) に、どの程度従うべ きなのでしょうか? スクラムガイドのことでしょうか。ス クラムガイドに書いてあること(スク ラムのフレームワーク)はすべて導入 しないと本来の効果は得られません。 外れる場合は、デメリットを理解した 上で実施する必要あります。 アジャイルの管理方法は使っているが、やっていること はWF のようなプロジェクトにしか参加したことが無い。 アジャイルをそもそもどのような時に導入するか、WF と 比べた利点は何かを理解しないまま運用を始めるプロジ ェクトが多いのかと思っていますが、アジャイルの経験 豊富な方からはどうやったらアジャイル開発がうまくい くのかなどの前提条件やどの層まで意識させるか等はご ざいますか? なぜWF ではなくアジャイル開 発をするのかの理由、目的を明確にして合意す るのが第一歩です。 また、アジャイル開発をスムーズに導入するに は組織の理解(今までにやり方を変える)が必 要なので、社内のルールを変える権限がる層ま で理解してもらう必要があります。 先ずはそのままやってみるのがいいと 思います。そのまま実施することによ ってスクラムの透明性、検査、適用が 出来てくるので1 つのイベントを実施 しなかったりすると何かが欠けます。 従えないものがあるのであれば、 それがどういう影響を及ぼすのかを 考えないとアジャイルを導入する メリットが失われる可能性が高いです。 最低限の軽量フレームワークですので、こ れができないとそもそも何もルール化、仕 組化できないになってしまうと思います。 現場でアジャイルやりたいぜーに なっても、予算や権限の問題から、 なかなか実現できないのが現状で、 上位層の理解を得る必要があります。 小さいプロジェクト、社内ツールなどで 効果を確認できるようなものから 始めるとよいです 変化の大きそうなプロダクトなどはアジャイルに向いて いると思いますが本当にアジャイルで実施するのかどん なメリットがあるのか検討が必要だと思います。 アジャイル開発が上手くいく前提条件としてはプロジェ クトに対しての決定権がある層までにアジャイル開発の 考え方を理解していただく必要があると思います。 デイリースクラムがた だの進捗報告会になり がちなのが悩みです。 よくある3 つの質問をやっていると 進捗報告会になりがちです。 あとSM がひたすら仕切るとSM への進捗報告になりがち です 開発チームがお互いで困っていること、今話をしないと いけないことを うまく引き出すようにSM がファシリできれば。 アイスブレイクも効果的 スプリントゴールが達成できそうか。 スプリントレビューで価値が見せるこ とが出来そうか を確認するといいかなと思います。 PO に対して実 際に行ったア クション・プ ラクティス ファイブフィンガー PBI の内容があまりDEV に伝わ らなかった。 →PO に対して書き方の指導。 PO とDEV 集めて会議してすり 合わせ。 PO の上にモンスター ステークホルダーが おり、PO の存在感が 薄まってしまってい ます。どう対処した ら良いでしょうか? PO に対して、DEV から 疑問質問が出てきたら 回答するように意識付 けをした 具体的にもう少し どこに困っている かをいただけると 回答も解像度があ がります! PO はWhat、DEV はHow を 徹底するように意識付け。 ※ つまりPO は作り方まで口 を出さないように 全部やりたい! リリースまで1 年以 上かかる開発をやりたい! というP O に対して、できれば小さくリリ ースしていくことを伝えたいなと 考えています( 検査適応サイクルが 回せないので) その際、どのようなことを話した り、どのような切り口から話しま すか? 2 つ。1 つ目はステークホルダーをPO とす る、2 つ目は権限を委譲する。 上記は最終で、まずはステークホルダーが 何をどこまで望んでいるのか?を会話する (※ 例えばしっかり進捗を把握できればい いのか、など) 簡単に腹を割って話 せないような、モン スターステークホル ダーの場合には、ど のようにすれば良い でしょうか? アカマネとか、偉い人 にアプローチできる偉 い人を仲間にして攻略 していく! 要求を出してもらうところを スプリントレビューの場だけ にしてもらうなど、絞っても らうようにしていく。 モンスター=スケジュールを 圧迫するような人? ともあれ、どうにかして「味 方につける」というのが大切 スプリント毎にとどく価値を 作るのがアジャイルですよね 、そうじゃないとアジャイル でやる意味ないよね、とひた すら伝える 1 年後、ほんとに今 考えてるの価値ある ?とひたすら伝える ビジネスとして1 年後成り立つ? 作ることが大切であればWF でもいい のかもしれない。早くFB もらいたい のであればアジャイルかもしれない。 どうしてアジャイルでやりたいのか、 をしっかりと会話することが大切では ないか。 (佐々木から の質問)アジ ャイルでやる 意味って? ステークホルダーやPO から プロダクトで実現したい要 件要求がすべて出てこず、 プロダクトのあるべき姿を 理解して提案しろと言われ ています。 誰に対してどのように動く べきでしょうか? アジャイルを「銀の弾 丸」と考えているのか もしれない、、、これ はまずい アジャイルのプロセス に納得(理解)してい ないのかもしれない SM の場合:PO に一緒に考 えましょうよ!と会話する 。どういう方向にもってい きたいですかー?など どういうポジョションにいる人? DEV の場合:プロトタイプつくってこんな かんじ?と言っていく? 出てる部分で作 ってみました。こんな感じでいかがでしょ うか? ※ プロトタイプってどれぐらい時間かける イメージ?→1 ~2 日ぐらい 今の現場でスクラ ムマスターがPO の タスクをやってい るように感じてい て、兼任はかのう ですか? SM の場合:要件はある と思うので、出てくる ものに対して優先度つ けろ!という DEV の場合:・・・ (いけてない場合=成 熟度が低い)ブリッジP O 的な人を準備して、そ の人が要件をまとめる (いけてる場合=成熟度高い )PO が方向性だけ示す。DEV が何を作るかまで考え実現し ていくことで全体のスピード があがる PO とSM の兼任はダメ! 絶対ダメ!(アジャイ ルにならない気がする ) 多くの開発では、守るべき期日の デッドラインがあると思います。 最低限どこまでリリースできるか 、PO 的には知りたいケースに何回 か遭遇してきました。( ステークホ ルダーに現時点での想定を伝える ため) その際の見積もり、どのように行 っていますか? なぜ? → 何をやっているかわからなくなって くる・・・(体験談) これ正しいの? チームが成立してい る? あたりが怪しくなってきた。 基本的にはバッドプラクティス。かつかつじゃなければ出来るかも ね。 PO がアクセル、SM がブレーキ、いい意味でのせめぎ合いをやるた めにも同じ人だとできないから。限られたリソースで最大限の価値 をだすことを考えたら兼任無理だよね。 あとPO しっかりやろうとするとやること多くて兼任している場合じ ゃない。 ベロシティをみて、PBI の数値 から計算。 今時点の想定です。Must とし ては言えないです、という。 単年度で入札となる案件で あり、どうしてもステーク ホルダーやPO の方が立場的 に強い関係になってしまっ ています。 対等な関係を築くためには どうしたら良いでしょうか? チームの成熟度によって変わりそう。ベロ シティが安定しているなら「これでいけま す!」でOK 安定していないのであればリスクがある、 ここまでは出来ると思うんですけど、、、 とリスク込みで伝える。 実績ベースで、「常に」「 早く」伝える。そうするこ とで想定通りにならなそう でも打ち手が増える。 どうPO を支援していくか難 しいです。PO もステークホ ルダーとの関係があるので 、あまりあやふやには言え ないケースなどもあるので 、どのような武器や情報を 伝えればよいのか... ・・・ プロダクトのことを考えて、こっちも 強気で! 少なくとも下手にでるのは 違う。同じチームなんだから。 一緒に飲みにいく、とかw そもそもアジャイルでやるべきじゃな いかもしれない。 WF だと上下あってよい・・・?→ 請 負という意味ではそうかもしれないが 。 プロダクトの価値とかを上手 にステークホルダーに見せれ れば・・・ スプリントレビ ューでうまく見せるとか。 ステークホルダ ーと同じ目線を もててないから ちゃうか 早く、真実を、伝える。 DEV から見た場合、PO が嘘でもいいから こうだ!と言い切ってほしい。 PO はステークホルダー調整大変なので、D EV にいかないように防波堤になる!(そ のうえでバックログをちゃんと並べる) ※ だからこそPO は大変、、、