LoginSignup
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

@fruscianteee

スクラム勉強会

Last updated at Posted at 2021-06-19

以前、勉強会で使用した内容を書き残します。
これからアジャイル開発をしたいと思っている人、
少しスクラムの業務経験があるが、アジャイル開発やスクラムがなんなのか腹落ちできていない人、
に向けた勉強会資料です。
想定時間は1.5~2h。細かいところは口頭で補足しながら、聞いている人たちと話しながら進めていきます。

ゴール & 目的

  • スクラムの概要と何を意識するべきかを理解し、スクラムに興味を持っていただく。
  • 今後の業務に活かして欲しい。

アジェンダ

  • はじめに
  • スクラムとは
  • アジャイル開発とは
  • メリット、デメリット
  • スクラム詳細
  • 終わりに

はじめに

スクラムと検索した時に、色々解説しているサイトがあると思いますので、
そちらで詳細は補完していただき、ここではイメージしやすいように一部解説しつつ、そこに載っていないような情報も挟んでいこうと思います。

注意点

人によって実務や講習を受けた人に理解に差が生まれたりするので、
私の解釈のスクラムと思っていただければと思います。
不明点や質問は、どんどん口を挟んで聞いてください。

スクラム(scrum)とは

  • アジャイル開発の開発手法の一種
    • なので、「アジャイル開発で開発してますっ！」って言っても、「なんの？！」
    • って思われる可能性があるので、「(アジャイルの)スクラムで開発してます！」の方がいいかもしれない
  • トヨタ生産方式を参考にして作られていたりします。

アジャイル開発とは

スクラムは単にアジャイル開発の手法の一種でしかないため、まずはアジャイル開発を知る必要がある。

これだけを意識していれば、アジャイル開発はマスターできます！！

ウォーターフォール開発とは

v_shaped_model.png (82.2 kB)

画像引用元 1

ウォーターフォール開発とのイメージ

その１

シンプルに見るなら、こんな感じ
article-image02-2.png (61.8 kB)

画像引用元 2

その２

よくケーキで例えられます。
cake.png (22.0 kB)

画像引用元 3

その３

イテレーティブ開発とインクリメンタル開発

メリット、デメリット

ウォーターフォールのメリットデメリット

メリット デメリット
納期が決まっているので、スケジュールが建てやすい 納期が決まっているので、それを守るために死に物狂いに頑張る必要がある。そのため、品質も犠牲になりやすい
実装機能や仕様をじっくり計画するため、予め決まっているので、何をすればいいかわかりやすい それでも仕様は変わっていく、、、。デスマーチの始まり！！
バッファを積むことで、事前に多めに予算を確保できる デスマーチで伸びると、どんどん開発費用が膨れ上がっていく
予算内であれば、どんどんメンバーを追加可能 人が増えるたびに管理コストやリスクが出てくる。
計画時の実装機能を網羅できる 規模が大きいシステムだと、リリース時にほしかった機能を網羅できない可能性がある

※少し意地悪に書いています

アジャイルのメリットデメリット

メリット デメリット
仕様がモヤっとしているプロジェクトに向いている モヤっとしているからってモヤっと依頼される場合がある
納期がない そこに甘えるとプロジェクトが破綻する
初回実装時の機能が少ないため開発しやすい その分、品質については妥協できない
現状の機能を見て、次の実装を考えるため、仕様変更に柔軟に対応しやすい それだけ仕様変更が多い
初期で実装する機能分の費用を考えればいいので、初期予算が抑えられる 次の追加開発予算をもらうのにかなり苦労する
積極的に動く人にあっている WF開発があっている人には少しつらい
色々実装や設計など幅広く経験できる それだけITの基礎知識が必要なので初心者チームだとパフォーマンスが出ない可能性がある
慣れると開発スピードが想像以上に上がる そこに行き着くまでにはCI/CDなどの自動化の仕組みがほぼ必須
常に動くものがある。 途中でいつ切られても良い覚悟が必要。
QCDを意識しよう

アジャイル開発タスクを消化する際に、特に意識して欲しいことは、QCDになります。
※基本的な仕事でも使えるテクニックなので、是非とも活用してみてください！

Quality：品質(製品、ソフトの品質)
Cost：コスト(費用、人、機能)
Delivery：期限(リリース時期)

基本的にアジャイル開発では品質を落とすという選択肢はないので、
品質を担保することで、何を犠牲にするかを考える。

■いついつまでに納品することになりました。＞お客様
パターン1：間に合わせるために人数を増やす
パターン2：機能を減らす

■これだけの機能を実装して欲しい＞お客様
パターン1：それだけの機能は多いので、納期を延ばしてください
パターン2：納期も伸ばせないのであれば、メンバーを増やしてください。

