スクラム: 早すぎるプロダクトバックログリファインメント

スクラム (Scrum)

複雑で変化の激しい問題に対応するためのプロセスフレームワーク。

記事

エッセンシャルスクラムを読む会

2017年4月14日 (金)

第23回エッセンシャルスクラムを読む会 (最終回)

rimage:/nDiki/2017/04/14/2017-04-14-092915-nDiki-800x1200.jpg

社内で「エッセンシャルスクラム」を読みたい人が集まる勉強会の23回目。第23章未来へ。ついに最後の章です。

スクラムは継続的な改善の一形態なのだからこれが最終形態というものは無いし、どのチームをとっても同じというものは無い。プラクティスはあってもベストプラクティスはチームによって違う。準備ができていないからスクラムを始められないというのはそもそも原則に反するので、まずやって学ぼう。現状を変えるよりもスクラムを無視したりスクラムを変更したりすることの方が簡単だけれど、組織を変革するために協力しあいながら確固たる信念をもって立ち向かおう。

そんなメッセージを本章から受け取りました。

第1章の「スクラムは役に立つか?」で出た通り全ての領域でスクラムが適しているわけではないので、盲目的に導入すれば良いというものではなく、領域が変わった場合はスクラムを続けるか続けないかの判断が必要になるのでしょう。もし取り組む領域が「複雑な領域」であるならばスクラムフレームワークはとても強力だということは間違いありません。

「エッセンシャルスクラム」と「エッセンシャルスクラムを読む会」そしてなによりこの半年のスクラム開発経験でスクラムについて多くを学ぶことができました。「エッセンシャルスクラム」は「スクラムガイド」を読んだだけでは得られない広範囲な知識やノウハウが詰まった良い一冊でした。

エッセンシャルスクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

エッセンシャルスクラムを読む会のふりかえり

エッセンシャルスクラムを読む会を終えたあとは、オフィスのコラボスペースでビールを飲みながらお疲れさま会。参加の皆さんお疲れさまでした。この回を始めてくれたはらかち氏に感謝。休まず毎回参加してディスカッションしたことでいろいろな学びを得ることができました。嬉しい限りなので珍しく私もビールで乾杯しました。いっしょに全回参加した2人のうちの1人である RabbitFake 氏も特にお疲れさまでした。

ふりかえって出てきた話題としては

取り組む領域がクネビンフレームワーク(第1章)のどの領域なのかを見てスクラムを採用するかどうか考えたい。
チームメンバでエッセンシャルスクラムを読むことで「PBI」などの同じ理解で使える言葉が増えた。チームの共通言語作りに貢献できた。
原則大事(第3章・第14章など)。
WIP を下げる重要性をあらためて学んだ。
準備完了の定義・受け入れ条件が重要。

などが上がりました。

また実際に読む会と並行してスクラムを行ってきた中で

プロダクトバックログリファインメントで1スプリントにおさまるように適切にプロダクトバックログアイテムを分割するの大変だよね。
スクラムマスターと開発チームメンバ(エンジニア)との兼任が難しかった。
スクラムマスターであると同時に組織図上のリーダーという立場でいると、自発的行動を促すのとある程度指示的に動かすのとの兼ね合いが悩ましかった。
困った状態であることにメンバが気がつくのを3カ月待った上で物理かんばんを導入してみた(すごい)。

などの話が出ました。

スクラム実践についての「検査と適応」をタイムリーに勉強会をしながら進められて学びの多い半年間でした。

全23回

スポンサードリンク

[ permalink ]

[ 4月14日全て ]

2017年4月27日 (木)

今日のさえずり: 昔、ケーキといえば芝大門の izumi のでした

2017年04月27日

08:34 今日はいい日だ。
09:00 某氏、土曜日はドールを連れて撮り歩くのかな。
11:00 試供品としてついてきていたリステリントータルケアは洗口液ではなくて液体歯磨きだったのか……。クチュクチュペしかしてなかったよ。後味が悪い訳だ。
14:50 さよならランチ。 (@ 青山星のなる木 in 渋谷区, 東京都) https://www.swarmapp.com/c/kmMqWLsaLib
18:38 歩きたこ焼きの人に遭遇した。
18:50 窯出しとろけるプリンも窯焼きとろけるプリンも終わってる。
21:50 RT @harakachi: なんか変だなって思う気づきと、何が変なんだろうって潜る力が、スクラムに出会って界王拳ぐらい増した気がする。善し悪しの判断基準が出来たからなんだろうなあ。
22:23 昔、ケーキといえば芝大門の izumi のでした。

