この記事は Akerun Advent Calendar 2020 - Qiita の 6 日目の記事です。
はじめまして、AkiAbe - Qiita です。
(まさか、初記事を誕生日に合わせて書くことになるとは思いもしませんでした。)
私は、2020/9 から Photosynth にジョインした新参者です。
2020/11 から弊社の組込みエンジニアチームでは スプリント開発を取り入れています。
ということで「組込み x スプリント開発」の話を書きます。
導入のきっかけ、背景
入社して一ヶ月くらい状況をみて感じたことを一言でいうと
「みんな、自分の作業 (主担当のデバイス) 以外のことに興味なさそう。チームとして機能していないなぁ。」
という印象をうけました。 (二言になっちゃったw)
以下、それぞれ文字にするとこんな感じです。
おそらく、どこの開発現場でもあるような気はします。
スケジュール全体の期間が大きい (クォーター単位とかでの管理)
メンバー全員が、途中途中で「プロダクトのあるべき姿」を共有できていない。
スケジュール完了にむけて、1 ヶ月後にどうなっているべきか？ 2 週間後はどうか？の認識に差異がある属人性が高すぎる
デバイスごとに担当者が固定になっていて、リーダー以外はフォローできない。
このご時世なので誰かが長期休んだり、特定のデバイスに機能追加が集中したら
一気にボトルネックとなりそう。
しかもチケットは切っているが中身が何も書かれてないものがほとんど。。作業進捗の遅れの検知が遅い
リーダーと担当者しか作業の内容や方針を把握できていない。
そのため、デイリーなどで進捗報告を聞いても
「本当に大丈夫？」「こういうことは考慮しなくていい？」
などのツッコミが、リーダー以外からできない。
しかもチケットは切っているが中身が何も書かれてないものがほとんど。。(再掲)レビューのタイミングが遅い
設計レビューの明示的なタイミングがない。
コードレビューで設計内容をみるような形 になっていて
何か問題がおきると手戻りが大きくなりすぎる。機能品質と性能品質 (機能要件/非機能要件) がごっちゃになっている
機能を作りこむタスクで、性能面にベクトルが向いてしまうことがある。
一つのタスクの中でいろんな作業を混ぜ込んでしまい、完了時期がうやむやになってしまう。
改善したいこと
チームとして機能する状況をつくりたい。
全員が 1 ヶ月後、2 週間後、1 週間後、プロダクトがどうあるべきかを理解し
全員が 1 週間後のあるべき姿にもっていくために全力で取り組める環境にする
必要があると感じたため、スプリント開発を取り入れてみました。
決めたこと
スプリント開発に向けていくつか決め事をしました。
走りながら改善をする前提ですが、何もルールがないと始められないので
まずは以下のように定義しました。
スプリント期間
1 スプリント 1 週間 とします。
- 毎週木曜からはじまって、水曜の午前中までが一つの区切り
- 木、金の 2 日働いて、土、日でしっかり休んで、月、火の 2 日で終わらせる
というサイクルを目指します。
チームとして過去にもスプリント開発をしようとしたことがあるそうですが、当時はうまくいかなかったそう。
スプリント期間を短くして体に染み込ませられないかなぁと思い、短く設定しました。
定常的な会議の時間
以下の 3 つの会議を設定しました。
- デイリースクラム (月、火、木、金で 15min )
- 話す内容は以下の通り。込み入った話になりそうな時は、気づいた人が勇気をもって「別でやりましょう」という。
- 昨日やったこと、それにどのくらい時間をつかったか
- 本日やること
- 困っていること
- 話す内容は以下の通り。込み入った話になりそうな時は、気づいた人が勇気をもって「別でやりましょう」という。
- 次スプリントに向けたタスク分割 (火曜午後、各担当者 30min を目処)
- スプリントの振り返りと計画会議 (水曜午後、max 2h を目処)
ポイントの決め方
後述するようにタスク粒度をちょっと粗めに定義しているので 1pt を 4h とする。
1 人あたりの 1 スプリントの稼働時間が 4.5 日で、各自事務作業や割り込み時間があることを想定して 1 日 7.5h 稼働できる
という前提でポイントの計算をする。
また、次スプリントを計画する段階で目に見えた割り込み (例えば過去機種の障害調査の依頼がきている) なども考慮して
チームの総ポイントを決定します。
タスクの粒度
1 タスク、最長 2 日としています。
1 タスク、1 日 or 半日で終わる粒度にもっていけるのが今の自分の理想。
作業管理ツール
backlog を使います。
というのも、弊社は組込み開発チームと横並びで、ハードウェア開発チームも存在していて
私がジョインする前から、両チームのタスクをまとめて backlog で 1 つのプロジェクトとして管理しています。
ハード開発側は backlog で、組込み開発側は redmine で、とツールをばらけて管理すると
統括のマネージャーが発狂してしまいますw
ので、本プロジェクトでは backlog をそのまま使い続ける決断をしました。
backlog の運用方法
backlog の使い方もある程度ルール決めました。
- スプリント期間の進捗を管理するための、専用のマイルストーンを用意
- マイルストーンが一週間ですべて完了になるようにするのが目標
- 作業中に気づいたタスク (障害含む) はそのマイルストーンではチケット発行しない
- 要は、「計画されてない作業はやらない」というのが基本スタンス
- 作業中に発見した不具合などは、次スプリントに回す
- (ただし、他チームが関わるような内容の作業の割り込みは容認する)
- 振り返りが終わった時点で、完了になったタスクのマイルストーンから外す
- これにより、毎週マイルストーンが「1 週間でやるべきもの」でリフレッシュされる仕組み
管理の側面 (苦労話含む)
ここからは管理側の側面から。
まず言葉の定義
ストーリー、タスクなどの意味合いもチーム内でズレないように定義します。
今回は、一般的な定義をそのまま踏襲させてもらっています。
IoT デバイス開発にかかわらず、基本的な開発の流れってこんな感じですよね。
- A ということがしたい (ユーザストーリー : ステークホルダーの要望の単位)
- じゃあ B 、C、D みたいな振る舞いがいるね (ストーリー : プロダクトオーナーの考える分割できる機能の単位)
- B を実現するためには、X, Y , Z という手順でやらなきゃね (タスク : 開発者が作業する単位)
それをスプリント単位で考えると、GUI 系の開発を例とすると
- スプリント 1 では画面だけ作ってリリースしますね。
- スプリント 2 では、このボタンの動作をリリースしますね。
みたいな流れですね。
組込みで言うと
- スプリント 1 では LED やディスプレイ使えるようにします
- スプリント 2 では BLE 通信してその状態を LED の変色で通知します
みたいな感じで分割ですかね。
ストーリーの管理
弊社では、ハードウェア開発と組込み開発を並行して走らせており
ハード/組込みの開発スケジュールをミックスして管理しています。
そこで定義されてるソフトウェアの 1 機能を 1 ストーリーとしました。
また、上述のものは大枠のスケジュールとなるため実際にその機能を作るのに
どれくらい時間がかかるかは考慮されないことが多々あります。
( イメージしやすくするために少し乱暴に書くと 「X 月までにはこの機能できてないと困る」みたいな感じのスケジュール。)
そのため、一番最初に各ストーリーを、プロダクトオーナー、スクラムマスター、開発リーダーで粗めのタスクに分割して
「ざっくりと 1 スプリントでこのあたりまでやる必要がある」
というのを決める (ゴールを共有する) 作業をする必要がありました。
この作業を進めていくと
「ストーリー A は 3 スプリントくらいかかりそうだな。」
などが見えてきます。
こうやって、
・各ストーリーは実際のところどのくらいの期間をみればいいのか ・そもそも期間内に全部のストーリーの完遂が可能なのか
を具体化するところからはじめました。
このように洗い出しをした後に、プロダクトオーナーとステークホルダーとで
納期や優先度の調整をしなければなりません。
これができないと
「できない約束 (もしくはデスマーチをして作る約束) 」
を、してしまうことになります。
そのため、「規模感を改めて開発チーム内で見積もる」を丁寧にやることが
とても大事なことだと感じています。
「できないことをできない」と言うことは悪いことではなく
「やりきれないことをやります」という約束をするのが一番悪いこと
だと、私は思っています。
タスクの管理
スプレットシートでストーリーとそのタスク、さらにスプリントの状況をまとめています。
次の項目と同じシートをつかって
というような流れでやっています。
スプリント内で、見積もり超過しているような作業があれば、デイリースクラムで
backlog のチケットを開きながら、状況確認をするようにしています。
IoT 開発ならではの問題点
既出ですが、弊社はハードとファームを並行して開発しています。
そのため
- メカのこの部品を変えたいから、それに合わせた試作ファームを作って欲しい
- 回路のここがちょっと怪しいので、こういう評価できるようなファームを作って欲しい
などなど、ハード設計 FIX に向けて緊急で対応しなきゃいけないことを
お願いされることがしばしばあります。
製品開発上、必要な作業なので対応必須なのですが、そうすると当初の
スプリント計画が崩れて、スプリントの積み残しが増えてきます。
このあたりの割り込みを予想したうえでスプリント計画を立てるのに
なかなか難しさを感じています。
ベストプラクティスは見つかっておらず、余裕を持ったスプリント計画にして
対応をしていますが、そうすると、全ストーリーの完遂が難しくなるという
あっちを叩けばこっちが出てくるような状態。。
1 ヶ月たった現状はどうなったか
もう 12 月になるのでスプリント開発に取り組んで 1 ヶ月が経過しました。
状況的には 、このあたりは改善傾向にありそうです。
- メンバが自分の担当外の作業の状況も気にするようになった
- チケットへの記載も丁寧になってきたため、情報の蓄積も共有も進んだ
まだまだ改善すべきこともたくさんあるので、これからも改善を繰り返して
よりよい製品をつくるために、よりよいチームビルディングができればなと思っています。
株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 hrmos.co
Akerun Proの購入はこちらから akerun.com
