INSPIRE

(株) 永和システムマネジメント アジャイル事業部

Ruby x Agile グループ 伊藤 浩一 (@koic)

2015.01.16 (Fri)(株)永和システムマネジメント Room Right/Left

ありがたい話 公開版

FUTUREGENERATIONS現場リーダーのありがたい話2015

満員御礼

対象者•ちょっと未来の@ivezuki •ちょっと過去の@flada_auxv •私と一緒のプロジェクトを経験していないメンバー

自己紹介

株式会社 永和システムマネジメント アジャイル事業部所属。JavaによるWebアプリケーション開発やセミナー講師などを経て、XPとオブジェクト指向をキーワードに2004年より現職。2007年よりRailsを用いた Webアプリケーションの構築に携わり、現在はRubyとアジャイルをキーワードとした4～6人程度の小中規模の受託開発プロジェクトのリーダーを務める。共著書に『Web 2.0ビギナーズバイブル』(絶版) 。最も影響を受けた開発手法は『エクストリーム・プログラミング』。

伊藤 浩一 (@koic)

現場での私のミッション

•アジャイルソフトウェア開発の現場をリードする

•チーム、メンバーを育成する

現場での私のミッション

•アジャイルソフトウェア開発の現場をリードする

•チーム、メンバーを育成する

仲間たち

http://www.slideshare.net/esminc/new-year-2015-agile-div

現場での私のミッション

•アジャイルソフトウェア開発の現場をリードする

•チーム、メンバーを育成する

http://www.esm.co.jp/agile/business_plan_esm_agile_div_35th.pdf

育成担当

@koic @moroプロジェクトリード職 プログラミング職

@koic @moroプロジェクトリード職 プログラミング職

どこを “より” 特化するか

@koic @moroプロジェクトリード職 プログラミング職

今日の話の育成観点

私のミッション

•アジャイルソフトウェア開発の現場をリードする

•チーム、メンバーを育成する

永和現場リーダーとしての私のミッションと実践の話

本日は よろしく

お願いします

文化の形成

おさらい

現場リーダーのお仕事•プロジェクトを進めるにあたるレール上の障害物を退ける

•メンバーとチームの育成

現場リーダーのお仕事•プロジェクトを進めるにあたるレール上の障害物を退ける

•メンバーとチームの育成

プロジェクトデザイン

『Extreme Programming Embrace Change』より

開発を成功させるためには、プログラマーとユーザーが自分たちの不安を認識し、権利と責任を受け入れられる文化 (環境) を創らなければならない。

『エクストリーム・プログラミング実行計画』9ページより抜粋

プログラマーの権利章典

ユーザーの権利章典プロジェクトの両輪

• 全体の計画でいつ何がどのくらいのコストで達成されたかを知る権利がある。

ユーザーの権利章典• 毎週のプログラミング週から、最も可能な価値を得る権利がある。

• 作業中のシステムの進捗状況、規定した繰り返しテストをパスできていること (作業の証明) を見る権利がある。

• 法外なコストを支払うことなく、自分の考えを変えたり、機能の入れ替え、プライオリティの変更を行う権利がある。

• 予定日を修正しスコープを縮小するために、スケジュールの変更通知を受ける権利がある。いつでもキャンセルすることができ、現在までの投資を反映して機能しているシステムを残してもらうこともできる。

• 何が必要なのか、プライオリティの明確な位置づけを知る権利がある。

プログラマーの権利章典

• 常に質の高い仕事を行う権利がある。

• 援助を要求し、仲間、マネージャ、ユーザーから助けを得る権利がある。

• 自分の見積りを作成し更新する権利がある。

• 責任を割り当てられるのではなく、受容する権利がある。

ユーザーとプログラマーの権利を尊重する文化の形成

現場リーダーの仕事

本編

•#1 ソフトウェアの見積り •#2 チームのはなし •#3 チーム開発の意義

お品書き

#1•#1 ソフトウェアの見積り •#2 チームのはなし •#3 チーム開発の意義

お品書き

?なぜ見積るのか？

計画のない プロジェクト

はない

https://ja.wikipedia.org/wiki/プロジェクト

“見積りは 計画を立てるための視点”

ユーザーのための計画

現場リーダーのお仕事•プロジェクト (計画) を進めるにあたるレール上の障害物を退ける

•メンバーとチームの育成

レールから障害物を退けるのがリーダーの仕事

障害物

