見出し画像

Lychee Redmine開発チームの開発スタイルについて


開発チームと開発スタイルについて

初めまして、アプリケーションエンジニアの朝倉と申します。普段はLychee Redmineの開発を行なっており、フロントエンドからバックエンドまで全てをやってます。

この記事では、Lychee Redmineの開発チームがどのようなやり方で、どのようなことを大切にして日々の仕事に取り組んでいるかを紹介します。アジャイル開発の一事例として参考になれば幸いです。

アジャイルウェアのプロダクト

アジャイルウェアには大きく2つのプロダクトがあります。

  • Lychee Redmine

  • KIWI GO

それぞれの詳細な説明は省きますが、Lychee Redmineはプロジェクト管理ツール、KIWI GOはウェルビーイング促進アプリとなります。

私はLychee Redmineチームに属しており、この記事はLychee Redmineチームについての紹介となります。

Lychee Redmineの開発チーム

基本的にスクラム開発のスタイルを採用しています。現在いくつかのサブチームがあり、それぞれエンジニア、テスター含めて平均して6名程度のチーム編成となっています。他にPOが1名、そしてチームを横断してデザインを担当してくれているデザイナーが1名います。

以降の記述は私が所属しているサブチームのものとなります。それぞれのサブチームで別々の改善策を行うことを良しとしており、各サブチームで色んな改善案を行なっています。他のサブチームに関しては、誰かがそのうち書いてくれるかもしれません。 😁

開発の流れ

まず、2週間スプリントを採用しているので、2週間の中の動きを説明します。

スクラムのイメージ図
引用元: Scrum Primer アニメ版 スクラム概要図
ライセンス: 画像はOdd-eまたはScrum Primerサイトに帰属します CC BY-ND 3.0 DEED

まずスプリントが開始すると、スプリントバックログからタスクを取ってやり始めます。スプリントバックログは、前スプリント最終日に行われるプランニングで作成済みなので、あとはタスクを取るだけになっています。

スプリント期間中は毎日デイリーミーティングを行い、全員の作業内容や問題点、またスプリントバックログのタスクが全てスプリント内に終わるかどうかを毎日気にしてお互いに確認し合います。

スプリント期間中の間の丸1日を、リファインメントの日として使っています。リファインメントでは次のスプリントでやるタスクの詳細を話して見積もりを行い、タスクを着手可能な状態にすることを行なっています。

スプリント最終日には、POやステークホルダーに対してスプリントレビューを行います。このスプリントレビューのファシリテーションも、チームメンバーが順番に皆で回すようにしています。そしてスプリントレビューの後、振り返りを行い、その後にプランニングを行なってスプリントが完了となります。

次にスプリントイベントの内容について、書いていきます。

デイリーミーティング

毎日昼過ぎに行なっています。

  • 全員の作業内容の確認・問題点の共有
    1人ずつ今何をやっていて、問題が発生していればそれが何なのかを共有します。

  • 進捗の確認(スプリントバックログのタスクが全てスプリント中に終わるかどうか)
    バーンダウンチャートやカンバンを見ながら本当に終わるかを話し合います。また、タスクに着手中であれば、それがいつまでに完了しそうかお互いに確認します。

  • パーキングロットの確認
    デイリーミーティングで話し合いたいことを置いておく場として、パーキングロットを用意していますが、そこに書かれたことを話します。POがいないと判断できないことであればPOに来てもらい、話します。

  • 連絡事項の確認
    休む予定が入ればこのタイミングで共有します。

リファインメント

次のスプリント以降で着手する予定のタスクについて、皆でタスクの詳細を話して見積もりを行い、タスクが着手可能な状態にします。
基本的にスプリント期間中の固定の1日を取っていますが、例えば割り込みのタスクが依頼された場合や、プランニング時に緊急でタスクが依頼された場合には臨時でリファインメントの時間を取ってやることもあります。

私たちが行なっているリファインメントでは、下記のことを行います。

  • POが書いたタスクの期待値を元に、実装する際の仕様に落とし込む
    タスクの仕様を話すために、実例マッピングという手法を用いてやっています。実例マッピングは疑問点や仕様の不明点をタイムボックスを切りながら皆で話して詰めていく手法で、やり方が定型化されているので取り組みやすいです。

  • 実例マッピングを行い書き下した仕様を元に、テストの観点をざっくり書き出す
    私たちのチームではエンジニアが実装(自動テストの実装を含む)を行い、それを元にテスターが手動テストを実施して、タスクを完了するというフローを取っています。そのため、テスターがテストを実行した際に実装の不備やバグが見つかると、それをエンジニア側にフィードバックする必要があります。このフィードバックが量が多かったり何度も往復したりすると、必然的にタスクを着手してから完了するまでの時間(リードタイムと我々は呼んでいます)が伸びていきます。そこで我々はそのリードタイムが出来るだけ短縮されるように、フィードバックが出ないような取り組みを積極的に行なっています。その1つがリファインメントにおけるテスト観点のざっくりな洗い出しです。
    リファインメント時にテスト観点をざっくり洗い出しておき、エンジニアが実装時にその観点を気にして実装を行うことで、フィードバックを減らすことができます。

  • ポイント見積もり
    テストの観点をざっくり出し終えたら、全員でポイント見積もりを行います。基本的に相対見積もりですが、シンプルな言葉で書いた指標リスト的なものも用意しており、新しく入ってきた人がポイントのイメージを築きやすいようにしています。
    ポイントは基準となるポイント以上の大きさになったら分割するルールを決めています。ただし、分割が難しければそのまま、など柔軟に運用しています。

