Bottom Up Scrum 20120323 #kanjava

• 椎葉 光行(しいば みつゆき)
• twitter: bufferings
• 仕事: Webサービスの開発
• タグ: Java,京都GTUG,GWT,GAE,

　　　　Slim3,ことーじゃ,Scrum,TDD

もっと楽しくコード書きたい

アジャイル・スクラムを勉強

これまでのやり方の中に

スクラムの良いところを

取り入れてみてるところ

(イマココ)

コードほとんど書けてない

(ホントはイマココ)｡ﾟ(ﾟ´Д｀ﾟ)ﾟ｡

自分の周りの人に

楽しく仕事してもらいたい

小さなことからやってみる

1.Introduction

自己紹介

関西Javaエンジニアの会(関ジャバ)

'12 3月度

Bottom Up Scrum

Scrum@bufferings

• 2011.09 Scrum Boot Camp in 関西
• 2011.10 Certified Scrum Master
• 2012.03 アジャイルサムライ道場 in 楽天

アジャイルとかスクラムって

よさげなーと思ってるんだけど

いきなりガツンと

変えられるもんじゃないなんだぜ。

というところから踏み出す

スクラムへの一歩。

開発を楽しんでますか？

それは仕様です

今更戻れない・・・

進捗が95%から進まない

終盤の仕様変更

2012/03/23 @bufferings

2.価値を届ける

5.ボトムアップ

スクラム

価値を早く届ける

解決できそうな問題点

さいごに

よりよい開発をやることが目的なのであって

Agile開発やScrumをやることが目的じゃない

自分の環境や立場に合わせて

できることからちょっとずつやったら

よいねと思う

(終)

チームメンバー間のセクショナリズム

• マイクロマネージメントのため
• 他の人のタスクを見る隙がない
• 他の人の時間を使ってまで質問できない

残業

終わりが見えないタスク

• 次々に追加されるタスク
• 早く終わる人にどんどんタスクが与えられる
• 次々に変更される仕様

報告の先延ばしとごまかし

タスクの落とし

見せる化

1日は5時間

共同所有

目的の共有

継続可能な開発

休みたい時に休もう

自己組織化へ

言いたくないこと程

早く見せる

参考資料

• ペアプロのペアをローテーションと全体レビュー。
• 誰かが休んでも別のメンバーが進めることができる。
• 1人で責任を持たない
• チーム全員でカバーしあう

動くソフトウェアを見せる

• メールや会議その他の作業があるので、実際に開発に集中できるのは1日で5時間程度。
• それで見積もる。
• 8時間で見積もったら、その時点で残業決定。
• 残業せずにやれる作業が1人日なんだぜ。

Henrik Kniberg

• 「うまくいく可能性があるから今言わなくていい」ではなく「うまくいかない可能性があるから今言わなければならない」
• マネージャに判断のための材料と機会を見せ続けること

http://flic.kr/p/9hPZQu

• 目の前のタスクだけが目的になってしまわないように共有。
• 全員でゴールを目指すことができる。
• 自己組織化されたチームへの第一歩。
• Redmineの入力をしてくれない、やJenkinsの放置は、これを見直すと良いと思う。

http://www.crisp.se/henrik.kniberg

Ryuzee.com

http://www.ryuzee.com/

タスクポイント

ペアプロ

チーム責任

知識の共有

助けあう

リアルに想像できない

単位にする

http://www.ryuzee.com/contents/blog/4778

アジャイルサムライ　達人開発者への道

• プロセスに関係なく導入可能。
• メンバー同士がお互いに何を知っていて何を知らないのかを把握できる。
• 普段から相談しやすくなる。
• 無駄な機能を作らない。
• 教え合える。
• (疲れる)

http://flic.kr/p/9hPZQu

• 個人個人ではなくチーム全員で、チームの成果物に対して責任を持つ。
• 自分の作業が遅れてでも、他の人の作業を手伝ったほうがチームとしてよいならそうする。
• (逆に他の人に迷惑かかるからってことで、みんな頑張る気がする)

http://flic.kr/p/9hPZQu

• アジャイルのプラクティスにはない。あるのはストーリーポイント。
• タスクに「7時間」と書くと通りすがりの人は「1日だね」と思ってしまう。
• そこで「7pt」と書くと「1日は5ptなんだ」と説明するだけで「1.5日か」と納得してもらえる。

