Blogアプレッソのエンジニアが書く技術ブログです。この広告は、90日以上更新していないブログに表示しています。時間以下の単位に分割するのはなぜか開発こんにちは、開発部の野口です。移行しようかどうか検討中です。週間スプリントのプランニング」について書きます。次期バージョン開発チームで、開発者をやっています。週間に設定しています。スクラムによる開発を始めた経緯や、スクラムによる開発の様子については、ぜひ昨日の記事をご一読ください。時間以下の単位に分割するのはなぜか」について、その始まりから、実践、メリット、今後の課題についてお話ししていきます。週間か、いいね、それでいこう」とただちに思える開発者は、まだそれほど多くないと思います。始めた頃の私たちもそうでした。いいネ、毎週デリバリーしてこ!」といきなり思えるほうがおかしい。本物のスクラムでプロジェクトを運用すると決めたとき、私たちが受け入れることにしたのは以下のような条件でした。まで分解する根拠は、昨日の記事でも何度か登場した、認定スクラムマスター研修講師の江端さんのおすすめです。私も研修に参加したのですが、この話が出たときあまりのショックに思わず「マジでやるんですか」と聞いたら「やるんです」と言うので、「やるか」と思いました。Planning)とは何でしょうか。スクラムフレームワークで定められたセレモニーの一つで、簡単にまとめると、以下のようなものです。完成させられるように計画を行います。成果物は、コミットメントです。「完成できそう」「完成できるかもしれない」ではなく「完成させます」という「約束」です。当然ながら、「すみません、一日遅れます」もありえません。予想ではなくコミットメントであるということは、スクラムの透明性を確保するために重要な部分だと思います。できるのかとは言ってみたものの、不安です。時間以下の単位に分割する?どちらも、できそうなイメージが湧きません。以下のような不安がいくらでも湧いてきます。数が多すぎませんか?計画した機能を期間内にすべて完了できたこともほとんどなかった。以下に分割するには、メソッド単位の設計が必要になりそう。BDUF(事前の過剰な設計)を助長するのでは?とにかく、やってみるしかありませんでした。ヶ月あまりが経ちました。それがとてもうまくいっていることは、昨日の記事で紹介された通りです。時間以下」という制約を、どのように克服したのでしょうか。やっているのかはじめに言っておくと、さまざまな紆余曲折を経ました。Retrospective)を行い、開発チームとして、必ず何か一つ(以上)の改善アクションに合意します。やって少しずつ改善してきました。その経緯をくだくだしく説明することはしません。現在のやり方を、かいつまんで紹介します。時間未満に分割しようとすると、タスクの数は膨大になります。枚でした)もちろん、そのために設計上の調査や議論も必要になります。ある程度(ストーリーポイント数から判断して、ほぼ確実にコミットできるだろうという数だけ)選択したあと、まずチームをいくつかに分けて、並列で見積を始めます。取り組むという傾向です。チームに分かれて見積もります。見積る計算になります。メンバ)が混在しており、スキルセットがかなり異なります。この図を見れば、その背景をわかっていただけるかと思います。▲前バージョンまでの開発体制。チーム」は部レベルで異なる(開発部と品質管理部。タスクかによって担当者が限られます。メンバはそれぞれでタスクの見積りを行っています。グループ程度に分かれて調査・見積を行っています。スキルセットが大きく異なるという背景もあり、「プログラマが実装してから、テスターが手動テストをする」というモデルが残っています。週間では完了できません。「チェックポイント」を設けて、計画中に「ここまでできたら、ここまでテストできる」ということを取り決めます。集まって行っておき、のちにチーム全体でレビューします。タスクに分けるさて、いよいよタスク分割です。当然ですが、計画では、実際のコードを見ます。ときには少しだけコードを書いてみて、動作を確かめたりもします。ような成果物は原則として残しません。議論したことを覚えていれば十分だからです。一週間なら、覚えていられます。量が多く、覚えていられなそうなときには、試しに書いたコード辺のスクリーンショットを撮ったり、クラス名をメモしたりします。どれくらいメモするかということは経験による感覚なので、一概には説明できません。ある程度設計が見えてきたら、タスクを作っていきます。時間以下のタスクの集まりにします。メンバのタスク分割に参加したことはありません。時間以内の単位で区切ってタスクとしているようです。メンバはテスト項目の大まかなリストを作ります。メンバが想定するものよりも、より広範で緻密な観点になっていることが往々にしてあります。メンバはレビューし、設計上の考慮漏れや自動化テストの不足を補います。メンバにフィードバックします。間のフィードバックも行いました。週間で確実に機能を届けるために、すべてのメンバが、任意のタイミングで、任意のタスクを実行できることが目標です。できあがったタスクリストを、皆で集まってレビューします。私はこのタスクを正しく実行できそうにない」)があれば、質問します。結果として、計画がより洗練され、実際のところ、誰でも任意のタスクを実行できる状態になります。名のコミットが含まれます。関わることになります。分かれて行っていることです。週間で実行する、数十(今スプリントでは、82)のタスクができあがります。タスクの見積を合計し、今スプリントの稼働時間と比較します。この際は、これまでの実測データに基づくバッファ率を掛けてから比較します。