DevLove 甲子園2014 インクリメンタルに 設計?テストする
Download as pptx, pdf0 likes182 views
インクリメンタルに 設計?テストする スクラム初心者が取り組んだ『中身』の話し
DevLove 甲子園2014 インクリメンタルに 設計?テストする
- 1. インクリメンタルに 設計?テストする Aug 23 2014 Yasushi Hagai DevLove甲子園2014西日本大会 1 スクラム初心者が取り組んだ『中身』の話し
- 3. どんな話し？ ? スクラムで受託開発案件 ? アジャイルプラクティス的な 話しはほぼナシ ? どんなふうに設計?テストし たかというお話 ? 割と普通ですすいません 3
- 4. スクラムで受託開発 4
- 5. 納品のある受託開発案件 ? 中小企業の基幹システム ? 既存システム(vb6でOracle8)のリプレイス ? 小規模 ? 既存システムの事はよく知っている ? それなりの精度で見積もれる 5
- 6. アジャイルでやろうと思った ? こういう（ある想定）メンバーで ? 無駄な作業しないで ? 常に最適化しながら 6 こんなふうにお仕事したら工数は半分以下 にはなるよなぁって日頃から思っていた
- 7. まじめに学んだ ? 本を読む ? 勉強会に参加 ? SCRUM BOOT CAMP ? CSM研修 ? ウマイやりかただと確信 7
- 8. チームメンバー一本釣り ? メンバーA： – 広い知識 – アジャイルの事も良く知っている – アジャイルやったことはない ? メンバーB： – まじめ – アジャイルの事は良く知らない 8
- 9. まずはみんなでお勉強 ? アジャイル、スクラムの事 – 『スクラム入門』とか使って説明 – 少なくともスクラムのやり方は理解する – マルチタレントになろう！ ? 技術的な事 – ビルド、テスト自動化、CI – 使う要素技術についてなどいろいろ 9
- 10. こうやってやることにした #1 ? スクラムする – まずは“教義”を守る ? スプリント計画(1,2) ? デイリースクラム ? スプリントレビュー ? ふりかえり ? タスクボード ? バーンダウンチャート ? ベロシティの計測 ? Etc. 10
- 11. こうやってやることにした #2 ? 少人数でやりきる仕掛け – CI (Jenkins) – JavaScriptのUnit Testも自動化（PhantomJS) – 体裁より中身 ? モデリングツールのファイルを成果物とする ? 美しく紙にならなくてもいい 11
- 14. 要求：なにを作る？ 14
- 15. 幸いに作るべきモノは明確だった ? リプレイスということもあり迷走せず ? 現状業務の変えたいところ ? 既存システムの変えたいところ を押さえれば基本的にはＯＫ 15
- 16. バックログは普通にユーザーストーリー ?As a 誰 ?I want to なにする ?So that ビジネス価値 16
- 17. 最初は正直ピンと来なかったけど ? 既存システムを使った業務からユーザー ストーリーを起してみるとそれなりに使 えるかなと – よくある要求列挙の「～できること」という書き方 より優れている点は ? 誰がそうしたいんだっけ？ ? なんでそうしたいんだっけ？ ってならない事 17
- 20. 設計：どう作る？ 20
- 21. ユースケースモデリング ? ユースケースを使って、ユーザーストーリーを システムの振る舞いとして表現する ? １Storyで1～数個のユースケース ? アクターはストーリーの “as a”から ? ユースケースも依存性をチェック ? ユースケースもパッケージに分けて組織 化する 21
- 22. ユースケース図って大事 ? システムを使って誰が何するかを簡単に 確認できる ? 単なる目次では無く、ユースケース間の 依存関係も定義する ? モデリングツールの機能を使ってスプリ ント毎に増えてゆくユースケース間の関 連を確認する 22
- 24. ユースケースシナリオはもっと大事 ? 実際の業務で使われている言葉でアクターと システムの振る舞いを記述 ? 例外シナリオを抽出 ? ユーザとシステムの対話の両側を記述 ? 名詞 ? 名詞 ? 動詞 のスタイルで記述 1. 担当者はアレをどうする 2. システムはソレをこうする ? これが作る物の元ネタとなり、テストの元 ネタとなる 24
- 27. ドメインモデリング ? ユースケースシナリオで使われている言 葉を使って、静的構造をモデリングする ? このドメインモデルが、全体を俯瞰でき るとても重要なビッグピクチャとなる ? 日々育ってゆく物であるが故に、気をつ けないと重複、矛盾が生じる 27
- 29. ドメインモデル ? 実装 ? モデリングに時間をかけすぎない ? 実装時にモデルのまずさに気づくことが ある – 実装が困難なモデル – 実装の都合に合わないモデル ? そんなときはまたモデリングに戻る ? モデルとコードの間を行ったり来たり ? 実装できないモデルは無価値 29
- 30. インクリメンタルに設計するということ ? 新たなストーリーが『加わる』ことが全 体の設計にどう影響するのかを常に チェックする ? 沢田マンション化するくらいなら手戻り のほうが良い ? 実際それほど大変な物では無かった 30
- 31. ? どう作られているかを残す – 次への備えが第２のゴール ? 第１のゴールは動くソフトウェア ? ウソを残さない – 実装との乖離はちゃんと埋めようね 31 納品のある受託開発なので 作り終えたら チームは解散する 設計を『残す』ということ
- 32. 活躍した道具 ? 両面ホワイトボード ? モデリングツール ? プロジェクター ? ホワイトボードはメンバーの近くに ? プロジェクターはいつでも使える位置に 32
- 33. テスト 33
- 34. 最初に 全手動はムリ！ 34 ? ストーリーがテストされてDone ? でも次のスプリントでまたそこ触るかも ね ? 何度もテストをサクッとやりたい
- 35. まずは普通にUnit Test ? JavaのコードはJunitでテスト ? Java ScriptはSiestaというフレームワーク ? CI利用（Jenkins） ? PhantomJSを使ってJSのテストもCI上で ? プロジェクトが進んでゆけばテスト量が 増えるので実行時間も長くなる 35
- 37. それ自動化したの？ ? ユースケース毎のテストを自動化 – Siesta利用 ? 一気に複数のユースケースのテストを流せるよ うにはなっていなかった（半自動） – すればよかったと思う ? テストデータの準備からテスト結果の保 存まで自動化できたらステキね 37
- 39. 活躍した道具 ? Junit ? Siesta – Java Scriptのテスティングフレームワーク ? Jenkins ? TestLink – テスト計画／実行結果管理 39
- 40. まとめ 40
- 41. やってみてどうだったの？ ? 実はそんな迷走せず、わりと普通にでき ました – 対象の業務をよく知っていた – そもそも移行前のシステムの担当者が私 ? 小規模で少人数だったので意思疎通もス ムース ? 大規模の場合は大変そう 41
- 42. 沢田マンションの恐怖 ? 沢田マンションを設計してしまうという ことはアジャイルでもウォーターフォー ルでもあり得る ? ただしウォーターフォールの場合は、実 装フェーズに入っていなければそれはま だ絵に描いた沢田マンションである ? しかしアジャイルの場合は絵である期間 が短い – すぐ作っちゃうからね 42
- 45. 便利な道具を使いこなす ? ホワイトボード ? モデリングツール ? テスティングフレームワーク ? ＣＩ ? ITS/BTS 45
- 47. Ｑ＆Ａ 47
- 48. ありがとうございました 48
Editor's Notes
- #4: ゆっくり スクラムの中でどんなコトやってるの？話しがあまり聞こえてこないので、まあ私のこんなのでもさらしてみようかなと。
- #5: ゆっくり
- #6: ゆっくり 背景についてたっぷりしゃべる
- #7: ゆっくり ＷＦでの無駄が多いやり方にうんざり お客さんそこまでお金持ってない お客さんはプロセスに対するこだわりは無い
- #8: ゆっくり
- #9: この一本钓りが大事
- #10: アジャイルに対する認識を会わせたかった。 スクラムやるので、スクラムについてはちゃんと知ってもらう必要があった。 Bさんはマルチタレントという部分でちょっと重圧と不安があったようです。 その他要素技術についても他の二人と比べて知識に差があったので、最初はけっこうキツかったみたいです。
- #11: スクラムをちゃんとやってみようという事。 Dogma Follwerですからね。 というのは冗談で、Dogmaには目的があります。 その目的を達成するためにちゃんとやってみようとしたわけです。
- #12: インクリメンタルに作るので、少なくともテストの自動化はしないと死ぬなと。 ドキュメント方面は、お客さんに「こうやると高くなるけど欲しい？」って言って納得してもらっています。 ぶっちゃけお客さんは見ないんです。次への備えになればいい。
- #13: ゆっくり
- #14: 「設計図はわしの頭の中にある」として、きちんとした図面もなく独自に工事をしていった。 部屋番号がバラバラなのは、建設当初入居者が決まった順に決定したものであり、今は宅配業者などの悩みの種となっている。 1971年（昭和46年） 第1期工事（50坪）開始。 1973年（昭和48年） 第1期工事終了、4階建て24戸。スーパーマーケット開店、以後5年間営業。のちには、鮮魚店や焼肉店さらには露天風呂付共同浴場が設けられた時期もあった。 引き続き、第2期工事（140坪）開始。5階に大家である沢田夫妻の自宅住居を建設。高知市内初といわれる地下駐車場が完成（高さ3m、広さ140坪、収容台数25台。のちに270坪まで拡張）。 1975年（昭和49年） マンションの断熱を考えて屋上を土で覆い、畑作を開始。のちに水田にも。 1989年（平成元年）?スロープを設置。3階まで車が進入可能に。 1994年（平成6年） 道路から部屋を目隠しするため各階に、花壇を備えたテラスの整備を開始。 1998年（平成10年） 4階に嘉農の孫のためプール設置を計画するも、「魚を飼いたい」という孫の意向で池（25坪）に変更。
- #17: ユーザーストーリーの As a ： ～として I wan to : ～したい So that : ～できるように
- #18: 最初はなんじゃコレってちょっと思った。 これのなにがそんなにありがたいのかな？と。 実際すごくありがたいものでもない。 テンプレートがあると人によって記述がばらばらになることが避けられる。 「誰がなにを求めて」っていうのを書かされることによって、それを意識することができる。 かなって思っています。
- #20: 請求書のチェックが先行していないと、支払はできないとか 承認されないと発注できないとか 業務間に依存関係がある以上ストーリー、パッケージ間の依存はあり得る そしてそれは結合テストの元ネタとなる
- #23: 単純な先行関係は一見すると「その順番で作業すればいいんでしょ」と見える。 ただしそこに締めなどの時間的制約などが加わった場合、その実行が簡単では無いかもしれない その結果たとえば通知機能などが必要になるかもしれない
- #25: これが作る物の元ネタとなりテストの元ネタとなる。