nDiki : 計画

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の14回目。今日は第14章 スクラムのプランニングの原則。

原則とは?

今回は「原則」の章ということで、今日の発表当番だった CSM の人があらためて「原則とは?」という点について掘り下げてくれました。「価値とプラクティスを結ぶ」原則について

「原則なしに上辺だけプラクティスを実行してても意味ないよ」

と CSM の人が語ってくれました。「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」についてその場でみんなで見返しました。

事業体としての価値観と原則、個人としての価値観と原則、そして開発プロセスフレームワークとしての価値観と原則と、この辺り自身でも整理しないとなと最近考えているところです。

プランニング

プランニングについては出来上がった計画よりも計画のための対話などのプロセスが重要なのだなと最近感じるようになりました。

• 事前にきちんと計画を作れると思うな
• 計画を守ることよりも、計画の調整や再計画を重視する

ということで継続的にプランニングし直していくことが大切なのだなと。

14.4 プランニングの選択肢は、最終責任時点まで変更可能にする

についてはここではかなりあっさりとかかれています。物事を進めるには常に大小様々な意思決定をしていく必要があるので、さらっと読むと気持ちわるい感じがします。ここは 3.3 節にも

重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。

とあるので、方向転換できない状態に早い段階でならないようにするといったところなのだと理解しました。

14.7 早めにリリース、頻繁にリリース

については原則として頭にいれつつ、実際には適切なフィーチャーが揃っているかをきちんと考える必要がありますね。あまりに小さなリリースすぎて早い段階でユーザーに見限られてしまう危険性や、頻繁な変更によってユーザーが負担を感じて満足度が低下してしまう可能性も常に意識すべきかと。

この章でも

この手法には限界もある。まずどんなプロダクトであっても、最低限これだけは揃えないとリリースできないし市場で勝負できないというフィーチャー群がある。

と言った上で

もし部分的にでもよいから少しでも早めに受け取りたいという業界を相手にしているのなら、小さい単位で頻繁にリリースするという原則はとても重要になる。

としていました。

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の15回目。今日は第15章 さまざまなプランニング。昨年12月のプロダクトオーナーの章ぶりの発表当番です。

この章ではスクラムを使ったプロダクト開発に関係する以下のプランニングを紹介しています。

• ストラテジープランニング
• ポートフォリオプランニング
• プロダクトプランニング(エンビジョニング)
• リリースプランニング
• スプリントプランニング
• デイリープランニング

勉強会では自分たちの事業でのプロダクトは何か(例えば mixi は1つのプロダクト)を確認し、実際やっていることのどれが各プランニングにあたるのかを確認。スクラムチームメンバから直接体感できるのはプロダクトプランニングまでで、ポートフォリオプランニングはうかがい知れないことが多そうという話になりました。

それから(旧来からの)受託開発の場合は、リリースが固定スコープ・固定日だよねなんて話も。

スクラム開発チームメンバからは「トップダウン型のプランニングの流れの印象だが、スクラムチームの見積もりでわかった計画との差異はどのように上位の計画に反映していくのか?」という疑問もあがりました。

このあたりは続く章で説明があるのかもしれません。

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の16回目。今日は第16章 ポートフォリオプランニング。

これまで読んだ章の中で一番頭にすっと入ってこない章だったのは、あまりかかわってこなかった領域だからでしょうか。

ポートフォリオプランニングはプロダクト(あるいはその1リリース、プロジェクトなど)をどれぐらいの期間でどの順番でやるかを計画する作業です。

本書ではプロダクトのライフサイクル収益(プロダクトの生存期間中に見込める利益の総合計)が最大になるように優先順位を決めましょうと言っています。ライフサイクル収益は遅延コストと存続期間の影響を受けるのでこれをきちんと考えましょうとのことでした。

今日の発表者によると「ライフサイクル収益を使うのは社内政治の排除のため。ライフサイクル収益には利益以外にも社員満足度・顧客満足度・従業員満足度(離職率と採用コスト・回復コスト)なども考えれれる」といったことを CSPO 研修で聞いたとのことでした。社内政治排除のためというところが重要どころだそうです。

本書によるとポートフォリオバックログに入れる際は

コストや価値に関するちょっとした見解の相違で言い争いになって決断ができないのだとしたら、そのプロダクトの開発は却下すべきだ。

とのこと。

ほとんどの組織では、価値の高いプロダクトを開発する機会が有り余っている。価値を生み出すか疑わしいプロダクトについて、いつまでも議論をしている余裕はないはずだ。

と言い切ってます。迷ったら不採用という考えについて Joel on Software の採用面接ゲリラガイドを思い出しました。

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の18回目。今日は第18章 リリースプランニング (長期計画)。

今日は7人参加。

タイミング

リリースプランニングは一度限りのものではなく、スプリントごと行うアクティビティだ。

他のプランニング同様リリースプランニングも一度限りのものではないと明言されています。章の後半で説明される進捗の把握をしながら、スプリント毎に見直されていきます。

