スクラム

過去に自分がプロジェクトを促進していたときに
まとめていたやつ。

アジャイル開発なんだけど、それに細かくいろいろ役割を決めて、ぐるぐるスケジュールを回してく手法。
それがスクラム開発。

字汚いのは勘弁したいところだけど、
システムの早い変化には対応できる手法だと思っている。
もちろんレビューとかはしっかりやっておかなければいけないし、
なによりも、役割や権限が決められていたとしても、上下関係があると進まない。
どうやって互いに協力しあっていくかが、プロジェクトの将来を左右していくことになりそうだ。

個人としてこれの実績があるかというと、実績としてはあるけど
手法問わず、要件定義と基本設計をしっかりチーム全体にレビューすることが重要ではないかと思う。
プロジェクト規模にもよるけど、システム基盤が確立し、詳細設計とプログラミングを反復させていけば、人の負荷も少ないし、工数の負荷分散も難しくない。
・・・と、これらのことがしっかりできた上での実績になると思う。

でもスクラム開発手法をやってた当時は、意思決定と行動を早く行うことができたので、自分が客先で打ち合わせしながら要望を聞きつつ、さらにシステムの変更を打ち合わせ中に行うことができた。
そして、その場でユーザーに理解が得られることができたので、持ち帰り作業がなくなり、次のステップに早く移行することができたということは結構あった。
100％完成していなくても、ユーザーに早い段階で見せることができるというメリットが非常に大きかったと思う。
これによって、システムの問い合わせが減ったのと、ドキュメントも反復の計画内でのちょびちょび更新程度になったので、
プロジェクト後半が非常に楽で、システム本番稼働の日が担当者との食事会になってたような記憶がある。

これにはまだ先の話があるけど、
座学にようなものになりそうなので、その先は自分自身で調べて
使えるのであれば、使ってみてはどうかなと思う。