スプリント / スクラム開発のルールについて

スプリントの準備物に関して

スプリント開始前に以下の準備をEMが行ってください。

• スプリント専用Asana
• スプリント専用ブランチの作成
• スプリント専用STG環境の作成
  • SFの変更セット設定を追加（/lightning/setup/DeploymentSettings/home）
• リリース不可期日の決定、スケジューリング
• プルリクエストを実施するSTGブランチを周知する
• バックアップ用SF - Sandboxの「classlab2--staging.sandbox.lightning.force.com」に最新版を反映する

スプリント開発でのタスク決定までの流れ

1. タスクの見積もり

日々見積もりを取り「依頼確定済み」をスプリントまでに増やして確定させてください。

1. 依頼は Classlab SalesForceタスクで管理しています。
2. 40Hを超えるタスクは分解してAsanaに登録するようにしてください。
   • ※ルールを整備中のため暫定処理
3. プルリクエスト後に発生する工数の内訳を定義してください。
   • 現在の構築～STGにアップまでのフローでは、構築とリリース関連の準備が分割されています。
   • タスクの見積もり段階で、プルリクエスト後に発生する工数（リリース準備等）の内訳を明確にしておいてください。

2. スプリントタスク決定MTG

1. スプリント期間の出勤日数から事前確定工数を計算し引いた数値がタスクに割く工数です。
2. 上記で確定した工数分のタスクを決定します。
3. スプリント毎のAsana - PRJに決定したAsanaタスクを追加してください。
   • タスクの選定は古谷承認制です。MTGでタスクを各自選定後、古谷に確認をとってください。
4. Googleカレンダーに予定工数分のスケジュールを割り当ててください。

カレンダーに入れる時の注意点

• Asanaタスクのスケジュールにはカレンダーの説明にAsanaURLを入力してください。
• 業務改善タスクの16Hはスプリントの最終日あたりで設定してください。
• エラー改善の8Hは4Hで二つに分割し、1週間に1度来るように設定してください。
• Asanaタスクにてリリース準備のカレンダーと構築を分けて登録してください。
  • 現在の構築フローではプルリクエストのタイミング～STGまで時間が空きます。
  • ここで以下の様な問題が発生します：
    • 例：構築に8Hと設定していたが、5Hで完了し次のタスクへ。プルリOK後にSTGにデプロイする作業が別で発生し、スケジュールにズレが生まれる可能性
  • Asanaのタスクの洗い出し段階でリリース準備の内訳はできているはずなので、構築のカレンダー登録とリリースのカレンダー登録は別でカレンダーに登録するようにしてください。
  • リリース準備の詳細は「Asanaタスクにてリリース準備」を参照してください。

この時、2週間分のGoogleカレンダーが埋まります。

重要: エンジニアルールでGoogleカレンダーは実績の役割もあります。ルールを確認し正確にカレンダーを入れてください。

Asanaタスクにてリリース準備

実施すること

1. STG環境に変更セットをアップする
2. 各環境のリリースを1H以内で実行できるように準備してください
   • 例 - SFなら変更セットをあげて、クリックリリースできる状態
   • 例 - Laravelならアップロードファイルをgitの差分で洗い出し、リリースするファイルのフォルダを作成する等

Asanaにて報告

以下を提出する目的は、EMがどの環境のどのファイルをどの影響範囲でリリースするか把握するためです。

リリース先の分類

• SF
• VUE
• Laravel
• Python
• その他

既存改修 / 新規の分類

• リリースしても既存処理に影響が出ないもの（新規機能等）
• リリースした時点で処理に影響が出るもの（既存機能の改修等）

スプリント開発 - タスク遂行中に発生するルール

タスクの着手の開始

Asanaにタスクの着手を開始したことを報告

EMとステークホルダーにAsanaでも開始したことを報告してください。

着手タイミングで以下の内容をSlackのgeneralチャンネルに投稿

• 宛先: ステークホルダー cc 日浦、平井、古谷
• 内容:
  • 着手開始報告
  • スケジュール概要
  • プルリクエスト予定日
  • プルリクエスト承認予定担当者
  • お客様確認開始予定日【タスク毎】
  • お客様確認締切日【スプリント毎】
  • リリース予定日
  • Asana URL

