ぬか床

思考と趣味と、たまにIT。

ダメダメScrum開発をどこまでテコ入れしたらいいのか

備忘 開発手法

概要

タイトルの通りです。
支援先プロジェクトでScrumを実験導入していたのですが、いかしてない箇所がたくさんあったので、最低限のテコ入れをしました。 (プロジェクト自体が収束に向かっていたので、あまり大きなテコ入れをするのは現実的ではなかったため)
テコ入れしたプロジェクトでは開発チームメンバーとして参画してます。

やったこと

開発の状況

複数の開発対象のうち1つの部品の開発をScrum手法で回していました。
いかしてない点はいくつかありますが、メインは下記3点です。

  1. Scrum開発手法に乗っ取ってプロダクトが作成されていない
    • Scrum開発手法を学習した(有識者から学んだ)メンバーが1人もいない
    • バックログの粒度がバラバラで進捗が管理できていない
  2. 課題が見えない
    • KPTを出しているが放置されている
    • Excelに書き起こしているが、Sprint終了時にしか見直しされていない
    • タスク遅延がSprintの終わりの報告の時まで判明してない（一部のメンバーを除いて、他全員が認知していない）
  3. そもそもプロダクトバックログが無い

テコ入れ

1. Scrum開発手法に乗っ取ってプロダクトが作成されていない

  • Scrumマスター含む数名をScrumの研修受講＋開発メンバー全員にScrum開発手法の簡易勉強会を実施
    自身の上司と、支援先の上司にお願いして研修を受講しました。研修については以下の記事をご覧ください。
    nuka-duke.hatenablog.com

  • バックログの書き方のルール化
    バックログを機能レベルで書くようにして、粒度を統一しましました。
    また、CI/CD導入後はエラーのバックログもガンガン書かれるように、前もってこちらについても記述ルールを作成しました。

2. 課題が見えない

  • KPTの管理方法の変更
    元々Sprintの都度にExcelファイルを作成していたので、全てを1つのExcelにまとめてそこで管理することにしました。
    それにより、過去のKPTも見直せる(状況の改善状況の見える化)ようになりました。

本当は壁にKPT用の用紙を貼りたかったのですが、部屋の都合上ファイルサーバに置く形になってしまったので、個々人が常に確認していたかは微妙でしたが。。
あとKPT管理用のおすすめのツール(できればWebアプリ)が見つからなかったので泣く泣くExcelを使用しました。何かおすすめあったらだれか教えてください。。。

  • デイリースクラムの導入
    今まで日時報告をMattermost上で行っていましたが、「定型でMattermost投稿＋デイリースクラムで顔合わせ報告」の形式に変更しました。
    全員が顔合わせするので、課題や遅延等の報告と相談が即時に行える環境を作ることができました。
    (そもそもScrumは誰とでも即座に情報共有ができるのが重要)

3. そもそもプロダクトバックログが無い

  • プロジェクトの偉い人へバックログの作成お手伝いのお願い
    このプロジェクトの特性上、プロダクトオーナーがいなかったため、下記の通り変則ルールで作業を行いました。

  • 外部の人へのUXレビュー依頼
    プロジェクト関係者で開発メンバー外の人へのUXレビューを依頼しました。

振り返り

すでにプロジェクト自体が収束に向かっていたため、大きなテコ入れはできませんでしたが、最低限のルール整備のみで安定したSprintを回せるようにはなりました。
心残りとしては、各種管理ツールが継ぎ足し＆継ぎ足ししたため、連携をとったりできず二重管理になった部分がいくつかあったことです。
もし次に早い段階でScrum開発に入れた場合は、プロジェクトの特性に合わせてツール選び・ルール整備を行ってみたいです。

認定スクラムマスターになった話

資格 開発手法

昨年の11月に認定スクラムマスター(CSM)になりました。
資格取得からもうすぐ1年経つので健忘を防ぐため当時のことをメモ。

認定スクラムマスターとは

