興味を持つものだけに興味を持つ暮らし

とある企業に勤めるおじさん アジャイルらぶです

スプリント6

スクラムマスター視点でのふりかえりです。スクラムを再開したときほどの熱量でブログにふりかえりを書けなくなってきた感はありますが、自分が意味を見出せなくなるまで継続することにします。

時間

  • 14:00-14:30 sprint review
  • 14:30-14:50 break
  • 14:50-15:20 retrospective(FDL)
  • 15:20-15:30 break
  • 15:30-15:50 sprint planning

成果

計画に対して実績がどうであったかを書きます。

見積もりの精度が良かったか悪かったかを書きます。

完成したストーリー/計画したストーリー,6/5

感想

1営業少なかったけれど、ストーリーは予定より多く消化しました。消化したストーリーは前回のスプリントの継続のものが含まれていました。仕掛りのものはある程度は開発できていたため、今スプリントで早く終わりました。1スプリントで終わらないストーリーが2スプリント目で完了するという傾向があります。これまでの6スプリント目までのベロシティを見ると3、6、3、6みたいな感じで推移しています。1スプリントの一週間で開発を進めていますが計画しているストーリーのサイズと期間があっていないかもしれません。しばらく様子見です。

スプリントレビュー

レビュー会(デモ)でのデモがどうであったかを書きます。

ステークホルダーからフィードバックをうまく引き出せる内容だったかを気にします。

感想

前回のスプリントレビューからgoogleスライドにレビューに関する事柄を書くようにしました。資料に関して不都合は感じませんでした。しばらくはこのフォーマットで続けると思います。

  • スプリントゴール
  • スプリント結果
  • スプリント中の重要な出来事
  • ベロシティ
  • 開発チームからの連絡事項
  • ビジネスチームからの連絡事項
  • 次のスプリントに向けた優先度のレビュー

前回からスプリントレビューのファシリテーションは私ではなく、開発チームの誰かが やることになりました。私と開発チームとの会話でレビュー会の進行は開発チームで行うことになりました。スクラムマスターの私は書記をしています。たまに口を動かすことはありますが、基本的にはレビュー会をステークホルダーに近い立場で眺めている感じです。

スプリントレトロスペクティブ

前回と同じ手法でふりかえりをしました。 qiita.com

