_enog53_kaneko

Size: px

Start display at page:

Download "_enog53_kaneko"

ゆきさかやぬま
5 years ago
Views:

1 スクラム開発に取り組んでみた - ENOG53 Meeting /10/19 Yasuyuki Kaneko

2 はじめに社インフラサービス基盤の運開発 (DevOps) を推進するためスクラムの法を導してみました的資源が極めて限られる地域事業者の中でスクラムに取り組んでみた実例とその所感をお話ししたいと思いますちょっといやだいぶ恥ずかしいのですが 2

3 スクラムとは何か 3

4 すべてのきっかけカイゼンジャーニー市聡啓 / 新井剛著 JANOG 会の平井くんにオススメされて早速購ストーリー仕てでスクラムが学べるめっちゃ熱い!! 4

5 Twitter で感想書いたら著者の市さんからコメントもらいました! ありがとうございます!! 5

6 スクラムとはアジャイルソフトウェア開発法のひとつスプリントと呼ぶ短い開発期間を何度も繰り返すチームメンバーの密なコミュニケーション体感を重視予測不能な変化に対して素早く柔軟に対応することができる 6

アジャイルソフトウェア開発宣私たちはソフトウェア開発の実践あるいは実践を助けをする活動を通じてよりよい開発法をつけだそうとしているこの活動を通して私たちは以下の価値にったプロセスやツールよりも個と対話を包括的なドキュメントよりも動くソフトウェアを契約交渉よりも顧客との協調を計画に従うことよりも変化への対応を価値とするすなわち

7 アジャイルソフトウェア開発宣私たちはソフトウェア開発の実践あるいは実践を助けをする活動を通じてよりよい開発法をつけだそうとしているこの活動を通して私たちは以下の価値にったプロセスやツールよりも個と対話を包括的なドキュメントよりも動くソフトウェアを契約交渉よりも顧客との協調を計画に従うことよりも変化への対応を価値とするすなわち左記のことがらに価値があることを認めながらも私たちは右記のことがらにより価値をおく Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas 2001, 上記の著者たちこの宣はこの注意書きも含めた形で全を含めることを条件に由にコピーしてよい 7

8 アジャイルのマインドセットプロセスやツール < 個と対話包括的なドキュメント < 動くソフトウェア契約交渉 < 顧客との協調計画に従うこと < 変化への対応対話を重視適応的漸進的アプローチ 8

作業環境の継続的な改善を可能にする Developed and sustained by Scrum creators: Ken Schwaber and Jeff

9 スクラムの定義スクラムガイド複雑て変化の激しい問題に対応するためのフレームワークてあり可能な限り価値のいフロタグトを産的かつ創造的に届けるためのものてあるスクラム公式ガイド : ゲームのルール 2017 年 11 月スクラムはこれまてのフロタグト管理や仕事のテクニックの相対的な有効性を明確にしてフロタグトチーム作業環境の継続的な改善を可能にする Developed and sustained by Scrum creators: Ken Schwaber and Jeff Sutherland 日本語版 Japanese 9

Scrum Framework https://commons.wikimedia.

10 Scrum Framework チーム役割イベント作成物ルールを規定 10

11 スクラムに取り組む 11

12 背景となる状況と課題少量多品種産柔軟で親切な運作業が多く完全にシステム化されていない顧客数が増加作業数も増加個別設定調査脆弱性対応障害対応などなど対象の洗い出しや構成情報把握が変そして業務は破綻に向かう台帳の氾濫情報の不整合記録より記憶? 12

13 運開発の取り組み運改善のため業務システムの開発を推進運担当は開発経験がなく常業務に忙殺されているソフトウェアエンジニアを 1 名確保運開発担当に運部隊へのヒアリングからスタート今の運課題を解決するツールシステムを! 軽量システム疎結合がキーワード 13

14 運開発の取り組みもちろんそう簡単にはうまくいかない 14

15 運開発の取り組み何かが違うそもそも運担当が欲しいものを明確にイメージできていない開発側が忖度してシステム実装実物をてダメ出しスケジュール通りに進まない開発者がだけリソースがらない相談相不在でモチベーション維持が困難やるべきことよりやってみたいこと ( 技術的興味 ) に気が向いてしまう 15

16 スクラムで打開しよう! チームを組むことで開発者を孤独にしない短い開発期間でさくとも確実なアウトプットを指す失敗や戻りはある程度織り込み済みで柔軟かつ継続的な開発を志向してみる 16

17 スクラムチームの結成チームメンバーは 3 名 ( もうぼっちじゃないよ!) かねこプロダクトオーナー部統括マネージャーたかつ開発チームメンバー運開発エンジニアさとう開発チームメンバー運担当エンジニアスクラムマスターはいません 17

