Download to read offline
More Related Content
![[ダウンロード推奨]OOW2017 and Javaone2017 report Daisuke Nishino(Sompo Systems)](https://cdn.slidesharecdn.com/ss_thumbnails/oowandjavaone2017reportsompo-171103140305-thumbnail.jpg?width=640&height=640&fit=bounds)
INSPIRE FUTURE GENERATIONS
- 1. INSPIRE (株) 永和システムマネジメント アジャイル事業部 Ruby xAgile グループ 伊藤 浩一 (@koic) 2015.01.16 (Fri) (株)永和システムマネジメント Room Right/Left ありがたい話 公開版 FUTURE GENERATIONS 現場リーダーのありがたい話2015
- 2.
- 6.
- 7.
- 8. 株式会社 永和システムマネジメント アジャイル事業部 所属。JavaによるWebアプリケーション開発やセミナー 講師などを経て、XPとオブジェクト指向をキーワード に2004年より現職。2007年よりRailsを用いたWeb アプリケーションの構築に携わり、現在はRubyとアジャ イルをキーワードとした4∼6人程度の小中規模の受託 開発プロジェクトのリーダーを務める。共著書に 『Web 2.0ビギナーズバイブル』(絶版) 。最も影響を 受けた開発手法は『エクストリーム・プログラミング』。 伊藤 浩一 (@koic)
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24. 『Extreme Programming EmbraceChange』より
- 26.
- 27.
- 28. • 全体の計画でいつ何がどのくらいのコストで達成されたかを知る 権利がある。 ユーザーの権利章典 • 毎週のプログラミング週から、最も可能な価値を得る権利がある。 •作業中のシステムの進 状況、規定した繰り返しテストをパスで きていること (作業の証明) を見る権利がある。 • 法外なコストを支払うことなく、自分の考えを変えたり、機能の 入れ替え、プライオリティの変更を行う権利がある。 • 予定日を修正しスコープを縮小するために、スケジュールの変更 通知を受ける権利がある。いつでもキャンセルすることができ、 現在までの投資を反映して機能しているシステムを残してもらう こともできる。
- 29. • 何が必要なのか、プライオリティの明確な位置づけを知る権利が ある。 プログラマーの権利章典 • 常に質の高い仕事を行う権利がある。 •援助を要求し、仲間、マネージャ、ユーザーから助けを得る権利 がある。 • 自分の見積りを作成し更新する権利がある。 • 責任を割り当てられるのではなく、受容する権利がある。
- 30.
- 31.
- 32. •#1 ソフトウェアの見積り •#2 チームのはなし •#3チーム開発の意義 お品書き
- 33. #1 •#1 ソフトウェアの見積り •#2 チームのはなし •#3チーム開発の意義 お品書き
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46. • 見積りの難しさ (途中で変わる/固り切らない状態でゴー) •存在していないものは期待にすぎない • ユーザーインタフェースのあるシステムであれば、ワイ ヤーフレームによる期待の擦り合わせは有効 • ペーパープロトタイピングはやったことないけど、ど うなんでしょうね？ (ある程度で作っちゃうので) そして厄介な現実 ユーザーも真実欲しいものは分からない (正解があるとは限らない)
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56. Copyright (c) 2011Eiwa System Management, Inc. イテレーション (1週間) の流れ 要求 リリース可能な ソフトウェア Ship It! 次の イテレーションへ 内部リリース ふりかえり ! KPT !ベロシティ バックログ タスク プログラミング "機能 "バグ "データ移行 "ドキュメント "環境構築 "性能 "ジョーカー 受入テストを 書く 受入テストを する " 完了基準 ! TDD ! CI ! 仕様の確認 ! 見積り ! スパイク ふりかえりやバックログの優先度 付けなどはお客さまにご協力いた だきながら進めていきます。
- 57. Copyright (c) 2011Eiwa System Management, Inc. まわして「見積り続ける」 要求 リリース可能な ソフトウェア Ship It! 次の イテレーションへ 内部リリース ふりかえり ! KPT !ベロシティ バックログ タスク プログラミング "機能 "バグ "データ移行 "ドキュメント "環境構築 "性能 "ジョーカー 受入テストを 書く 受入テストを する " 完了基準 ! TDD ! CI ! 仕様の確認 ! 見積り ! スパイク ふりかえりやバックログの優先度 付けなどはお客さまにご協力いた だきながら進めていきます。
- 58. • だいたい半年前に作った○○機能と同じくらい • 同じ経験があると強い(それなりに根拠ある信頼) • 相対的な数値化してユーザーに伝えられる (責任) • 「これだけのことをやると、○○機能に比べて△△ くらいの大きさです」 • もちろん他プロジェクトでの経験も大きな標本 • 最後は開発者の作れそう感 (経験重要) サンプルの重要性
- 59. • プランニングポーカーを使ったチームでの見積り • 見積りは設計行為 •数字の違いにリスクが隠れていることも 開発チームのやれそう感
- 60.
- 61.
- 62.
- 63. #2 •#1 ソフトウェアの見積り •#2 チームのはなし •#3チーム開発の意義 お品書き
- 64.
- 65.
- 66. • 本を読んだだけではプログラミングはできない • 本を読んだだけではプロジェクトはまわせない •実際は知識も大事、経験も大事 • 『巨人の肩の上に立つ』 実践に勝る経験はない
- 67. • メンバーの特徴とプロジェクトの状況をつかむ • メンバーはできるだけ縦で見る •似た機能を作った経験の速度重視か、あまり経験のない ないようにフォーカスしたストレッチした成長重視か • ユーザーの計画を考慮したうえで組み立てる • 開発者の「おもしろそう」「作ってみたい」もだいじ フォーメーション
- 68.
- 69. • ユーザーとの会話が分かる (議事録) •使ったことのない技術をもちいる (できるだけ地雷は先に 踏む) • 外部チームと連携する (インタフェース設計、異文化交 流) • ユーザーへの提案を行う (フロント業) • 自分で作れる前提で、あえて手を動かさない (ただし放置 はしない) ストレッチのポイント例
- 70.
- 71. • 4人以上のチームの場合のサブチームづくり • PivotalTrackerでいうEpicの粒度でチームを組む • 編成として「刺激になりそう」を組み合わせたり Epicとフォーメーション
- 72.
- 73.
- 74. • すごいRubyistだったり、コミュニティの仲間だったり、 ネット著名人だったり、From Javato Rubyな同僚 だったりさまざま • 安定したプロジェクト経験者と新しいメンバーで組むのが 黄金パターン (オブジェクト指向の設計原則にも『安定 に依存せよ』とありますね) • なんとなく知っていると他人に説明できるのギャップを 埋める (アウトプットすることで整理できることも) 新しいメンバーを迎え入れる
- 75.
- 76. • 「開発はうまいことやる」お任せ安心感 • いつ頃に次の作業が出来そうか(透明性) • いつまでに要件凍結が必要か • 開発メンバーのやることがないを作らない • いったことをきちんとやる アカウンタビリティ
- 77.
- 78.
- 79.
- 80.
- 81. 要求ヒアリング 見積り 計画づくり ビジネス検討 実装 効果測定 テストリリース 9:1 5:5 ボールの滞在率(ユーザー:プログラマー) 1:9 9:1 7:3 1:9 1:9 5:5
- 82.
- 83.
- 84. #3 •#1 ソフトウェアの見積り •#2 チームのはなし •#3チーム開発の意義 お品書き
- 85.
- 86.
- 87.
- 88. • コミュニケーション • シンプルさ •フィードバック • 勇気 • 敬意 XPの5つの価値
- 89.
- 90.
- 91.
- 92.
- 93. • コミュニケーション • シンプルさ •フィードバック • 勇気 • 敬意 XPの5つの価値
- 94.
- 95. • コミュニケーション • シンプルさ •フィードバック • 勇気 • 敬意 気持ちにかかわるもの
- 96.
- 97.
- 99.