INSPIRE FUTURE GENERATIONS
-
Upload
koichi-ito -
Category
Engineering
-
view
2.312 -
download
3
Transcript of INSPIRE FUTURE GENERATIONS
INSPIRE
(株) 永和システムマネジメント アジャイル事業部
Ruby x Agile グループ 伊藤 浩一 (@koic)
2015.01.16 (Fri)(株)永和システムマネジメント Room Right/Left
ありがたい話 公開版
FUTUREGENERATIONS現場リーダーのありがたい話2015
株式会社 永和システムマネジメント アジャイル事業部所属。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
開発を成功させるためには、プログラマーとユーザーが自分たちの不安を認識し、権利と責任を受け入れられる文化 (環境) を創らなければならない。
『エクストリーム・プログラミング実行計画』9ページより抜粋
• 全体の計画でいつ何がどのくらいのコストで達成されたかを知る権利がある。
ユーザーの権利章典• 毎週のプログラミング週から、最も可能な価値を得る権利がある。
• 作業中のシステムの進捗状況、規定した繰り返しテストをパスできていること (作業の証明) を見る権利がある。
• 法外なコストを支払うことなく、自分の考えを変えたり、機能の入れ替え、プライオリティの変更を行う権利がある。
• 予定日を修正しスコープを縮小するために、スケジュールの変更通知を受ける権利がある。いつでもキャンセルすることができ、現在までの投資を反映して機能しているシステムを残してもらうこともできる。
• 何が必要なのか、プライオリティの明確な位置づけを知る権利がある。
プログラマーの権利章典
• 常に質の高い仕事を行う権利がある。
• 援助を要求し、仲間、マネージャ、ユーザーから助けを得る権利がある。
• 自分の見積りを作成し更新する権利がある。
• 責任を割り当てられるのではなく、受容する権利がある。
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
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
!仕様の確認 ! 見積り ! スパイク
ふりかえりやバックログの優先度 付けなどはお客さまにご協力いた だきながら進めていきます。
• だいたい半年前に作った○○機能と同じくらい
• 同じ経験があると強い (それなりに根拠ある信頼)
• 相対的な数値化してユーザーに伝えられる (責任)
• 「これだけのことをやると、○○機能に比べて△△くらいの大きさです」
• もちろん他プロジェクトでの経験も大きな標本
• 最後は開発者の作れそう感 (経験重要)
サンプルの重要性
• メンバーの特徴とプロジェクトの状況をつかむ
• メンバーはできるだけ縦で見る
• 似た機能を作った経験の速度重視か、あまり経験のないないようにフォーカスしたストレッチした成長重視か
• ユーザーの計画を考慮したうえで組み立てる
• 開発者の「おもしろそう」「作ってみたい」もだいじ
フォーメーション
• ユーザーとの会話が分かる (議事録)
• 使ったことのない技術をもちいる (できるだけ地雷は先に踏む)
• 外部チームと連携する (インタフェース設計、異文化交流)
• ユーザーへの提案を行う (フロント業)
• 自分で作れる前提で、あえて手を動かさない (ただし放置はしない)
ストレッチのポイント例
• すごいRubyistだったり、コミュニティの仲間だったり、ネット著名人だったり、From Java to Rubyな同僚だったりさまざま
• 安定したプロジェクト経験者と新しいメンバーで組むのが黄金パターン (オブジェクト指向の設計原則にも『安定に依存せよ』とありますね)
• なんとなく知っていると他人に説明できるのギャップを埋める (アウトプットすることで整理できることも)
新しいメンバーを迎え入れる
• 「開発はうまいことやる」お任せ安心感
• いつ頃に次の作業が出来そうか (透明性)
• いつまでに要件凍結が必要か
• 開発メンバーのやることがないを作らない
• いったことをきちんとやる
アカウンタビリティ
予習復習研究はこちら
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著