[DevLove Nagoya]Burnin’ Scrum始めました

DevLove Nagoya #1

Transcript

1. Burnin’ Scrum始めました May 28 2013 Yasushi Hagai DevLove Nagoya #1 1
2. ⽻飼 康（ハガイ ヤスシ） 名古屋アジャイル勉強会スタッフ @onestepbeyond_y 2
3. AGENDA • はじめに • なぜアジャイル • アジャイルを学んでみた • スクラムはじめてみよう • 実践してみた • そして今思う事 3
4. はじめに 4
5. 本⽇は • 私がスクラムを学んで • 調⼦に乗ってやってみている • そんな話をしたいと思います 5
6. Burninʻ なんてタイトルですが • スクラム導⼊までの熱い戦いとか • 始めてからのドタバタ劇とか 6 すいません そういうの無いです
7. 世間でよく⾔われてる事 • ムダを省いて⽣産性アップ • 変化に対応 • スクラムを理解するのは簡単だが実践は ちょっと難しい • “⼈”が⼤事 • 銀の弾丸じゃない • Etc. 7 今のところだいたいその通り
8. Burnin’ • 現在進⾏形の話なので、『成功事例』で はないです（今から炎上するかもしれな い） • 今まさにburndownしているお仕事の話で す 8
9. なぜアジャイル 9
10. ⾃慢じゃないけど 結構⻑くこの仕事やってるけど 10 計画通り出来た事なんて ほとんどありません ホントすいません… 計画がブレなくても⼈がブレる
11. まじめな話 • こういう（ある想定）メンバーで • 無駄な作業しないで • 常に最適化しながら 11 こんなふうにお仕事したら⼯数は半分以下 にはなるよなぁって⽇頃から思ってた
12. ビってきたスクラム • ある⽇出会った「塹壕より Scrum と XP」 – http://www.infoq.com/jp/minibooks/scrum-xp-from-the-trenches • これはウマイと思って – WFのプロジェクトの中で⾃分のチームだけ ボードを作ってみたりした – 概ね評判は良かった – だけど特に劇的な改善とかなかった 12
13. アジャイルを学んでみた 13
14. まずは読んでみた • 塹壕より Scrum と XP • アジャイルな⾒積と計画作り • アジャイルサムライ • その他いろいろけっこう闇雲に アジャイルはウマイやり⽅だと思ったけど どう実践しようかってのはモヤモヤ 14
15. SCRUM BOOT CAMP 名古屋 • 体感する事が出来た • ウマイやり⽅だろうという確信は持てた • 楽しかった • もう少し深いところでモヤモヤ • かじさんと出会った 15
16. 認定スクラムマスター研修 • 教わった事 – スクラムとは – スクラムマスター（SM）とは – スクラムが機能するためのSMの振る舞い • スクラムに対する⾃信みたいなもの • いろいろだいぶスッキリ • かじさんが居た 16
17. スクラムはじめてみよう 17
18. ちょうどそのころ始った案件があった 18
19. どんなシステム︖ • 建設業のお客様 • ⼯事の原価管理とかそういうやつ • 既存システムのリプレイス • 以前⾃分が関わったやつ • ⼩規模 迷わずスクラムでやることにした 19
20. お客様とネゴ 20 細かいツメを断続的に進め ながら、それをどんどん触 れるようにしていくのって どうですか︖ うん、全然それがいい。
21. チームメンバー⼀本釣り • メンバーA︓ – 広い知識 – アジャイルの事も良く知っている – アジャイルやったことはない • メンバーB︓ – まじめ – アジャイルの事は良く知らない 21
22. まずはお勉強 • アジャイル、スクラムの事 – 『スクラム⼊⾨』とか使って説明 – 少なくともスクラムのやり⽅は理解する – マルチタレントになろう︕ • 技術的な事 – ビルド、テスト⾃動化、CI – 使う要素技術についてなどいろいろ 22
23. こうやってやることにした #1 • スクラムする – まずは“教義”を守る • スプリント計画(1,2) • デイリースクラム • スプリントレビュー • ふりかえり • タスクボード • バーンダウンチャート • ベロシティの計測 • Etc. 23
24. こうやってやることにした #2 • 少⼈数でやりきる仕掛け – CI (Jenkins) – JavaScriptのUnit Testも⾃動化（PhantomJS) – 体裁より中⾝ • モデリングツールのファイルを成果物とする • 美しく紙にならなくてもいい 24
25. 実践してみた 25
26. 最初に気になった事 • チームで成果を出すという事の理解が イマイチ – たとえば、「Aさんが書いたプログラムはAさ んが直す」的な癖が結構あった – 『モデルもコードもバグも共同所有』という のが理解されなかった これはすぐに改善された 26
27. そして… • Ken Schwaber⽒が • と申されたそうですが… 27 Scrumは組織の製品および システム開発の能⼒不⾜、 機能不全を露にする。
28. まさにその通り︕ • ひとたび問題が起きればそのスプリント はダメダメ • 何度かあったのは新しい取り組みでの ハマり – スプリントは2週間しかない – リカバリのバッファなし 28
29. 凹む • バックログが残りまくったタスクボード • その⾒た⽬がかなりアレ • 正直不安になりますよ 29
30. それでどうなる︖どうする︖ • さすがに『頑張る』以外の⽅策を考える – 判断は早く – 戦うのか回避するのか︖ – 早期の顧客への確認・ネゴ – やり⽅を変える • もちろん『頑張る』もアリですよ 30
31. もちろん良い事たくさん • 使わない物は作らない – 使わない機能満載（なわりには⼤事な機能が抜け落ちて たりする）のフレームワーク作りに沢⼭の⼯数 を使ったりしない • ⾜枷になるようなルールは適⽤しない – ⽣産性を⾼めるためのルールしかない（はず） • WFより明らかに⾼い仕事の『密度』 • 何度も得られる達成感 31
32. ひとことで⾔うと まあ今のところ 「そこそこいけてる」 です すいません、つまんなくて… 32
33. パフォーマンス • James Grening⽒がAgile Japan 2013で⾔って た5〜10倍とかってのは何処の話︖ • でも向上し続けはている • もう⼀⽪むけたい 33
34. ⾃分の事 • スクラムマスターの役割を果たせている か︖ – まず、上⼿くはやれていないと思う – 正直よくわからん • ⽇々精進としか… 34
35. そして今思う事 35
36. 無責任に⾔っちゃうと • ある条件が揃うなら… 36 でっかい基幹システムとか こそアジャイルがいけるん じゃないかと思います
37. ⼤規模システムって • 初期に要件出し切ることが既に無理ゲー – でも⾦額も責任もでかい – だから要件定義フェーズが終わらないでしょ • 『今出来る事・知ってる事』だけですべて作 るのは無理 – 必ず何らかの技術的（またはそれ以外の）チャレ ンジがある 37 初期の計画通りに進めるのはムリってみん なが気づいてるのではないか
38. で、その条件とは ⼈ 38 じゃないかなぁって思います
39. だって • 好きな⼈って勝⼿に学習する • そういう意欲を⽣産に直結させる 39 アジャイルだったらコレが出来ると思う
40. 少なくとも… こんな私でも ⼤失敗にはなっていません アジャイルって意外と⼤丈夫︕ （個⼈の感想です） 40
41. ありがとうございました 41