■これだけの機能をこの時期に納品して欲しい＞お客様
パターン1：絶対に無理なので、できません。
パターン2：色々工程を減らしてバグだらけまともに動かない可能性もありますが、それでいいですか？(お客様に「それでもいい」と、言われたら従うが、ツケは開発メンバーとお客様に返ってくるので非推奨)

スクラム詳細

ロール

役職はなく、以下のロールのみがあります。これらはフラットな関係です。

  • プロダクトオーナー(PO)
    • プロジェクトに責任を持つ人
    • 仕様を決める人
    • ROIの最大化を意識したタスク作り
    • ちなみにPOが2人以上Pjに居たら、スクラムは破綻する。
      • 何故だと思います？
    • インセプションデッキを作成する
    • バックログ を作成し、優先度を決める
      • バックログ毎に受け入れ基準を設定
        • 指定の画面、ボタンが配置されていること。
    • Doneの定義
      • コードレビューしたか
      • 各テストを行ったか
        • 画面の表示速度は遅くないか
  • スクラムマスター (SM)
    • スクラムのルールに沿っているか確認
    • このプロジェクトの障害となる要因を全て排除する
    • チームの進捗や問題を見える化をしていく
    • POの方向性を修正
    • ファシリテーター、タイムキーパー
    • 上記は行うが、決して指示しない。メンバーを促すのみ。
  • 開発メンバー
    • 一番上のタスクを全力で消化していく
    • スタンドアローンではなく、協力していく
      • 自己組織化を目指す
    • どのように開発していくか、手法は開発メンバーが決める
    • スプリントスケジュールを意識する
    • バックログを作成する

イベント(儀式)

重要：以下のイベントをこなすことで、スクラムを行うことができるが、
各イベントの真意を理解していないと、スクラムの真価を発揮できない。

  • デイリーミーティング（ここで言う夕会）

    • 報告内容
      • 前回まで行ったこと
      • これから行うこと
      • 困っていること
    • タイムボックス
      • 人数問わず、15分以内に済ます
    • ねらい
      • 困っていることがないか把握する

  • スプリントレビュー

    • demo
      • そのスプリントで行ったバックログについてメンバーからPOに対して説明する
      • POがOKをだせば、バックログがDoneになる
    • スプリントの分析
      • メンバーからそのスプリントで起きたことを報告する
        • 遅れた理由は〇〇で休みが多くなった
        • 見積もりが少なめ/多めに積んだから、早く終わった/終わらなかった
      • バーンダウンチャート、ベロシティの傾向分析して共有する
        • 重要なので、詳しく説明
    • ねらい
      • POが承認する品質であるかどうか判断する大事な時間

  • レトロスペクティブ(振り返り)

    • KPTを実施
      • よかったこと、気になること、挑戦したいこと
    • ねらい
      • チームのモチベーションを上げていく
      • 問題、リスク、スケジュールなどを共有

  • スプリントプランニング

    • プランニングポーカー（いつやってもOK）
      • タスクごとにポイントを割り当てていく
    • タスク分割
      • 開発メンバーがバックログ の詳細を掘り下げる
    • ねらい
      • 規模感を把握することでチームの開発力やリリース時期を把握することができるようになる。
      • かなり重要な部分

  • リファインメント

    • 中長期のバックログを確認し合う
      • PBI追加や変更などを共有
      • 大きなPBIの分割
      • 各PBIを着手可能にする
      • ポイント見積もる
    • ねらい
      • 少し先のことが見えることで、どう動くか開発チームが意識できる

スクラムを導入すると成功するのか！

闇雲に導入しただけでは、成功しません！！！
※前提としては、スクラムあくまで開発のフレームワークなので、
　初めての開発でどうやって開発を進めていいかわからない場合、
　今のお客様の要望の出し方と開発方法がうまく噛み合っていない場合などで
　一度試してみると言う意味で、やると良いと思っています。

大体、期限が決まっている、実装機能が決まっているものであれば、WFで開発した方が楽だったりします。
合わなければ、スクラムを止めることも、アジャイル開発の変化に対応すると言う意味で行います。(このような決定もスクラムマスターの仕事だったりします。)

終わりに

イメージは掴めたでしょうか？
気になったことがあればいつでも聞いてください！

資格

資格も用意されているので、興味があれば、受けてみてください！！

  • CSM 認定スクラムマスター
    • 研修日 2~3日
    • 受験料 20~30万円前後
  • CSPO 認定プロダクトオーナー
    • 研修日 2日
    • 受験料 20万円前後

参考書

入門書

ガチ

  1. https://webrage.jp/techblog/v_shaped_mode/ ↩

  2. https://backlog.com/ja/blog/advantages-and-disadvantages-for-waterfall-model/ ↩

  3. https://teamhackers.io/goal-setting-changes/ ↩

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?