その他

  • スプリント中(最終日9にバックログリファイメントをしました。
    • 本社側はビデオカメラが設置されている会議室でリモート拠点のひととミーティングをしました。  * ビデオカメラがあると助かるとリモート拠点の人から言われたのでAmazonでポチって即購入しました。
  • 次のスプリントからデイリースクラム等、リモート拠点の人とミーティングする場合は双方でカメラで顔を映した状態で行うことにします。

f:id:yuichan-otentosama:20190119074704j:plain

スプリント5 - Fun!Done!Learn!はじめました

スクラムマスター視点でのふりかえりです。 前回のエントリーはこちらです。Fun!Done!Learn!によるふりかえりについてはスプリントレトロスペクティブのパートに 書いています。

スプリント4 - 興味を持つものだけに興味を持つ暮らし

時間

  • スプリントレビュー準備,13:00-13:45
  • 休憩,13:45-14:00
  • スプリントレビュー,14:00-14:45
  • 休憩,14:25-15:00
  • スプリントレトロスペクティブ,15:00-15:35
  • 休憩,15:35-15:45
  • スプリントプランニング,15:45-16:30

成果

  • 計画に対して実績がどうであったかを書きます。
  • 見積もりの精度が良かったか悪かったかを気にします。

完成したストーリー/計画したストーリー,3/7

スプリントレビュー

  • レビュー会(デモ)でのデモがどうであったかを書きます。
  • ステークホルダーからフィードバックをうまく引き出せる内容だったかを気にします。

googleドキュメントにアジェンダを記載する形式から、googleスライドにアジェンダを記載する形式に 変更しました。スクラム現場開発ガイドの"15章 スプリントレビュー"に書かれていたことを模倣しました。

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

フォーマットの変更に伴い、項目を見直しました。今回は以下の項目で進めました。

  • スプリントゴール
  • スプリント結果
  • スプリント中の重要な出来事
  • ベロシティ
  • 開発チームからの連絡事項
  • ビジネスチームからの連絡事項
  • 次のスプリントに向けた優先度のレビュー

前回まではgoogleドキュメントに議事メモ(決定事項、意見)を書いていましたが、フォーマット変更に伴い、 googleスライドに書くことにしました。が、それなりの文章をリアルタイムに書くのには不向きなので Slackにメモを書いた後、あとでgoogleドキュメントに転記する対応をしました。次回は googleスライドにアジェンダ、議事メモはgoogleドキュメントという形式を試す予定です。

レビュー会の満足度を後述のレトロスペクティブの時に計りました。計測には五本指で表すやつを使いました。

それなりに満足度はあったけど、まだカイゼンの余地ありな感じです。5段階評価のうち平均で3な感じです。

細かく控えていないのでたぶんこんな感じ。プロダクトオーナーとしては2の辛口評価だったのは覚えています。

スプリントレトロスペクティブ

前回のふりかえりでは

  • 次回から何かふりかえりのフレームワークを使ってふりかえってみましょう ということになっていました。 それを踏まえフレームワークを使ったふりかえりをしました。 今回は巷で話題のFun!Done!Learn!をやってみました。yattomさんが書いた以下の記事を 参考に進めました。

qiita.com

私はファシリテートする立場で参加しました。私がやったことは模造紙、ポストイット、サインペンを用紙することです。それと3つの円を書くことと、Fun,Done,Learnと書くことです。これらの準備ができたあとは、yattomさんの記事をスマホで適時みながら、ゆるゆると進行しました。

このふりかえりは良いです。スクラムを再起動(最近、チーム編成を変えてスクラムきちんとすることにした)した後で スクラムは良い感じに回っていると私は思っていますが、ふりかえりはいまいちな状況でした。ポジティブな3つの項目 でふりかえると楽しいです。

今回は楽しくもなく、学びがないケースはDoneに区分されました。辛くて学びがあるケースはFunとLearnの両方に区分されました。辛いケースではどこにいれれば良いの?とメンバーから質問がありましたが、

ポジティブに考えて辛いこともある意味面白いって捉えようってことでFunに区分しました(それで良いのかは不明)。

開発チームのひとはこのふりかえりは良いといってくれた人もいたので一発目のFun!Done!Learn!(FDL)としてはうまくやれたと思います。 過去、私は職場でふりかえりにKPTを良く使っていました。KPTよりかっちりしていなくて、気持ちがあげあげになりやすいふりかえり 手法な気がします。しばらくFDLを使ってどのようになるか様子をみようと思います。

参考までに私がやったやり方は以下のとおりです。オリジナルに近いと思います。

  1. 模造紙に、Fun/Done/Learnの図を描く
  2. チームにスプリント内の活動を付箋に書き出してもらう(ひとり3個を目安とする)
  3. 1.の付箋を私が読み上げて、付箋を書いたひとに内容の説明をしてもらいチームと相談しながら該当する領域に付箋を貼る

1.のときに、FDLの説明はあまりせずに、スプリント内の活動を付箋に書き出してもらいました。 FDLの枠で洗い出してもらうのか、FDLを意識せず、活動を純粋に付箋に書き出してもらうか 2通りやりかたがあると思いますが、うちのチームでは後者でやりました。私としては思考を狭めないために、 FDLを意識せずに、活動を洗い出す方が良い気がします。タスクベースで洗い出しても、その活動はFDLのいずれかの 領域に区分する必要があるので、その会話の中でFunなのか,Doneなのか、Learnなのか区分されるからです。

https://qiita.com/viva_tweet_x/items/7e279f41f4388d9162ef

f:id:yuichan-otentosama:20190111235546j:plain

そういえば、ふりかえりの中でペアプロの話題が出ました。

ペアが固定されている

次回からは片方のペアのストーリーが終わったら一方が未完了でもペアをシャッフルすることにしました、

スプリントプランニング

45分で終わりました。上位にあるストーリー(バグ系)がポイント付けされていないものがありました。

理想はスプリントプランニングのときにはポイント付けされていることだと思うのですが、ポイントづけされていないものがありました。

前回の反省を踏まえて、ストーリーreadyな状態にはしていました。けれど、ポイントづけされていないのはあまり気にしていませんでした。

スプリントの進捗にもよりますが、スプリント中にポイントづけするのは難しい気がします。なので今後はスプリントプランニングを前半(ポイントづけ)、後半(計画作り)にわけてみようと思います。

参考

わたしよりも先行してFUN!Done!Learn!(FDL)を実践されている方の記事をご紹介します。 それぞれ

www.ogis-ri.co.jp

qiita.com

2018年のふりかえり

プライベート、仕事をひっくるめてふりかえります。時系列順で印象的な出来事を並べていきます。

Regional Scrum Gathering Tokyo 2018登壇

おやつ神社で登壇しました。原田さんがfacebookでパートナーを募集していた時に、勢いで手を上げて一緒に登壇するに至りました。実は原田さんとはそれほど面識があるという訳ではなく、XP祭り2017で原田さんのLTを見て面白い方だなという印象を持ったのを覚えています。そのXP祭りの出会いからギャザリングの登壇にまで至るという流れは面白いというか不思議というか縁ってすごいなと思います。

おやつ神社のセッションは2日目だったのですが、初日は2日目の登壇が気になって私自身がナーバスになっていたことが印象に残っています。加えてそのとき私はメンタル的に不安定な時だったため、スクラムギャザリングというお祭りを本人的には充分に楽しむことができませんでした。そんな状態ではありましたが、ふりかえってみればそこで学んだことはたくさんありました。その時は理解できなくても時間が経過すると理解できたりするものです。

総評としては棚ぼた的なものですが、登壇するという貴重な経験を積めたのは自分にとってはとてもありがたいことでした。私をパートナーにしてくれた原田さんに感謝です。

ちなみに褌に関するセッションを勢いであげました。もしかしたら、変なプロポーザルをがあるなと思った人はいるかもしれませんが、本人的には大真面目でした。言語化するに至らずなのですが、昇華していつか何らかの形で発表したいと思いっています。

禅・裸・褌

禅と褌には共通項があります。この共通性を話の起点として 私がスクラムで学んだこと、これから学ぼうとしていることを発表したいと思います。

ハーフマラソン完走

私は普段から週末にマラソンをしていたのですが、大会に出ることなく、もっぱら一人ランをしていました。その私が何がきっかけでハーフマラソンに出場したのでしょうか。それは私のこどもが同じ園のこどもたちと川崎の月例マラソンに参加することになり、付き添いとして私も参加したことがきっかになっています。それで月例マラソンに参加して、他のひとと一緒にマラソンをすることの楽しみを知りました。普段は走る距離は7キロくらいです。気まぐれで10キロ くらい走ることはありましたが、20キロ近く走ることは未経験でした。この時は気力、体力共にみなぎっていましたので勢いでハーフマラソンに申し込み完走しました。記録は2:24:44で40人中27位でした。

当日の様子はここにあります。中段にあるハーフマラソンエントリーの全員集合の写真にさりげなくセンターのポジションにいる私がいます。

その後も立川ベジタルマラソンに参加したりとマラソンを楽しみました。最近は大会には出ていませんが、2019年になったら、何か大会に出たいと思います。そして次はハーフマラソンではなく、フルマラソンにチャレンジしたいと思います。そのために、まだまだ足りないものがあるので、ただ走るのではなく、フルマラソンに出れる体力作りを意識的にしていきたいと思います。

プロダクトマネージャーカンファレンス2018にボランティア枠で参加

プロダクトマネージャー・カンファレンス 2018にボランティア枠で2日間に渡り参加しました。有給を取得して参加しました。 omoiyari.fmでお馴染みの三浦さんや元楽天の川口さんや現楽天の及部さんを知る楽天の山下さん(day2登壇)や、ボランティアスタッフの方など、新しく知り合いが増えました。 プロダクトマネージャーカンファレンスは以前から気になっていたのですが、ようやく参加できました。刺激をもらえるカンファレンスなので来年も参加したいと思っています。ボランティア枠の参加、参加者枠での参加とは違って ボランティアして、空き時間はセッション聴いてとメリハリを付けて活動できてので、私的にはボランティア枠で カンファレンスに参加するのがお好み。

カンファレンスは愛がテーマでカンファレンスの締めくくりで各自がプロダクトに対してコミットすることをツイートすることになりました。私がツイートしたのはこれです。実現できるがは分かりませんが、やれることをコツコツと やってきたいと思います。少しでも前進できれば良いと思っています。

まとめ

他にも色々と出来事はありましたが、印象的な出来事を3つに絞って書いてみました。 こうやって書いて見るとリアルが充実していたようです。来年も良い一年になるように活動していきたいと思います。 私と面識のあるひとは来年もよろしくお願いします。面識のない人はどこかであったときはよろしくお願いします。

さて最後に私が推しているももいろクローバーZさんのMVをご紹介して今年を締めくくりたいと思います。 この曲は5ヶ月連続配信シングルの4曲目です。疾走感のある映像が好きです。曲ももちろん好きです。


【ももクロMV】ももいろクローバーZ『GODSPEED』Music Video

それではみなさま来年お会いしましょう、良いお年を!

IBM Cloud Container勉強会に参加しました

はじめに

IBM Cloudの勉強会に関するエントリですが、技術的なことは書いておりません。ご了承くださいませ。

12/19(木)に自社に来てもらい、IBMの方にIBM Cloud Containerの勉強会を開催していただきました。 会社のえらい人*1が戸倉様と面識があるようで、その流れでうちの会社で勉強会が開催される運びとなったようです。 私自身は普段、SIOS CoatiというSaaS型の監視復旧サービスのプロダクト開発をしています。このCoatiというサービスはAWS向けのもので、普段はIBM Cloud, Microsoft Azureなど別のパブリッククラウドに触れる機会がありません。

冒頭に書いたとおり、社内SNSIBM Cloudの勉強会の参加者を募集していたので私はぜひ他のパブリッククラウドに触れてみたいと思い参加を決めました。私の他に参加していた人に聞いてみたら案件としてIBM Cloudを触る機会がありそうなので勉強のために参加した人や、純粋にKubernetes(k8s)に興味があって参加している人もいるようでした。

ちなみに私は業界で有名な方と実際に会って、その後SNSでつながるのが密かな楽しみなのです。 戸倉さんはマイクロソフトに在籍*2されていたときからSNS上で存在を知っていたので、 今回の勉強会に戸倉様の名前があった時は良しこれは会えるチャンスだと密かに楽しみにしていたのです。 さてさて本題に入ります。

事前準備

IBM Cloudの勉強会開催までに事前準備することの連絡があったので、その対応をしました。 やったことは次の2点です。

私の業務PCはWindowsです。IBMの公式ドキュメントに書かれた手順でインストールをすると、 ibmcloudコマンドがインストールされます。けれど、dockerのインストールに失敗します*3。この点につきましては github.com にIssue登録されているので確認してみると良いと思います。ワークショップではdockerがインストール できなくても支障がないと講師の斎藤様に説明を受けたので、dockerのインストールできない点は気にせず 作業を進めました。

今回は勉強会はワークショップ形式でIBM Cloud Kubernetes Serviceに触れるというものでした。当日のアジェンダは以下のとおりです。戸倉様、佐藤様からそれぞれ説明があり、IBM Cloud、IBM Cloudコンテナがなんたるかを説明を受けます。そのあと、IBM Cloud Kubernetes Serviceのワークショップという流れです。

アジェンダIBM Cloud Container 勉強会)

  • IBM Cloud 概要紹介(座学) - 戸倉様
  • IBM Cloud コンテナについて(座学) - 斎藤様
  • IBM Cloud Kubernetes Service ワークショップ(ハンズオン)
    • 斎藤様、佐藤様、戸倉様

