はじめに
この記事では私が立ち上げたWebアプリ開発コミュニティのマネジメントについて書きます。
コンテンツ
1. 我流スクラム開発概要
2. プロダクトバックログとは
3. スプリントプランニングとは
4. ウィークリースクラムとは
5. レトロスペクティブとは
では早速概要の説明に移ります。
1. 我流スクラム概要
我々の開発手法はなんちゃってスクラムです。
なんちゃってスクラムですが、継続してPDCAを回すことでより良い開発体制を実現できるよう活動しています。
次の図が概要となります。
専門用語ばかりで読みづらいので、日本語化します。。
プロダクトバックログ ・・・ 製品の機能（例：ユーザー検索）
スプリントプランニング ・・・ 次の開発サイクルの計画（実装する追加機能の選定やタスク割り振り）
ウィークリースクラム ・・・ 週次定例会議（進捗や課題を話し合う）
レトロスペクティブ ・・・ 各開発サイクルの最後に行い、開発サイクルでのKPT(Keep：これからも続けたいこと, Try：次回挑戦したいこと, Problem：問題があったこと)を洗い出し、議論する
次の図では実際の活動はどうなっているのか、その実績を説明します。
以上で我流スクラム開発の概要説明は終わりです。
以降のチャプターではそれぞれのフェーズをより具体的に説明します。
2. プロダクトバックログとは
製品に実装する機能のこと
管理方法
1. 浮かんだアイデアをslackの#backlogに投稿
2. slackに投稿したアイデアに対して、受入基準・工数見積もりを付与（スレッドを活用）
3. GitHubのissue化
サンプル
タグ一覧のトップページ表示
イベント作成時に日程が決まっていない場合に、日程調整機能を使用することができる
- 思いついたらアイデアベースでslackに書き込み。
- slack上でメンバーと議論しながら詳細をつめる。
3.GitHubを開いてissueを作成する
3. スプリントプランニングとは
今回のスプリントで実装するバックログを決め、担当者を割り振る。
GitHubのアドオンZenHubを用いて、カンバン方式（Trelloでも作成可能）で管理しているissueのうち、Pre-Backlogの状態のissueの中から本スプリントで実施するものを選定し、タスクを割り振る。
図. カンバン
選定の基準となるのは、
1. スプリント期間(2週間)でこなせる仕事量に余裕をもつ
2. ユーザーにとって価値がある
3. 運営を圧迫しない
の3点。
1は各自のプロジェクト・プライベートの状況に合わせて柔軟に設定。
2はUI/UXの観点から本当にユーザーに必要な機能かどうか。
3はその機能を作ることで運営側の対応が必要となり、首を絞めることにつながらないかどうか。
という観点で議論しています。
4. ウィークリースクラムとは
そのまんまで、週次定例会議のこと。
▶︎内容
① 進捗確認（5min × 8person = 40min）
GitHubを使い、図. カンバンのように管理されているissueを人単位でフィルターすることができるので、各自5分で自分のタスクの進捗状況を共有
② 議題 （15min × 議題の数 = (max)1hour）
実装上の課題や運用の課題などを話す
③ UATテスト（20 - 30min）
その週に追加実装された機能を統合したUAT環境で、一通りの機能の統合テストを行う。
▶︎場所
月に1回Face to Faceでそれ以外はリモートで実施。
・リモート（skype, slackを使用して画面共有）
・Face to Face
▶︎所要時間
基本は2時間（最大で3時間）
5. レトロスペクティブとは
1ヶ月に1度、各開発サイクルの最後に行い、開発サイクルでのKPT(Keep：これからも続けたいこと、Try：次回挑戦したいこと、Problem：問題があったこと)を洗い出し、議論する。
議論した結果、コミュニティの運営方針に決定事項を追加する。
おわりに
長々と書いてしまいましたが、最後まで読んでくれた方、どうも有難うございます。
もっとこうした方がいいんじゃないか、こういうところはいいと思う！など感想を書き込んでくれたら嬉しいです。
質問などありましたら、気軽にコメントしてください。
ではでは。