ポートフォリオプランニングでは「終わることのない作業」、エンビジョニング(プロダクトプランニング)では「一度やってそれで終わりではない」とそれぞれここまでの章で書かれています。全てのレベルにおいて継続が求められます。

ただスプリントプランニングをスプリントごとにやるとすると、どの程度時間を使うことになるのかが気になるところです。1週間スプリントの場合だと、さっと済ませるか何回かに1回にするのかが現実的なところでしょうか。

プロセス

各リリースには、明確に定義されたリリース可能な最小限のフィーチャー(MRF)がなければならない。(中略)顧客視点で、実用最小限の製品となっていることを確かめるのだ。

今の仕事は「フィーチャーごとにリリース」という方針でやっています。1スプリントで完成できるように例えばバックエンドという PBI にして先に完成させデプロイしておくというのをやったりしています。しかしバックエンドだけではここでいう MRF ではないですね。

いまチームではこのデプロイもリリースと呼んでいますが、エッセンシャル スクラム的に考えるとそれはリリースではないと考えた方が良いのかもしれません。

「各スプリントで価値を届ける」ことと「各スプリントでデプロイする」は同義でないと考え直した方が良いようです。

「いくつかのスプリントの成果物をひとまとめにしてリリースする」というプランニングの場合もあるのですから、毎スプリント必ずリリースするということに無理にこだわらなくてもということでしょうか。スプリントが終わった時点で常にリリース可能な状態になっていることが重要ということでしょうか。

リリース制約

気がつくと「スコープを固定」と無意識にしてしまいがち。ステークホルダーに期日を約束していないと、ずるずるとリリースを延期してしまいがち。

「スコープを固定」になる原因は、全体的なスコープがあまりにも大きすぎることであることが多い。

とあり、ここでもできるだけ小さくというのが推奨されています。MRF をいかに小さく定義しておけるかがポイント。18.4 節では「常にMRFを調整し続ける。」と書かれていて、MRF も適宜見直していくべきです。

期日を固定する方式がスクラムの原則にうまく当てはまるということなのでリリースプランニングの際にきちんと意識できるようにしたいです。

スプリントマッピング

主に複数チームで協調してスプリントを進めていくための話。ここは困ることが起きた場合にまた読み返したい部分です。

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の19回目。今日は第19章 スプリントプランニング。ここから「第IV部 スプリント」。スクラムチームにとって馴染みがあるパートです。

スプリントを回すにあたり第19章はすでに何度か先読みしているところですが、あらためて書籍にあたり気付きを得て実践していきたいところです。

タイミングと時間と参加者

スプリントプランニングはスプリントを開始するときに行います。2週間から1カ月のスプリントで4〜8時間ということなので、単純に計算すると1週間スプリントでは2時間程度でしょうか。

今は1週間/2週間スプリントのチームで賞味30分から45分ぐらいしかやっていません。実際時間不足を感じています。

• チームメンバが2時間のプランニングミーティングに耐えられない。きちんとスプリントプランニングするメリットを感じられていない。
• 3チームのプロダクトオーナー(自分)が時間を確保できない。

もちろん長ければ良いというものでもありませんが、もし不足だとしたらこのあたりが適切な時間をかけられていない障壁かなと。前者はチームが成長することで解消される気がします。後者は LeSS (Large-Scale Scrum) の2段階のスプリントプランニングにしてチーム別のにはプロダクトオーナーは出ないという形式にするという解決案も思い浮かぶのですが、参加しないデメリットを考えると躊躇してしまいます。

プロダクトバックログアイテムにかけるキャパシティ

完成させる自信のある計画を行うにはキャパシティの把握が不可欠になります。

 スプリントのキャパシティ
   = PBI にかけるキャパシティ + スプリントバッファ + それ以外

予定している休暇があるのにスプリントプランニングの際に宣言しないのは不誠実だということになるでしょう(休んではいけないということではなく、わかっているのに共有しないということが問題。体調不良等による突発的な休みももちろん別の話)。

今のところ自分たちのチームではベロシティ(ストーリーポイント)でなんとなくキャパシティがこれぐらいかなといった感じでしか考えられていませんが、次のスプリント期間をまず見通すことも必要だなと感じました。

作業時間を使ったキャパシティも紹介されていますが、実際ここまで精緻に管理したいと思うことはあまりないんじゃないかなという印象です。

プロダクトバックログアイテムの選択

基本優先順位順ですがスプリントゴールを示している場合はその限りではなく、またスキルの問題などでコミットできないプロダクトバックログアイテムはスキップするという選択も考える必要があります。

完成できそうにないプロダクトバックログアイテムを選択してはならない。プロダクトバックログアイテムが大きすぎて完成できそうにない場合は、顧客にとって価値のあるアイテムに分割するか、完成できそうな別のアイテムに着手する。(中略)未完成のアイテムを次のスプリントに繰り越していくと、スプリントの終了時に出荷判断可能なプロダクトインクリメントを手に入れるという目標がいつまで経っても達成できない。

ここがいつもスプリントプランニングでぶちあたるところです。プロダクトバックログリファインメントがしっかりできていないんですね。プロダクトバックログリファインメントは最重要レベルのアクティビティなんだなと。

