nDiki : スクラム

スクラム (Scrum)

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

2017年9月8日 (金)

スクラムよりカンバンか【日記】

今の開発・保守のバランスだとやはりスクラムよりカンバンの方がいい気がしてきました。

メンバが1人運用当番に入ることになりチームのキャパシティが小さく不安定になるので、1スプリントで完成をコミットできるサイズが小さくなりそうです。スプリント期間を伸ばせば解決するというものでもなく。

スポンサード リンク

今日のさえずり: 夜ご飯食べた。ここから眠気との勝負。

2017年09月08日

  • 08:00 今の開発・保守のバランスだとやはりスクラムよりカンバンの方がいい気がしてきた。
  • 21:49 夜ご飯食べた。ここから眠気との勝負。
  • 24:09 今晩は寝ずに起きれている。宣言したからかな。
[ 9月8日全て ]

2017年9月20日 (水)

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

今日はスクラム開発している CS 開発チームのスプリントプランニングだったのですが、プロダクトバックログアイテムの中に見積もりした時のことをあまり覚えてないという事案が発生しました。多分1カ月ぐらい前にプロダクトバックログリファインメント済みのもの。

プロダクトバックログリファインメントであまり先まで検討しても、状況が変わって無断になる場合があるよというのは言われているのですが、それ以外にも単純に忘却してしまうというデメリットがありますね。

[ 9月20日全て ]

2017年11月8日 (水)

ふりかえりで出たプロセスの改善策をスプリントバックログに入れる

スクラムガイドが改訂されました。スプリントバックログのセクションに

継続的改善を確実なものとするために、前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも1つは含めておく。

が追加されました。ふりかえりで出たアクションが次回のふりかえりまで忘れられてしまうことも多いので、よく目にするスプリントバックログに載せておくというのが明確になったのとても良いなと。

[ スクラム ]

今日のさえずり: ポストに箱根駅伝のチラシが入る季節がきた

2017年11月08日

  • 09:12 PLAYBOY のビジネスバッグを持っているスーツの人がいた。ウサギがかわいい。
  • 09:27 渋谷警察署前、報道陣がたむろしてる。
  • 11:00 「金のエンゼル」が通常の2倍! / “チョコボール発売50周年 過去発売大人気だった“きなこもち”を、50周年にあわせてリニューアル 「チョコボール<金のきなこもち>」 11月7日(火)より期間限定で新発売” http://bit.ly/2j46AbU
  • 11:02 第一回品川国際アニメーションフェスティバル 2017年11月9日から11月20日まで。 / “News” http://bit.ly/2yFPpVi
  • 19:54 ポストに箱根駅伝のチラシが入る季節がきた。
  • 22:33 スクラムガイド改訂。スプリントバックログ節に「継続的改善を確実なものとするために、前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも1つは含めておく。」が追加された。明確になったの良い。 / “The S… https://twitter.com/...
[ 11月8日全て ]

2017年12月14日 (木)

チームで使う共通の言語をもつ

ストラテジーグループという新しい3人チームでプロセス作りをしています。

3人のうち2人は「エッセンシャル スクラム」を読んでいて例えば「経済的フィルター」と言えばアレのことねとなるのですが、もう1人には今は通じません。「エッセンシャル スクラム」を読んでいないのが悪い、あるいは「エッセンシャル スクラム用語で話す2人が悪いという話ではなく、同じ言語を共有していると楽だし誤解が無くていいよねという話になりました。

アジャイルサムライでは

11.4 プロジェクトで使う言葉を共有する (pp.228-229)

で説明されていますね(原著だと Create and Share a Common Domain Language)。

そういえば以前部署で「エッセンシャル スクラムを読む会」を続けているうちに例えば PBI で話が通じるようになったりして楽になったなと感じました。

プロセスについてでもプロダクトについてでも、共通の言語をもつ(作る)というのは大切だなとあらためて感じた次第です。

[ opinion ]

[ 12月14日全て ]

2018年2月1日 (木)

新体制から1カ月、落ち着いた仕事ができるようになってきた【日記】

新体制・新ポジションになってから1カ月経ちました。

年末までのここ1年半ぐらいは複数チームのプロダクトオーナーやマネージャーを兼務していて、それぞれのスクラムイベントや one-on-one ミーティングなどで忙殺され気味だったのですが、今月になって少し落ち着いた仕事ができるようになってきた気がします。

引き継いだ役割・業務について学んだり来期に向けて予算を立てたりが済んだら、より主体的な攻めの仕事にシフトしていけるかなとワクワクしています。

[ 2月1日全て ]

2018年2月16日 (金)

エッセンシャル スクラムを読む会: 第16章 ポートフォリオプランニング

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

今のチームでポートフォリオプランニングの運営をしているので、勉強のためチームメンバでエッセンシャル スクラムの「16章 ポートフォリオプランニング」を読む会をやりました。昨年度に別のメンバで1冊通しでエッセンシャル スクラムを読む会をやって以来なので久しぶりです。

