スクラム開発の面白いところを書いてみる

お疲れ様です。

スクラム開発のプロジェクトに参画し
いろいろと面白いところ、メリット・デメリットが見えてきたので
少し書いてみたいと思います。

###1.前項　スクラム開発って何？
わかりやすくいうと、
「開発するものと時間を細かく区切って、システムを完成にまで導く」開発手法です。

例えばウォーターフォールの開発手法だと、
●ヶ月で詳細設計をかきあげて、●ヶ月で製造やって、●ヶ月でテストやって、と
製造のフェーズごとに区切られていますが
スクラム開発の場合、
1スプリント（チームによってスプリントの定義は異なりますが1～2周間が多いそう）
という定義の中で、設計・製造・テストを行う、ということになります。

それぞれ役割等々は下記のページを参考にしてください。
画像は下記ページの引用です。

####2.スクラム開発の手法

スクラム開発の場合は1スプリントの中に「イベント」というものがあり
次スプリントの製造に向けた準備・見積もり→プロダクトバックログリファインメント（スプリントリファインメント）
終えたスプリントの振り返り→スプリントレトロスペクティブ
今スプリントの時間をどう使うかを考える→スプリントプランニング
というようなイベントが多くあります。

一週間で1スプリントに例えて説明すると
月曜日…スプリントプランニング
火曜日…イベントなし
水曜日…プロダクトバックログリファインメント
木曜日…イベントなし
金曜日…プロダクトオーナーのレビュー＆レトロスペクティブ

翌月曜日…スプリントプランニング
……
という細かい期間で開発していく、という手法になります。

この細かい期間で開発していくメリット・デメリットがあり、
メリット：時間を非常に意識する。
　　　　　→一週間でどれくらい時間が使えるのか、
　　　　　　一週間でどれくらい開発ができるのか
　　　　　　が見えやすいため、遅延が起きたかどうかの判断がしやすい。
　　　　　→そもそもプランが現実的なものかどうかも見える。

デメリット：イベントが多い
　　　　　→イベントのために使用しなくてはいけない時間が多いため
　　　　　　絶妙な塩梅が求められる。
　　　　　　仮にプランニングで十全なプランを設計しようとすると時間を要する。
　　　　　　が、予期せぬ自体が起こると崩れやすい。

20190618追記

肝心なこと書いてないことに気がついたので追追記

スクラムでは、上記のスプリントで作業の難易度、複雑さ、影響範囲に応じてポイントをつけます。

そのポイントを、スプリント毎に高めていく。ということで効率性を視覚化します。

つまり、
1スプリント目 5ポイント
２スプリント目 7ポイント

というように高めていくことで開発における生産性の指標を儲けます。

スクラムではこのチームの行ったポイントをベロシティと言います。
このポイント性はスクラム独特の考え方ですが、生産性が視覚化できるというのは非常に強力なツールと言えます。

####3.スクラム開発の面白いところ

######人間関係が出やすい。
もともとプログラマーはコミュニケーションを求められるところがありますが
特にスクラム開発は求められるところがあるなぁというのが所感です。

スプリントプランニングや、リファインメントのときに
「こういうふうにやったらいいのでは」と考えがぶつかりやすいのですが
うまくやる方法というのもいろいろ見えてきたりします
この人にはこう伝えたら伝わりやすいかなぁとか。
なのでチームで動きたい人には向いていると思います。

#####効率がいい
単純にこれは効率がいいところが多いなと思いました。
時間の区切りをつけることでウォーターフォールのように
仕様変更による無茶な労働時間等になりにくいなと思います。

このスプリントでは100時間使えるから、こうしましょう。
逆に割り込み対応入ったので100時間オーバーするからこの実装は無理だね。等。
理屈をもって説明できるため、このスプリントでは無理です
と実働部隊からも説明しやすいのでPMに殺意を抱かなくて無用な争いをせずに済みます。
それでも納期はあるので、次のスプリントでどうやるか、
等々考えなくてはならないところはあるのですが…。

あとはこの部分の実装はこの人がやったら良いよね。
等々割り振りがしやすい。
それぞれ得意分野（フロント・サーバーサイド等）があるので
そこの持ち味を活かせる機会が多いし、覚えようと思えばいろいろ覚えられる。

一方でここからはデメリットになりやすいなぁと思うところ

#####チームガチャが発生する。
上で述べたように人間関係が出やすいので、
人と人との組み合わせによっては混沌とします。

例えば
・定時で帰りたい人VS残業してでもきれいに終わらせたい
・設計をしっかりしたい人VS設計はそこそこにしといて実装で取り返す人
・インデントや記法をしっかりしたい人VS雑な人
等々ありますが、人と人との相性なのでイカンともしがたいところがあるのが本音。
急な離脱等も影響範囲は大きいので負荷になる人は負荷になると思います。

#####意見を発さないと辛い
こちらも同様ですが、意思表示や理解できない箇所はキッチリ詰めないと
後々に響きます。スプリントプランニング等でも
この設計したらやばいな…と思うところは発して、
事前に潰さないと「時間の見積もり」が決まってしまった後に
直す工数が発生すると後々厳しくなります。発狂します。

なのでここはやばい。ここはOK等きっちり発信しないと
辛くなるため気をつけましょう。気をつけます。

####個人的な見解
非常に効率的な一方で、スクラム開発がうまく回ると
ポイントの奪い合いになるとのことですので、
何事もほどほどに。