AzureDevOpsを使ったScrumの実践 &あるある(?)問題への対処方を考えてみた AgileTalk #techplaygirls　2020/08/28 yuriemori　

今日はこんな感じで 1. About Me 2. 改めて、Agile & DevOpsって? 3. AzureDevOpsでScrumをやる（demo） 4. あるある(?)問題&その対処法を考えてみる(Retrospective) 5. Summary 6. KEEP CALM AND SCRUM ON 2

About Me yuriemori（森　友梨映） Twitter: @1115_lilium ○ 前職：web developer@日系のベンチャー（自社開発） ○ CRMソリューションの開発をやってました ● developer @Avanade Japan（MSとAccentureのジョイントベンチャー） ○ Digital Marketing領域のdeveloper ● C#, SQL, JavaScript/TypeScript,　.Net, Azure ● アジャイル（スクラム）の経験は2年ぐらい ○ 転職したばっかりなので今日は主に前職での経験を基にお話します 3

アジャイルやってるけど何 かうまくいかない、、、 何がダメだったのか？ どうやればマシになるんだろう？ 開発者としてアジャイル（スクラム）チームをよくするためにはどうすればいいのか？ ※このLTはセルフレトロスペクティブ的な感じです 4

改めて、Agile & DevOpsって? 5

Agile≠DevOps ● 開発チームとエンド ユーザーのギャップを埋める ● 顧客のニーズや期待に迅速に対応する ● 開発と運用がコラボレートしてLean（無駄のない）ソフ トウェア開発という思想、カルチャー ● DevOps は、開発、運用、品質保証の集合 Agile DevOps スクラム XP TDD かんばん ペアプロ CI（継続的インテグレーション） 自動ビルド CD（継続的デリバリ） 6

Client Devs Ops Agile=ClientとDevsとのgapを最小化 DevOps=DevsとOpsとのgapを最小化 7

AzureDevOpsでScrumをやる(demo) 8

スプリントプランニング デイリースクラム &開発 レトロスペクティブ（振り返り会） スプリントレビュー（お披露目会） リファインメント（途中確認） 9

あるある(?)問題の対処法を考えてみる 10

仕様変更に振り回される 開発入ってから「やっぱりこれはこ うで！」 レトロスペクティブが反省会っぽく なってお通夜状態 仕様フワフワのまま開発 突然の割り込み リリース前日に「ここのデザイン ちょっと変えてよ！」 開発サイドvsビジネスレイヤー bis「この施策〇日からスタートさせたいから この日までに絶対リリース！」 devs「そんな急かされたら質のいいソフト ウェアはできない！！締め切りきつい！残 業多い！！」 見積が上手くいかない。 実績よりオーバーしがちで申し 訳なくてつらい。 色々フワフワ。ドキュメントな い。暗黙知が多くて効率悪い。 オーバーワークで開発メン バーが疲弊しててチームの空 気が悪い 11

見積が上手くいかない。 実績よりオーバーしがちで申し 訳なくてつらい。 Problem Solution/Try 見積りはフィボナッチでいれた ら？ 開発者が1人で決めるんじゃな くて、スプリントプランニングで プランニングポーカーとかで皆 で決める。 （経験の浅い開発者だとそもそ も見積なんて無理ゲーでは？） 見積の単位の基準を見直す。 （時間じゃなくてストーリーポイン トにするとか） AzureDevOpsの拡張機能の Estimate使おう 12 見積り問題

Problem Solution/Try 受け入れ条件と仕様を fixしない とチケット切らない体制を作る （SMに協力してもらう） 勝手な割り込み許すまじという 強い意志を持つ。 そういうカルチャーを作る。 割り込みされたら即 SMにエス カレーション。 コーディング規約とかアーキテク チャで守るべき最低限のことと かはAzureDevOpsのwikiにス タックして共有する 仕様フワフワのまま開発 色々フワフワ。ドキュメントな い。暗黙知が多くて効率悪い。 仕様変更に振り回される 開発入ってから「やっぱりこれはこ うで！」 イヤ！という勇気を持つ 予想外の事があったら即 SMに エスカレーション。 13 sprint0の期間を設ける？（アー キテクチャとか受け入れ条件と か開発前にfixしたいことをfixす るためのsprint） ※スクラムの公式プラクティス ではない 仕様フワフワ問題 突然の割り込み リリース前日に「ここのデザイン ちょっと変えてよ！」