http://books.rakuten.co.jp/rb/item/11264116/

見積もりポーカー

3rd Annual Survey: 2008

“The State of Agile Development” Conducted: June-July, 2008

スプリント

テストファースト

認識の齟齬をなくす

不安の払拭

見えるところにゴールを

• タスクポイントに対して行った。
• 想定の違いがポイントの差として出てくる。
• 見積がすぐに終わる。
• (遊んでいると思われる。実際遊び気分だけど。)

http://flic.kr/p/9hPZQu

http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf

• (TDDまでは飛ばしすぎだったのでテストファーストから)
• ペアプロとの組み合わせ
• 95%から進捗進まないのはこれやってないからだと思う
• 無駄な機能を作らない
• コードがテスト可能でクリーンになる
• 夜安心して眠れる

• 2週間のスプリント
• スプリントで行うタスクを固定
• 金曜に打ち上げ
• あとどれだけやれば終わりかがはっきり見える
• 逆に、あとどれだけやらなければ終わらないかもはっきり見える。
• (しんどい)

http://flic.kr/p/9hPZQu

価値の高いものから届ける

スクラム入門

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

TiDD

タイムボックス

全員レビュー

タスクの漏れを防ぐ

悩みすぎない

クリーンコード

http://bit.ly/scrum-primer-ja

• タスクをRedmineで管理。
• 漏れがなくなった。

• 調査するとき、考えるとき、などに「あと30分後までね」とタイムボックスを切る。
• 完璧な回答よりも前進を。
• 忙しすぎる人から回答をもらいたいときにも有効。

• 週に一度全員でレビュー
• 「このメソッド長すぎる」
• 「この変数名意味不明」
• 「この処理ダサイ」
• 「これもっとこうやったほうが読みやすい」
• 「このメソッドカッコイイ」
• ただ動けばいい、ではなく保守しやすいクリーンコードであること

http://flic.kr/p/9hPZQu

4.スクラム

3.アジャイル開発

チーム

• 自己組織化
• 職能横断的

チーム(推奨)

• 複数のプロジェクトは避けた方が良い
• メンバー変更は避けた方が良い

ベロシティ

チームが1スプリントで

何ポイントくらいの仕事が

できるか

バーンダウンチャート

http://flic.kr/p/9VcGAC

デイリースクラムの注意点

チーム内の共有であって、管理者やSMへの状況報告ではない。

議論はしない。必要なら後ほどフォローアップMTGを行う。

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践

あるいは実践を手助けをする活動を通じて、

よりよい開発方法を見つけだそうとしている。

この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを

認めながらも、私たちは右記のことがらにより価値をおく。

Kent Beck, Mike Beedle, Arie van Bennekum,

Alistair Cockburn, Ward Cunningham, Martin Fowler,

James Grenning, Jim Highsmith, Andrew Hunt,

Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin,

Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

© 2001, 上記の著者たち

この宣言は、この注意書きも含めた形で全文を含めることを条件に

自由にコピーしてよい。

アジャイル宣言の背後にある原則

私たちは以下の原則に従う:

顧客満足を最優先し、

価値のあるソフトウェアを早く継続的に提供します。

要求の変更はたとえ開発の後期であっても歓迎します。

変化を味方につけることによって、お客様の競争力を引き上げます。

動くソフトウェアを、2-3週間から2-3ヶ月という

できるだけ短い時間間隔でリリースします。

ビジネス側の人と開発者は、プロジェクトを通して

日々一緒に働かなければなりません。

意欲に満ちた人々を集めてプロジェクトを構成します。

環境と支援を与え仕事が無事終わるまで彼らを信頼します。

情報を伝えるもっとも効率的で効果的な方法は

フェイス・トゥ・フェイスで話をすることです。

動くソフトウェアこそが進捗の最も重要な尺度です。

アジャイル･プロセスは持続可能な開発を促進します。

一定のペースを継続的に維持できるようにしなければなりません。

技術的卓越性と優れた設計に対する

不断の注意が機敏さを高めます。

シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

最良のアーキテクチャ・要求・設計は、

自己組織的なチームから生み出されます。

チームがもっと効率を高めることができるかを定期的に振り返り、

それに基づいて自分たちのやり方を最適に調整します。

3rd Annual ”State of Agile Development” Survey June-July 2008

http://www.crisp.se/henrik.kniberg