この記事は、NFLaboratories Advent Calendar 2022 5日目の記事です。
こんにちは。ソリューション事業部 セキュリティソリューション担当の香川です。 普段はスクラムマスターおよび開発者としてスクラムの手法を用いた開発を行っています。
スクラムの作成物の1つにスプリントバックログがあります。スプリントバックログは開発者が作成するスプリントの作業の計画で、一般的には各PBIをタスクに分解して作成されることが多いと思います。以下の図はその例になります。
私のチームではGitLabのIssue Boardを使ってタスク管理をしています。しかし、GitLabではタスクがどのPBIに紐づいているのかを表現しづらいという課題がありました。そのため、PBIをDoneにするためにどんな作業が残っているのか?スプリントがどのようなステータスなのか?が分かりづらく、作業の進め方に困ることもありました。
また、GitLabでどのようにスプリントバックログを運用しているかを調べてもみましたが、あまり自分のチームにマッチしたものを見つけることができませんでした。
そこで、今回は私のチームでの試行錯誤と、現在どのように運用しているかについて書いていきます。
その1: Linked Issueを使う
私がチームに加入した初期の頃に行っていたやり方です。 GitLabのLinked Issueの機能を使ってPBIにタスクを紐づけていました。
OpneのIssueとClosedのIssueの区別が付くので、残りはタスク2とタスク3であることが分かります。
ボード全体はこんな感じになっています。
PBIのIssueを開くとPBIとタスクの紐付けが分かるのですが、ボードからはどれとどれが紐づいているのかが分かりません。また、新しくタスクが作られた時にIssueを関連付けさせるのを忘れてしまうこともしばしばありました。
その2: PBIと関連するタスクを同じ場所に並べる
次に試したのは、PBIとタスクを同じレーンに入れて、PBIの下に関連するタスクを並べる方法です。 プランニングが終わった直後のスプリントバックログは以下のようになります。
「ユーザが〇〇できる」に紐づくタスクがタスク1〜3、「ユーザが△△できる」に紐づくタスクがタスク4と5のように、ボードからPBIとタスクの関連が分かりやすくなりました。 しかしながら、プランニングが終わった直後は良いのですが、スプリントの作業が進んでタスクが別のレーンに移動すると結局関連付けが失われることになります。 またスプリントの途中にPBIを入れ替えたい場合、それに紐づくタスクもまとめて移動させる必要があり、これが結構面倒くさい作業でした。
その3: PBIごとのラベルを作る
3つ目に試した方法はPBIごとにラベルを作り、そのラベルを関連するタスクに付与する方法です。 ボードは以下のようになります。
これによって、ボードを見るだけで誰でも各PBIがどのような状態なのかがわかるようになりました。 個人的にこれはとても重要だと思っていることで、例えば1日休んでも次の日ボードを見ればすぐに状況を把握できます。 またデイリースクラムでもスプリントの状況の共有を素早く済ませ、進捗の検査とスプリントバックログの適応に時間を使うことができます。
このやり方はチームに定着し、今現在もこの方法でスプリントバックログの管理を行っています。
おまけ: ラベル作成作業の自動化
PBIのラベルを作成することでPBIとタスク間の関連が分かりやすくなりましたが、毎回のスプリントでラベルを作るのが面倒という課題がありました。 そこで、ラベルを作成するPythonスクリプトとGitLabのScheduled Pipelineを使い、スプリントが始まるたびにラベルが自動的に作成されるようにしました。
ラベルを作成するPythonスクリプト
PythonにはGitLab APIのラッパーであるpython-gitlabライブラリがあり、これを利用してスプリントに投入しているPBIのIssueを取得し、それと同名のラベルを作るスクリプトを作成しました。
import random import gitlab def create_random_colorcode(): return "#"+''.join([random.choice('0123456789ABCDEF') for j in range(6)]) def main(): private_token = "YOUR_ACCESS_TOKEN" project_id = YOUR_PROJECT_ID # APIを利用してPBIを表すIssueを取得 gl = gitlab.Gitlab(private_token=private_token) project = gl.projects.get(project_id) pbi_issues = project.issues.list(state='opened', labels=['PBI', 'Todo']) for pbi_issue in pbi_issues: # label名を「pbi-<PBIのタイトル>」に、色をランダムに設定してlabelを作成 label_name = 'pbi-' + pbi_issue.title label_color = create_random_colorcode() try: project.labels.create({'name': label_name, 'color': label_color}) # PBI Issueに新しく作成したラベルを付与 pbi_issue.labels.append(label_name) pbi_issue.save() print('Label created: ' + label_name) except gitlab.exceptions.GitlabCreateError as error: # 既に同名のラベルが存在する場合は作成しない if str(error) == '409: Label already exists': print('Label already exists: ' + label_name) else: print('Unknown error: ' + label_name) if __name__ == '__main__': main()
Scheduled Pipeline
先ほどのスクリプトをプロジェクトにPushした上で、Scheduled Pipelineを実装します。 .gitlab-ci.yml は以下のようになります。
default: image: python:3.10 create_label: stage: build script: - pip install python-gitlab - python create_label.py rules: - if: $CI_PIPELINE_SOURCE == "schedule"
その上で、Scheduled Pipelineの設定で毎週月曜の13時にスクリプトが走るように設定しました。 (私のチームでは月曜の10時半からスプリントプランニングを始めているため、13時にはプランニングが終わっている想定)
こうすることで、毎回のスプリント開始時にPBIのラベルが自動的に作成されるようになりました。
おわりに
このようにして、めでたくいい感じのスプリントバックログができ、毎回のスプリントでいい感じにPBIのラベルを作ってくれるようになりました。 スクラムガイドではスプリントバックログをどのように運用するかは定義されておらず、開発者に委ねられています。 みなさんもぜひ自分のチームに合ったスプリントバックログの形を見つけてみてください。