ワークショップの進め方

github.com

に沿って手を動かすとK8sクラスターへのアプリケーションデプロイが簡単にできました。 はじめて、IBM Cloud Kubernetes Service(IKS)で触ってみたのですが、ワークショップではあまり触らず、ほとんどがCLIで行えました。会社のネットワーク環境の問題でデプロイがうまくいかない状況になりましたが、会社スマホテザリングにより問題を回避することができ、無事アプリケーションのデプロイができました。

ワークショップではLab1ができた人は、Lab2,Lab3と手を動かして進めました。私はLab1を行ったあとは、講師の佐藤様と30分近く雑談をしていました。コンテナの話やパブリッククラウドに関する雑談を色々としました。

IBM Cloudを使ってみましょう

私が書いた内容を読み返して見ると技術的なことを書いておりません。それは引用したリンク内の手順に書かれているとおりに手を動かせば、おそらくさほど詰まらずにIKSを利用できるという意味だと思います。私の観測できる範囲ではパブリッククラウドの利用者はAWSMicrosoft Azureが多いです。私はこれまで使う機会がなかったですが、今回の勉強会を機にIBM Cloudをもっと使ってみたいと思いました。

宣伝

戸倉様はSoftware DesignVCSの連載をしているそうです。興味のある方を読んでみてください。それとうちの会社にいるDebianコミッターの山根さんが同じくSoftware Designで隔月でDebianに関する連載をしています。そちらもよろしくお願いします。

