AzureDevOpsを使ったScrumの実践_あるある問題への対処方を考えてみた.pdf

Transcript

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

   View Slide

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

   View Slide

3. 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
   

   View Slide

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

   View Slide

5. 改めて、Agile & DevOpsって?
   5
   

   View Slide

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

   View Slide

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

   View Slide

8. AzureDevOpsでScrumをやる(demo)
   8
   

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

16. なにがダメだったのか？
    こうなってない？？
    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
    

    View Slide

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

    View Slide

18. Summary
    18
    

    View Slide

19. 開発者としてアジャイル（スクラム）チームをよくす
    るためにはどうすればいいのか？
    ● 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かもしれない？
    心理的安全性低いチームでスクラムでお互いに
    コラボレートするとか無理。
    

    View Slide

20. 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
    

    View Slide