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
150
アジャイル開発お悩み相談会_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でセキュリティ運用業務効率UP ~ セキュリティアナリストの頭の中を RAGにしてみた / 20241220 Tetsuharu Kokaki
shift_evolve
0
50
生成AIによるテスト設計支援プロセスの構築とプロセス内のボトルネック解消の取り組み / 20241220 Suguru Ishii
shift_evolve
0
180
XSS攻撃から考察するAWS設定不備の恐怖 / 20241220 Hironobu Otaki
shift_evolve
0
59
SHIFT会社紹介 ビジネスの成功x技術への好奇心(エンジニア組織の未来 vol.2)/20241204 Rinto Ikenoue
shift_evolve
0
140
価値あるサービスを作り続けるためのエンジニアのマインドセット / 20241207 Shoya Shiraki
shift_evolve
0
660
自動化技術を応用したデータ分析環境の構築事例 / 20241207 Shinya Takano
shift_evolve
0
27
まだチケットを手動で書いてるの?!GitHub Actionsと生成AIでチケットの作成を自動化してみた話 / 20241207 Yoshinori Katayama
shift_evolve
1
1.1k
テスト自動化導入事例 ~事例に学ぶ 手動試験に潜む実施コストとテスト自動化の可能性~ / 20241207 Kaname Ohtuski
shift_evolve
2
73
Amazon CloudFrontを活用したゼロダウンタイム実現する安定的なデプロイメント / 20241129 Yoshiki Shinagawa
shift_evolve
0
360
Other Decks in Technology
See All in Technology
Unsafe.BitCast のすゝめ。
nenonaninu
0
150
大規模言語モデルとそのソフトウェア開発に向けた応用 (2024年版)
kazato
2
450
#TRG24 / David Cuartielles / Post Open Source
tarugoconf
0
420
サーバーなしでWordPress運用、できますよ。
sogaoh
PRO
0
170
ネットワーク可視化の世界
likr
7
5.7k
シフトライトなテスト活動を適切に行うことで、無理な開発をせず、過剰にテストせず、顧客をビックリさせないプロダクトを作り上げているお話 #RSGT2025 / Shift Right
nihonbuson
3
1.5k
20241228 - 成為最強魔法使!AI 實時生成比賽的策略 @ 2024 SD AI 年會
dpys
0
340
.NET 最新アップデート ~ AI とクラウド時代のアプリモダナイゼーション
chack411
0
140
動画配信の フロントエンドを支える 4年間とこれから
nisshii0313
0
110
普通のエンジニアがLaravelコアチームメンバーになるまで
avosalmon
0
670
3年でバックエンドエンジニアが5倍に増えても破綻しなかったアーキテクチャ そして、これから / Software architecture that scales even with a 5x increase in backend engineers in 3 years
euglena1215
11
4.3k
TSKaigi 2024 の登壇から広がったコミュニティ活動について
tsukuha
0
180
Featured
See All Featured
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
The Cult of Friendly URLs
andyhume
78
6.1k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
28
4.4k
Making Projects Easy
brettharned
116
6k
Building a Scalable Design System with Sketch
lauravandoore
460
33k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
Visualization
eitanlees
146
15k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
3
230
Done Done
chrislema
182
16k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
3
340
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.2k
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 は大変、、、