今回の自分のパートは以下。

  • 16.5 アウトフローの戦略
  • 16.5 仕掛品の戦略
  • 16.6 終わりに

「プロダクトをいつポートフォリオバックログから取り出すか」についてのアウトフローの戦略は

  • 「作業者の手待ちではなく、作業の手待ちに注目せよ」
  • WIPを制限する」
  • 「チーム全員の準備が整うのを待つ」

ポイントでこれらは、スプリントプランニングに通じるものがあるのでわかりやすいところです。

仕掛品の戦略は作業中のプロダクトについて

  • 維持
  • デリバリー
  • ピボット
  • 打ち切り

を判断するための戦略です。限界費用で考えましょうということ。限界費用が適切に見積もれる必要がありますが、そこが難しいところですね。

16章を通して11の戦略が示されていますが、おわりにの節でどれかを選ぶとしたらとして 11の戦略から選ぶとしたら

  • 遅延コスト
  • 小さめのリリースを頻繁に
  • WIP を制限する
  • 限界費用

だとのこと。参考にします。

やはりポートフォリオレベルでは収益とコストをしっかり考える必要があるなと。

読み直して、やはり今ポートフォリオバックログと呼んでいるのは階層化プロダクトバックログだなと。複数チームで取り組んでいるのでそれはそれで必要なのですが、ポートフォリオプランニングという意味では考え直したいところです。

[ 2月16日全て ]

2018年2月17日 (土)

今日のさえずり: 東京2020大会まであと888日

2018年02月17日

[ 2月17日全て ]

2018年2月19日 (月)

今日のさえずり: 今日は一日中ヘルシェイク矢野のことが頭から離れなくて辛かった

2018年02月19日

[ 2月19日全て ]

2018年3月13日 (火)

今日のさえずり: 夜ご飯の後に花粉に対する眼の怒りを鎮めるために点眼して目を閉じて目を開けたら今だ

2018年03月13日

  • 08:42 RT @kdmsnr: スクラムのプロダクトオーナーの仕事は従来の機能しないプロダクトマネージャーを置き換えるものだったはずだけど(そのために名前を変えた)プロダクトマネージャーの仕事をやり切れる人が増えてきたので、え、POの仕事しかやらないの?少なくない?みたいな感じになって…
  • 13:01 出来上がったら席まで運んでくれるサービス始めてた。 (@ マクドナルド 渋谷東映プラザ店 in Shibuya, 東京都) https://www.swarmapp.com/c/lPm3z8M9mBt
  • 20:31 RT @RabbitFake: 【CREウィーク火曜日】Zendeskまもるくんという社内ツールをオープンソース化しました | レポート | XFLAG(エックスフラッグ) キャリア採用サイト ケタハズレな冒険を。 https://career.xflag.com/.../ #XFLAG
  • 23:41 夜ご飯の後に花粉に対する眼の怒りを鎮めるために点眼して目を閉じて目を開けたら今だ。
[ 3月13日全て ]

2018年6月7日 (木)

プロダクトの遅延コストの算出方法を考える

WSJF (重み付けされた最短の作業から着手)という手法を使い始めるにあたり遅延コストを算出方法を見直し中。

エッセンシャル スクラムでは遅延コストの出し方をいくつか紹介しています。その中の1つ「アジャイルソフトウェア要求」で提案している3つ要素の和として決める方法をまずは使おうと思っています。

アジャイルソフトウェア要求では「フィーチャーの優先順位付け」と「エピックの優先順位付け」のところでそのやり方が出てきますが、今はポートフォリオプランニングレベルで考えているのでエピックの方が考え方として近そう。

プロダクトについて

  • ビジネス価値(BV): 収益・シェア・コスト削減・顧客の囲い込み向上についての相対的な価値。
  • 時間価値(TV): 時間が経つとどの程度価値が下がるかの相対的な価値。大きい値は価値が急速に低下することを表し、小さい値は安定していることを表す。
  • リスク低減/チャンス利用(RRV): 将来のプロダクトのリスクを低減する価値があるか、他のビジネスチャンスを活かす価値があるかの値。

をフィボナッチ数列の値で相対的に見積もります(アジャイルソフトウェア要求だと 1, 3, 5, 8, 13, 20, 40, 100 という等級を例として出しています)。

そして3つを足した

 [ビジネス価値] + [時間価値] + [リスク低減/チャンス利用]

を遅延コスト(CoD)とします。

正直なところ「金額」と「金額変化度合い」とをごっちゃに足しちゃう気持ち悪さがあってちょっとすっきりしない感じはあります。あと3要素それぞれで相対で決めていくとすると、特定の要素が大きめになって遅延コストを支配する可能性も出ちゃいそうだなと。

とりあえずやってまた考えるという感じかな。

[ 6月7日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

follow us in feedly

月別インデックス
Process Time: 0.080754s / load averages: 0.56, 0.45, 0.47
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker