INSPIRE FUTURE GENERATIONS

1. INSPIRE (株) 永和システムマネジメントアジャイル事業部 Ruby x Agile グループ伊藤浩一 (@koic) 2015.01.16 (Fri) (株)永和システムマネジメント Room Right/Left ありがたい話公開版 FUTURE GENERATIONS 現場リーダーのありがたい話2015

2. 満員御礼

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

4. 自己紹介

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

6. 現場での私のミッション •アジャイルソフトウェア開発の現場をリードする •チーム、メンバーを育成する

8. 仲間たち

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

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

12. 育成担当 @koic @moro プロジェクトリード職プログラミング職

13. @koic @moro プロジェクトリード職プログラミング職どこをより特化するか

14. @koic @moro プロジェクトリード職プログラミング職今日の話の育成観点

15. 私のミッション •アジャイルソフトウェア開発の現場をリードする •チーム、メンバーを育成する

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

17. 本日はよろしくお願いします

18. 文化の形成おさらい

19. 現場リーダーのお仕事 •プロジェクトを進めるにあたるレール上の障害物を退ける •メンバーとチームの育成

20. 現場リーダーのお仕事 •プロジェクトを進めるにあたるレール上の障害物を退ける •メンバーとチームの育成プロジェクトデザイン

21. 『Extreme Programming Embrace Change』より

22. 開発を成功させるためには、プログラマーとユーザーが自分たちの不安を認識し、権利と責任を受け入れられる文化 (環境) を創らなければならない。『エクストリーム・プログラミング実行計画』9ページより抜粋

23. プログラマーの権利章典ユーザーの権利章典プロジェクトの両輪

24. • 全体の計画でいつ何がどのくらいのコストで達成されたかを知る権利がある。ユーザーの権利章典 • 毎週のプログラミング週から、最も可能な価値を得る権利がある。 • 作業中のシステムの進状況、規定した繰り返しテストをパスできていること (作業の証明) を見る権利がある。 • 法外なコストを支払うことなく、自分の考えを変えたり、機能の入れ替え、プライオリティの変更を行う権利がある。 • 予定日を修正しスコープを縮小するために、スケジュールの変更通知を受ける権利がある。いつでもキャンセルすることができ、現在までの投資を反映して機能しているシステムを残してもらうこともできる。

25. • 何が必要なのか、プライオリティの明確な位置づけを知る権利がある。プログラマーの権利章典 • 常に質の高い仕事を行う権利がある。 • 援助を要求し、仲間、マネージャ、ユーザーから助けを得る権利がある。 • 自分の見積りを作成し更新する権利がある。 • 責任を割り当てられるのではなく、受容する権利がある。

26. ユーザーとプログラマーの権利を尊重する文化の形成現場リーダーの仕事

27. 本編

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

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

30. ?なぜ見積るのか？

31. 計画のないプロジェクトはない

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

33. 見積りは計画を立てるための視点

34. ユーザーのための計画

35. 現場リーダーのお仕事 •プロジェクト (計画) を進めるにあたるレール上の障害物を退ける •メンバーとチームの育成

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

37. 障害物

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

39. 確度の低い見積り未凍結の仕様割と密接

40. • 放っておいても狭くはならない • コーンを狭めるには情報が増えるなど状況変化が必要不確実性のコーン

41. 見積りできた？見積りできた？見積りできた？いつリリースできるの？

42. • 見積りの難しさ (途中で変わる/固り切らない状態でゴー) • 存在していないものは期待にすぎない • ユーザーインタフェースのあるシステムであれば、ワイヤーフレームによる期待の擦り合わせは有効 • ペーパープロトタイピングはやったことないけど、どうなんでしょうね？ (ある程度で作っちゃうので) そして厄介な現実ユーザーも真実欲しいものは分からない (正解があるとは限らない)

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

44. 要件がどこまで生煮えで手が動くかソフトウェア開発の現実

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

46. プログラミング

47. 何かをプログラムする時、どの位かかるかを見積るということは完全に技術的な決定であるエクストリームプログラミング実行計画15ページ

48. 見積りは開発者の仕事 FAQ. どれくらいでできそうですか？

49. 見積りプログラミング能力は十分条件ではなく必要条件書き読み

50. プログラミング能力は十分条件ではなく必要条件書き読み見積り時間という制約の中で結果を出すのがプロ

51. 1.標本を集める 2.相対値を作る繰り返してより地に足のついた数に

52. Copyright (c) 2011 Eiwa System Management, Inc. イテレーション (1週間) の流れ要求リリース可能なソフトウェア Ship It! 次のイテレーションへ内部リリースふりかえり ! KPT !ベロシティバックログタスクプログラミング "機能 "バグ "データ移行 "ドキュメント "環境構築 "性能 "ジョーカー受入テストを書く受入テストをする " 完了基準 ! TDD ! CI ! 仕様の確認 ! 見積り ! スパイクふりかえりやバックログの優先度付けなどはお客さまにご協力いただきながら進めていきます。

