GitLabのProduct Development Flowを導入した話

はじめに

これまでシンプルなスクラムで開発をしていたのですが、人員増加に伴い色々と課題が出てきたので、その色々に対応するためにGitLabのProduct Development Flowを導入しました。
https://handbook.gitlab.com/handbook/product-development-flow/

開発体制とプロセス

バックテックでは、エンジニア10名程度、PdM1名、デザイナー1名にて、2チームでのスクラムを行っています。
Scrum of Scrumsのような形で同期的にコミュニケーションを取っています。

複数チームスクラムについては、導入時にLarge-Scale Scrumにするかも悩みましたが、2チームで最優先のバックログに協同して取り組もうとすると、PBIごとに必要となるドメイン知識に追いつくコストが大きそうと見込み、SoSを採用しています。

問題だと感じたこと

2つのスクラムチームが活動しているうちに、次の問題が見えてくるようになりました。

1. PdMとデザイナーと開発チームの誰が仕様策定をするのかわかりづらい
2. PBIがどういった状態かかわかりづらい
3. エンジニアが技術調査や設計タスクを行う際、コードを書かないスプリントが発生し、スプリントレビューで提示するものがなく不安になる

検討したこと

元々の開発プロセスに明らかな欠陥や不足があったわけではないですが、1.2.については境界が曖昧な部分があるがそれを「認識するための共通言語がないこと」が課題であり、3.については「SpikeやDiscoveryにあたる活動についての共通認識がないこと」が課題だと定義しました。

そこで開発プロセスを整理して、自分たちが活動する際の言葉を合わせようとしました。
また自分たちで1から定義する選択肢もありましたが、先人が整理したプラクティスに乗っかる方が時間対効果のメリットがありそうであったため、既存のものを参照する形を取りました。
以下の3つの内容が候補にあがりました。

候補1: Dual Track Agile/Development
候補2: Spike
候補3: GitLab Product Development Flow

候補1: Dual Track Agile/Development

みんな大好きデュアルトラックアジャイルです。
価値検証のフェーズと価値提供のフェーズを1チームで両方担うやつです。

これまでのバックテックでは、デュアルトラックアジャイルでいうところのDeliveryに重きを置いていたので、Discoveryという概念をチームに取り入れること、またスパイク(技術調査や検証)をそこに含められる大きなメリットがありました。

しかし、Discoveryが示す範囲は広く、便宜上Problem DiscoveryとSolution Discoveryにわけると、いまのバックテックのエンジニアが価値を発揮しやすいのは後者になるものの、Discoveryという単語だけで括るとその範囲の広さから混乱が生まれやすいと思い、別案の検討に移りました。

候補2: Spike

続いて問題3.に紐づく「 エンジニアが技術調査や設計タスクを行うの状態や活動内容の定義」について、XPからSpikeの考え方を持ってきて、それを開発の1つのタスクとして定義するのはどうかと検討を行いました。
他の候補とは毛色が異なり、Spikeという部分だけ定義しようとしました。

http://www.extremeprogramming.org/rules/spike.html

こちらは割りと賛成するメンバーも多かったのですが、ディスカバリーからデリバリーまでが一貫して見られる状態が好ましいし、SpikeにとどまらずSolution Discoveryを行うことを考えると、範囲が狭すぎるという結論になり、次の検討に移りました。

候補3: GitLab Product Development Flow

デュアルトラックアジャイルに似た2Trackと、それぞれを4Phaseに細分化したフローです。

https://handbook.gitlab.com/handbook/product-development-flow/ を基に作成

境界が曖昧である課題や設計やエンジニアが仕様策定や技術調査をする状態定義もPhaseがあり、かつProblem DiscoveryやSolution Discovery、実装後のリリースreadyな状態やリリース後の計測まで定義されているので、少し細かすぎて管理が煩雑かも、、と思いつつ、今の自分達に適切だと感じ導入しました。

導入してみて

このような形でバックログに適用しました。

様々メリットがありましたので以下に書き連ねます。

• リファインメントやプランニング時にエンジニアがどのTrackのどのPhaseから着手するかを会話できるようになった(課題1.の解消)
• 「来週からもうBuild Trackに移行できるっけ？」と会話をできるようになった(課題2.の解消)
• ValidationかBuildかBuild Trackが明確になって、自分たちが「価値を届けるための検証をする状況」、「実装して価値を届ける状況」なのかなのかが明確になり、安心して開発活動を行えるようになった (課題3.の解消)
• 「Validation Trackは少人数でやった方が進みやすい」、「Build Trackからは1チームでやっても効率よく進められる」というTrackやPhaseごとに知見を貯められるようになった
• PdMや事業企画メンバーが検討しているValidation BacklogやProblem Validationの内容が開発チームから認識ができるようになり、例えば「事業上必要だと思っているのに起票されていないもの」があれば、「PBIがバックログに無いこと」を基準に疑問を投げられるようになった
• Build TrackのImproveのフェーズがあるので、リリース後に計測・改善をタスクとして計上し忘れることがなくなった
• レトロスペクティブにて、開発プロセスに関するネガティブな付箋の数が明らかに減った（良くなった！という付箋が多くなった）

これからやること

導入によるあまりデメリットは出ていないのですが、開発活動をより良くしていくために以下のようなことを考えています。

• いまはValidation TrackのDesignフェーズ以降をエンジニアが対応しているが、意欲のあるエンジニアであればValidation BacklogやProblem Validationにも関わっていく
• スクラムでやっているが、Validation TrackのDefinition of Doneを未定義なので決める（いまはそういった品質基準がないので、XPでいうところのAcceptance Criteriaの中に(仕方なく)書いている）
• 1チームにてValidation TrackとBuild Trackをどの程度の比率で実施するのが良いかの検証

おわりに

今回の導入活動では元々の開発プロセスから大きく変わった訳では無いですが、同じ人が同じように開発しているいるものの、共通言語があるだけでこんなにも動きやすさが違うのかと、活動に名前をつけることの大事さを実感しました。

蛇足

Royceの"Managing the development of large software systems"内で書かれている行ったり来たりのフローで定義するだけで十分かもと提案したのですが、あんまりウケがよくなかったので早々に却下になりました。馴染みやすさも大事。