Zenn
🏉

認定スクラムデベロッパー研修レポ

2022/08/06に公開
#
スクラム
#
レポ
idea

7月26日〜7月29日にアギレルゴコンサルティングさん主催の認定スクラムデベロッパー(CSD®)研修を受講してきました。
こちらの研修はZoomで行われ、15名ほどの方が参加されていました。
講師の方はレガシーコードからの脱却の著者のDavid Scott Bernsteinさんでした。
研修は英語で進められていましたが、通訳者の方々が日本語で同時通訳していただいていたので、おかげさまで英語が不慣れな状態で参加しても全く問題ありませんでした。

CSD®研修について

このトレーニングプログラムを修了すると、品質の高いソフトウェアを迅速に構築するためのスクラムとエクストリームプログラミングの中核となる原則と実践に関する知識が得られ、以下のことができるようになります。
・ストーリーを記述し、スプリントで機能を開発する
・開発タスクをより正確に見積もる
・貧弱なコードの病状を診断して修正する
・BDDを使ってストーリーを特定し、文書化する
・12種類のデザインパターンを見分けることができる
・効果的なCI戦略を定義する
・設計を評価し伝達するための共通言語を共有する
・コードの保守と拡張を容易にするソフトウェア品質を定量化する
・共通のコーディング標準を採用することの価値を評価する
・最も有用なUML図を読み書きできる
・スプリントで価値あるソフトウェアを提供する
・簡単に変更できる柔軟な設計を行うことができる
・コードの欠陥を認識し、それを修正する方法
・そして他にも...

https://www.jp.agilergo.com/online-csd-bernstein-202207

内容について

以下は4日間の研修でとったメモを加筆・修正したものです。

Day 1

アジャイル開発

  • アジャイル開発について
    • チーム全員が一斉に着手大きな機能(feature)を小さく分割してチーム全員が一斉に着手する
      • 待ち時間を減らせる
  • アジャイルソフトウェア開発宣言
  • アジャイルの背後にある原則
  • 顧客の要望によって現在のソフトウェアが今後どう変わっていくかは予測できない
    • 拡張性の高いソフトウェアを構築する
      • 保守のコストを抑えやすい
  • アジャイルとウォーターフォール
    • ウォーターフォールは複数の工程を決められたスケジュールに沿って進んでいく
      • 予測できていなかった事象が起こると後戻りが難しい
        • スケジュール通りにはなかなかうまくいかない
    • アジャイルは次に最も重要な機能を短期間で繰り返し定義・実装する (スプリント)
      • スプリントごとに顧客にとって最も重要な機能が期間内に実装されることが保証される
        • 機能の重要度の区分けをするために顧客と話すチャンスを何度もつくるのが必要

XP (エクストリームプログラミング)

  • ペアプログラミングおよびモブプログラミングを採用
    • コードレビューをその場で行うことができる
    • 個々人の過度な専門性を防ぎ、チームメンバーのシステムの認識を合わせる
      • すべてのチームメンバーがすべてのコードを操作できるようにする
  • 何よりもまずテストを書く
    • テストは仕様であり、振る舞いを定義するもの
    • TDD (テスト駆動開発)
      • コードの品質をあげることで作業が効率的に進められ、ベロシティがあがる
      • すぐにフィードバックが得られるのでリファクタリングにも有用
  • 新たなコードベースから始めることが大事
    • 既存プロジェクトのリファクタリングから始めるのは難しい

Day 2

要件や仕様のサイズ

  • エピック
  • 市場価値のある最小限の機能 (MMF)
    • プロダクトが生き残り、役立つものであるためにリリースで絶対必要な機能群
  • ユーザーストーリー
  • タスク

ユーザーストーリー

  • システム要件ではなく、ユーザーが達成したいこと
  • 顧客と対話を通じてストーリーを作り上げる
    • よりよい機能のアイデアを見つけられるチャンスが生まれる
  • INVEST
    • よいユーザーストーリーかどうかの6つの判断基準
    • 以下の頭文字を取っている
      • 独立している(Independent)
        • 現在取り組んでいるストーリーと次のストーリーとが独立している
      • 協議できる(Negotiable)
      • ユーザーや顧客に意味がある(Valuable to users or customers)
      • 見積れる(Estimatable)
      • 十分に小さく(Small)
      • 検証できる(Testable)
  • ストーリーが大きい場合
    • 組み合わさったストーリー
      • 分割が可能
    • 複雑なストーリー
      • わからないことがあるから複雑
        • イテレーションの中でわからないことをつぶしていく
          • 時間をとってリサーチし、見積もり可能なストーリーにする
            • スパイクストーリー

ユーザーストーリーとユースケースの対比

  • ユーザーストーリー
    • プロダクトオーナーが作るもの。開発者がその実装を行っている際の一助とできるようなもので、それほど詳細ではない
  • ユースケース
    • 開発者が自分自身で実装するための詳細なシナリオのこと

XPでは特別なストーリーをコーディングで置き換えられる

  • 資料の代わりにテストを書く
    • APIの使い方はテストを見ればわかるようになるため
  • 開発者がみやすいドキュメントをコードベースで表す

ストーリーの見積もり

  • 昨日の天気
    • 前回の機能と比較してどれくらいむずかしいか、かんたんかを判定する
  • プランニングポーカー
    • 1,2,3,5,8,...
      • 8以上は見積もり不可
        • 見積もり可能な大きさまで分割する
        • それも難しければ調査用のストーリーを行う
  • ストーリーがしっかりと分割できていればストーリーポイントを出す必要はなくなる
    • 予測可能なため