Scrum Allianceが認定している、スクラムマスターの資格です。下のページを見ていただいたほうが早い気がします。 www.scrumalliance.org
この資格を取るためには、Scrum Allianceの認定スクラムマスター研修を受けた後、Web試験に合格する必要があります。

研修の受講

会社のお金で受けました。20万円くらいしますからね。。
講師はJames Coplienさん、川口恭伸さんのお二方。
川口さんにつきましては、研修受講する半年前に「ユーザーストーリーマッピング」を読んでいたので、うわ～～仕事で読んでる本書いてる人だ～～ってミーハーな気持ちになりました。

ユーザーストーリーマッピング

ユーザーストーリーマッピング

講義はすべて英語で行われますが、同時通訳有りでしたので内容理解には特に問題はなかったです。
でも英語できるとワークショップとかもっと楽しめたんじゃないかなあと思いました。度胸だけではカバーしきれないですからね、語学力は大事。
元々Scrumを自己流に崩した開発プロセスを行っているプロジェクトに参画していたり、研修前に書籍で勉強をしていたので内容そのものに目新しさはありませんでしたが、自身が課題に感じていることや周りの人を通じたQAが聞けたのが非常に良かったと思います。

Web試験

内容そのものよりも、めちゃくちゃな日本語訳の問題文に苦しめられました。
時間は無制限なので、じっくり問題文を読んで解答することをお勧めします。

書籍紹介

CI/CD Test Night #5に参加してきました

レポート CI/CD

イベント概要

testnight.connpass.com 当日のtwitterハッシュタグは#cicd_test_night。 イベント開始からしばらくの間、Twitterの障害？でツイートの実況ができない状態でした。。

セッション

1．GitHubにおけるGitHub Actions利用法

話し手：yuichielectric / 田中さん
資料：GitHubにおける GitHub Actions利用法/How GitHub uses GitHub Actions - Speaker Deck
概要：GitHub Actionsのお話。

  • 強み

    • 処理をコンポーネント化(actions)して再利用できる！←これかなりうれしい
    • いろんなイベントをトリガーに設定可能
      • GitHub内のイベントはもちろん、cronの定期実行やHTTP requestにも対応。

  • actionsのマーケットプレイスもある

    • 他の方が作成されたactionsを組み合わせてジョブネット（パイプライン）を簡単に作れてしまう。
    • 実際、GitHubのパッケージリリースも既存のactionsを組み合わせて作っている。

→actionsがいろんな人に作られてどんどん増えていくと嬉しい！

  • 今後について
    • 自分の用意したホストでの実行なども対応予定
    • ビルドキャッシュの要望も多かったので、対応予定。

2．シナリオに依存しないテストの基盤作ってます

話し手：Kuniwak / クニワッさん
資料：Speaker DeckのURLが閲覧できなかったため、ツイートにて失礼します。

概要：モバイルゲームの開発におけるCI環境を構築した話。

  • 背景 モバイルゲームのバグを早く見つけたい！が、どうしてあげるとよいのか。
    →プロダクトの特性上、UTはしにくい。。結合テストありきの部分がある。。
    →結合テストは壊れやすい。。
    →UIテストは作りこみとかで保守が大変。。
    →UIのモンキーテストをしよう！

  • UIのモンキーテストをCIする

    • AppliumやAltUnityTester等のツールはあるが、今回はアプリに埋め込む方式を採用。
    • 環境は実機で行った（横並びで試験するならデバイスクラウド使うのもアリだが）

  • devfarmを開発！

    • 指定したデバイスクラウド/OS/機種/台数/アプリ/引数を設定して、アプリの起動状況を管理するツール
    • 将来的には公開予定

3．Azure PipelinesをサーバサイドのCI/CDに活用

