Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アジャイル開発お悩み相談会_vol.4_Q&A
Search
SHIFT EVOLVE
January 24, 2024
Technology
0
89
アジャイル開発お悩み相談会_vol.4_Q&A
2024/1/24に開催したアジャイル開発お悩み相談会でいただいた質問と回答資料です
SHIFT EVOLVE
January 24, 2024
Tweet
Share
More Decks by SHIFT EVOLVE
See All by SHIFT EVOLVE
さらに高品質・高速化を目指すAI時代のテスト設計支援と、めざす先 / AI Test Lab vol.1
shift_evolve
0
190
テストケースの自動生成に生成AIの導入を試みた話と生成AIによる今後の期待
shift_evolve
0
180
E2Eテスト自動化プラットフォームにおけるAIの活用
shift_evolve
0
180
人財育成は社会を救う~最速でアジャイルなQA人財を育てる仕組み~
shift_evolve
0
130
アーキテクチャを把握し、テスト観点の漏れをなくす
shift_evolve
0
37
アジャイル開発お悩み相談会 vol.5 質問と回答
shift_evolve
0
130
アジャイル開発お悩み相談会2-1_ボード
shift_evolve
0
170
テストの自動化〜始める、使う、捉える
shift_evolve
0
360
LatteArtによるテストログの記録とそれを用いたメンテナンス性の高いテストスクリプト生成技術の紹介
shift_evolve
2
610
Other Decks in Technology
See All in Technology
OSSコミットしてZennの課題を解決した話
dyoshikawa1993
0
150
GoとアクターモデルでES+CQRSを実践! / proto_actor_es_cqrs
ytake
1
150
ACRiルーム最新情報とAMD GPUサーバーのご紹介
anjn
0
150
コンテナ・K8s研修 - 後半 Kubernetes 基礎&ハンズオン【MIXI 24新卒技術研修】
mixi_engineers
PRO
1
120
Amazon FSx for NetApp ONTAPのパフォーマンスチューニング要素をまとめてみた #cm_odyssey #devio2024
non97
0
220
DDDにおける認可の扱いとKotlinにおける実装パターン / authorization-for-ddd-and-kotlin-implement-pattern
urmot
4
390
[NIKKEI Tech Talk]Bias for Action!! 実践から学ぶための仕組とコミュニティ / Community for Practice and Learning
kanamasa
0
260
AIアシスタントの活用で品質の向上と開発ワークフローのスピードアップ
nagix
1
190
「我々はどこに向かっているのか」を問い続けるための仕組みづくり / Establishing a System for Continuous Inquiry about where we are
daitasu
0
170
Datadog Cloud SIEMを使ってAWS環境の脅威を可視化した話/lifeistech-datadog-cloud-siem
gidajun
0
480
テスト・設計研修【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
170
データベース研修 DB基礎【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
210
Featured
See All Featured
No one is an island. Learnings from fostering a developers community.
thoeni
17
2.8k
Web Components: a chance to create the future
zenorocha
307
41k
Fontdeck: Realign not Redesign
paulrobertlloyd
79
5.1k
The Language of Interfaces
destraynor
151
23k
Building Flexible Design Systems
yeseniaperezcruz
323
37k
Typedesign – Prime Four
hannesfritz
37
2.2k
It's Worth the Effort
3n
181
27k
Designing for Performance
lara
604
67k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
26
1.6k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
35
6.3k
Ruby is Unlike a Banana
tanoku
96
10k
Making Projects Easy
brettharned
111
5.7k
Transcript
当日出た質問 アジャイル開発 全般についての 感じている課題 があればご記載 ください 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 は大変、、、