More Related Content Similar to スクラムマスターはじめのいっぽ (20) 28. スプリント
27
月 火 水 金木 土
日土
計画し
毎日確認しながら 作って
できたものを
レビューして
やり方を
レビューする
1.5h 4コマ 3人 11週 = 198人時
37. 目次
• 参加経緯
• enPiT BizApp
- 概要
- 学習スケジュール
- 分散PBL
• 振り返ってみて
- スクラムマスターとして
- 教科書通りやってみて
36
38. 目次
• 参加経緯
• enPiT BizApp
- 概要
- 学習スケジュール
- 分散PBL
• 振り返ってみて
- スクラムマスターとして
- 教科書通りやってみて
37
57. 目次
• 参加経緯
• enPiT BizApp
- 概要
- 学習スケジュール
- 分散PBL
• 振り返ってみて
- スクラムマスターとして
- 教科書通りやってみて
57
64. 参考
•『SCRUM BOOTCAMP THE BOOK』
2013 西村直人、永瀬美穂、吉羽龍太郎著
•アジャイル開発手法特論講義資料
2014 永瀬美穂
•2014 Qcon LT資料
http://www.slideshare.net/MihoNagase/enpit-bizappaiitqcontokyo2014
• 2014 永瀬美穂
64
Editor's Notes わたくしは竹葉と申します。SCSK株式会社というIT企業で、研究開発をしております。enPiTには業務としてではなく、自己研鑽で参加しました。
これ以上、なんの肩書きもない一般人です。文系です。課ではいちばん下っ端です。持ってる資格は情報処理技術者ぐらいです。
CSMを取った先輩主導でスタート。私はというと、あまり身に染みてないままやるっていうカンジ。メリットもデメリットも理解しないまま、なんとなくこなしていた。計画MTGとかデイリースクラムとか振り返りやったし、Redmineでカンバン使ったりバーンダウンチャート使ったり、２週間スプリントでプロトタイプ開発していた。でもうまくいかない。最たるは、終わらない。先輩が頑張ったり、残業したりする。それでも終わらないので、デモのときに「ここは終わってないんですけど、機能には影響ないです」「テストは正常系だけ終わってます」「これゴミデータです」とか言って説明で補う。それで毎スプリント、終わった達成感はなくて、はあ。終わりにしようか。っていうテンション。すごくもやもやしてた。
残業して終わらすのは終わったと言うの？それ成功って言うの？なんでわたしはこんなもやもやしているの？きっと私もこの人も基本を飛ばして応用例だけ見せている。よく会社ごとに文化とか違うんでそこは適宜カスタマイズして…とか聞くけど、わたしもっと基本をしっかりやった方がいいんじゃないか？ということで興味が湧く。
ふと行ったQCon2014で永瀬美穂さんがLTでenPiTを紹介。大学でスクラム開発を学べるぜー！会社でできない挑戦できますよー！という宣伝。
ふと行ったQCon2014で永瀬美穂さんがLTでenPiTを紹介。大学でスクラム開発を学べるぜー！会社でできない挑戦できますよー！という宣伝。
１日のセミナーなんかじゃなくて、体験じゃなくてお試しじゃなくて実践できそう！
きっとうまくいかずに悩んでいる人とか、自分の経験と社会で語られる経験に齟齬に感じている人がいるはず！
会社では下っ端だし、リーダーやらしてくださいって言うの恐いし面倒だし自信ないけど、ここでならできるかも！
これは行くしかないでしょう！！！！！！！で願書もらって帰宅。翌日には上司に相談。推薦書とかも書いてもらって幸いなことに全力で応援してくれた。
無事通過してenPiT受講許可が！早速授業開始！
学習スケジュールはこんなカンジです。６〜８月は事前学習としてアジャイル開発手法特論を勉強しました。土曜日に２コマ、３時間の講義を受講しました。
７月末には会社でAgile 2014に出張。やはりアジャイル開発熱い！！更にモチベーションが上がる！！！これ是非行って欲しい！切腹してでも！試験あったし、早朝に着いて午後には学校へ。
合宿といっても泊まりではなくて、昼一から夜までのスケジュールです。
私の場合は朝に仕事行って、午前中が終わったらすぐ大学に向かって、昼からRuby On Rails、Github、TravisCIといった技術系の演習を受けて、夜はえらい人のお話を聞いて、帰って寝て次の日また仕事、というようなカンジです。正直、みっちりで結構キツかったです。
そしていよいよ分散PBLが始まります。
チームには役割を持つ人がいます。
アプリケーションについて考えるプロダクトオーナーと、チームを上手く進めるスクラムマスター、それからアプリケーションを開発する開発チームです。
チームはですね、この教室で、はい今からチーム作ってくださいねー！という放置プレイ型。事前学習で顔は知っているものの話したことない人がほとんどで、もちろんお互いどんな性格でどんな仕事してるかもわからない。私の場合は２人とちょっとだけ話したことがあって、活動時間も合いそうだったからイチ抜けしたカンジ。他のチームは時間いっぱい使ってうじゃうじゃしてたのを引け目感じながら見ていた。こういう決め方からだからかわからないけど、その後空中分解したチームもあります。
私たちは１週間スプリントで開発していました。開発に充てられたのは週４コマ分です。まず計画して、月曜に２コマ分作業して、水曜日に２コマ分作業していました。もちろん仕事があるので、仕事終わって18:30に集合して、21:30解散というスケジュールで動いてました。そして土曜日にコーチや他の受講生に対してデモを行って、その後にその１週間を振り返って良い点や悪い点について話し合います。１週間あるように見えるんですが、活動したのは土、月、水のみです。１コマが1.5hで、週4コマ、それを11週で3人だったので約198人時のプロジェクトとなります。
会社で毎日このプロジェクトに取り組んでいたとすると大体2週間くらいの換算になります。
実際には私たちは１週間スプリントで開発していました。開発に充てられたのは週４コマ分です。まず計画して、月曜に２コマ分作業して、水曜日に２コマ分作業していました。もちろん仕事があるので、仕事終わって18:30に集合して、21:30解散というスケジュールで動いてました。そして土曜日にコーチや他の受講生に対してデモを行って、その後にその１週間を振り返って良い点や悪い点について話し合います。１週間あるように見えるんですが、活動したのは土、月、水のみです。１コマが1.5hで、週4コマ、それを11週で3人だったので約198人時のプロジェクトとなります。
会社で毎日このプロジェクトに取り組んでいたとすると大体2週間くらいの換算になります。
実際には私たちは１週間スプリントで開発していました。開発に充てられたのは週４コマ分です。まず計画して、月曜に２コマ分作業して、水曜日に２コマ分作業していました。もちろん仕事があるので、仕事終わって18:30に集合して、21:30解散というスケジュールで動いてました。そして土曜日にコーチや他の受講生に対してデモを行って、その後にその１週間を振り返って良い点や悪い点について話し合います。１週間あるように見えるんですが、活動したのは土、月、水のみです。１コマが1.5hで、週4コマ、それを11週で3人だったので約198人時のプロジェクトとなります。
会社で毎日このプロジェクトに取り組んでいたとすると大体2週間くらいの換算になります。
実際には私たちは１週間スプリントで開発していました。開発に充てられたのは週４コマ分です。まず計画して、月曜に２コマ分作業して、水曜日に２コマ分作業していました。もちろん仕事があるので、仕事終わって18:30に集合して、21:30解散というスケジュールで動いてました。そして土曜日にコーチや他の受講生に対してデモを行って、その後にその１週間を振り返って良い点や悪い点について話し合います。１週間あるように見えるんですが、活動したのは土、月、水のみです。１コマが1.5hで、週4コマ、それを11週で3人だったので約198人時のプロジェクトとなります。
会社で毎日このプロジェクトに取り組んでいたとすると大体2週間くらいの換算になります。
社会人だからこそ教科書通りにやるのって難しいし、挑戦しがいがあります。特にタイムボックス厳守！残業しないっていうのって、仕事やりきりたくなっちゃうし、上司の目もあるし、かなり難しいと思います。これは私がどうしてもやりたかったことです。「できませんでした」って言うこと。終わってないのに終わりましたって言って流すと、反省しないのでは？という想いで。
後藤さんと遠藤さんは業務とは違う分野の技術を勉強したいという目的があったので、それを実践できるようにしようという方針で始めました。
そんな３人が開発したプロダクトについてご紹介します。
その名もあいまいランチ！早速デモをお見せします。
最初はランチに迷う人向けで、単純に和食食べたいとか場所選ぶようなアプリだったんですが、真面目にスクラムやってるチームがふざけたもの作ったら面白いんじゃないかっていうので、男性のタイプを選んで、その趣向からランチのお店を進めるというアプリに仕上げました。
最初はランチ迷っている人に対して有無を言わさず二郎をオススメするというとんでもないアプリでした。
それにスタートページが付いたり
最終的にはこんな素敵なUIになりました。
スクラムマスターとしての喜怒哀楽を交えながらご紹介します。
本日はどんな風にプロダクト成長させてったか、ということは割愛します。ここでは駆け出しスクラムマスターとしてプロセス振り返ってみてどうだったかっていうのお話します。
本日はどんな風にプロダクト成長させてったか、ということは割愛します。ここでは駆け出しスクラムマスターとしてプロセス振り返ってみてどうだったかっていうのお話します。
ちゅーことで喜怒哀楽いってみよー
まず楽！楽しいって意味です、もちろん。合宿疲れてモチベーション低いところから入ってるんですが、いいチームできたし、わたしたちには輝かしい未来が待っているー！と意気揚々と臨みます。
最初なんでできないこといっぱいあって、伸びしろがたっぷりあるのが楽しくてしょうがなかったです。自分てこんなにできないんだ！っていうのがわかるのって意外に楽しかったです。
次もう哀が来ます。
スプリント早速失敗しました。プロダクトバックログ１つもクリアできず、先週から１つも価値を上げられなかったという状況に私がまずめちゃめちゃ落ち込みます。ホントだったら残業してどうにかしちゃうんです。そうすると思います。でもそれはやらずに、自分たちの実力こんなもんです。できないんです。ってことを受け止めました。土曜のデモではまず失敗しました。死にましたと。デモオアダイなので。このときはもう絶対デモさせてもらえないと思ってたんですが、テスト終わってないって状態だったので、一応させてもらえました。でもあのショックはもう酷いもんです。
その次！なんと！
なんとというかスプリント成功！ペアプロとかしたりして、問題早めに摘んだり、作業の透明化ってとこがうまくいった結果だと思います。その前のスプリント失敗の痛みがある分、この喜びは突き抜けていて、終わった瞬間にチームで拍手。終わったー！やったー！ってのを初めて味わいました。これめちゃめちゃ嬉しいんですよ。
残業解禁したけども。
得意分野やってみたけども。
開発そんな進んでないでしょ。
それまでも散々、この人なんでこう言ってるのに聞いてくれないんだろうってことが山ほどありました。それって私がすごい真面目で、教科書通りにやりたくて、色々強制してたんです。それ通りにいかないことっていっぱいあるのに、わかっててもそこから外れるとイライラしちゃうんですよねー。
最終スプリント何が起こったかというと、最終スプリントのとき３人とも仕事が忙しくなって、対面で作業できるのがデモの前日だったんです。で、19時に集まって作業して、3時間残ってたので本来なら22時には作業打ち切らなきゃいけなかったんです。でも計画のところ終わった時点で22:30で、すでに30分残業している状態。さらにメンバーは最後だからここまでやりきりたいと言う。しかしもう残業してるし、このやりきりたいって部分が30分では絶対に終わらないとわたしは言う。で膠着。結局わたしが折れて、さらに23時までやることになりました。幸か不幸か30分で終わったんですが、そのときにメンバーが言った一言。やっぱこれも気になるんでやっちゃいません？すぐ終わるんで。ってはー。結局これ会社と同じじゃん。最後はやっぱりやりたくなって、我慢できなくて、際限なくやるっていう。私はここで、やっぱり諦めるとか潔く割り切るって難しいんだなーというのを感じました。
でもですね、相手がわかってくれないのって、それ自分が悪いんですよ。自分の伝え方が悪いんです。この普遍の真理、みなさん知ってました？わたし知らなかったです。
また、スクラムマスターを務めた私が、自信の振る舞いを振り返ってみて１つ、気付いたことがあります。
が、私が思うにスクラムマスターは後藤さんだったんじゃないかと思っています。プロダクトオーナーは後藤さん１人ではなくて、まあ開発も３人でしているし、３人でアプリケーションについて色々考えていました。
みなさんご存知ですか？リーダー的なものにはこんな要素があるみたいです。
この中で私がやってたのは管理者と意思決定者です。計画とか進捗の管理、ファシリテーションや最終的な議論の進む方向は私が決めていました。チームに規律はもたらせましたし、それで上手くいっていたこともあったと思っています。
けどスクラムマスターには、チームを和ませたりメンバーを励ますとか、この支援者でいることが重要だと思ってます。それを上手くできていたのは後藤さんだと思います。
指導者や技術とか進め方の指導する人なので、コーチ陣、伝道者はゴールを明確にして俺に付いてこい的な人なので、不在として、また遠藤さんは開発に徹していたとして、こんな役割だったかなと思います。
けどこうしてみると、支援者だけでもチームは成り立ちません。私がいなかったらチーム崩壊してるなという面もあります。
教科書ではスクラムマスターは１人しかいないように見えましたが、別に１人である必要はなくて、メンバーで補完し合っていられるなら特にスクラムマスターとか役割にこだわる必要はないのかなということに気付けました。
実力がわかると見積もりの正確性が増す。するとスプリントの成功率が増す。成功すると喜びが増す。喜びが増すと楽しい。いいサイクルができてく。
最初は伸びしろがあるから楽しい。段々慣れてくると最初喜んでたことが普通になってくる。できることも少なくなってくる。言っても言っても人間てそうそう変わらないし、諦めてくる。
あと自分を過信する。何度やっても「できますよ」とか「大丈夫だと思います」とか願望が入る。そのときは大丈夫だと思ったんですよ、ってそりゃそうなんだけど、さっきと矛盾しているようだけど、潔く諦めるとか、もっとやわらかく言うと人を頼るとかした方が良いこともあるのではと思います。
人って自分のためには頑張れないけど、人のためには頑張れるものなんです。だから、これやってください！って言うよりも、あなたがこうしてくれたら私こんな風に助かるんです、とか、こうしてくれたら嬉しいんですってことを言うと、動いてくれますよ！
週明け、会社で何か役に立ったら嬉しいです。残業しないとかやってみたらどうでしょう。できませんって言ってみたらどうでしょう。言ってみても死なないと思います。でもねー、私の話聴いて色々知って、実際にやるとなると相当難しいと思いますよ！っていうの早速知ってください。何か実践できたら、絶対何か拓けることは保証します。
去年は自分がこうして壇上に立つなんて考えてもみなかったけど、誰かと共有したいって思えるぐらいの挑戦と学びがありました。わたしの場合はenPiTでしたが、みなさんもビビッとくるもの、何か挑戦してみると面白いように転がっていくと思います。