18 スクラムチームの結成教科書 ( スクラムガイド ) によれば開発チームに最適な数は回りが利く程度に少なく 1 つのスプリントで重要な作業が成し遂げられる程度に多い数であるメンバーが 3 未満の場合は相互作が少なく産性の向上につながらないスキル不が原因でリリース判断可能なインクリメントを届けられない可能性もあるメンバーが 9 を超えた場合は調整の機会が多くなってしまう経験的プロセスが複雑になり有益ではなくなる 18

19 スクラムチームの結成教科書 ( スクラムガイド ) によれば開発チームに最適な数は回りが利く程度に少なく 1 つのスプリントで重要な作業が成し遂げられる程度に多い数である教科書どおりじゃなくても気にしない! メンバーが3 未満の場合は相互作が少なく産性の向上につながらないスキル不が原因でリリース判断可能なインクリメントを届けられない可能性もあるやらないよりやったほうがマシ!! メンバーが 9 を超えた場合は調整の機会が多くなってしまう経験的プロセスが複雑になり有益ではなくなる 19

20 スクラムサイクルの決定スプリント期間は 4 週間少数チームでインクリメントを出せるギリギリの期間と考えた /18 7/13 7/23 8/24 9/3 スプリント 01 スプリント 02 スプリント 03 スプリントプランニングリリーススプリントプランニングリリーススプリントプランニング 20

21 スクラムサイクルの決定スプリント期間前後に 1 週間のインターバルを設定休スプリントプランニングに分な時間を割けるようにスプリントが終了できなかった場合のバッファとしての意図も /18 7/13 7/23 8/24 9/3 スプリント 01 スプリント 02 スプリント 03 スプリントプランニングリリーススプリントプランニングリリーススプリントプランニング 21

22 スクラムの道具基本は Trello カンバンとして利スプリントごとのボードでスプリントバックログと進捗を管理スクラムチームのボードでプロダクトバックログを管理バーンダウンチャートは作っていません々のコミュニケーションはSlackが中スプリントの記録は簡単ににまとめてwikiに残す 22

23 デイリースプリント毎 12 時 00 分から 15 分間のデイリースプリント 15 分きっかりで終わらせるよう昼休み開始 15 分前に予定を固定執務室の打ち合わせコーナーに集合して進捗確認 8:45 12:00 12:15 13:00 17:30 業務時間昼休み業務時間デイリースクラム 15min 23

24 スクラムで開発したプロダクト構成管理 DB サーバ (Linux Windows) ルータスイッチ FW 等管理対象機器 IP アドレス台帳管理構成情報確認変更履歴管理 IP アドレス管理 Ping 疎通確認逆引きホスト名確認状態変化通知構成情報管理構成情報取得指実結果格納 Ansible 実構成情報取得運エンジニア踏み台サーバ 24

25 スクラムで開発したプロダクト IP アドレス台帳様々な機種環境に元的に対応可能サーバ (Linux Windows) ルータスイッチ FW 等脱 Excel 構成管理 DB 管理対象機器運エンジニア IP アドレス管理 IPアドレス台帳管理構成情報確認変更履歴管理変更履歴管理いつ誰が何を変更したか状態変化通知構成情報管理状態変化通知により登録漏れや隠れたミスを検知実機から取得した情報を格納 Ping 疎通確認逆引きホスト名確認構成情報取得指実結果格納実機の情報は常に正しい踏み台サーバ Ansible 実構成情報取得エージェントレスで実現再利性がい仕組み 25

26 スプリント 01 のインクリメント IP アドレス台帳社外 IP アドレスの取り込み構成管理 DB 管理対象機器 IP アドレス台帳管理構成情報確認変更履歴管理 IP アドレス管理 Ping 疎通確認逆引きホスト名確認状態変更通知構成情報管理構成情報取得指実結果格納 Ansible 実構成情報取得運エンジニア個別の接続式認証式に対応踏み台サーバネットワーク機器の情報取得に対応 26

27 スプリント 02 のインクリメント IP アドレス台帳構成管理 DB 管理対象機器 IP アドレス台帳管理構成情報確認変更履歴管理 IP アドレス管理 Ping 疎通確認逆引きホスト名確認状態変更通知構成情報管理構成情報取得指実結果格納 Ansible 実構成情報取得運エンジニア U/I 直し検索機能強化運者がより使いやすくわかりやすく踏み台サーバサーバ情報取得機能強化真に必要な情報を能動的に取得 27

28 スプリント 03 のインクリメント IP アドレス台帳プライベート IP アドレスの取り込み管理移管 Excel 台帳は廃に! 構成管理 DB 管理対象機器 IP アドレス台帳管理構成情報確認変更履歴管理 IP アドレス管理 Ping 疎通確認逆引きホスト名確認状態変更通知構成情報管理構成情報取得指実結果格納 Ansible 実構成情報取得運エンジニアネットワーク機器情報取得機能の強化踏み台サーバファイアウォール等対象機種追加 28