[ permalink ]

[ 4月27日全て ]

2017年7月10日 (月)

スクラムマスターのいるチーム【日記】

暑いのでお昼は社内販売の弁当。

スクラムマスターのいるチーム

やはりスクラムマスターがいるのといないのとでは、スプリントの回しやすさ・プロセス改善のしやすさが全然違うなと感じています。スクラムをやるまでは謎な存在でしたが偉大さがわかってきました。

Prime Dayセール

安くなっていた Fire HD 8 タブレット (Newモデル) 16GB を購入。

Fire HD 8 タブレット (Newモデル) 16GB

シューズ25%オフにつられてニューバランスのウォーキングシューズも買い足し。

[ permalink ]

[ 7月10日全て ]

2017年8月1日 (火)

メンテナンスフェーズに入ってきたプロダクトの保守とスクラム

メンテナンスフェーズに入ってきたプロダクトを保守しているスクラムチームのプロダクトバックログが枯渇してきました。無理に新しいことを絞り出して手を入れ続けるのが得策ではない感じに。

もはやスクラムで開発には適さない領域に入ってきたのかもしれません。一段上のレベルに戻ってプランニングするのが良さそう。

[ permalink ]

今日のさえずり: Emacs を起動して M-x shell してゔぃむしたら崩れた

2017年08月01日

13:22 メンテナンスのみの領域に入ったら、もはやスクラムは最適ではないということ。
13:34 Emacs を起動して M-x shell してゔぃむしたら崩れた。
24:35 ドライヤーをかければすぐ寝られる事を最近覚えたのだが、この時間にドライヤーをかけるの面倒だというのも最近覚えた。

[ permalink ]

[ 8月1日全て ]

2017年8月2日 (水)

何もコミットしないスプリントで各自好きなことをする

インクリメントの完成に高いコミット意識をもって毎スプリント取り組んできている CS 開発チームがいくつか大きなリリースを終えたので、スクラムマスターと相談して今日からの1週間スプリントは「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良いことにしました。

リファクタリング・技術的負債の返済・開発環境の整備や、調査・学習・ドキュメントの整理など、いつものスプリント中にはなかなかできないことを各自でしてよい1週間です。

普段から持続可能なペースを意識してスプリントプランニングしていますが、それでも頑張り続ければストレスも溜まってくるでしょう。適切なタイミングでブレイクを挟むことで、バーンアウトを防ぎ長期的にデリバリーし続けられるチームでいられればと思っています。

ちなみにこの取り組みは去年別のチームが unwinding period と呼んでやっていたのを真似てみたものです。

今回スプリントがどういう感じだったのかは、いつも通りスプリントレトロスペクティブでふりかえってみます。

[ スクラム ]

[ permalink ]

[ 8月2日全て ]

2017年8月6日 (日)

仕事に追われない仕事術 マニャーナの法則完全版

タスク管理の記事を読んでいると「マニャーナの法則」というキーワードがよく出てきます。今までスルーしていたのですがここ最近クローズリストの考え方を取り入れてみているので、その辺りの話が書かれている「仕事に追われない仕事術マニャーナの法則完全版 (Do It Tomorrow and Other Secrets of Time Management)」を読んでみました。

仕事に追われない仕事術マニャーナの法則完全版

マニャーナの法則

まずマニャーナの法則ですが

原則1 新しい仕事は「明日やる」を基本にする
原則2 クローズリストを使う

という2つの原則のこととあります。日本語ではマニャーナの法則と訳されていますが the mañana principle なので「(行動)原則」の方が適切に感じました。

「すぐやる」ことの弊害

すぐやると「忙しいだけの仕事」ばかりが進み「本当の仕事」が進まないと指摘しています。新しくきた仕事にすぐとりかかってしまうのではなく、既存の仕事より価値があるかをまず考える必要があると説いています。

「すぐやる」は自分の行動原則の一つなのでショッキングな指摘です。言われてみれば主体的な仕事よりも反応的な仕事に時間を使いがちです。

ただ「すぐやる」については

「後回しにしてチャンスを逃す」ことのないようにする。
先送りすることで増大するコストを最小化する。

というメリットがあるのも事実。このあたりは本書で言うところの「緊急レベルの判断」とバランスを取っていく感じなのでしょう。

