午後から→オーバークロック

駆け出しハッカー()によるプログラミング・サービス開発備忘録。

スクラム開発合宿に行って来ました

f:id:nemupm:20140824044423j:plain

産学連携プロジェクトの一環で、クラウド技術について学ぶenPit・Cloud Spiralという授業を私は受講しているのですが、
8/18~22にそれの合宿があったので、簡単に学んだ事や感想をまとめてみました。

合宿の概要

合宿の大まかな内容は、1チーム6人でイベントチケット予約システム(WEBサービス)を作成するというプロジェクトを完成させるという目的のもと、スクラム開発を行う事です。

サービスの仕様については、javadocなどでかなりガチガチに決められていて、それに従ってコーディングしていく形です。

スクラム開発なので、1日を1スプリントとして、それを4回(4日)繰り返すという形式を取ります。

1日(1スプリント)の流れは

  1. 朝にスプリント計画を行う
  2. 10:30〜17:30まで開発を行う
    • 登録したチケットを次々に消化していく
    • その日のスクラムマスター担当者は出来るだけサポートを意識する
  3. スプリント終了後プロダクトオーナー担当者は完成したユースケースを顧客に説明する
  4. スクラムマスター中心に議事録を作成する
    • QAD分析を行う
    • 振り返りを行ってKPT(keep,problem,try)を整理する

となります。

振り返り

見積もりについて

開発では、

などなど、やるべきタスクをそれぞれtracチケットというものに登録し、それを消化していく形で実装を進めていきます。
このとき、チケットにはそのタスクにかかりそうな時間というものを見積もるのですが、これがかなり難しいです。

個人的には

  • 人によってかかる時間が異なるので、チケット発行時にはある程度実装する人を想定できるとベター
  • 単体テストソースコード作成以上に時間がかかる
    • 境界値分析を考えるとModel系は特に時間がかかる

ということを強く思いました。

スプリント計画について

スクラムマスターが主導してその日の実装の流れを決める重要なミーティングがスプリント計画ですが、
合宿を通じてスプリント計画の重要性に本当に気付かされました。

ここで決める大事な事の一つが開発順序(チケットの消化順序)なのですが、今回私たちの班の大きな問題として

  • ユースケース単位で大まかにしか開発順序を設定しなかった
  • 仕様書を深く読み込まず、クラス図やjavadocなどを表面的に読んだだけだった

ということがありました。すると起こった問題として、

  • データベースの仕様について理解しないまま実装を進めたため、データベースのやり取りの部分でかなりの勘違いが生まれてしまった
  • 各々がかなり自由にチケットを取ったため、controllerなどの依存関係のかなり多いソースコードを先に実装してしまったりする事が多く生じ、結果的に開発スピードに悪影響を与えた

ということがありました。 そのため、話し合った結果

  • まず実装に移る前にデータベースの仕様書については全員が理解しているか確認し、テスト用に使うデータベースのInitializerについてもこの段階で詳しい事を決めておくべきだ
  • 開発順序はかなり細かく決め、データオブジェクト(entityなど)→model→controller→html の順序が最もスムーズに開発を進められそうだ

という結論を得ました。

全体的な感想

スクラム開発の特徴である「スプリント計画」でしっかり予定を立て、
「スプリント終了時の振り返り」で予定通りに行かなかった事などについて多くの問題点を挙げ、それについて分析する事で、
スプリントごとにどんどん成長・改善していくことが実感できました。

これはウォーターフォール形式では味わえない事だと思います。

また、チーム開発においては、全員が同じ様に仕様書を深く理解し、手順を共有し、ツールの使い方を理解し、…など共通認識を持つ事が非常に大事だという事を痛感しました。
そのため、開発時間を削ってでも、話し合いはかなり慎重に行うべきだと思いました。

…しかし、このような、開発合宿というものは初めて経験しましたが、
ノミニケーションなどで大分チームのみんなとも仲良くなり、かなり楽しく過ごせたのではないでしょうか。
今後もハッカソンなど開発合宿を狙っていきたいなあと思ってます。