29 スプリント 01 振り返りそもそもにしてスクラムをはじめてよかったスクラムは良かったいつでも相談できるし軌道修正できるスクラムをやったこと体は良かった標と期限が明確になるスクラムやってよかった! ゴールを明確にしよう! デイリースクラムは徐々に集中が落ちてきた進捗管理もくなったやっている間に到達点がぼやけてくるので繰り返し意図的に確認したほうがいいゴールの認識合わせをもうちょっとしっかりやりたいみんながを動かそう! 津だけでなくや佐藤もを動かせるようになれば津に任せっきりだったもっと伝えることはないだろうかリリース後の状況確認も必要使われているのか? 追加要望は? 運課のフィードバックがうまく取れていなかったより活してもらえるための仕掛け作りもっとユーザと会話を! 29

30 スプリント 02 振り返り最初のスプリントプランニングが重要ゴールをしっかり固めてからスプリントにるべきプランニングがかった! 最初のスプリントプランニングでしっかり決めきれなかったのが反省デイリースクラムは 15 分で収まらないも多かったがコミュニケーションでうまく機能したたくさん会話したね! 前回は津に開発をお任せだったが今回は佐藤もを動かすことができたのが良かったスキルにあった作業分担が出来ていたと思う分は製造に集中することができたみんながを動かせたよ! 運課との調整コミュニケーションフィードバックループにはまだ改善の余地がある台帳類の整理運がどう変わるかなど周りを巻き込んでの準備がりてなかったように思うまかな機能はリリースできているが細かい使い勝やU/Iまでがき届いていないもっともっとユーザと会話を! 開発した成果物に対してドキュメントが残っていないのが課題 30

31 スプリント 03 振り返り今回は無事 4 週間のスプリント期間を守ることができたプランニング勝利! 当初から4 週間を意識して作業ボリュームを抑えめにしたゴール設定が功奏した細かい部分での割り切りは較的はっきりできたと思うコミュニケーションにまだ課題がある! デイリースクラムを15 分に収められた回が較的多かったデイリーの中で確認した事を作業中に迷って再度確認するような場があったデイリー以外でのコミュニケーションがらなかったもっと丁寧に受け渡しを終盤の実計画がい! 後半レビューが遅れ気になる部分を相談することが難しかった終盤のスケジュール管理 ( リリース前後で何をやるか ) が毎回雑なのを改善したい終盤は別件障害にを取られてスクラムに貢献ができなかったのは申し訳ない途中障害対応でほとんど何もできなくなったのが無念別件業務でが取られてしまった! 31

32 今後のスプリント予定現在はスプリント 04 が進中今回は構成管理 DB とは別のテーマに取り組み中その内容はまた別の機会があればお話しするかも? 構成管理 DB もさらなる進化を検討中他のシステムツールとの連携 ( 顧客管理監視システム等 ) 機器設定情報の動収集保存機能各種設定の括投機能 32

33 スクラムのススメ 33

34 やってみてわかったことスクラムの真髄はコミュニケーション!? スプリント期間中は必ず毎顔を合わせて話すことになるそれだけでチームとプロダクトに良い影響が出るすぐに相談すぐに確認すぐに軌道修正チームの相互理解熟成度が上がる 34

35 やってみてわかったことスクラムはスプリント ( 短距離 )!? 短い期間で明確な標に向かって前のゴールに向け全でり切るたくさん話してたくさん考えるめっちゃ疲れるけど達成感も半端ない!! 35

36 やってみてわかったことスクラムは継続的改善!? 継続的な問題発と解決のフレームワークプロダクトだけでなく業務プロセスも継続的に改善問題を発しやすい発したらすぐ取りかかれるアジャイルなマインドセットで!! 36

37 私からのメッセージ騙されたと思ってスクラムやってみよう! どんな形であれやれば得るものがあるはず弊社はまだまだ不完全もっと進化させたいみなさんの経験もぜひ教えてください!! 37

38 みなさんもぜひ!! カイゼンジャーニー市聡啓 / 新井剛著改めて本当にいい本なのでぜひ読んで! 越境を指し楽しい旅を!! 38

39 Thank you!! Special Thanks: いらすとや 39

<4D F736F F F696E74202D208A4A94AD82C6895E977082F082C282C882AE B8DC C E >

<4D F736F F F696E74202D208A4A94AD82C6895E977082F082C282C882AE B8DC C E > 開発と運用をつなぐアジャイル最新トレンド ~ アジャイルを誤解していませんか? ~ 会社紹介会社名本社設立資本金代表者事業内容株式会社テクノロジックアート (Technologic Arts Incorporated) 東京都文京区小石川 1-28-3 NIS 小石川ビル 2 階 1989 年 12 月 5 日 39,980,000 円代表取締役長瀬嘉秀コンサルティング ( アジャイル開発