スクラムが様になってきたのでXP導入しようと模索中

Adways Advent Calendar 2018 5日目の記事です。

http://blog.engineer.adways.net/entry/advent_calendar_2018

こんにちは、広告サービスの開発・運用を行っているエンジニアのsndyです。

広島の丸選手をFAで獲得出来て、テンションが上がっていますw(巨人ファン)
FA移籍後にも活躍できる選手はそれほど多くないですが、ガッツや男村田がやってくれたように、丸選手もやってくれるハズ！
今から来シーズンが待ち遠しいですね！

さて、このまま野球のお話をしても良いのですが、せっかくのエンジニアブログなのでそれっぽい事を書きますw

私の所属しているチームでは、スクラム開発を取り入れていて、始まってから2年近く経ちますが、割と様になってきたと実感しています。
スクラムについては、同じチームのりょーまさんが以前に紹介していたので、気になる方は一度読んでみてください。

blog.engineer.adways.net

今回は、少し物足りないと感じている技術的な面へのアプローチに関して、XPのプラクティスを取り入れてさらに強いチームを作る為に現在進行形で取り組んでいるのでその一部を紹介したいと思います。

XPとは

エクストリーム・プログラミング、XP（英: extreme programming）は、ケント・ベックらによって定式化され、提唱されているソフトウェア開発手法である。柔軟性の高い開発手法であるため、難易度の高い開発やビジネス上の要求が刻々と変わるような状況に向いた開発手法である。事前計画よりも柔軟性を重視する。

XPは、軽量開発手法あるいはアジャイルソフトウェア開発手法と呼ばれる、同種の開発手法のなかで代表的なものである。自動テストを導入するなど様々な対策をすることにより開発が進んでも変更コストが大きくならないような工夫を持ち込むことにより、変更に対する柔軟性を実現している。

このようにWikiには書いてあります。
柔軟性が高い所以としては、開発が進んでも変更コストが増えない工夫があるという事のようです。

今回XPを導入しようと考えたのも、自動テストやデプロイ等の環境がある程度整ってきたという事実があってこそでした。
日々デプロイを行ったり、コードのリファクタリングを実施する上では欠かす事が出来ない事ですから、ここは重要でした。

他にもXPの特徴は沢山ありますが、ここではこれ以上詳しく説明しないので、興味のある方は是非ググってみてくださいw
また、自分が始めに読んだXPの本も載せておきます。読みやすい内容で理解も深まると思います。

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

作者: ケントベック,シンシアアンドレス,Kent Beck,Cynthia Andres,角征典
出版社/メーカー: オーム社
発売日: 2015/06/26
メディア: 単行本
この商品を含むブログ (6件) を見る

XPについての学習

何をやるにもまずは知識が必要です。

そこで先ほど紹介した本を読む事にしました。本の内容は実際に読んでもらった方が良いですが、
私が読んで感じたポイントは大きく分けてこのようなものでした。

1.リファクタリング文化をつけよう

f:id:AdwaysEngineerBlog:20181206184830p:image:w98

コードはその時にベストなコードだったとしても、今度見たときにベストとは限りません。
日頃からリファクタリングを行い、常に健康なコードを維持しましょう。

2.ペアプロ・モブプロを取り入れよう

1人で開発した開発物のスペシャリストは開発者1人ですが、複数人で開発すればその開発物のスペシャリストは関わった人達です。
また、1人で悩むよりも複数人で解決策を導き出した方が基本的には早く解決出来、結果効率的だったりします。

3.テストを先に記述しよう

テスト駆動にする事で、先に仕様を網羅することが出来、仕様漏れによる不具合などを防ぐことが出来ます。
部分的に正常に動くように開発していくので、それぞれのパーツが信頼性の高いものになり、バグ発生率を減らすことが出来ます。

4.何事もシンプルに。そのとき必要なモノを実装しよう

今後必要になるだろうという考えで、色々な'便利機能'を作ってしまうケースはよくあります。
それらは大半が使われる事がなく、メンテナンスコストが増加するだけの産物になってしまいます。
極力シンプルに実装しましょう。

まだまだ沢山の内容がXPには含まれていますが、私が特に大切だと感じたポイントはこの4つでした。
どれも現状のチームでは取り入れておらず、取り入れる事によって今ある課題を解消出来るかもと感じました。

チーム内のメンバーで簡単な流れを実践

XPについてある程度把握する事が出来たので、いざ実践！
以前セミナーに参加して体験した内容を参考に、簡単なテーマを決めて実施しました。

テーマ

「FizzBuzz」

使用言語

「自由」

ルール

TDDの考えを取り入れ、テスト駆動でやっていこう
1つのテストがパスしたら次のテストを書いてドライバーチェンジ！(コードを書く人)
否定的な意見は無しで。良い感じに楽しもう

テーマが簡単過ぎる？
実践しながら流れを理解する事を重視していたのでこれくらいで丁度良かったです。

使用言語はテーマの難易度が低いのでなんでも大丈夫！
今回はメンバーが書いて見たいという事で、Ruby&Rspec に決定！

実際の流れ

FizzBuzzの仕様決め
まずはFizzBuzzを完成させる為に必要な要素をホワイトボードに書き出します。要件に対する仕様のような感じですかね。
例えば「3が渡された場合"Fizz"と返す」みたいな。
テストコードを書く
取り組む内容をホワイトボードから選んで、テストコードを書きます。
ここでは当然内容が実装されていないので、テストは失敗します。TDD的には Red の状態です
すぐに Green になるように実装
最悪return "Fizz"のようにしてもOK
Refactorフェーズ(期待結果を変えずに処理を変更する)
このままだと3以外を渡しても"Fizz"しか返ってこないので、「3を渡したとき」という条件を追加
テストを変更せずにコードが通れば完成！
ステップ2に戻る
次に取り組む内容をホワイトボードから選んで、テストコードを書きます。
期待結果に対する実装はまだ無い段階なので、ここで Red の状態になりドライバー交代です。

やってみて Keep / Problem / 感想

[ K ]

楽しくできた
- ここは重要なポイントなので良かったです。
テストコードの漏れが無くなりそう
- 最初にペアでテストをチェックしながら出来るので、漏れは減りそうですね。
スムーズに導入出来、勝手が理解できた
- 「勝手を理解する」部分を重視していたのでホッとしましたw
すぐ実践できそう
- 手応えを掴んでもらえたのは良かったですね。

[ P ]

キーボードがUS/JISでやりづらかった
- メンバーがUSなのですが自分はJISなので。。。(JIS悪く無いと思います)
4人以上だとやりづらそう
- ナビゲーターが増えると意見の量も増えますから、確かに人数多いと工夫が必要そうです；

[ 感想 ]

実業務規模で実施する場合、工夫は必要
- FizzBuzzという簡単なモノであれば割とイメージはしやすいですが、実際の業務で行う内容はもっと複雑で難易度が高いものになります。
  その場合、要素出しの段階から工夫しないとテストが書けなかったり、粒度がバラバラでドライバー交代のタイミングを見逃したりしそうです。
人によっては個人でやった方が早く正確という人も居ると思うので、導入方法は要検討
- こればかりは個人の性格という面もあるので、慎重に進めたいと思っています。強制は良くないと思いますし、パフォーマンス下がってしまうのも微妙ですからね。。。