あと、これまた宣伝となるのですが、2019年1月にOSSライセンスの教科書のイベントを会社でやります。 好評なようで参加者がたくさん集まっております。スタッフ枠はまだ空いておりますので、興味のあるかたはぜひお申し込みください。

sios.connpass.com

*1:肩書きがOSSテクノロジーセンター長

*2:現在は日本IBMの人

*3:2018年12月19日時点

フィードバックループしていなかった

状態からフィードバックループをする状態になりました。スプリントレビューは成果物をお披露目する場ではなく、成果物をお披露目してステークホルダーから フィードバックをもらう場所だということにようやく気がつきました。

12月からスクラムを再始動したのですが、実はそれまではフィードバックループというものができておりませんでした。 再起動する直前はスクラムマスターとしての活動をやめていたので、レビュー会では私も成果のお披露目を少ししていました。 フロントエンド側の作業を担当していたので、レビュー会でその成果をお披露目したのです。普段、レビュー会では ファシリテートするくらいでデモをすることはなかったのでとても緊張しました。普段からレビュー会でデモをやるひとは すごいな、尊敬するなとそのときは思いました。

ちなみにフロントエンド側というと少しカッコ良いかもしれませんが、私が単独でやっていたことは製品ページの英語の文言修正や、キャラクターの 画像の配置を修正など、わりと地味な作業をしていました。スクラム再起動する前にほぼ単独やっていたことは大体、以下です。

  • 製品ページの修正
    • 英語の文言修正
    • キャラクター画像の修正
    • 製品紹介の図の修正
    • チャット機能の組み込み
    • FAQページの追加
    • etc..