見積もり !真実8：プロジェクトが大失敗する原因には二つある。一つは見積も 　　　　りミスだ（もう一つはP.110の真実23を参照） !真実9：ソフトウエア開発の見積もりは、プロジェクトの開発時に 　　　　実施する場合が非常に多い。これだと、要求定義が固まる 　　　　前に見積もることになり、どんな問題がどこにあるかを 　　　　理解する以前に予測するので、意味がない。従って、 　　　　見積もり時期として適切ではない。 !真実10：見積もりは、上層部かマーケティングが実施する場合がほと 　　　　んどだ。実際にプログラムを開発したり、開発プロジェクト 　　　　の直接のマネジャが見積もることはない。結局、適切な人が 　　　　見積もっていないのだ。 !真実11：プロジェクトが進むに従って、見積もりを調整することは、 　　　　まずない。従って、不適切な時期に不適切な人間が実施した 　　　　見積もりをが修正することは、ほとんどない。 !

ソフトウェアエンジニアリング

ソフトウェア開発55の真実と10のウソ ロバート・L・グラス

確度の低い見積り

未凍結の仕様割と密接

• 放っておいても狭くはならない

• コーンを狭めるには情報が増えるなど状況変化が必要

不確実性のコーン

見積りできた？

見積りできた？

見積りできた？

いつリリースできるの？

• 見積りの難しさ (途中で変わる/固り切らない状態でゴー)

• 存在していないものは期待にすぎない

• ユーザーインタフェースのあるシステムであれば、ワイヤーフレームによる期待の擦り合わせは有効

• ペーパープロトタイピングはやったことないけど、どうなんでしょうね？ (ある程度で作っちゃうので)

そして厄介な現実

ユーザーも真実欲しいものは分からない (正解があるとは限らない)

でもやるんだよ。だって仕事でしょ？

http://d.hatena.ne.jp/m_seki+b/20101202/p1

要件がどこまで生煮えで手が動くか

ソフトウェア開発の現実

地に足のついた見積りに 必要な能力

プログラミング

“何かをプログラムする時、どの位かかるかを見積るということは完全に技術的な決定である”

エクストリームプログラミング実行計画15ページ

見積りは 開発者の仕事

FAQ. どれくらいでできそうですか？

見積り

プログラミング能力は 十分条件ではなく必要条件

書き読み

プログラミング能力は 十分条件ではなく必要条件

書き読み

見積り

時間という制約の中で 結果を出すのがプロ

1.標本を集める 2.相対値を作る

繰り返してより地に足のついた数に

Copyright (c) 2011 Eiwa System Management, Inc.

イテレーション (1週間) の流れ要求

リリース可能な ソフトウェア Ship It!

次の イテレーションへ

内部リリース

ふりかえり! KPT !ベロシティ

バックログ

タスクプログラミング

"機能 "バグ "データ移行 "ドキュメント "環境構築 "性能 "ジョーカー 受入テストを

書く 受入テストを する

" 完了基準

!TDD ! CI

!仕様の確認 ! 見積り ! スパイク

ふりかえりやバックログの優先度 付けなどはお客さまにご協力いた だきながら進めていきます。

Copyright (c) 2011 Eiwa System Management, Inc.

まわして「見積り続ける」要求

リリース可能な ソフトウェア Ship It!

次の イテレーションへ

内部リリース

ふりかえり! KPT !ベロシティ

バックログ

タスクプログラミング

"機能 "バグ "データ移行 "ドキュメント "環境構築 "性能 "ジョーカー 受入テストを

書く 受入テストを する

" 完了基準

!TDD ! CI

!仕様の確認 ! 見積り ! スパイク

ふりかえりやバックログの優先度 付けなどはお客さまにご協力いた だきながら進めていきます。

• だいたい半年前に作った○○機能と同じくらい

• 同じ経験があると強い (それなりに根拠ある信頼)

• 相対的な数値化してユーザーに伝えられる (責任)

• 「これだけのことをやると、○○機能に比べて△△くらいの大きさです」

• もちろん他プロジェクトでの経験も大きな標本

• 最後は開発者の作れそう感 (経験重要)

サンプルの重要性

• プランニングポーカーを使ったチームでの見積り

• 見積りは設計行為

• 数字の違いにリスクが隠れていることも

開発チームのやれそう感

人間は成長する生き物

だんだんとうまくなる

だんだんとうまくなる