全員がマニャーナの法則をやるとどうなるか?

個人個人がマニャーナの法則に従ってバッファリングすると組織全体のリードタイムが伸びるのではという懸念を持ちました。個人の稼働が最適化されるかわりに、作業の手待ち(idle work)が多く発生することになるからです。

このあたり要注意に思われます。

緊急レベルを判断する

入ってきた仕事はまず緊急レベルを判断するというのが本書の考え方です。

緊急レベル1「今すぐ」
緊急レベル2「今日中に」
緊急レベル3「明日やる」(ベスト)

本書では「明日やる」がベスト。

これはすでに2週間前からRemember The Milk の優先度設定に取り入れてみています。

WILL DO リスト

その日にやるとコミットしたタスクを入れておくクローズリスト。自分は Remember The Milk でタスクの優先度を1にすることでリスト化しています。

処理する順番はファースト・タスクが最初で「明日のリスト作成」が最後です。それ以外はまったく自由。

1日の最後に何をおいても明日の WILL DO リストは作成することが必須とあります。仕事については実践していますが、プライベートでは翌日の WILL DO リストを夜に作るのがまだ習慣にしきれていません。

ちなみに本書ではタスクにかかる時間の見積もりについてはほとんど触れられていません。翌日時間が足りず WILL DO リストを完了できそうもない場合もいつもどおりリストを作成し翌日は「できるとこまでやる」「完了できない日が続くなら対策をとる」という感じになっています。

やり残しをどうするか?

WILL DO リストで完了できなかったものは、「やり残し」フォルダに放り込み、ファースト・タスクで処理しましょうとあります。

これは今週から Remember The Milk で backlog タグを付けるようにして実践中です。

ファースト・タスク

ファースト・タスクは「毎日の最初に行い、そこから1日をスタートさせるのが望ましい仕事」とのこと。毎朝最初にできる仕事は1つしかないので、常に1つ。

原則1 とにかく、する (Do)
原則2 一番始めに、する (First)
原則3 毎日、する (Every day)

ファースト・タスクに向いている仕事は

「やり残し」を片付ける
仕事のシステムを修正する
プロジェクトを進める

です。今は「やり残し」を片付けるのに使っています。先送りし続けることが減りました。

実際のところ実際に一番最初にはやれてなくてまず「セットアップタスク」なるものをやってたりします。これらを前日に済ませるようにできれば本当のファースト・タスクにできるのかも。

ダッシュ法

ダッシュ法はポモドーロテクニックにつながるところを感じました。ちょっとマニアックでテクニカルなやり方だというのと、マルチタスク型な印象なのとで今回はスルー。

二分等法すべての仕事を半分にする

プロジェクトをタスクに分解する方法。 GTD でプロジェクトに対して具体的な行動を設定するのと同様、本書でも具体的な行動に落とし込むよう指導しています。

その具体的なやり方として二等分法というのが紹介されていました。プロジェクトを二等分し、先にやる方をまた二等分にするというのを繰り返して「抵抗感が問題にならない状態」になるまで分割を続けるという方法です。

全てをブレークダウンすることはせず直近取り組む部分だけ具体的にするというやり方がスクラムにおけるプロダクトバックログリファインメントの考え方に似ていて気に入りました。

行動の合間に考える習慣をつける

最後の方の「考える」ということについての話で「行動の合間に考える習慣をつける」エクササイズが紹介されていました。

「毎日15分」など時間を決め確保する。
邪魔が入らない場所でノートと筆記用具を用意し、浮かんできたアイデアや考え方をノートに書き留める。
時間の終わりに近づいたら書いたものについて考える。良いアイデアや行動が必要なことに下線を引く。

というものです。時間(期限)を決めその時間の最後まで考え抜くというのがポイントだそう。ぜひ取り組んでみたいなと思います。

冒頭にキーワードが説明されているのが良かった

最後に本書の構成について。

本書では冒頭で「本書に登場する18のキーワード」として

「クローズ・リスト」「オープン・リスト」「チェック・リスト」
「コミットメント」「本当の仕事」「忙しいだけの仕事」
「バッファー・ゾーン」「マニャーナの法則」
「タスク」「プロジェクト」
「タスク・ダイアリー」
「デイリー・タスク」「ファースト・タスク」
「TODOリスト」「WILL DOリスト」
「ダッシュ法」「期限の効果」
「ラベリング」

