Uberの割引コード:uber_suni / AirBnB紹介コード:ここをクリック

◎空港ラウンジ使い放題!楽天プレミアムカードでプライオリティパスを無料でゲットしよう◎


プライオリティパスでVIPラウンジ無料体験談はこちら
いざというときのための、国内・海外旅行障害保険の適用範囲はこちら

2016年2月5日金曜日

スクラムお母さん的Sprint Planning Mtg Memo as of Feb. 5


フィリピンからこんばんは。@suniです。

日本から期間限定でやってきたスクラムマスターが導入したスクラムを私が回し始めて4ヶ月目…かな。
※調整ゴトが得意なのでその延長で、って感じなので、スクラムマスター的な資格は持っていません。日々試行錯誤。

今日はRetrospectiveとSprint Planning Mtgをやってクタクタなんですけど、ふとこのエントリを見てふと我が身を振り返りたいポイントがあったのと、そういえば自分も何か残しておこうかなと思い、

「こんなことやっています」
「こういう背景で、だからこうしてみました」
「自分のスクラムお母さん業務の備忘録がてら」

書いてみようと思います。

#最近仕事の事書いてなかったしね
#後で振り返る時に、evernoteよりもメモ帳よりも検索窓で「sunikang スクラム」で出てくる方が便利。
#誰かに状況を相談したくなったときにも使えるかもしれない
#ブログに書こうとする→それなりにちゃんと書こうとする→evernoteのメモよりわかりやすい

Kanban as of Feb. 5


YOYO的スクラムの前提情報

・10月中旬から1ヶ月、日本からスクラムマスター侍がやってきて、YOYOにスクラム・アジャイルの概念と実践方法を導入
・うっすらぼんやり使っていたKanbanを、もうちょっと体系だったKanban方式でプロジェクトを進めるように
・ちなみにScrumの正しいセオリーには沿っていないと自覚しているし、侍もそういう認識
・そして侍は帰国
・その後しばらく、1週間Sprintで回してみた
・「あの人今何やっているんだろう」とか「なんで優先度高いAじゃなくてDをやっているんだろう」がなくなった
・指示待ちではなく能動的に仕事を取りに行くようになった
・一方で、毎週金曜がRetrospectiveとSprint Planning Mtgで潰れるのは痛いよね、と気づき始めた
・先月から…かな? 2週間Sprintでやることに
・とはいえ2週間以内で終わるものばかりをやっているわけではない。
・2週間Sprint、リリースサイクルは毎週水曜日
・RetrospectiveとSprint Planning Mtgはキッチリやる(なので隔週金曜はつぶれる)
・ポストイットは誰でも取れる状態がベストだけど、PBIごとに担当者はうっすらぼんやり決まっている感じ
・実は最近Retrospectiveをやるタイミングが悩ましいんだけどそれはまた別の話






今日の背景とSprint Planning Mtg中に実施した内容


(1)先週の3.3.9.1のリリースがちょいと遅れた
→終わりそうなネタで行き当たりばったりでリリースアイテムを決めるのではなく、『事前に計画しよう』
→計画的な変更はアリ(土壇場で『やっぱりダメでした』がクセになるのはよくないので)


(2)優先度とリリース日が相関してなく(PBIごとにかかるリソースが違うのでそれは仕方ないのでいいとして)、例えばQAがテストケース作成にとりかかる時に、「優先度順で進めるべきか、先に開発が終わりそうなものから着手すべきか」の判断はカンに頼っているところもあった
→いっその事Sprint Planning Mtgで仮のリリース日をセットして、それに向けてKanbanのPBIも並び替えた方がわかりやすいよね、とPOに提案した


(3)上記2つの事情もあり、Sprint Planning Mtgで仮のリリース予定日を決めることにした。
そのために「70% Rule for capacity 30% as a buffer」を使ってみた。
#70%ルール云々は、POがこっちのアジャイルミートアップに参加してそこで参考になった話として教えてくれた
#velocityをちゃんと測り始めたのは今年に入ってからという感じだけど
#「このあと不足の事態が起こるのは全然アリ。なにか起きたら都度上司に相談してね」というスタンス。「計画する」「予測する」「リスクヘッジ」「優先度の高いものからやる」的なマインドを持ってもらうための一環。

A. Sprint Planning Mtgまでに、次Sprintに割ける工数を各自所定のシートに記載
B. 残案件にかかる工数の確認(Posti-itに書くようにした)
C. 次のSprintで実施予定の各PBIの、想定工数をplanning mtg中にホワイトボードに書いておく。

D. Aの70%を計算し、それを、1週間ごとに分割。1週間ごとの理由は「リリースサイクルが毎週だから」
その計算結果を元に、この2週間 (+ その先の1週間)でどこまでやれるかを試算してみる。
PBI8までは次のバージョンでイケる?いや、怪しいから7まで?
「PBI9まではイケるとして10は?11は?あ、12はクライアント案件だから2/24がマストだから12を先にやらないと。とすると9は…」
というような、他PBIとの兼ね合いも考えながらリリース日を調整。
E. 同時に、各PBI同士のコンフリクトや、例えば「あー4をそこで出すなら7も一緒の方が…」みたいなのの確認。
F. 「このスケジュールは仮で、開発中に不足の事態が起こるかもしれないから、何かあったらあなたのボスや関係メンバーと相談してね」と最後に伝えて終了。"フィリピンあるある"的な隠し事や嘘はウチは全然ないんだけど、スケジュールで縛(っているよに見え)ることで、悪いことは報告は後で…みたいなことになるのもアレなので。


終わってみて


・QAも兼務してるんで、SOの仕様説明を聞きつつ疑問や矛盾がないか思考を巡らせつつ、ポストイットを作りつつ、PBIごとのリソース計算や70%計算云々でめっちゃ脳みそ使った。疲れたw
・なぜかブログに書きたくなったw
・3のD,E をPOが旗振りしてくれたんだけどマジでスマートだった。
・仕様のシェアの途中、東京とジャカルタ向けにスライドが届いてなくて(Hangoutでよくありがち)、気づかなくてマジでごめんなさい


その他、課題(おいおい…)

・Standup mtgやRetro、Sprint Planning Mtgでの「ジブンゴト化」マインドが人によって違う件
・Retroのタイミング
・Hangout問題


最後に


という訳で、最近は「プロセス改善」的な仕事がメインでQAも兼務でやってます。
「富士通やヤフーで培った大企業的な調整業務や部署間のカスガイが得意」という自覚があって、「このスキルってスタートアップには向かなくね?」と思うことも前々職の頓智ドット時代には思ったりもしていましたが、前職のKDDIフィリピンでも現職YOYOでもこのスキルが自分のポジション形成に活きているので、今後も影武者として水面下でバタバタもがこうと思っています。

そういえば富士通でSEやってた頃からバグ発見の才能あったなぁとふと思い出した。











@suniのブログを引き続きよろしくお願いします。
ぜひ定期購読もね!ヾ(*´∀`*)ノ
    follow us in feedly
    このエントリーをはてなブックマークに追加 

Blog Archive