読者です 読者をやめる 読者になる 読者になる

Rails Webook

自社のECを開発している会社で働いています。Rails情報やサービスを成長させる方法を書いていきます

スクラム開発メモ

スクラム開発の課題とプラクティス

  • 予定外の仕事が入ってタスクをこなしきれず、残業ばかりである。

=> 急な仕事にスプリントバックログを使って相談する。ポイントは状況を共有し、問題vsチームの状態を作る

スクラム開発の基礎知識

プロダクト・バックログ

機能や技術的改善要素を優先順位をつけて記述したもの。誰のために、何のために、それを実現するかを関係者がいつでも開発している目的を思い出せるようにすることが目的。
ステークホルダ全員が参照し、現在のプロダクトの状況を把握できるようにする。

スプリント・バックログ

プロダクト・バックログからスプリント期間(1〜4週間)分を抜き出したチームのタスクリスト。
チームメンバーのスキルを総動員して、自信を持って「終わる」と宣言できるかどうかが、確認ポイント。

スプリント期間中は、スプリント・バックログにある作業や機能を完了させるべく、チームとしてベストを尽くす。
私の仕事、あなたの仕事ではなく、チームの仕事として、チームとして責任を持ち、全力で仕上げていく。

デイリースクラム

朝会のようなチームミーティング。業務の進捗報告や情報共有が目的。
「昨日やったこと」「今日やること」「障害になっていること」を共有する。細かい問題に立ち入ることは別の時間をとってやり、15分ぐらいで終わらせる。

スプリント・バックログを実施していくために、スクラム開発に必要な情報の進捗の「見える化」を進める上で必須のミーティング。

カンバン

スクラム開発の象徴。プロジェクト全体で「誰が」「いま」「何を」しているかが一目で分かる。
カンバンを用いることで「自分が今どんな仕事を抱えているのか」や「周りの人が今何をしているのか」を瞬時に把握できるようになる。

使い方は、ストーリー・タスク・Todo・Dogin・Doneに区切る。
そして、ストーリー(ビジネス要求)を細かいタスクに割り振りし、一定期間にできるもの(スプリント・バックログ)をTodoへ。
今やっているタスクについてはDoingに入れ、終了したタスクはDoneで管理する。

KPT

Keep(良かったこと、継続すること)-Problem(問題点)-Try(その問題をどのように解決するか)の略。チームでスプリント(一定期間)ごとに、このKPTフレームワークで振り返りを行う。
KPTにはチームメンバーが抱える課題を「見える化」させるという効果があり、問題解決に非常に有効に働く。

スクラム開発の成功させるポイント

必須条件

  • プロジェクトリーダーにスクラムの良さについて理解してもらうこと
  • それぞれのチームに最適なスクラムがある。まずはスクラム開発体制の基礎を学び、基礎を活かしてチームに合ったスクラムを模索し、自分たちのスタイルを作っていかなくてはならない
  • 当事者意識を刺激し、他のメンバーから学びとろうという意識を生みだす。誰かがきっと解決してくれるじゃない。次は自分の番になりやすい。

推奨条件

  • スクラム開発は、現状の問題点を明確にし、それを解決する手段として実施していくことがコツ
  • チーム内に自分より詳しい人がいないスキルがたくさん存在するので、チームとは別に、専門コミュニティに属し、自分より詳しい人の意見を聞く

スクラム開発の成功・失敗事例

成功事例

  • 他のPJと掛け持ちメンバーが多いため、カンバンに兼任しているPJのタスクも加え、別PJが理由でタスクが遅れた場合に責められないような仕組みを作っている。
  • 既存事業ではストーリーを作るのが意外と難しく、割り切ってPLや営業の要望をストーリーとしている
  • 既存のウォーターフォールと、スクラムを掛けあわせて活用している

失敗事例