話し手：nakasho / 中島さん
資料：Azure PipelinesをサーバサイドのCI/CDに活用
概要：Azure Pipelineの紹介

  • Azure Pipeline

    • 様々な環境やツールがそろっている。
      • Azure以外にもGCPとかでも動かせちゃう！
    • 初心者はGUIでパイプラインが作れる「Classic Editor」を使うのがおすすめ。
    • ビルドとリリースのPipelineは分割されている。

  • Azure Artifact

    • プライベートパッケージリポジトリ。
      • Python等にも対応している。欲しいものは要望をあげよう。

4．AWS CodeBuildを使ったCI環境の構築

話し手：KINOSHITA Minoru / 樹下さん
資料：AWS CodeBuildを使ったCI環境の構築 - Speaker Deck
概要：AWS CodeBuildの事例紹介

  • CIでやったこと

    • LambdaでCodeBuildを複数起動する
    • トリガーはGitHub Webhookを設定する
    • ログをGitHub Checksで管理する
      →メンバーにAWSアカウントを持っていない人がいても、GitHubならみられる！
      →既存のAWSのログは慣れていないと見づらいが、GitHub Checksならわかりやすい！

  • 大変だったこと

    • 前準備に時間がかかった
      • 特にポジトリのセットアップに時間がかかる点。
    • 当初の想定よりコーディングが必要だった

5．expoアプリ開発におけるCI/CD

話し手：mats / 松木さん
資料：expoのおけるCICD.pptx - Google スライド
概要：expo開発の事例紹介

  • expoのつよみ

    • ネイティブアプリ開発におけるツールが豊富　→ネイティブ故のデメリットもある
    • チーム内共有が簡単
    • OTAアップデートによるアプリ配信が可能
      • マーケット登録せずに配信ができる！

  • CIを取り入れた背景

    • パブリッシュしすぎてどれが最新版かわからなくなった
    • 本番用アプリでテストを行いたい

  • やったこと

    • リリースチャンネルの固定、コミット時に自動でパブリッシュ
      →最新版がどれかわかるように！
    • プルリクでDB切り替え
      →アプリ検証をしやすく！

6．開発・保守して初めてわかったBitriseのつらみ

話し手：SatoshiBaba / 馬場さん
資料：開発_保守して初めてわかったBitriseのつらみ - Speaker Deck
概要：BITRISEのつらみ紹介

  • BITRISEとは

    • モバイルアプリに特化したCI/CDサービス
    • 公式サポート有りIntegration、無償プランも有り
    • GitHub以外のリポジトリにも対応

  • つらみポイント

    • WorkFlowがガラパゴス化する
      • 古いものが残ってる
      • iOSとAndroidで足並みが揃ってない
        →WorkFlowを設計しよう！
    • ビルドマシンがしょぼい
      →上司におねだりしてプランを上げてもらおう！（CIに時間がかかるのとプランの料金を天秤にかけたら当然ですよね）
    • かゆいところに手が届かない
      →覚悟してスクリプトを書いて対応しよう

7．Kindで量産する使い捨てKubernetes

話し手：チェシャ猫さん
資料：Kind で量産する使い捨て Kubernetes #cicd_test_night / CICD Test Night 5th - Speaker Deck
概要：Kindを使ってKubernetesをCIに乗せる話

  • 背景
    Kubernetesは便利！
    →でも凝りすぎて混沌化する
    →現物のKubernetesをCIに乗せたい！

  • Kindを使おう。

    • Kubernetes IN Docker の略。つまりDockerのコンテナ内にKubernetesを入れる！
    • 使い捨てのKubernetesが作れるため、「ビルドごとに名前空間を分ける」「マネジードサービスから払い出す」の両方のうまみを使える。
    • CircleCIとの組み合わせも◎。

個人的な感想

  • 「CI/CD」というテーマでも、環境や使用するツールが発表者の皆様全員バラバラで、全く知らない技術ワードも出てきて非常に面白かった。
    • GitHub Actions
    • expo開発
    • Kind
  • 懇親会では「自社ではなかなかCI導入も大変」という悩みを話されている方がちらほらいらしてた。
    ツールも様々なので、何から手を付けたらよいのかわからない、というのもあるようです。