これらの作業はわりと簡単にデモで見せられてフィードバックを得やすいので、フィードバックループというのが なんなのかを体感できました。主要な項目をピックアップします。

チャット機能の組み込み

これはもともと計画にあったものではなく、私が手が空いていたので、関係者に提案するために、やったものです。 あまり大きな声ではいえませんが、私が開発に携わっているプロダクトはまだまだ発展途上です。製品に興味を持ったユーザが 製品を使えるようになるまでにリーズナブルな方法で支援できる方法がないかと考えた結果、製品ページにチャット機能を つけようと思ったのです。

ローカル環境でチャット機能をつけた製品ページをデモして、関係者の反応をうかがう。そしたらほとんどがポジティブな 反応でデモ会から時間をあけずに、本番環境の製品ページにチャット機能を設けることになりました。これはさっさと 動作するものを見せて、フィードバックを得て、多少手直しして本番にリリースできた良い例だと思っています。

FAQページの追加

これはどういうストーリーかというと製品ページにFAQを用意して欲しいというものです。

  1. FAQの設置場所の候補は静的ページにベタにFAQページを設ける
  2. ZendeskというヘルプデスクツールのFAQを利用する

の2案がありました。メンテナンスコストを考えて、私は2.の対応を進めていました。 デモ会の直前の準備で当時のプロダクトオーナーに前者のパターンは候補にないのかと尋ねられて、 少し会話したあと両方のパターンを見せてどちらか良いか関係者の判断*1を求めた方が良い と助言をもらいました。だから両方デモを見せて関係者からフィードバックをもらいました。

