大阪ではあまり開催されていない「Scrum」の勉強会がある…とのことで行ってきました。
※ソフトウェア技術者協会(SEA)関西支部 プロセス分科会＃ちなみに、この勉強会、(自分の)TLでほとんど流れておらず、ATNDなどでの募集でも無かったので、申し込んだものの直前になるまで「本当にあるんだろうか？」と思っていました。 自分が参加している今のチームは、(「Scrum」とあまり口にしていませんが)Scrumな開発に割となっています。
ですので、自分の知識や考え方、動きの再確認などができれば良いなぁと期待して行ってきました。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
■講師と参加者 原田さん(
@haradakiro)さん、アシスタント(？)が
@e_yamaneさんでした。
参加者は20名程度でほとんどが私服でした。
(自分が似たような勉強会に出てせいもありますが)数人知っている方もいました。
＃ノートPC率は低かったです…というかワーク中心だからみんな持っていたけど出さなかった感じかも。■アイスブレイク お互い…特に講師が参加者のことを…知ろうということで「Scrum(を含めたAgile開発)をどれくらいやっているか？」「コードを書いているか？」などの質問のやり取りからスタートでした。
よくある「挙手」ではなく、会場の両端をそれぞれ「よくやっている」「未経験」などに見立てて、どこに立つか…というやり方でやりました。
＃ある程度シーンを選びますが、体を動かすという点では良いなぁと思いました。 「コードを書いているか？」で、ほとんどYes側にいなかったのがちょっと意外でした。
■最初 まずはScrumが出来上がった歴史的経緯、同じAgile開発の1つであるXPとの関係性などのお話がありました。
それから、この勉強会の「Working Agreements(作業合意)」を決めました。
「○○時に撤収も含めて完了する」「休憩は○○時に10分取る」というようなものです。
実際のPJなら「デイリーミーティング(朝会)は9時15分にカンバンの前で行う」などの働き方に対するチームの合意のようなものと感じました。
(チームが成熟しない、慣れないうちは)これをいつでも見える場所にあるのが大事だとも思いました。
チームが良くない時はこの「Working Agreements」が無かったよなぁと思い返していました。
＃例えば、朝会の時間がいつもバラバラだったり、ある時/ない時があったり…。■ワークショップ：マルチタスクの大変さ 「マルチタスクの大変さ」を実感するというものでした。
「2の倍数」「3の倍数」をそれぞれ別々の紙に1分間で書き出していきます。
1回目はそれぞれ交互に…Aの紙に2、Bの紙に3、またAの紙に4と書く…書いていきます。
2回目は30秒毎に…Aの紙、Bの紙…書いていきます。
結果は(個人差はありますが)1.5〜2倍で2回目の方が多く書けていました。
実際のPJでは1回目のような効率の悪いマルチタスクな状況によくなっています。
「(実際のPJではマルチタスクになりがちだが)これをいかにマルチタスクにならずにシングルタスクを維持しているか？(いけるか？)」というディスカッションを個人/チームの視点でもう少ししてみたいと思いました。
＃これはそのうちブログに書こうかなと思います。 そのマルチタスクつながりで、「コンポーネントチーム」でなく「フューチャーチーム」にしていけば良いかも…という話をしていました。
コンポーネント…画面、ロジック、DBなどの階層…でアサインせず、会議室登録機能…ここには画面、ロジック、DB、ドキュメント…1つの機能を作り上げる全てが含まれる…などの「機能」単位でアサインするというものです。
「多能工」(さらにその中で自分の得意な分野、層があると尚良し)が多い、またチームがそれを目指すのであれば出来る…と感じました。
＃今のチームはこれに近い形まで行っていると思います。 いくつか聞いた話では、なかなかこれは難しく「壁越しに設計書やコードを投げあっている」状況のような所もあるようです。
■その他のお話 そのワークショップの後は「Doneの定義」「Velocity」「優先順」のお話を少しずつ。
特に「Doneの定義」の計算ドリルの例が分かりやすくて良かったです。
宿題「計算ドリル」における子供の「Doneの定義」は(早く遊びに行きたいので)
「計算ドリルに答えを書き込んだこと」になる。
でも親のそれは
「答え合わせをして、間違えた箇所をもう1度やる(できれば、『なぜ』を理解して)」となる。
この「Doneの定義」の合意ができていないと「こんなはずじゃなかった」が後になって発生するというわけです。
これは仕事でも上司と部下、PM-PL-メンバー、発注者と受注者でよく起きていることだと思います。
■ワークショップ：見積り メインのワークショップです。
＃事前に参加者から「今日聞きたいことはなんでしょう？」と聞いていた中から選びました。 不確実性のコーン※のお話の後、「会議室予約システム」を題材にプランニングポーカーを使って見積もってみましょうという内容でした。
※「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」
にこの話は出ています。＃私達のグループは5人で、うち3人がプランニングポーカー未経験だったで、その方々のワクワク感が伝わってきてきました(ワークショップ本来の目的とは違いますが)。 いざ、やってみるとそれぞれ違う数字…見積もり…が出てきます。
A：「この数字の根拠はどんな感じですか？」
B：「○○という仕様、機能もいるだろうと思って…」
C：「(少ない数字を出した人が)あ、それは私いらないて思っていました」
D：「プロダクトオーナーに聞いてみないと分からないですねぇ。確認事項ですね」 …という様な会話がたくさん出てきて、見積もり行為そのものよりも、それ以上に
「チーム内の仕様の共有」や「足りない機能/不確定な仕様を洗い出し」という側面が強いと思いました。
これを実際に導入するキモはプロダクトオーナーが側にいる…何か疑問があったらすぐに聞けるような状況になっている…のがその1つかと思いました。
このワークショップの途中で時間が来てWorking Agreementsの通りに終了しました。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
懇親会でも(料理そっちのけで)色々な方とお話しましたが、「優秀/成功しているチームへのやっかみはある。またそういうチームだからこそ人貸しを要求されたりする。その場合に…」というような話題などは興味深かったです。
後、Twitterでのやり取りはあったけど、実際に面識の無かった方とも会えたり、
@kuranukiさんと共著で本を書いた方とお話したりもしてなかなか面白かったです。
Favorite
Retweet
Reply
