C言語によるアジャイル開発とテスト駆動開発(CI入門) ~ 1.概念 ~

# アジャイルしてますか？
皆様アジャイル開発してますか？ それとも なんちゃってアジャイル開発ですか？
ちゃんとアジャイル開発しているという方、下記のツールは使ってますか？

- ソースコード管理ツール
    - git 等
- ビルドツール
    - make, ant, Nant 等
- ビルド自動化ツール(CI)
    - Jenkins, Circle CI 等
- 単体テストツール
    - xUnit, google test 等

全て使ってアジャイル開発しているという方は、この記事を読む必要はありません。
使ってないという方は、この記事を読む価値があるかもしれません。
全く何を言っているのか分からないという方は、この記事を読む価値があるかもしれません。



## 記事の全体像
- [C言語によるアジャイル開発とテスト駆動開発(CI入門) ~ 1.概念 ~](https://qiita.com/denden14/items/a1435a225e386c32dab5)
- [C言語によるアジャイル開発とテスト駆動開発(CI入門) ~ 2.CUnit導入 ~](https://qiita.com/denden14/items/27d29735caef9b5639e0)
- [C言語によるアジャイル開発とテスト駆動開発(CI入門) ~ 3.CMake導入 ~](https://qiita.com/denden14/items/7b1729c7ff273c4165bd)
- [C言語によるアジャイル開発とテスト駆動開発(CI入門) ~ 4.Jenkins導入 ~](https://qiita.com/denden14/items/30cbe6d327a404aaa2a7)

# アジャイル開発とは
アジャイ開発とは、Wikipediaによると
>
アジャイルソフトウェア開発は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。
例えばオブジェクト指向開発において、設計とプログラミングを何度か行き来し、トライアンドエラーで改良していく手法を指す。 
アジャイルソフトウェア開発手法の例としては、エクストリーム・プログラミング (XP) やスクラム開発などがある。 

です。
もう少し噛み砕きます。

## 従来型の開発 ~ウォーターフォール型開発
従来型の開発手法として、ウォーターフォール型が挙げられます。
これはざっくり言うと、開発には
__「要求→設計→開発→テスト→受け入れ」__という大きな流れがあり、
このプロセスを__一周__することで製品をリリースするというものです。
えてしてこの開発手法では、テスト工程が最後に押し込まれ、十分にテストがなされないまま納期を迎える可能性が高いです。

## ~~新しい?~~開発手法 ~アジャイル型開発
これに対して、アジャイル開発は、
__「要求→設計→開発→テスト→受け入れ」__という開発の流れを
何回も繰り返しながら、最終的な製品を作り上げていきます。
さらに、各開発の流れ毎に実行可能なものを作ります。

これは、

- 作りたいものっていくつかの機能に分割できるよね？ じゃあ、その順で開発しよう
- 機能毎の開発ならコードを動かせるよね？ 
- その動きをみてフィードバックを素早くできるよね？？

結果的に、ウォーターフォール型の開発ではフィードバックをし辛かったけど、
アジャイル開発であればフィードバックが用意なので、エンドユーザーにとってより良いものが作れるんじゃないか？？
ついでに、早めのフィードバックは手戻り分の工数が抑えられるから、開発工数も短くなるよね？？
という思想です。

つまるところ、アジャイル開発は、ソフトウェア開発を「早い、安い、高品質」にするプロセスだといえます。

## アジャイル開発で開発効率は上がる？ ~ミニウォーターフォール型開発
これで終わればハッピーですが、
アジャイルを導入するだけで本当に「早い、安い、高品質」なソフトウェア開発ができるのでしょうか？
特に私が気になっていたのは、

- 開発サイクルを小分けにしても、やることって変わらないよね？？
- 担当箇所が目まぐるしく変わっていくので、オーバーヘッド分開発工数増えないの？？

でした。

つまり、ウォーターフォールを小分けにしただけなので、__ミニウォーターフォール型__(~~なんちゃってアジャイル開発~~)と言えます。
このミニウォーターフォール型の開発では、テスト工程が開発サイクルの最後に押し込まれ、
十分にテストがなされないまま、次の開発サイクルに行こうするといったように、
ウォーターフォール型の開発と同じ悩みが発生します。

実際やってみてもそんな感じでした。

# TDD(テスト駆動開発)
ここでTDDの登場です。
真のアジャイル開発には、TDDが欠かせません。

## TDDとは
TDDを簡単に説明すると、
テストを最初に書いて、そのテストをパスするようにソフトウェアを開発するという開発手法です。
これにはいくつかのメリットがあります。

- testableなコードが自然と設計される
- 意図しない変更が起きづらくなる

特に、testableなコードが設計されるという点が重要で、
これにより常にテストを動かせる状態にある。→ 自動化により常にコードが正しいことをフィードバックできる
ことになります。

## TDDによるアジャイル開発
TDDを導入したアジャイル開発は、
__「要求→設計→テスト記述→開発→受け入れ」__という開発の流れになります。
また、テスト記述後はテストを自動化するため、常にテスト工程が実行されているイメージになります。
さらに、自動化されたテストは別の開発サイクル中でも実行され続けるため、
ある変更が、意図しない箇所へ影響があったとしても逃さず即座にキャッチできる可能性が格段と上がるわけです。

あくまで私の解釈ですが、
昨今、開発規模は大きくなり続け、さらに顧客の要求も難易度が高まり続けている。
更に顧客自身も何がしたいのかよく分かっていない！！

そんな中で、これまでの開発のやり方では顧客の要求を満たせないので、開発プロセスを変えるべきだ。
そのためにまず開発サイクルを短くしよう。そして毎回動くものを見せることで、顧客の要求をちゃんと引き出そう。

でも、その要望に答えるために時間を捻出しないと、とても開発が回らない。
TDDとテスト自動化によりテスト工程を効率化することで、時間を捻出しよう。

というふうに捉えても良いかもしれません。

# これからやること
前置きが長くなってしまいましたが、
上記の__「TDDによるアジャイル開発」__を実現可能なものにするために、
以降の記事では下記のようなことをやっていこうと思います。

- CUnitでテストコードを書く
- C言語で開発を行う
- CMakeを使ってビルドを自動化する
- gitでソースコードを管理する
- Jenkinsを使ってテストを自動で実行できるようにする

なんでC言語なのかというと、この領域が一番CIに乗り遅れていると思ったからです。
あと、筆者がC言語を書く予定なので。

# 参考文献
[実践アジャイルテスト](https://www.amazon.co.jp/%E5%AE%9F%E8%B7%B5%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%83%86%E3%82%B9%E3%83%88-%E3%83%86%E3%82%B9%E3%82%BF%E3%83%BC%E3%81%A8%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%83%81%E3%83%BC%E3%83%A0%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89-Architects-Archive%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E3%81%AE%E5%AE%9F%E8%B7%B5-Gregory/dp/4798119970/ref=sr_1_1?adgrpid=56053864951&dchild=1&gclid=Cj0KCQiA6t6ABhDMARIsAONIYywsW8Dcc0helcahNyuGZpu7gyYNmh5HFD2reohUYOcr6utx7024ga8aAuirEALw_wcB&hvadid=259133987508&hvdev=c&hvlocphy=1009332&hvnetw=g&hvqmt=e&hvrand=4109340324460123613&hvtargid=kwd-334554117991&hydadcr=27263_10580108&jp-ad-ap=0&keywords=%E5%AE%9F%E8%B7%B5%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%83%86%E3%82%B9%E3%83%88&qid=1612251848&sr=8-1&tag=googhydr-22)