スクラム再始動

というわけでデモをしてフィードバックをもらって事を進めることの大切さを身を以て学んだわけです。 そんなこともありつつ、私の活動はスクラムマスターとしての役割を外れていた時は、スクラム再始動のための助走を 結果的にしていたのかなと、今は思っていました。後付けかもしれませんけど。 12月にスクラムを再始動してから、スクラムは凄いと日々感じています。

川口さんのブログに書かれていた kawaguti.hateblo.jp

プランニングと実行とフィードバックが繋がっているのがスクラムのポイント。

というのを最近読んで、なるほどそういことか。私がなんとなく思っていたことが 言語化されていて目から鱗状態だったのであります。

*1:本来はプロダクトオーナーが決めること

スプリント4

スクラムマスター視点でのふりかえりです。

前回のエントリーはこちら otentosama.hatenablog.com

時間

  • スプリントレビュー準備,13:00-13:25
  • スプリントレビュー,14:00-14:30
  • スプリントレトロスペクティブ,14:40-15:01
  • 休憩,15:01-15:15
  • スプリントプランニング,15:15-16:45(15分休憩あり)

成果

  • 計画に対して実績がどうであったかを書きます。
  • 見積もりの精度が良かったか悪かったかを気にします。

6ポイントを計画して6ポイント達成しました。 1営業日少なくて6ポイント達成だから通常であれば8ポイントくらい行けそうというチームのふりかえりです。

スプリントレビュー

  • レビュー会(デモ)でのデモがどうであったかを書きます。
  • ステークホルダーからフィードバックをうまく引き出せる内容だったかを気にします。

ストーリを2つデモできました。修正したバグをデモできたけれど、開発チームとプロダクトオーナーは して見落としていました。これは反省すべき点。私は気がついていたけどあえて伝えなかった。 この手のものは経験(失敗含む)しないと分からない気がするのでこれでよかったと思っています。

スプリントレトロスペクティブ

  • 先週から取りいれた試みを検査した
  • 想定していたより計画が早く終わった
  • 次回から何かふりかえりのフレームワークを使ってふりかえってみましょう

スプリントプランニング

トータル90分かかった。もう少し早く終わりたかった。年内のお仕事終了だったので、早く終わっても それほどメリットはない感じもあるので、良しとする。もう少し早く終わらせるためには、ACをきちんと書いておいて、ストーリーで実現するべき動作を明確にしておく必要がある。プロダクトオーナーと直近のストーリーがreadyな状態になっているかを日々点検しておいた方が良い。

まとめ

今年もお疲れ様でした。

f:id:yuichan-otentosama:20181229055925j:plain

ももクリ 2018の感想

ももクロコンサート(ライブビューイング)の感想を記憶が新鮮な内に書いておきます。内容はフェイスブックに書いたものと同じです。おそらくら後でアップデートします。

ももクロのクリスマスコンサートはとても楽しかったです。例年ダウンタウンももクロバンド(通称DMB)とももクロで行われていますが、今年はそこに新しい要素が加わりました。‬

‪Stringsというオーケストラで演奏するような方達です。楽器はバイオリンとか‬コントラバスとかです。

私はオープニングから圧倒されました。普段のバンドに、オーケストラの音が加わるとすごいです(表現が貧弱)。

アンコール手前から直後あたりに、Stringsのまとめ役の方が感想をももクロのメンバーに聞かれて答える場面がありました。今回の演奏はチャレンジングなことで普段の演奏よりも難易度が高かったそうです(確かに聴いていて素人ながら凄い演奏だと思いましたもん)。

メンバーによっては思うような演奏がなかなかできず、カラオケボックスにいって個人練習したりして納得できる演奏ができるように個人個人が努力して本番当日を迎えたそうです。

とかそういう背景を踏まえて各局のももクロコンサートの様子を放送しているのを見るとまた捉え方が変わってくるかもしれません。