リファインメントにかなり時間をかけていると思われるかもしれませんが、ここをしっかりやることで、実際の実装を行った時に発生する、各々の認識の違いを出来るだけ発生させないことに良い影響を与えることができています。非常に重要なイベントです。

また以上の全ての作業は皆でMiroというオンラインホワイトボードツールを使い、付箋を適宜使いつつ進めています。

Miroで使っている、リファインメント用テンプレート
※このテンプレートがバックログアイテム1つ分の作業用スペースになります

スプリントレビュー

POやステークホルダーを招待し、スプリントで実装した機能についてデモンストレーションを行い、フィードバックを貰います。
見せることが容易なタスクは基本的に全て画面で見せますが、例えば見せるのが非常に難しいタスクの場合は説明だけを行うこともあります。

振り返り

振り返りのファシリテーターはチームメンバー皆で持ち回っています。また社内のカイゼンを専門としたチームにファシリテーターをやってもらうこともあります。
ファシリテーターが振り返りの手法を決めてやっています。
基本的にKPTでやることが多いですが、他にもFun-Done-Learn、4Lsなどの振り返り手法を試して、適宜取り入れています。

振り返りのアイスブレイクにはSprint Varveをやっています。これは何かというと、あるスプリントの期間に仕事やチーム、プライベートで何が起きたかを年縞(Varve)のように積み重ねて記録していくワークです。チームの歴史がそこに刻まれるので、色々な思い出を振り返る時に役立ちます。

Sprint Varveの一部

プランニング

基本的にリファインメント時にある程度タスクの詳細は詰めて、かつ見積もりも済ませているのでプランニングでは積むだけになります。ただ、POが新規のタスクを積んだり、リファインメントしたけど要件が少し変わったタスクなどについては、このタイミングで再度リファインメントを行うこともあります。

プランニングではLychee Redmineに備わっているベロシティ機能を用いて、次のスプリントに詰めるポイント数を計算し、それを元にタスクを積みます。ただ、ポイント分ギッチギチに詰むのではなく、あくまでちゃんと完了させることが出来る分のタスクを積むことを、PO・チームメンバー全員意識して話し合います。割り込みが入りやすそうという見立てがあればポイントより少なめに積みます。

大事にしていること

スプリントバックログに積んだタスクを完了させること

現在スクラムをちゃんとやっているのは、そもそも以前スプリント的なことをやっていたにも関わらず、積んだタスクが全然終わらないことが常態化していたことにあります。そのため、積んだタスクは終わらせることを非常に強く意識してスクラムを実施しています。

みんなでタスクに取り組むこと

これはスクラムをやっているチームでは当たり前かもしれませんが、誰か1人にタスクをお任せするのではなく、適宜助け合い、タスクが終わるように皆で頑張っていくことを意識しています。テスターの人手が足りなければエンジニアがテストの手伝いをしますし、定型的なコードの置き換えなどについてはテスターの手をエンジニアが借りることもあります。

自分たちでやり方を改善していくこと

自分たちで自分たちを律することを強く意識しています。どうやったら目標をより達成できるのか、どうやったらチームメンバーがよりよく仕事をできるのか、常に皆で考えています。

最後に

Lychee Redmine開発チームの実際の開発スタイルの雰囲気が伝わりましたでしょうか。これからも開発チームや実際の開発について発信していきたいと思います。


補遺

プランニングをスプリント最終日にやる理由

なぜ最終日にプランニングをやっているかというと、サブチームが複数あり、プランニングや他のスプリントイベントの時間を被らせないようにするためです。諸々の調整の結果、私のサブチームはプランニングをスプリント最終日にやるようにしています。

専任のスクラムマスターはいない

私のサブチーム、それからLychee Redmineの開発チームには専任のスクラムマスターはいません。それによって起きている明確な弊害は感じていません。とはいえ、アジャイルウェア社内にはスクラムマスターの資格を持った方やカイゼンを専門としたチームも存在しており、そういった方から適宜アドバイスなどは受けています。また私自身もスクラムマスターの資格を持っており、チームのスクラムができるだけうまく回るよう注視はしています。

みんなにも読んでほしいですか?

オススメした記事はフォロワーのタイムラインに表示されます!

広報の無法地帯とも言える公式裏アカTwitterでは、ありのままのアジャイルウェアを発信しています!