スクラム始めました-スプリント5実施【#3】

ずいぶん間が会いてしまいましたが・・・

4月より進めてきたスプリントもすでに５サイクル目に。

スクラムっぽくは実施しているが、なかなかうまくいかないなということが

多く出てきているので、自分の整理を込めて今回は記載。

＜遂行が難しい点＞

１．新規開発での難しさ

開発フレームも整っておらず、利用する言語について、深い見識があるメンバーがいない中で始めて入る部分もあり、開発の生産性が高まらない中、スプリントを繰り返している。

徐々に部品は出来上がっており、作り始めにおけるコストは下がっているのだが、要求の変化に伴う、機能の変化にうまく対応できておらず、波に乗れない。

２．ふわふわすぎる要求

プロダクトオーナーとの打ち合わせを実施しているが、要望ではなく、確認会になっているのも原因と考えている。本来ならば、オーナー側に業務プロセスのイメージを固めてもらい、「こうやって進めたい」というのベースに、システムとしてはどうするというのを検討する形になるのだが、業務プロセスもシステムも構築サイドで検討している状況。

作成したものを見て、業務プロセスを考えなおすというやり方になっているため、機能要求に沿ったテストが出来ないことやいつまで立っても仕様が確定しない。

（スプリントのゴールは出しているが、リリースの条件を満たさない状況になっている）

３．広がる要求

小さく進めて開発しているのだが、今回はWebサービスではなく、ビジネスアプリケーションの一部分の開発である。そのため、スプリントで作成したものだけではリリースはできず、複数機能を全て作成し、システムテスト、ユーザテストを経ないとリリースができない。

が、エンドは切られているにも関わらず追加で要求が増える状況。。

これくらいの規模だったらこれくらいかかるなという感覚がプロダクトオーナーにはないことと、要求を持ってきた時点でエンドユーザーと入れる方向性で話を持ってきているため、柔軟に納期を変更できない。しかし、要求は増えていく。。。

＜やっていて良い点＞

スクラムでやることによって、今までの分業制で開発していたのとは異なるという点もありました。

１．実装時に仕様やユーザ視点に立った場合の問題点に気づいてくれる

がちっとした仕様書を書いているわけではなく、Redmineにチケットを発行し、やりたいことを備考欄に記載して、タスクを割り振っている。

また、都度あることにプロダクトオーナーと話したこと、エンドユーザの仕事、業務の内容を説明している。そのため「こういう機能だと、ここにこまらないかな？」と考えてながら実装する意識が芽生えてきている。

言われたとおり作成するというのではなく、考えて作る意識に変えられるのがいいこと。

２．タスクの分割

タスクが大きすぎると分割！とすぐ気づく文化が醸成できている。

タスクが大きいと進捗が個人の内部に隠れ、「どこまで進んでいるんだろうか？」が分からないが、細かくし、都度進捗を記載してもらうことである程度状況を把握できる。

＜ロケーション上困っていること＞

スクラムの書籍などを読んでいると、壁にタスクボードやカンバンがはられ可視化できているが、私のプロジェクトはできてない。

と、いうのもお客さん先の環境で実施しており、他のベンダーとの共有環境で作業を実施しているため、情報を外に出せない。

システムが充実してきており、デジタルで実施できることは増えている一方、コンプライアンスやセキュリティーなどの要件で、アナログな手法が使えなくなっているのが制約だなと・・。プロダクトオーナーへのインパクトがデジタルだと弱い・・と感じています。