受け入れテスト

  • Given-When-Thenのフォーマットに従って受け入れテストを書く
    • 自動化ツールを利用すると、プログラムがわからないプロダクトオーナーや顧客でもわかるようになる
      • Cucumber・SpecFlow・Fitなどのツールがある
    • 受け入れテストが完了すると、その機能が完了したとみなされるため、次の機能実装に移ることができる
    • 顧客の視点から書く

Day 3

ソフトウェアにおける第一原理

  • テスト容易性
    • テストが書きやすい、検証がやりやすい
    • 変更が加えやすい
    • テストを最初に書くのが必要
      • テストファースト

デザインの第一原理

  • オープン・クローズドの原則
    • 拡張のためには開かれ、変更のためには閉じられているべき
    • コードが変更されるときに最小限の変更で済むように
    • 他の人のコードを変えるより新しくコードを書く方がエラーを起こしづらいことが多い
      • オープン・クローズドの原則を知っておくことで、拡張しやすいコードを書くように意識できるようになる
  • 単一責任の原則
    • "クラスは存在する理由を一つだけもつべきで、それゆえ変更する理由も一つだけ存在する"
      • "Uncle Bob" Martin
  • 依存関係逆転の原則
    • APIを開発する際には、呼び出し先が必要なデータを考えるのではなく、呼び出し元が欲しいデータを優先しなければならない

継承と集約

  • むやみに継承を利用するとクラス爆発を生み出してしまう
  • 継承
    • is-a(aである)関係があるときに使う
      • 似ているものには使わない
  • 集約
    • has-a(aの性質を持つ)関係があるときに使う
  • GoFでは集約を好んで使う
    • バリエーションをカプセル化するため
      • これはクラスの凝集度を改善する
        • 凝集: ソフトウェアのエンティティが単一の責任を持つこと
    • コードの再利用を促進する

抽象クラスとインターフェースの違い

  • 抽象クラスはコンセプト
    • 車
    • メソッドを追加しても壊れない
  • インターフェースは振る舞いを表す
    • 加速
    • メソッドを追加するとすべての実装元でメソッドを実装する必要がある

擬人化

  • 擬人化を利用するとソフトウェア開発においてイメージしやすくなる
  • 優秀な開発者では必須の技術

デザインパターン

  • 詳細に焦点を当てると全体像を失う
    • パターンを利用するとおおまかなレベルで話し始めることができる
  • 問題の中からパターンを発見していくのがソフトウェア開発の自然な流れ
  • デザインパターンは建設界から来た言葉
  • ソフトウェア開発においてデザインパターンという名称は誤っている
    • ソフトウェアパターンもしくはパターンと呼ぶのが好ましい
  • 意図
    • パターンの意図はそれが何を達成しようとしているかを示している
      • なによりもまず意図をみて、感じ取るべき
  • StrategyパターンとTemplate Methodパターンの違い
    • 意図が異なる
    • Strategyパターン
      • それぞれのアルゴリズムをカプセル化して、交換可能にする
    • Template Methodパターン
      • 共通のアルゴリズムを定義し、その他のステップをサブクラスに任せる
        • 「その他のステップをサブクラスに任せる」はオーバーライドで表す

Day 4

要件からパターンを用いて設計する演習

  • 最初の要件から、次々出てくる追加要件により現在の設計が覆されることは往々にして存在する
    • 変更が加えやすい設計を追求する
      • 顧客との度重なる対話が大事
        • 顧客満足度が究極のゴール

パターンの効能

  • "最終的には、パターンはもはや重要ではない: 現実の物事を受け入れるということをパターンは教えてくれた"
    • A Timeless Way of Building, Page 545

まとめ

4日間の研修は座学中心で構成されていました。上位資格であるA-CSD℠の研修では実践的な演習がメインとなっており、本研修はその前提知識を補うための位置づけでした。
前半2日で主にスクラムの概要について学びました。私自身、スクラムでの実務経験がほとんどなく、前提知識の乏しい状態での参加となりましたが、アジャイルソフトウェア開発宣言からユーザーストーリーの作成まで順を追って説明いただくことで、スクラム開発やアジャイル開発についてのエッセンスを感じ取ることができました。
特に、アジャイル宣言の背後にある原則の ”要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。” という言葉が繰り返し使われていたのが印象的でした。
https://agilemanifesto.org/iso/ja/principles.html
また、本研修はスクラムデベロッパーということもあって、XPやTDD、ATDD(BDD)についても多く取り上げられていました。
これらの用語については以前から聞き覚えはあるものの詳しい内容やその効果について理解ができているわけではなかったため、良い機会だと思い、より深く調べてみようと思っています。

後半2日では原則やGoFデザインパターンなどの変更に耐えうる設計手法について学習しました。
最終日にある題材についての設計演習があり、パターンを共通言語として話し合いの道具にできるのは効率的で良い体験でした。同時に、要求による変更に耐えうる設計を実現するためには今まで作ってきたものに固執せず、場合によってはひっくり返す勇気も必要だと感じさせられました。

おそらく社会人になって最も学びのある刺激的な4日間となり、参加できたことに非常にうれしく思っています。

最後に

無事認定スクラムデベロッパーになれました :raised_hands:
かといって、これからの働き方が大きく変わるというわけではありませんが、研修を通じて今後の自学の指針となるヒントがたくさん得られたので、引き続き邁進していこうと思います。

P.S. 業務委託であるにもかかわらず、私のために研修費用を出してくださったインテグリティスさん、ありがとうだっピ。。

GitHubで編集を提案

Discussion