注意: お客様確認締切日を超過した場合は、リリース予定日にリリースされません。

プルリクエストとSTGに変更セットのアップについて

プルリクエストからSTG環境へのアップのフロー

1. プルリクエストをスプリント毎のリポジトリに実行
2. プルリクエスト承認後、お客様確認へ移行
3. お客様確認後、「仮想付加価値」の算出を実施
   • 📊 仮想付加価値計算ツール: https://cleath.space/input/20251218b.html
   • 依頼者から情報を回収する必要があります。お客様確認後、本タスクの評価を含めて実施してください。
   • 算出できた場合：
     • Slack報告用のテキストをSlackのスレッドに展開
     • Asanaのカスタムフィールド「仮想付加価値」に算出された金額を入力
   • 詳しくは「仮想付加価値計算について」を参照してください。
4. STGに変更セットでアップロード完了
   • 手動でオブジェクトを作成等の予定がある場合、リリース手順書をまとめてください。

スプリントを跨ぐ開発について

test環境での構築を禁止します。

スプリントを跨ぐ可能性があるタスクはそのタスク専用のSF環境を構築してください。

Gitに関して

以下のGitで管理されているプロジェクトはSTG毎にStaging環境を作成します。

※随時追加していきます。

• cl-crm-salesforce
• cl-crm-itandi-import-csv
• cl-crm-guide_guide_infomation
• cl-crm-form_auto_submit
• cl-crm-lambda_auto_form_submit
• cl-crm-referral-form
• cl-crm-api-server

SFのテスト環境に関して

• https://classlab2--test.sandbox.lightning.force.com/lightning/o/MoveIn__c/list?filterName=All
• テスト環境
  • スプリント毎にSFの本番環境のデータを更新します。
• STG環境に関して
  • スプリント毎にSFのSTG環境を作成しなおします。

タスクの完了

Asanaに完了、お客様確認依頼の報告

Asanaでタスクが完了したことを報告

プルリクの準備

プルリクを実行し、プログラムの確認を行なってください。

リリースの準備

SFの場合、変更セットをSTG環境にあげて確認を行なってください。

注意: これが抜けていると、リリース日にリリースができない事案が発生します。

タスクが想定よりも早く終わった場合

タスクが想定よりも早く終わった場合は事前に決定したタスクのスケジュールを前倒しして、Asanaタスクを実行してください。

緊急のエラー、バグの確認依頼があった場合

1週間に1度エラーの時間4Hが割り当てられています。エラーの時間を割り当て、実績分カレンダーを更新し整合を担保してください。

1週間に4H以上の対応をする場合はEMに確認してください。

例外: ただしインシデントレベルが「高」の場合はインシデント修正を最優先にしてください。

エラーが発生せず、1週間に1度くるエラー対応のスケジュール時間がきた場合

エラー対応予定スケジュールをスプリントの最後にずらし、次に予定していたタスクを前倒しして実行してください。

重要: ただし、Googleカレンダーの整合性を担保してください。

エラーが全く発生せず、スプリント最終日に8Hのエラー対応時間に差し迫った場合

業務改善タスクのタイミングでEMに相談してください。

EMがAsanaを基本的に確認しているので、他のタスクをアサインします。

もし何らかの理由でタスクがアサインされない場合、業務改善タスクを追加で実行してください。

スプリントスケジュールイメージ

事前確定工数（出勤日数が10日の場合）

注意: 出勤日数によって前後します。その都度自分で計算してください。Slackの返信は1日0.5Hとしているが、Slackの返信が多い人は1日1Hでも問題ないです。古谷に相談の上決定してください。

内訳の計算例

前提条件

• 出勤日数：10日（1スプリント = 2週間）
• 1日の稼働時間：8H
• 1スプリントの総稼働時間：10日 × 8H = 80H

計算

総稼働時間 - 事前確定工数 = Asana保守タスクに使える時間
80H - 47H = 33H