プログラマーもユーザーも

#2•#1 ソフトウェアの見積り •#2 チームのはなし •#3 チーム開発の意義

お品書き

育成担当

@koic @moroプロジェクトリード職 プログラミング職

チームの成長

• 本を読んだだけではプログラミングはできない

• 本を読んだだけではプロジェクトはまわせない

• 実際は知識も大事、経験も大事

• 『巨人の肩の上に立つ』

実践に勝る経験はない

• メンバーの特徴とプロジェクトの状況をつかむ

• メンバーはできるだけ縦で見る

• 似た機能を作った経験の速度重視か、あまり経験のないないようにフォーカスしたストレッチした成長重視か

• ユーザーの計画を考慮したうえで組み立てる

• 開発者の「おもしろそう」「作ってみたい」もだいじ

フォーメーション

弾けないフレーズを弾けるようにするのが練習

オレのB面から

• ユーザーとの会話が分かる (議事録)

• 使ったことのない技術をもちいる (できるだけ地雷は先に踏む)

• 外部チームと連携する (インタフェース設計、異文化交流)

• ユーザーへの提案を行う (フロント業)

• 自分で作れる前提で、あえて手を動かさない (ただし放置はしない)

ストレッチのポイント例

受託開発の持つ性質

仕事要員リスク

チャンス

• 4人以上のチームの場合のサブチームづくり

• Pivotal TrackerでいうEpicの粒度でチームを組む

• 編成として「刺激になりそう」を組み合わせたり

Epicとフォーメーション

刺激を 演出する

誰と重要@beakmark

• すごいRubyistだったり、コミュニティの仲間だったり、ネット著名人だったり、From Java to Rubyな同僚だったりさまざま

• 安定したプロジェクト経験者と新しいメンバーで組むのが黄金パターン (オブジェクト指向の設計原則にも『安定に依存せよ』とありますね)

• なんとなく知っていると他人に説明できるのギャップを埋める (アウトプットすることで整理できることも)

新しいメンバーを迎え入れる

演出の 大前提

• 「開発はうまいことやる」お任せ安心感

• いつ頃に次の作業が出来そうか (透明性)

• いつまでに要件凍結が必要か

• 開発メンバーのやることがないを作らない

• いったことをきちんとやる

アカウンタビリティ

現場での私のミッション

•アジャイルソフトウェア開発の現場をリードする

•チーム、メンバーを育成する

XPTrackerという役割

全体 俯瞰

見積りと 予測可能性

要求ヒアリング 見積り計画づくり

ビジネス検討 実装効果測定 テストリリース

9:1

5:5

ボールの滞在率 (ユーザー:プログラマー)

1:9

9:1

7:3

1:9

1:95:5

プロジェクトの成功とチームの成長のバランスを見る

現場リーダーの心得

現場での私のミッション

•アジャイルソフトウェア開発の現場をリードする

•チーム、メンバーを育成する

#3•#1 ソフトウェアの見積り •#2 チームのはなし •#3 チーム開発の意義

お品書き

チーム開発の意義

何事もひとりでは成し遂げられない

ユーザーとプログラマーの権利を尊重する文化の形成

リーダー業のひとつのゴール

•コミュニケーション

•シンプルさ

•フィードバック

•勇気

•敬意

XPの5つの価値

敬意

業務

○○に 期待

サービス インフラ提供

ご近所さん

この世に同じプロジェクトはふたつない

自分たちのやり方を 自分たちで決めて作って

いける(株)永和システムマネジメント アジャイル事業部 事業部長 木下 史彦 氏

•コミュニケーション

•シンプルさ

•フィードバック

•勇気

•敬意

XPの5つの価値

勇気

•コミュニケーション

•シンプルさ

•フィードバック

•勇気

•敬意

気持ちにかかわるもの

ソフトウェアは 人が人のために 作るもの

―Kenji Hiranabe

INSPIREFUTUREGENERATIONS

いきいきした文化の継承を

予習復習研究はこちら

http://capsctrl.que.jp/kdmsnr/wiki/bliki/

ぶりきじゃ

ソフトウェア見積り 人月の暗黙知を解き明かす

http://www.amazon.co.jp/dp/489100522X

エクストリーム・プログラミング実行計画http://www.amazon.co.jp/dp/4894713411ケント・ベック／マーチン・ファウラー

Matin Flowler’s Blikiの翻訳Wiki

Steve McConnel著