iyuichiの私的開発ログ

渋谷で働くWebエンジニアのログ. Java, Android, iOS, Docker, GCP, AWS, ゲーム開発

スクラムを実践してみる

導入の背景

自社サービスの機能追加とか運用を担当していて割と短い期間の開発案件を回していくような状況で開発をしています。

社内での開発なので、ノウハウを蓄積して効率化とか品質向上とか目標に掲げるのですがどうもうまくいかない状況があります。

自分なりにどこがダメそうなのかを分析してみて以下のようなところが見られました。

  • チームでゴールを目指す意識が薄い
  • 自分の仕事に勝手に線を引いていてコミュニケーションがうまくいっていない事がある
  • ふりかえりの習慣がなく、案件がうまくいっても問題があっても次につながっていない

メンバからは改善とか標準化とか自動化とかって声は聞こえてきます。

そして、その取り組みもしています。

でも、担当した人の自己満足になっていたり、決まったルールを守っていれば良いという雰囲気だったりで、良いスパイラルが回っていない気がします。

そこで、コミュニケーション不足によるムダとか意思疎通の間違いを減らそうと朝会を始めました。

進捗報告会のようになってしまい、ちょっと意図したのと違ったけれど、とりあえず顔を突き合わせて話す機会を持つことでプラスもあるかな。

次にふりかえりの1つとして、開発が完了したプロジェクトの成果物発表とか、利用した技術の勉強会の開催をメンバにお願いしました。

こちらも一定の成果はあったと思うものの特に活発な意見交換がされることもなく、もう少しかなと。

スクラムいってみます

こんな試行錯誤をしながら、部分的に取り入れていたスクラムですが、プロセス全般的に導入してみます!と宣言してみました。

スクラムと言ってしまうことで一般化されるんで個々で勉強して提案とかも出てくることを期待していたり。

スクラムで設定されているイベントをまず1回まわしてみます。

自らはサーバント型のリーダを目指します。

「スプリント計画〜デイリースクラム〜ふりかえり」を回すときに考えた事などを書いてみます。

スプリント計画

1部、2部分けて実施するものを選びました。

進捗ミーティング化している朝会の改善のためにも、まずはプランニングの透明化をし、メンバみんなが当事者になれるようにしようと思っています。

参考にしたスライドがこれです。

デイリースクラム(朝会)

「上司、リーダへの進捗報告会ではない」と宣言をし報告内容の補正をするべく、自らはスクラムマスターとして参加します。

どうしても、課題を解決するような発言をしてしまいがちですが、ここはがまん。

メンバから報告してもらう内容は以下のようにして欲しいとリクエスト。

昨日やったこと:昨日コミットしたタスクが完了したのか

今日やること:今日完了するタスクのコミット

問題点:スプリント計画との乖離、コミットしたタスクの変更などが発生したら報告。解決策は別途、デイリースクラム後にチームで協議。

参考にした資料はこれ。

ふりかえり

これは、来月が実質初回となります。

ただ、これをやることだけは伝えてある状況です。

  • スプリントレビュー:成果物のレビュー
  • スプリントレトロスペクティブ:やり方のレビュー

こんなのやりたい。

さいごに

これから開始って段階なのでいくつかのスプリントがまわったら、またふりかえりのエントリーを書いてみたいと思っています。

SCRUM BOOT CAMP THE BOOK