第２回 すくすく・スクラム

すくすく・スクラム第２回

セントラルソフト株式会社

林　栄一

2009/05/28

クリエイティブな仕事したい人？

自己紹介所属：セントラルソフト株式会社　課長趣味はピアノ、ジェンベ、作曲、たまにライブ。PMとかアーキテクトとか、教育制度のプランニング、運営とか前職では楽器メーカーで電子楽器の開発オブジェクト大好き、モノ作り大好き認定スクラムマスタードラムサークルファシリテーター協会メンバーＮＬＰ認定プラクティショナー

トロント　アジャイル２００８

Thanksチームの皆へ送り出してくれた人達へ今日聞いてくれた人達へ

トム・ポッペンディック

ヘンリック・クニーベルグ

EM ZERO　VOL2

今日やること

•ウォータフォールVSアジャイル•グループワーク•スクラムの概要•スクラムの適用概要•開発者兼経営者　ミルズさん講演•Q＆A、グループワーク

グループ分け

•自己紹介•一人１分づつ

ウォーターフォールvsアジャイル

滝　vs　いきいき

ウォーターフォール

ウォーターフォール

市場 ビジネス IT

市場分析 発注

納品リリース

３ヶ月から３年

平鍋さんの資料から転載、一部修正

ウォーターフォール

フィードバックの欠落したウォーターフォール・モデルが広まったのは防衛用ソフトウェア開発に関する仕様を定めた米国防総省の規格書（1985年6月）がきっかけだとされる。

これをベースに英国のJSP-188、フランスのGAM-T-17、ドイツのVモデルなどが作成されている。

しかし、これらの標準に基づいて推進されたソフトウェア開発プロジェクトが失敗を重ねたことから、米国防総省は1994年12月に反復型開発を推奨する「MIL-STD-498」定めている。　（wikipedia）

非ウォーターフォール

開発単位：大

上流工程ですべてを見通せる

各工程は一発勝負（実際は、手戻りによるやりなおし多発）

開発単位：小

上流工程ではもれがあるだろう

各行程をやりなおせる

ウォーターフォール 非ウォーターフォール

アジャイル

機能A

機能B

機能C

開発 サービス

開発 サービス

サービス開発

時間軸:　１週間～１ヶ月単位のリリースを繰り返す

機能軸　　重要機能から積み上げる

R1 R2 R3

反復(Iterative)インクリメンタル(Incremental)

平鍋さんの資料から転載、一部修正

アジャイル

市場

IT１週間から1ヶ月

ビジネス

市場

ビジネスとITが一体になった「OneTeam」を作り、ミッションとリスクを共有する。やってみて、結果から戦略を作りながら進む。

チーム主動型

平鍋さんの資料から転載、一部修正

みなさんの現場の課題？

•ペアでシェア•テーマ：•開発現場で困っていること、こうしたいと思っていること。

•一人２分ずつ話します•聞いている人はちゃちゃを入れない

•グループ内で発表しながら模造紙の左半分に記入

KeepProblemTry

のPだけやってみましょう

スクラム概要

スクラムとは 日本の製造業の製品開発手法をソフトウエア開発に応用した方法論

最初のスクラムは１９９３年 繰り返し型開発手法 重要なものから作って使ってもらう 使ってもらって優先順位を区切りごとにメンテ 推進する役割をスクラムマスターという

スクラムの役割• スクラムチーム　開発を行うチーム。　スプリントにコミットする。

• スクラムマスター　外部との折衝、チームを雑音から守る　ミーティングをファシリテートする。　指示型→促進型　スクラム推進のキーパーソン

• プロダクトオーナー　業務の視点で、ＲＯＩ（費用対効果）　からプロダクトバックログの優先順位を　管理する。　総責任者

•デイリースクラム•毎日定時に15分間のミーティング、朝会

•スプリント•2週間～４週間の繰り返し。開発単位。•スプリント計画で決めた機能を開発

•スプリントバックログ•スプリント（イテレーション）で•実現する作業リスト

•プロダクトバックログ•業務視点で優先順位付けされた機能リスト

•スプリント計画ミーティング•スプリントバックログを作成するミーティング

•スプリントレビュー•スプリントの終了時に行うデモと振り返り

スクラムのプロセス

スクラムの基礎となる価値

自己組織化

予測型　⇒　実測駆動

問題の原因はプロセスや技術ではなく人間に依存する

スクラムのポイント実測駆動管理と制御プロセスからなる振り返りと調整のループ２～４週間ごとの納品原理は単純一種の管理しない管理個人ではなくチームとしての生産性を高めるチームに責任と権限

（ちなみに）従来の管理方法

リーダーは部下の管理と監視が役割− 指示を出して結果を確認− 部下の選択を承認する権限を維持する− 部下が使えるリソースと情報を制限する

顧客ではなく、作業者の管理によって、作業が決まる。

タスクごとの担当、期間

プロダクトバックログ（機能リスト）

スプリントバックログ（タスクリスト）

タスクカンバン

バーンダウンチャート　

スクラム適用

２つのプロジェクト

プロトタイプシステムの開発をとおして、システム開発と同時にシステム開発手法を作る。

− 業務システムを開発する＝>開発プロジェクト

− 開発方式を開発する＝>メタプロジェクト

開発プロジェクトゴール

担当が使いやすく、使いたくなる 担当から仕様アイディアを誘発する 利用が増える 内部調整がスムーズに行える

メタプロジェクトゴール 引継ぎ可能な必要十分なドキュメント方式 重要なものから早期にリリースするアジャイル方式からビジネス効率化可能性を高める

お客様の環境に適合したアジャイル開発手法を適切に適用するプロジェクト運営方式を作りあげる。− 各種規約、運営方針、運営ノウハウ− ワークショップ資料− 基礎理論資料

プロジェクト体制

プロジェクトの進め方

プロジェクト全体像

達成したい目標を挙げてください目標の詳細を明らかにしてください

スケジュール（３ヶ月間）スクラムマスター：林

スクラムマスターをBさんにス

イッチ

スクラムマスターを林がコーチ

ユーザー部門− 責任者：１名− 現場ご担当

開発− プロダクトオーナー：A− スクラムマスター　林 →　B− チームメンバー：

お客様会社:２名 セントラルソフト：３名

− スクラムコーチ：林（認定スクラムマスター）

プロジェクト体制（敬称略）

• TDD（テスト駆動開発、自動テスト）• CI（継続的統合、毎日二回の最新ビルドと自動テスト）• ペアプログラミング• 朝会（デイリースクラム）• スプリントプランニング• プランニングポーカー• タスク分割

• タスクカンバン• TRACによる、タスク管理、ドキュメント管理• バーンダウンチャート• 振り返り

開発で行ったプラクティス

次ぎはミルズさんのご講演です！

みなさんの現場の課題？

•グループで先ほどの課題の解決策を考えてみましょう。•アジャイルをつかってもいいしつかわなくてもかまいません。

•使える考え方はなかったか考えてみましょう。

•グループ内で検討しながら模造紙の右半分に記入してください。

KeepProblemTry

のTをやってみましょう

リーダーの人はスクラムマスターになったつもりでグループをファシリテー

トしてみてください。

グループごとに発表

おつかれさまでした！