53. Copyright (c) 2011 Eiwa System Management, Inc. まわして「見積り続ける」要求リリース可能なソフトウェア Ship It! 次のイテレーションへ内部リリースふりかえり ! KPT !ベロシティバックログタスクプログラミング "機能 "バグ "データ移行 "ドキュメント "環境構築 "性能 "ジョーカー受入テストを書く受入テストをする " 完了基準 ! TDD ! CI ! 仕様の確認 ! 見積り ! スパイクふりかえりやバックログの優先度付けなどはお客さまにご協力いただきながら進めていきます。

54. • だいたい半年前に作った○○機能と同じくらい • 同じ経験があると強い (それなりに根拠ある信頼) • 相対的な数値化してユーザーに伝えられる (責任) • 「これだけのことをやると、○○機能に比べて△△ くらいの大きさです」 • もちろん他プロジェクトでの経験も大きな標本 • 最後は開発者の作れそう感 (経験重要) サンプルの重要性

55. • プランニングポーカーを使ったチームでの見積り • 見積りは設計行為 • 数字の違いにリスクが隠れていることも開発チームのやれそう感

56. 人間は成長する生き物

57. だんだんとうまくなる

58. だんだんとうまくなるプログラマーもユーザーも

60. 育成担当 @koic @moro プロジェクトリード職プログラミング職

61. チームの成長

62. • 本を読んだだけではプログラミングはできない • 本を読んだだけではプロジェクトはまわせない • 実際は知識も大事、経験も大事 • 『巨人の肩の上に立つ』実践に勝る経験はない

63. • メンバーの特徴とプロジェクトの状況をつかむ • メンバーはできるだけ縦で見る • 似た機能を作った経験の速度重視か、あまり経験のないないようにフォーカスしたストレッチした成長重視か • ユーザーの計画を考慮したうえで組み立てる • 開発者の「おもしろそう」「作ってみたい」もだいじフォーメーション

64. 弾けないフレーズを弾けるようにするのが練習オレのB面から

65. • ユーザーとの会話が分かる (議事録) • 使ったことのない技術をもちいる (できるだけ地雷は先に踏む) • 外部チームと連携する (インタフェース設計、異文化交流) • ユーザーへの提案を行う (フロント業) • 自分で作れる前提で、あえて手を動かさない (ただし放置はしない) ストレッチのポイント例

66. 受託開発の持つ性質仕事要員リスクチャンス

67. • 4人以上のチームの場合のサブチームづくり • Pivotal TrackerでいうEpicの粒度でチームを組む • 編成として「刺激になりそう」を組み合わせたり Epicとフォーメーション

68. 刺激を演出する

69. 誰と重要 @beakmark

70. • すごいRubyistだったり、コミュニティの仲間だったり、ネット著名人だったり、From Java to Rubyな同僚だったりさまざま • 安定したプロジェクト経験者と新しいメンバーで組むのが黄金パターン (オブジェクト指向の設計原則にも『安定に依存せよ』とありますね) • なんとなく知っていると他人に説明できるのギャップを埋める (アウトプットすることで整理できることも) 新しいメンバーを迎え入れる

71. 演出の大前提

72. • 「開発はうまいことやる」お任せ安心感 • いつ頃に次の作業が出来そうか (透明性) • いつまでに要件凍結が必要か • 開発メンバーのやることがないを作らない • いったことをきちんとやるアカウンタビリティ

74. XP Tracker という役割

75. 全体俯瞰

76. 見積りと予測可能性

77. 要求ヒアリング見積り計画づくりビジネス検討実装効果測定テストリリース 9:1 5:5 ボールの滞在率 (ユーザー:プログラマー) 1:9 9:1 7:3 1:9 1:9 5:5

78. プロジェクトの成功とチームの成長のバランスを見る現場リーダーの心得

81. チーム開発の意義

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

83. ユーザーとプログラマーの権利を尊重する文化の形成リーダー業のひとつのゴール

84. • コミュニケーション • シンプル • フィードバック • 勇気 • 敬意 XPの5つの価値

85. 敬意

86. 業務 ○○に期待サービスインフラ提供ご近所さん

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

88. 自分たちのやり方を自分たちで決めて作っていける(株)永和システムマネジメントアジャイル事業部事業部長木下史彦氏

89. • コミュニケーション • シンプル • フィードバック • 勇気 • 敬意 XPの5つの価値

90. 勇気

91. • コミュニケーション • シンプル • フィードバック • 勇気 • 敬意気持ちにかかわるもの

92. ソフトウェアは人が人のために作るもの ―Kenji Hiranabe

93. INSPIRE FUTURE GENERATIONS いきいきした文化の継承を

94. 予習復習研究はこちら 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著

INSPIRE FUTURE GENERATIONS

Koichi ITO

Views

Actions

Embeds 0

Report content

Transcript