スクラム開発の理解と誤解について
SI企業ではめずらしく(?)スクラム開発をやっているごーと申します。
ウォーターフォールとスクラム両方をやってきた上で、得た知見やプラクティスなどを今後まとめて行こうと考えています。
スクラムの理解と誤解
Web系の企業や内製開発をしっかりできているような企業だとスクラムに対する理解がかなりあるように思えますが、企業の文化や予算どりの仕組み(特に大企業に多いように見えますが)などからスクラムへの理解が薄かったり、スクラムの効果を発揮できてないケースなどがかなりあると見受けられます。
ここでよくある誤解について少し取り上げておきたいと思います。
スクラム開発をすると欲しいものがとても早くできる
スクラムだから早くできるとということは残念ながらありません。
よくあるケースですが、既存の開発(WF的な手法)のアウトプットを持ち出して、これと同じものがすぐに、コストも小さく(工数であったり、人月だったり...)なると思い、その指摘をしてくることが多いです。
スクラムのメリットはチームを固定して、真に必要なもの・ことに絞り込んだのちに、最適なタイミングでユーザに提供することにあり、アウトプット量を固定して早く、安くというものではありません。
POを含めたチーム全体で、何をどのレベルでやるか見定めてチームを運営して行きましょう。
このアウトプットに関する感覚を取り違えると、エンジニアにとって非常に苦しいプロジェクトになってしまいます。
スクラムにドキュメントは不要
これも非常に多い話ではありますが、様々な記事で取り扱われているように不要ではありません。
スクラムチームの継続状況、成熟状態、ステークホルダーや他チーム連携、チームのスケーリングなどの状況を鑑みて、然るべきタイミングで然るべき粒度・規模のファイルを作成することになります。
スクラムに成熟したDevチームであれば自然に行えますが、理解度合いに応じてSMやアジャイルコーチなどの指導を仰ぐといいでしょう。
この辺については後に記事にしてみたいと考えています。
スクラムは計画がない
計画は自由ではありますが、むしろリリース計画はしっかりとした方がいいでしょう。
ストーリーポイントやTシャツなどからチームのベロシティを計測しつつ、機能のリリース時期を見定めて行きます。
他PJの連携(特にAPI等の提供時期)や法務・業務要件で確実のリリース時期が決まっている場合、各SPのベロシティと全体の大まかなポイントを見定めて、毎SPでPBIの優先順位を整理して行きましょう。
スクラムは全員フルスタックである必要がある
スクラムだと、各メンバーが各々高いスキルがあった方が間違いなく良いです。が、なかなかチーム発足時点でそのようなメンバーを探し出すのは難しいでしょう。
なので、実際は ある程度スキル的な基礎ができている + 担当PJのどこかの1領域で高いスキルがある というメンバーで揃えるといいでしょう。
ですが、それ以上に重要なのはチーム参画後に変更(成長)不可能な人格面です。スクラムはチームメンバーの変更を少なくします。ウォーターフォールと違って各フェーズでメンバーの入れ替えや開発内容の受け渡しは発生しません。
故に長期間同じチームメンバーでやっていく必要があるため、協調性やコミュニケーション能力など、人間的なソフトスキルがあるかというのを意識していくといいでしょう。
まとめ
- スクラムは早くない。適切なデリバリー内容と時期を見定める。
- スクラムのドキュメントは適切な時期と量で作成する。優先度はチームの状況に依存。
- スクラムの計画は柔軟である。外部要因でリリース時期が決まるならば、それを意識して計画していく。
- スクラムはチームにスキルを要求する。しかし万能でなくて良い。より重要なのは人格。
あとがき
今回は、自分が考えてみたbad practiceと比較しつつ、自分の考えをまとめました。
スクラムブックのようにスクラムの体系的な内容がまとまったものはありますが、理解は簡単だが、実践は難しいというのは本当にそうだと思います。
一覧を読むというよりは、各シチュエーションをイメージして実践と観察をする、そしてスクラムの原則に立ち戻ってどうか振り返る。とにかくそれしかないのかなと思いました。
Discussion