社会人1年目エンジニアのブログ

if you can't explain it simply, you don't understand it well enough.

SCRUM BOOT CAMP THE BOOK

エンジニアになるにしろならないにろスクラム開発にかかわるかもしれないから読んどいたほうがいいよ~と内定先の先輩に言われ、貸してもらって読んだのでメモ

www.amazon.co.jp

スクラム開発って何

アジャイル開発の一つ。最初インフラ系の開発をスクラム開発って言うんだと壮大な勘違いしてた。

ロール

プロダクトオーナー

-プロダクトバックログ(実現したい要求を優先順位が高いのから上にならべてリスト化したもの)の管理
- プロダクトの結果責任を取る
- 全体の進行
- 開発チームには干渉できない。(相談はできる)
→つまりはPMみたいな感じでタスクが順調に進んでいるかとかをチェックする人

開発チーム(3~9人)

  • 開発チームはスプリントミーティングでプロダクトバックログをもとにスプリント中なにをやるのかタスクを決める。1タスク1日以下。
  • スプリントは最短1週間~最長1か月で定め、1度決めたら延長や短縮は絶対にしない。
  • またスプリントでどのくらい作業が進むかの実績をベロシティという。ベロシティから期間の見積もりなどが行える
  • スプリント中は毎日同じ時間同じ場所でデイリースクラムを行い進捗報告や相談。時間は15分程度。

スクラムマスター

  • 一連のプロセスがうまくいくように回すひと。教育係。環境整備。
  • プロダクトオーナーとの違いはPOはプロダクトの作業進捗などを管理する人だが
  • スクラムマスターはプロダクト自体というよりも全体がうまく効率的に回っているかなどを見る。なのでPOとSMは同じ人が兼ねてはいけない。

スクラム開発の流れ

プロダクトバックログの作成→何をもってタスクを完了するかの定義づけ

―――スプリント―――
スプリントミーティング(スプリントでなにをやるのか決める)→スプリントバックログの作成→開発→スプリントレビュー→スプリントレトロスペクティブ(改善点・問題点などを話し合う)→リリース判断可能なプロダクト ―――――――――――

以後スプリントを繰り替えす。

最初にやること

ゴールとミッションを全員が把握する

どうやって? 

  • インセプションデッキ
    • ①エレベーターピッチ 自分たちがやることにどれくらいの期待があって予算をかける価値があるか どんな人に向けたものでどんなことができるのか
    • ②我々はなぜここにいるのか なんのためにやるのか。

見積もり

見積もりはプロダクトバックログをもとに素早くやる。 見積もりは作業量から決める。作業量の多さでおおまかにふりわけてから基準となる作業を1つさだめ その基準に対してほかのタスクは作業量がどうかというのをフィボナッチ数を使って開発チーム全員で決める。(見積もりポーカー)

タイムボックスとその遵守は不可欠

スプリントの期間など決めたタイムボックスは絶対に守る そうしないと予測がたてられなくなる。

完了の定義はあらかじめはっきり決めておく

ここ押したらこうなりまーすとかエラーでたけどこれすぐ直せます とかではだめで、スプリントレビューの段階ではきちんと動くものを出せるようにする。

全員がリーダー

POやSMが指示してそれに従うという形ではなく相互にコミュニケーションをとって それぞれが自立・協力をして作業を行うのがスクラム開発の特徴。

この本読んだ後にサイバーさんの記事読んだらさらにイメージつかめた。 https://www.cyberagent.co.jp/technology/ca_tech/report/8990174.html

最後に

理論としてはわかったけど結局実践してみないとわからないというのが本当のところ。開発手法だからあくまで。

研修で自分で1個サービス作った時もスケジュール管理ってむちゃくちゃ難しいと思った。
本当に予定通り進まない。1人でしかもテストとかも走らせてないし実装もたいしたことない サービスでさえ大変だと思ったのに、これをチームでやるっていうんだからちょっと想像できない。

研修のサービスを内定先の社員さんの前でもプレゼンしたときは

  • ①フィードバックをもらうタイミングっていうのは一概に一番最後にやればいいというものではない。なにに対する フィードバックがほしいのか(企画かUI/UXか実装か)でそのフェーズは変わる
  • ②調査の期間ってのをスケジュールに組み込むといい。予定が遅れにくくなる

上記2点をアドバイスとしていただいたのでそういうところも意識していきたい