認定スクラムデベロッパー(CSD)研修を受けてきた。
11月8日〜11月11日の4日間で、認定スクラムデベロッパー(CSD®)研修に参加してきました。
かなり色んなことを学んでこれたので、忘れてしまわない内にここにまとめたいと思います。
CSDとは
この没入型トレーニングプログラムは、スクラム開発者として成功し、スクラム開発チームの貴重なメンバーとなるための知識とスキルを提供します。
このトレーニングプログラムを修了すると、品質の高いソフトウェアを迅速に構築するためのスクラムとエクストリームプログラミングの中核となる原則と実践に関する知識が得られ、以下のことができるようになります。
・ストーリーを記述し、スプリントで機能を開発する
・開発タスクをより正確に見積もる
・貧弱なコードの病状を診断して修正する
・BDDを使ってストーリーを特定し、文書化する
・12種類のデザインパターンを見分けることができる
・効果的なCI戦略を定義する
・設計を評価し伝達するための共通言語を共有する
・コードの保守と拡張を容易にするソフトウェア品質を定量化する
・共通のコーディング標準を採用することの価値を評価する
・最も有用なUML図を読み書きできる
・スプリントで価値あるソフトウェアを提供する
・簡単に変更できる柔軟な設計を行うことができる
・コードの欠陥を認識し、それを修正する方法
・そして他にも...
研修のスタイル
基本的には座学がメインでした。本コースはスクラム・XPの基礎知識を身に着けることが目的のようだった。(CSDの上位にA-SCDという研修があるのですが、そちらは実践メインのコースのようです。)
4日間の中で2種類のグループ演習がありました(顧客の要求を元にユーザーストーリーを作成する/要件に対し、デザインパターンを用いて設計する)
今回はオンライン(Zoom)で、1時間ごとに小休止を挟む形で進行されました。グループ演習はブレイクアウトルームを使用。
アジャイル開発/スクラム/XPに関連する色んなトピックについて、その原則と実践を学ぶスタイルでした。
正直、情報量がとんでもなかったです…
講義の冒頭、講師からは「このクラスでは様々な手法を学ぶので、まずは自分に一番合うものを選びとればいい」と説明を受けました。
どんなことを学んできたのか？
もう色々ありすぎてまとめ切れてないんですが、トピックとしてはこんな感じでした。
アジャイル開発の概要
ユーザーストーリー作成
リファクタリング
XP
デザインパターン
この中から、印象に残っていることをピックアップしていきます。
強く印象に残っていること・思ったこと
ユーザーストーリーは同じくらいの小さなサイズにすべし
プランニングポーカーを使って個々のユーザーストーリー・チケットにポイントを付けるという方法が有名だが、プランニングポーカーの作者は、それを生み出したことを後悔している。なぜなら、皆が「個々のチケットにポイントを付ければいいんだ」と勘違いしてしまっているから。そうではなく、本当にやりたかったことは、「ストーリーを切り分けて、全てを同じくらいの小さなサイズにすること」
そのようにすることで、全体の見積もりを容易にする。そもそも、ストーリーのポイントが高くなってしまうのは、切り分けできるほどしっかり理解できていない、見積もれていないことの証左である。
[思ったこと]
たしかに私のチームでも、8ポイントのチケットを切ると大体大失敗する。把握していなかった作業が途中からどんどん発覚して、手戻りも多い。
それはそもそもポイントを付けて見積もったつもりになっていたんだなあということがわかった。この研修を受けて、チームで「チケットは3ポイントくらいのサイズになるまで切り分けよう」という試みを始めた。どういう結果になるのか楽しみ。
カプセル化を活用することで開発が円滑になる
NIST(National Institute of Standards and Technologyだったかな？)の調査では、開発者の作業時間の80%は、覆せない決定を後からやり直す作業に費やされているらしい
何か問題が発生して、その場では解決できない時、その問題をカプセル化することができれば、後で余裕が出た時に解決することができる。問題の最終決定を後回しにすることができるし、後からの変更も容易になる。
コードの振る舞いに関する知識は、全てコードに集約する(ドキュメントではなく)
コメントでもなくドキュメントでもなく、極力「コード自体」に知識を集約する。そうしないと、コードを変更した時必ずコメントも変更しないと、コードとコメントが一致しなくなる(そして往々にしてそのようなことが発生する)
とはいえ、「なぜそのようなコードになっているのか？」を説明するようなコメントは有用である
リファクタリングでは、学びを全てコードに集約していく。(よって、イテレーションの度にコードは変わっていく)
[思ったこと]
コードとドキュメントが一致しなくなるという点は非常に共感した。私のチームではかなりの量のレガシーコードを抱えているけれど、アジャイル開発の理想は、それらのコードを理解するための膨大なドキュメントを作ろうとするのではなく、リファクタリングを通してコード自体に知識を集約していくことなんだなあと理解した。
リファクタリングは3種類くらいのやり方がある。状況に応じて使い分ける
レッドグリーンリファクタリング
まず最初にテストを通すようにする
テストが通ったら、コードをきれいに整理していく
全体的なリファクタリング
定期的に、一定の期間を確保して行う(3か月おきに1週間など)
システムの構造を分析し、再構築していく
レガシーコードのリファクタリング
これをやるかどうか(これに時間を割くかは)経営的な判断を必要とする
レガシーなコードのリファクタリングには、まず最初にコードの中にスペースを確保することが大事(部屋の片づけも同じでしょ？)
プロダクトの答えは「顧客」の中にあるので顧客に聞く。顧客にプロダクト開発へ参加してもらう
全ての要件を事前に把握するのではなく、作るべきものを顧客との会話から捉える
そのやりとりの積み重ねは、今まで一度に提出していた、数百ページにわたる要件定義書の代わりになる
従来のウォーターフォール型では、顧客がプロダクトに関わりづらいので、要望通りのものを用意しても受け入れてもらえないことがあった。顧客にイテレーションに参加し、どんどん要望・意見を言ってもらうことで参画意識が上がってくる
[思ったこと]
ユーザーストーリーを作るというグループワークに取り組んだ時、私たちのチームは顧客に聞くことなしに、与えられた要望の箇条書きとにらめっこしながら話し合っていました。
でも、講師に「なぜ顧客に聞かなかったんですか？プロダクトの答えは全て顧客の中にあるんですよ」と言われてはっとしました。
そして、「顧客の参画意識」という視点も今まで私の中には無かった新しいものでした。顧客を「お客さん」と見なすのではなく、同じプロダクトを作るチームのメンバー同士という関係を構築するのがいいんだろうなあと感じました。
ペアプロ・モブプロを取り入れる
ペアプロ・モブプロは、コードレビューをその場で行うことができる
個々人の過度な専門性を防ぎ、チームメンバーのシステムの認識を合わせることができ、すべてのチームメンバーがすべてのコードを操作できるようになる
[思ったこと]
私たちのチームは普段からペアプロモブプロを取り入れているので、これに関しては共感の嵐だった。
講師が感じているペアプロモブプロの効用は普段私たちが実感しているものと一致していたので、私たちのペアプロモブプロの取り入れ方はそんなに間違ってなさそうだなあと安心した。
デザインパターンは、その形ではなく「意図」を理解することが大事
例えば、Strategyには「アルゴリズムをクライアントから独立して変化させたい」という意図があり、Template Methodには「ステップを変化させたい」という意図がある。
個々のパターンは継承や集約を使うし、見た目も似ている。決定的に違うのは上記のような意図。それを理解していないとパターンを正しく活用することはできない。
パターンは問題(作りたいシステム?)に内在している。パターンの意図を理解した上でシステムを分析すると、システムの中にパターンが内在しているのが見えてくる。
[思ったこと]
研修ではいくつかのパターンを学んだ上で、特定の要件を元に設計を行うという演習に取り組んだ。
パターンは問題に内在しているというのはまさにその通りで、パターンを学んだ上で要件に向き合うと、システムのあるべき姿(どの部分に拡張性を持たせたいのか、どの部分がバリエーションを持っているのか)が非常に見えやすかった。
今まではパターンを全然意識しておらず、要件からコードを書こうとしていたので、車輪の再発明に無駄に時間使ってたなあと痛感した。
パターンを理解していれば、特定の部分に拡張性を持たせたい時に、どのパターンを使えばうまくシステムを組み上げられるか容易に判断できるし、実装に悩むことも減りそうだし、何より後から読んだ時に理解できるコードになりそうだなと感じた。
最後に
結構つらつらと書きましたが、これでも全然学びを書ききれてないです…
座学メインの4日間でしたが、得られたものはものすごく多かったです。まだ整理しきれていません。
一つ上のクラスは実践メインらしいので是非受けてみたいなあと思いました。
自分たちのチームにも取り入れられそうな様々手法を学べたので、少しずつ取り入れて、チームをもっとよくしていきたいなあと考えています。
この記事が気に入ったらサポートをしてみませんか？