Problem Solution/Try お菓子食べながらやる （できるだけ深刻な雰囲気を作ら ないように） というかチームの雰囲気を良く する（心理的安全性を高める） のもスクラムメンバーの missionという意識を持つ 辛いということ（問題がある）を主 張する レトロスペクティブが反省会っぽく なってお通夜状態 オーバーワークで開発メンバーが 疲弊しててチームの空気が悪い レトロスペクティブ =このsprintでの 自分の罪はこれです。ごめんなさ い。。 ではなく、 「チームを改善させる場」。 問題が仕組みで解決できないか （ドキュメント残すとか自動化する とか）とかを考える場。 転職する 14 雰囲気悪い問題

Problem Solution/Try bisもdevも「よりよいソフトウェア でユーザーをハッピーにする」と いうmisionは同じ ニュータイプじゃないんで 対話する 開発サイドvsビジネスレイヤー bis「この施策〇日からスタートさせたいから この日までに絶対リリース！」 devs「そんな急かされたら質のいいソフトウェ アはできない！！締め切りきつい！残業多 い！！」 15 なんかほとんどのProblemは discommunicationが原因では？ 仲悪い問題（価値の対立）

なにがダメだったのか？ こうなってない？？ devs プレッシャー的な何か 開発者はSelf-Managingであるべき。 （いいなりになってはいけない） Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how. (by Scrum Guide 2020) 対話をおろそかにしてた 。開発だけやってりゃい いってもんじゃない。 「プロセスやツールよりも 個人と対話を」by アジャ イルソフトウェア開発宣言 16

なにがダメだったのか？ そもそもちゃんとスクラムのプラクティスを実践できてなかった (´;ω;｀) 本来こうあるべき スプリントプランニング デイリースクラム &開発 リファインメント（途中確認） スプリントレビュー（お披露目会） レトロスペクティブ（振り返り会） こうだった、、、 デイリースクラム &開発 スプリントレビュー（お披露目会） レトロスペクティブ（振り返り会） 17

Summary 18

開発者としてアジャイル（スクラム）チームをよくす るためにはどうすればいいのか？ ● Self-managing(team buildingとかmanagementをSMに丸投げしない) ● 対話する（Agileはカルチャー） ● 心理的安全性の高い team building ○ Successful use of Scrum depends on people becoming more proficient in living five values: Commitment, Focus, Openness, Respect, and Courage (by Scrum Guide 2020) 理的安全性低いチームでスクラムでお互いにコラボレートするとか無理。 19 そのProblemの原因はひょっとすると discommunicationかもしれない？ 心理的安全性低いチームでスクラムでお互いに コラボレートするとか無理。

KEEP CALM AND SCRUM ON ● References in this LT: ○ DevOps とアジャイルの比較 　 https://azure.microsoft.com/ja-jp/overview/devops-vs-agile/ ○ Scrum Framework https://www.scrum.org/resources/blog/scrum-classroom-part-2-time-change ○ DevOps Cycle (https://mendix.buildsystem.jp/mendix-guide-devops-overview/) ○ Scrum Guide 2020 (https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf) 日本語版：https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf ○ アジャイルソフトウェア開発宣言 (https://agilemanifesto.org/iso/ja/manifesto.html) ● For further study: ○ SCRUM BOOT CAMP THE BOOK ○ アジャイルサムライ ○ Scrum On Avanade TechTalk （前編） Avanade tech talk #1イベントレポート【前編】 —— アジャイルとスクラムを徹底解説 ○ Scrum On Avanade TechTalk （後編）　 Avanade tech talk #1イベントレポート【後編】 ——スクラム開発で気をつけるべきポイント 20