初投稿です。結構ふわっふわしてます。よろしくお願いします。
自己紹介
入社3年目のSEで、お仕事はJavaでやってます。クソザコです。現場ではスクラムで開発してます。
研修受けてきたので自身の理解アウトプットと研修を受けて感じた自身の現場の問題点を挙げるために初投稿です。
お品書き
- 研修内容のざっくりまとめ
- アジャイル開発の特徴
- 役割モデル
- スプリントとストーリーポイント、ベロシティ
- 現在の案件現場と研修内容の対比
- 役割モデルからみた現場の問題点
- スプリント
- ストーリーポイント
- 所感
研修内容のざっくりまとめ
アジャイル開発の特徴
ドキュメントよりも動くソースが正義。リリースの早さ is 正義。
必要最低限のドキュメントは作るけど、設計書なんてあったところで何も動かない。
なので頑張って動くもの作ることに集中してください、的なもの。
アジャイル開発の研修とか言っておきながら
スクラムの内容だったことをここで後出ししておきます。
スクラムってのはアジャイル開発における開発手法？フレームワーク？的なもの。
フレームワークなだけあり、中身はスカスカ。
大体エクストリームプログラミング（XP）の手法を使ったりして補ってあげる必要がある。
役割モデル
プロダクトオーナー(PO)
プロダクトの機能に対して責任を持つ。
大体顧客側のIT強くてユーザの要望を受け止める人。
この人がどんなシステムを作りたいか（プロダクトバックログ）を決める。
基本的に1人だけ。
1人である理由は複数人だと意思決定がブレやすくなるため？
スクラムマスター
ざっくりな説明だと「アドバイザー」。
POや後述の開発チームに対して「スクラムとはこういうもの」、
「こういう風に進めたほうがよいですよ」というアドバイスをする（スクラムのやり方をコーチする人）。
あとは開発チームが気持ちよく開発するための雑用も進んでやる。
間違ってもプロジェクトマネージャではない。
よくある現場だとこの役割の人をPMみたいに顧客が認識し、進捗管理をさせられるとか（間違った役割認識）。
開発チーム
開発するマン。
プロダクトバックログからタスクレベルに細分化したものをスプリントと呼ばれる
あらかじめ定義した期間内でどれだけ実現するか（スプリントゴール？）を見積もりつつ、
スケジュールする（スプリントバックログ）。
この人はスプリントゴールに向けてスプリントバックログの機能を
リリース可能な状態に持っていくことに対して責任を持ってる。
※スプリントゴールはPOと開発チームとの間で合意を取る。
あとは継続可能な開発に対して責任を持ってる。
たとえばインフルで人が欠けた際に
タスクを属人化していたために開発が止まる、なんてことが無いようにする。
そのためにペアプロやモブプロやって仕様やソースの認識を共有しておくんだとか。
スプリントと、ストーリーポイント、ベロシティ
スプリント
あらかじめ定義する期間のこと。スクラムではスプリントごとに何かをリリースする。
リリースする内容はスプリントゴール、スプリントバックログによる。
最近だと1スプリント＝1週間がおすすめらしい。
おすすめな理由はスプリントごとにリリースする規模を小さくしやすく
遅れが発生した場合も1週間のうちの1日、2日ぐらいになるため
リカバリ案を出しやすいしカバーも容易らしい。
ストーリーポイント
機能（ストーリー）の規模を示す。ファンクションポイントと似たようなもの。
スプリントバックログごとにどれぐらいのストーリーポイントになるか
メンバ全員で見積もる。
ストーリーポイントはおおよそ1人が2日でできる単純なレベルを3としてそれぞれのタスク（スプリントバックログ）を見積もるのが良いらしい。
ベロシティ
チームにおける1スプリント上のストーリーポイント消化率（仕事率）。
スプリントが完了した段階でどれぐらいのスプリントバックログ（と紐づくストーリーポイントの合計）を消化できたか、というもの。
ストーリーポイントが5のスプリントバックログを7個終えることができたらベロシティは35となる。
この前提でストーリーポイントの合計が350のスプリントバックログを
すべて終えるためにはおおよそ10スプリント必要になる、という形。
顧客に対して「どれぐらいかかるの？」を回答する際の指標の一つとして利用する。
※ただし必ずしもスプリント毎のベロシティが横並びになるわけではない。上下することは当たり前。
現在の案件現場と研修内容の対比
研修で学んだ内容はまだまだあった気がするけど一旦現場の状況と対比してみる。
今の現場はスクラムって感じ。
大前提として研修で学んだ内容を正義とする。
役割モデルからみた現場の問題点
POが1人じゃない（ユーザもPOになってる）し、プロダクトバックログを管理していない
ユーザの意見がまんまバックログに乗ってしまう（どんどん増えていく）。
全体感も見づらくなってるような気がしててあまり良くないと研修を受けて思うようになった。
そんでもってこのプロダクトはいつになったら全部終わるの？みたいなことを言われてたような気がした。
チームとしては全体感をざっくりスケジュールで掴んではいるものの、ダラダラやってる感じがする。
現在4週間のスプリントを2週間か1週間に変更し、その都度必要最低限システムが動く内容でリリースしていけたらいいのに。。。
（みんな進んでる感を意識できるし、後退はしていないのでモチベは下がりにくい？）
###見積もりにストーリーポイント、ベロシティを利用していない
ストーリーポイントで見積もっておけばスプリント毎のベロシティを観察でき、
チームの成長をトラッキングできる。けどウチの現場では利用していない。
自分たちがレベルアップしてることを客観的に知ることができたら
モチベの向上につながると思う。けどウチの現場では利用していない。
見積もりは開発チームの仕事。だって開発するのはこの人たちだから。
でもウチの現場ではストーリーポイントって感じで見積もりをしておらず
結局どれぐらいでこれ終わるの？を「人日」で聞かれてる。
良くないわけじゃないけど日付を意識することが強くなってあまり良くないとか。
日付を意識するあまり、テストがおざなりになるとか……。
もちろんチームの成長率を客観的に捉えることができないので、ただただ忙しいだけ。
ほぼほぼ個人プレイ
タスクは属人化してる。なので研修があって出勤できないとか
個人都合で退社してしまった際に開発が止まってしまう。
もちろん差し込みタスクも発生してそこに時間を使うことは珍しくないし、
結果的にそれでリリースを延期することもあり得る。
開発チームとしての責任が果たせてないと刺されたら何も言えない気がする。
あとこのタスクは自分の責任範囲だ、って意識が強すぎる。
強くならざるを得ない環境になってる。
たぶんフォローをお願いしたらやってくれるけど
自分の能力不足を強く意識するきっかけになるため、モチベが下がる。
※自身の能力不足を意識することが悪いのではなく、その結果としてモチベが下がってしまうことが悪い。
所感
現場の案件推進としては思ってた以上にスクラムだったことは研修を受けてわかった。
その一方で現在の案件推進にスクラムとして課題があることを強く認識した。
自分がアジャイル開発（とはいいつつもスクラム）で案件を推進する環境を作る際には、という意識を忘れず今後はアジャイル開発の推進についてアンテナを張って情報収集をしていきたい。