紙粘土スクラムの半日ワークショップ
アジャイル読書会繋がりの内藤さんから相談を受けて、アジャイル札幌が誇る紙粘土スクラムの半日ワークショップを実施しました。 参加者は内藤さんのチームメンバー6名と講師側としてしょーださんとnemorineです。 今回も様々なドラマがありましたw
ワークショップの変更点
4月から同じチームでアジャイル開発をするということを前提にワークショップをデザインしました。運営として今回変更したところは以下です。
- POのロールとやることを変える
- 動物園のビジョンを最初から提示する
お題
今回作ってもらった動物園は『親子で楽しめる動物園』です。 最初はメンバーが遠慮気味なためチームとしてバラバラな感じがしましたが、スプリントを回すごとに少しずつカイゼンしていき、チームとしてまとまっていくのを感じました。
スプリント
スプリントの簡単なイメージはこんな感じです。
【スプリント1】 プロダクトバックログの受け入り基準(完了基準)が曖昧なため、分担などが上手くいかない。POもスクラムマスターも上手く動けていない。 動物は完成するが、2頭作ったポニーのサイズが全然違うという問題発生。黒王号と言いたいとこだったが、大きい方は白かった。ペンギンは可愛くできていた。
【スプリント2】 POが実装中に顧客とやりとりしながら上手く動くことで受け入り基準(完了基準)を明確にできた。外から観察していると粘土で動物を作っている人が2人しかいない。迫力のあるシロクマ(ちょっとコアラ似)ができた。
【スプリント3】 チームに発生したアクシデントもギリギリ乗り越えた。スクラムマスターが全体を見れるようになり、チームの動きが改善されてきた。象の色はグレーと言っていたのに白で作ってしまい、顧客からはグレーでお願いしますとの依頼を受けた。おしいw。疲れが見える。。
【スプリント4】 チームとして見積もりは明確にやっていないが、頭の中ではイメージできている。作業分担もある程度終わって、実装中もお互いに声をかけながらイメージの共有や情報を補完しあっている。スクラムマスターは象を完璧に仕上げつつ、要所で指摘を入れる。他も分担しながらライオン、モルモットを作っていった。
スプリント4で作った動物達の品質、スピードともに最高でした。メンバーがロールを意識して動くことでこんなにチームとしてのアウトカムが変わるっていうのをチームのメンバーも自分達も体験した瞬間だったと思います。
ふりかえり
最後はFun/Done/Learnでふりかえりをして終わり。
『いままでは要件を決めた後はあまり手をかけなかったけど、スクラムでは沢山関わっていかないといけないことが分かった』とPO役の方が言ってくれて、グッときました。良かった!!
かなり時間オーバーして参加者は疲労困憊だったけど、しょーださんと自分で伝えたいことは伝えれたと思います。
チームとしてのスタートダッシュに少しでも貢献できればうれしいですね。
もちろん運営側もめちゃくちゃ勉強になりました。
自分としての反省はチョコを忘れたことです。次回はロイズを用意します ><
紙粘土スクラムをご希望の企業様は以下のページからお問い合わせください。
アジャイル札幌 | Doorkeeper
モブテストのハジメ
RSGTでの講演やアジャイルジャパン札幌サテライトについて検討していく中でモブという働き方を意識するようになりました。面白そうなので、2月からチームにジョインしたKさんともう一人のエンジニアの人と3人で会社内でモブテストをやってみました。
今回のテストはHDDのRAIDのテストでディスクを引き抜いてステータスが取れるかどうかを確認するというものです。もちろんRAIDの仕様上ホットスワップには対応しているとは知っていても、動いている状態で初めてHDDを抜くときは緊張しますよね。
今回意識するようにしたのは、対話を多くすることです。新しくジョインしたため分からないことが多いと思ったので小ネタや周辺の話も含めてお話しすることを心がけました。個人的には座学より、知識と体験を同時に学んでいく方が学習効果が高いと考えているからです。Kさんからも質問があったり、もう一人のエンジニアからの情報共有もあって盛り上がりました!
情報の共有だけではなく、「このHDDは思った以上にスッと抜けますね」「もう少しグッと刺さっている感が欲しいね」みたいな感覚の共有もできて面白かったです。
今回は試験仕様書に沿ったテスト(スクリプトテスト)をモブでやってみました。みんなでワイワイしながら新しいテストを試していくという探索的なモブテストとはちょっと違いますが、新しいチームメンバーへ周辺知識を伝えるという当初の目的は達成できたと思います。
これからもちょっとずつ実験していこうと思います。
熱かった!スクラムフェス大阪
スクラムフェス大阪に札幌からアジャイル札幌の運営を担っている4名のエンジニアで参加しました。 もちろん話を聞くこともそうですが、秋に実施予定の札幌のスクラムイベントへのヒントも探すつもりでした。 初回とは思えないすごい熱量で今の自分の悩みに当てはめながら考えたりして、2日間頭がグルグルしっぱなしでした。 気づいたことや印象的だったところを書き留めておきます。
コンテンツ
バランスが良いなぁというのが率直な感想です。 首都圏と地方、開発とQA(メトリクス)、真面目とエンタメ(?)、ワークショップ、説教などなど。スクラムに対する知識や実践のレベルがどのような人でも必ず何かを取れるようなコンテンツの作り方だと感じました。 当たり前かもですが、地元関西のコンテンツがしっかり入っていて関西の層の厚さを感じました。
参加者のダイバーシティ
参加者は日本どころか世界からも来ていました。こういうのが普通になるっていい環境ですね。
交流
途切れることなくみんながワイワイ話していた気がします。コーヒーブレイクやネットワーキングのときは沢山の人とお話することができました。自分もたまたま隣になった発表者の方と話していたら、その方の上司と知り合いだったことから話が盛り上がりました。札幌から一緒にいったゲーム好きのいづはスクエニのエンジニアと名刺交換して舞い上がり、そのあともズッと話して舞い上がっていました。これぞギャザリング。
プレゼン
聞いたものは全部書きたいですが、3つを厳選して。
新卒日系ブラジル人がリーン&アジャイルなメトリクス管理に出会った話 Arissa Nakamura
新人でありながらアジャイルなチームにコミットして、そのチームに必要なメトリクスを取って、そのメトリクスをきっかけにして、チームの考える場を作っているというのは本当に凄いです。
- 生産性
- バグの修正時間
- ストーリーのバーンダーン
- バグの予実
アジャイルプロジェクトのメトリクスは何を取ればいいんでしょ?と思っている人はこの発表を是非聞いてほしいです。発表資料は会社のQA関係者に回したいと思ってます。
基調「公」演 ぼくたちのアンパンマンマーチ(ちんもさんの案)
元気=およべさん、勇気=きょんくんの公演(講演ではない)。いままで見た中で一番インパクトがある技術の公演だったと思います。そして多分これからもないだろうなぁ。。。
超人と見られることが多い二人の人間っぽい一面を見れたのが凄く良かったです。二人とも考えて、行動して、考えて、行動して、を繰り返していて今の状態にいるのが良くわかりました。そしてエンターテイナーでしたね。面白過ぎました。 そしてねのさんの生演奏。凄すぎる。。。しかも後で基盤チームの人と話したら、JASRACに申請しているとか。どこまでもしっかりしていることにびっくりしましたwww 元気代表のおよべさんが3月に札幌に来てくれるので、それもまた楽しみです。
スクラムフレームワークを使用する具体的な方法。僕の場合。
しーばさんのセッションは今チームリーダーとして悩んでいる自分にガツンと響きました。 しーばさんのプレゼンはいつも強い現場感(ドロドロした感)とそれを悲観的にしない強さと優しさで溢れている気がします。 https://bufferings.hatenablog.com/entry/2019/02/24/124752
自分もまずはステークホルダーと今の開発方法、開発の状況を一枚絵にしておこうと決めました。そして一歩ずつカイゼンしていこうと決めました。
今秋予定している札幌でのスクラムイベントも大阪に負けないくらい熱く楽しいイベントにしたいと思います。
面白さでは勝てないので、違う方向性でwww
RSGT2019 Day1レポート
今年もリージョナルスクラムギャザリング東京2019(RSGT)へ行ってきました。
最近は一年の計はRSGTにあり的な感覚になっている気がします。今回はアジャイル札幌のメンバーのあべちゃんと勉強会の友人である上戸鎖夫婦と一緒に参加できて最高にHappyなRSGTになりました。
基調講演 Outcome Delivery: delivering what matters / Gabrielle Benefield
Whatではなく、Whyを考えよう!
その方法としてデザイン思考+アジャイルを統合したメビウスのループを提案するという内容でした。
いきなり素晴らしいコーヒーの絵を描くワークがありました。そのあと素晴らしいコーヒー体験の絵を描きました。自分は山に登って飲んだコーヒーが美味しかったのでそれを絵に描きました。そしてGabrielleさんがコーヒーは何のために飲むのかという問いかけをして、Whyについて考えました。
問題を定義しよう!ということでは新しいことではないんだけど、デザイン思考とアジャイルをグルグル回すイメージでそこに名前を付けてフレームワークにしたのが価値があると思います。 メビウスの図の中のカードがナイスデザインでした。
そしてGabrielleはめっちゃ美人でしたよっ!!
チームワークの会社で最高のプロダクトを目指すチームができるまで -強くてスケールするチームの作り方- 天野さん 大友さん
外部のスクラムマスターだった大友さんを連れてきて、サイボウズのチームが一体となってカイゼンした話。 大友さんのチームを見る冷静な観察眼とチームにあえて変化をもたらす天野さんのコンビが凄くて色々勉強になりました。
グッと来たのは見積もりの中に入れるバッファの運用を止めたところ。なかなかできないと思いました。付け足すのって比較的簡単だと思うんですが、やめるとか手放すって難しいですよね。。。
同期会
夜はスクラムマスター講習2014@仙台の同期会に参加しました。fam333というところで飲んだのですが、クラフトビールが美味しいすぎてヤバいです。Day0もよなよなしたので2日連続のクラフトビールになります。 仙台の半谷さんや師匠のエバッキーも来てくれて、同期+スクラムマスターたちでワイワイ飲みました。札幌からの友人たちもすんなりと受け入れてくれて本当にいい人たちだなぁと改めて思いました。 スクラムギャザリングの話やスクラムの話、会社の話など1年に一回だけど集まってワイワイ話せるってめっちゃいいですね!!企画してくれた野村さんありがとうございます。
ってことで、1日目のレポートは終了です~
あるノルウェーの大工の日記 読了
会社の上司から借りたノルウェーの大工さんの本を読みました。 ある大工さんが屋根裏の改築をしていく様子を書いたものです。 語り口は素朴な感じながら、仕事の進め方、チームというもの、お客さまへの信頼感の構築の方法などソフトウェアに共通するコトが書かれています。 特にDIY好きな自分にとっては、大工さんの仕事や思考の一面を知る楽しみも含めて、最後までワクワクしながら読むことができました。
- 作者: オーレ・トシュテンセン,牧尾晴喜,リセ・スコウ,中村冬美
- 出版社/メーカー: エクスナレッジ
- 発売日: 2017/09/29
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
気になったワード
大工道具は私の分身のようなものだ。道具を大切に扱うことは、大工という職業、仕事そして自分自身に対する敬意である。(P7)
道具を大事にするって重要ですよね。
職人、おして職人技(クラフトマンシップ)そのものには、ある程度の自由や裁量が必要だ。それがあって初めて、消費者が製品の美しさや機能性を享受できるようになる。(P79)
余裕、ゆとり、自由、言い方は色々あるかもしれませんが、それが製品の美しさや機能性に繋がる。ここらへんもソフトウェアと一緒だと思いますが、今のプロジェクトでは余裕がないのが実情です。
作業現場が整理整頓されると、作業効率が上がり、より安全になる。それに仕事に行くのも楽しくなる。(P161)
DIY作業のときは特に感じます。道具が行方不明になって探す時間は本当に無駄だと感じますし、めちゃくちゃイライラしますw
私たちは一つのチームとして働いているが、必ずどちらかがリーダーとしての責任を負う。(P204)
責任を押し付けあっているチーム、リーダーは居ませんか?(笑
自分の限界を認めるのは職人にとって最も重要なことだが、これについては実際に作業をしながら学んでいくしかない。弟子に口頭で教えることはできるが、その弟子も結局は時間をかけ経験を積みながら実感していくのだ。失敗することは、自分の限界を知るためにも大事だ。良い職場とは、失敗を許してくれて、しかもその失敗が大きくなりすぎないように、うまくカバーしてくれるようなところだろう。(P209)
失敗を許してくれて、大きくなりすぎないようにするっていいですよね。
私は細かい作業が発生する度にさっさとやってしまう方がいいと考えている。ちまちまとした手作業を長々と続けることは少々退屈なので、分散させたほうがいい。(P236)
これは耳が痛いので、退屈な作業もパパッとやる癖をつけたいところです。 が、性格上、、、うまく行かないことも多いんですが、、、
Fun Done Learn
はじめてのアドベントカレンダーの12/19のエントリです。
スクラムトゥギャザーリングのときに川口さんから教えてもらった新しいふりかえりの方法が面白かったので、やり方をまとめておきます。またKPTの違いについて少し考えてみました。(以下の写真はスクラムトゥギャザーリングのふりかえり時のもの)
やり方
- Fun Done Learnのベン図を書く
- 付箋にFun Done Learnと思うものを書いてはりつける
- チームの皆で話ながら、ベン図のどこにあたるかを確認していく(位置をずらしていく)
Fun Done Learnの特長
感情のFunが入っている
カイゼンをするときは事実に目を向け、、、と思ってきました。でもこのふりかえりには『楽しさ』を表すFunが入ってます!ゲーミフィケーションが好きな自分にはしっくりきました。何事も楽しくないと続かないですよね!
ネガティブにならない
KPTの場合はProblem→Tryに集中してしまうことが多く、一歩間違うと犯人捜しが始まります。一方、Fun Done Learnは全てのワードがポジティブなイメージを持っているため、ダークサイドに落ちにくいと感じています。 KPTのProblemはLearn=Problem+Tryの形で出てくることが多く、次にどうしたら良いかという未来へつながる思考になることが多いと感じています。
何度も話す機会がある
ベン図上で付箋を貼り替えていくため、何度も付箋に書かれていることに触れることになります。 ポジティブな言葉で書かれているため、チームの自信を深め、信頼を深める効果があると思います。 牛で言うと反芻ですね。
使いどころ
Fun Done Learnはどこでも使えると思いますが、個人的には以下の場合の効果が高そうだと思っています。
- ふりかえり自体をやったことがない場合
- かけだしのチームなどまだお互いの信頼感が薄い場合
- 初めてのことに挑戦した場合
- チームの雰囲気が落ち込んでいる場合
- Problemで犯人捜しが始まることが多い場合
川口さん、ありがとうございました!
境界の仕様
ソフトウェアテストの#2のアドベントカレンダーの12/16のエントリになります。
今回は自分がやらかしてしまった境界の仕様の話をしようと思います。
あるセンサーのデータを収集する機能があります。 そのままデータ収集を続けるとデータが多くなって、DBの容量がいっぱいになりますので、沢山たまったデータを削除するパージという機能が必要です。 それではそのパージの機能ですが、どちらの仕様(コード)が良いでしょうか? ※ここでは仕様に沿ってコードが実装されると仮定しています。
ID | 仕様 | 条件の疑似コード例 |
---|---|---|
A0 | ある日付より前のデータは消す | date < "2018/12/11" |
B0 | ある日付以前のデータは消す | date <= "2018/12/10" |
もちろんどちらでも大丈夫そうに見えますね。 dateは日付なのでどちらも期待通りに動作します。
さて、ここに時間の概念が入ってきたらどうなるでしょうか?
ID | 仕様 | 条件の疑似コード例 |
---|---|---|
A1 | ある日時より前のデータは消す | dateTime < "2018/12/11 00:00:00" |
B1 | ある日時以前のデータは消す | dateTime <= "2018/12/10 00:00:00" |
あれ?B1のパターンは2018/12/10 12:00:00のデータが消えないというバグがありそうですね。 これを期待通りに動作するように変更すると以下のようになります。
ID | 仕様 | 条件の疑似コード例 |
---|---|---|
A2 | ある日時より前のデータは消す | dateTime < "2018/12/11 00:00:00" |
B2 | ある日時以前のデータは消す | dateTime <= "2018/12/10 23:59:59" |
23:59:59なんて何か嫌な感じですね。
さて、さらにミリ秒の概念が入ってきたらどうでしょうか?
ID | 仕様 | 条件の疑似コード例 |
---|---|---|
A3 | ある日時より前のデータは消す | dateTime < "2018/12/11 00:00:00.000" |
B3 | ある日時以前のデータは消す | dateTime <= "2018/12/10 23:59:59.999" |
ここまで来るとだんだんわかってきますね。 日付というのは実は範囲を持っていて、2018/12/10 00:00:00.000 から 2018/12/10 23:59:59.999…(省略)になります。 仕様作成時、コード実装次に、以下の図の●と○の中間をちょっと考えることで変更に強い仕様やコードになると思います。
ちなみに自分が埋め込んだバグは 以前の仕様に則って、<=を使用し、
dateTime <= "2018/12/10 23:59:59.999"
と実装したのですが、小数点以下がなんと6桁のケースもありました >< すなわち、2018/12/10 23:59:59.999001 ~ 2018/12/10 23:59:59.999999が削除されないことになります。 レビュー指摘されて、事なきを得ましたが危なかったですねぇ。