が列挙されてそれぞれに簡単な説明がついています。簡潔でわかりやすく、本を読み進める助けになります。

本では「はじめに」で第1章では◯◯、第2章では△△とずらずらと書かれていたりしますが、前提知識が無いとわかりにくい書き方のものが多いです。それに対して、本書ではキーワードという見出しでサマリと流れをうまく説明していて素晴らしいなと感じました(ちなみに本書も「はじめに」では構成が手短に説明されています)。

仕事に追われない仕事術マニャーナの法則完全版

[ 読書ノート ] [ お薦めの本 ]

[ permalink ]

[ 8月6日全て ]

2017年8月9日 (水)

何もコミットしないスプリントで各自好きなことをして得られたもの

「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良い1週間スプリントが終わったのでチームでふりかえりました。

何をやらなかったか?

スプリントプランニング。スプリントバックログは空。

何をやったか?

チームとして
- デイリースクラム(朝会)はいつも通りやった。
- プロダクトバックログリファインメントもいつも通りやった。
- スクラム外でやったことをレビューした。
開発メンバがやったこと
- プロダクトバックログアイテムを準備完了にするための情報収集・まとめをやった。リリースできるものはリリースまでした。
- BTS にある不具合報告についてどんどん調査をした。
- まとまった時間でシェルの設定を見直して開発しやすくした。QOL が上がった。

このチームが自主的に決めたワーキングアグリーメント(記事)に

スプリントゴールが全て達成された場合は、優先する割り込みタスクがあれば対応し、そうでなければ準備完了になっていないプロダクトバックログアイテム(PBI)に関する情報収集・まとめを優先度の高いものからしよう。」

というのがあり、この活動をしていたメンバが多かったです。「スプリントバックログが空 = ただちにスプリントゴールが達成されたので PBI の準備に取り組んだ」わけですね。

環境整備にあてたりとかはあまり多くなかったようです。シェルの設定見直しをしたエンジニアは「失敗したら1日潰れてしまいそうで普段やれなかったことをできた」とやって良かったと言っておりました。

どう感じたか?

開発メンバからは以下のような意見が出ました。

「スクラムを始める前のチケット駆動開発時代に戻った感じ。」
「スクラムで開発をしない場合(タイムボックスが無い場合)、個人でしっかり時間・タスク管理する能力が求められると感じた。」
「半年に1度くらい頻度でまたやりたい。」
「スクラムでやりたい。」

得られた気付きは?

タイムボックスの良さにあらためて気付いた(期日から逆算していつまでに何をやるということを考えやすい)。
複数人で作業を見積もることで自信が得られることに気が付いた。

自由になったことで、普段やっているアクティビティの良さを再認識できたようです。チームが取り組んでいるプロダクトの状況から考えるとスクラムではなくカンバンの方が進めやすいのかもしれないのではと私は考えていたのですが、今回の取り組みで開発メンバは「スクラムで続けたい」と改めて思ったとのことです。

スクラムの基本からは外れる取り組みではありましたが、基本通りにやっていたのでは感じ考えることのことができないことを得られたという意味では非常に有意義な1週間でした。

[ permalink ]

[ 8月9日全て ]

2017年8月14日 (月)

今日のさえずり: C92 って C 言語の規格のことじゃなかったのか

2017年08月14日

05:02 スクラムの基本通りにやっていたのでは感じ考えることのことができないことを得られた。 / Naney の日記: 何もコミットしないスプリントで各自好きなことをして得られたもの http://bit.ly/2wR5dPl
09:03 お盆休みの山手線を満喫している。みんなどこへ。
09:21 渋谷、雨降ってきた。
13:04 RT @TwitterJP: コミックマーケット #C92 に参加された皆さん、お疲れさまでした。「コミケ」「C92」「夏コミ」「叶」「たつき」などで調べたところ、3日間の関連ツイートの合計数は✨約500万✨でした。楽しいツイートをありがとうございました！ https://t.…
17:41 C92 って C 言語の規格のことじゃなかったのか。
20:51 この時間の乗り換えでこんなに駅が空いてるなんて嘘だろ?
22:14 @maru_kei LSI C-86 試食版懐かしい!
22:15 C MAGAZINE 付録に収録されていた LSI C-86 試食版で C に触れた世代。関数の引数をレジスタで渡すようにコンパイルするとか、当時わくわくものでしたね。