タスク分解と作業時間見積もり

自信の獲得のためにタスク分解と作業時間の見積もりをまずしましょうとあるのですが、タスク分解と見積もりの方法については触れられていません。ここは自分たちで考えて頑張れという感じなんですかね。一般論にはできない部分だとは思いますが、ここは大ハマリするところなので参考になる話があると嬉しいなと思ってます。

スプリントプランニングでタスクを個人に割り当てるのは有害だというバッドプラクティスが挙げられていますが、ここは次の「スプリントの実施」で語られるところのようです。

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

RX-78-2 ガンダムにオンラインマニュアルは無かったのか? 【日記】

RX-78-2 ガンダムにオンラインマニュアルは無かったのか?

チームのエンジニアの

(ファースト)ガンダムで好きなシーンは、(アムロが)大きなマニュアルを開いているところ

と言ったところから、ガンダムにはオンラインマニュアル・オンラインヘルプは無かったのかなぁという話になりました。1979年にはまだそういう考えが無かったのか、わかった上で紙のマニュアルを表現として選択したのか興味があります。

ちなみに自分が好きなのはジャブローでシャア専用ズゴックがアイアンネイルでジムを貫くシーンです。

macOS でのデスクトップ切り替えショートカットキー

KDE の時に「Alt + 数字」だったので「command + 数字」に変更してみました。

Franz

入れてみました。Slack・Gmail・TweetDeck。

• http://meetfranz.com/

翌営業日の will do リスト(クローズドリスト)を前日帰る前に作っておく

その日にやることをリストアップした will do リスト(クローズドリスト)を作るのを朝のルーチンワークにしているのですが、朝ばたばたしていて気がつけば夕方になっていることがしばしば発生してしまっています。それだと意味ないので、昨日から前日帰る際に用意することしました。

帰り際の方がちょっとゆっくりと計画ができていいかも。

炊飯器壊れた

妻から連絡。アイロン → 扇風機からの炊飯器。

will do リスト作りを朝に戻した【日記】

その日にやることをリストアップした will do リスト(クローズドリスト)を作るのを昨年の夏から前日帰り際に用意することにしてから何カ月か経ちました。帰り際に余裕があればきちんと will do リストが作れていい感じですが、割り込みが多かったりすると前日に作っておけなくてもやっとした気分でした。

マニャーナの法則の通り割り込みをコントロールするのが一番良いのかもしれませんが、あくまで原則なのでなかなかそうもいかない場合もあります。それからやはり夜だとエネルギーが切れてきていて計画に力が入らないことも。

自分の場合はやはり朝に計画する方が良さそうなので、 will do リスト作りを今日から朝に戻すことにしました。

日曜日の朝食にパナビの冷凍クロワッサンを焼いたら熱々サクサクで最高だった

カルディコーヒーファームで売っている冷凍クロワッサンが美味しいとのことで、一昨日帰りに買ってきました。人気なのかカルディコーヒーファームのオンラインショップでは現在在庫なし。モノは三友フーズ株式会社が輸入販売している PANAVI (パナビ)のもののようです。5個入りで税込み498円。

• 【冷凍】パナビ クロワッサン 5p | カルディコーヒーファーム　公式オンラインショップ

室温で20〜30分解凍させてからオーブンで25分程度焼くので、朝食に焼きたてを食べるのには計画的に起きる必要がありますね。朝食の時間を決めてから昨夜は就寝しました。焼いてもらったクロワッサンはサクサク! 焼き色や中の食感からすると我が家のオープンではもう少し焼いてもいいかな。ふくらむとはいえ小さいかなと焼く前に思っていたのですが、焼きあがったら結構な大きさになってお腹も満足でした。家で焼き立てのクロワッサンが手軽に食べられるなんて幸せ。

冷凍でストックしておけるのでまた買っておきたい一品です。

ポートフォリオバックログのスプレッドシートに概要レベルのプロダクトバックログ列を追加

「ポートフォリオバックログ」のスプレッドシートに「概要レベルのプロダクトバックログ」列を追加したら、プランニングでより具体的な話し合いができるようになりました。

• 各アイテムが何をやるのかが明確になり共通認識になる。
• 内容が明確になることで規模感を考えられるようになる。
• 完了条件ではなくプロダクトバックログにすることで、柔軟に再計画できる。

みたいなメリットが生まれました。

8月の仙台泊のホテルを予約

8月に帰省する時に仙台で前泊するホテルを予約しました。

当初仙台駅前観光で考えていたのですがビジネスホテルだと人数的にちょっと難しいかなとも思って、秋保温泉の宿でゆっくりというの最近はちょっと考えていました。ただ秋保温泉だと仙台駅からの交通がちょっと不便で時間の融通がきかず計画しにくい割に、予算的にも宿だけで満喫するというグレードではないのかなと思えてきました。

もう一度仙台駅周辺でホテルを探したら、希望人数で泊まれる部屋が2室残っているというホテルがあったので、ならやはり仙台駅前観光にするかなと。ということで予約と相成りました。