【アジャイル】スクラム開発 ~ 入門編 ~

■ はじめに

スクラム(Scrum)に勉強する。徐々に書き足していく。

以下が非常にわかりやすかった

https://www.atmarkit.co.jp/ait/articles/1208/07/news128.html

目次

【1】スクラムとは?
【2】スクラムの理論
 1)スクラムの3本柱
 2)スクラムの5つの価値基準
【3】スクラム チーム(Scrum Team)
【4】スクラム イベント
【5】バックログ
【6】その他の関連用語
【7】個人的感想
 1)いいなーっと感じた点
 2)スクラム反対派の意見について

【1】スクラム (Scrum) とは?

* チームで仕事の進めるための枠組み
 => 別に、ソフトウェア開発だけのものではない

* 正確には、以下。

https://www.scrumguides.org/download.html

のスクラムガイドの日本語訳より抜粋。
~~~~~~~~~~~~~~~
 複雑な問題に対応する適応型のソリューションを通じて、
⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである

簡単に⾔えば、スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである

1. プロダクトオーナーは、複雑な問題に対応するための作業を
 プロダクトバックログに並べる
2. スクラムチームは、スプリントで選択した作業を
 価値のインクリメントに変える
3. スクラムチームとステークホルダーは、結果を検査して、
 次のスプリントに向けて調整する
4. 繰り返す
~~~~~~~~~~~~~~~

ネット上で「スクラム いらない」ってみるが、この定義で言うと
それって、もうスクラムじゃないんじゃないの?って思った、、、
(まー、別に、プロジェクトが円滑に進めば、それでいいけど)

動画

* 取っ掛かりとして、ざっくり以下の動画で学ぶのもいいかも。

https://www.youtube.com/watch?v=5JO3qwnYtjw

【2】スクラムの理論

1)スクラムの3本柱
2)スクラムの5つの価値基準

1)スクラムの3本柱

1) 透明性 (Transparency)

* 現在の状況 / 進捗 / 問題点 を常にオープン(見える化)しておく
 => 開発者全員が共通認識を持って開発が進められる

2) 検査 (Inspection)

* 定期的に、進捗状況 / 成果物 / 仕事の進め方に
 問題がないかを確認する
 => 「1) 透明性」により、見える化したことによりできること

3) 適応 (Adaptation)

* 問題があったり、よりいい方法がある場合、
 変化を受け入れ、やり方そのものを変えるなど
 臨機応変に適応していく
 => 「2) 検査」で見つけた問題に対して、改善策を考え、
  「3) 適応」していく

2)スクラムの5つの価値基準

https://www.scrumguides.org/download.html

のスクラムガイドの日本語訳より抜粋。

1) 確約(Commitment)

スクラムチームは、ゴールを達成し、
お互いにサポートすることを確約(Commitment)する

2) 集中(Focus)

スクラムチームは、ゴールに向けて可能な限り
進捗できるように、スプリントの作業に集中(Focus)する。

3) 公開(Openness)

スクラムチームとステークホルダーは、
作業や課題を公開(Openness)する。

4) 尊敬(Respect)

スクラムチームのメンバーは、
お互いに能⼒のある独⽴した個⼈として尊敬(Respect)し、
⼀緒に働く⼈たちからも同じように尊敬(Respect)される。

5) 勇気(Courage

スクラムチームのメンバーは、
正しいことをする勇気(Courage)や
困難な問題に取り組む勇気(Courage)を持つ。

【3】スクラム チーム(Scrum Team)

* 以下の関連記事を参照のこと。

https://dk521123.hatenablog.com/entry/2021/02/17/000000

【4】スクラム・イベント

* 以下の関連記事を参照のこと。

https://dk521123.hatenablog.com/entry/2021/02/19/000000

【5】バックログ

* 以下の関連記事を参照のこと。

https://dk521123.hatenablog.com/entry/2021/02/18/000000

【6】その他の関連用語

1)ベロシティ(Velocity)

* スプリント期間で、そのスクラムチームの開発量を表したもの
 => 進捗状況を計る目安となる
* Velocity = 速度

2)バーンダウンチャート(Burn-down chart)

* プロジェクトの残りの作業量と
 その作業を行うための時間をグラフ化したもの
 => 「実績線」「計画線」「理想線」で表示され、
   プロジェクトの進捗状況が計画から
  どのくらい離れているのかを一目で分かる

【7】個人的感想

1)いいなーっと感じた点

1)レトロスペクティブ (振り返り)で、反省会できること
 => これって中々できない
  => 次に活かすという目的であるなら、
     例えば、プロジェクト完了後やっても、
     終わってるから気持ち的にも気が抜けてるし、
     メンバーがそのまま残るとは限らないので
     効果的はないと思う
  => そもそも、ほとんどのプロジェクトで
    (やったほうがいいと思いつつも)やらない

2)スクラム反対派の意見について




参考文献

https://qiita.com/gold-kou/items/90ba982a14ca79d843c9
https://codezine.jp/article/detail/12296
https://techplay.jp/column/679
https://geechs-job.com/tips/details/30

関連記事

スクラム開発 ~ 基本編 / チーム ~
https://dk521123.hatenablog.com/entry/2021/02/17/000000
スクラム開発 ~ 基本編 / イベント ~
https://dk521123.hatenablog.com/entry/2021/02/19/000000
スクラム開発 ~ 基本編 / バックログ
https://dk521123.hatenablog.com/entry/2021/02/18/000000