12
15

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

アジャイル開発=スクラムでも無いし、テストもいらない

Last updated at Posted at 2018-08-08

勘違いアジャイルに向けた気持ちを書いた

アジャイル開発をやり始めた最初のうちは一部の情報しかないので誤解してしまうのは仕方ないが、全体像を理解してから自分の開発プロセスが何を解決しようとしてるのかを考えてもいいんじゃないかなと、アジャイル開発を始めたい、始めました、みたいな人に向けた記事です。

そもそもアジャイル開発とは?

開発プロセスの1つである。それは間違いない。
よく対比されるものがウォータフォールだが、ウォータフォールが悪いわけではない。目的が違うだけ。ウォータフォールが正解のときもある。

ウォータフォールがダメだって言っているのは、目的とフィットしてないこともあるが、ちゃんとウォータフォールが出来ていないだけの可能性がある。こちらのPDFはウォーターフォールの誤解などについて考察しているので参考になる。
ウォーターフォールモデルの起源に関する考察 (PDF)

ちょっと話が逸れました。アジャイル開発に戻ると、
アジャイル開発はアジャイルマニュフェストと呼ばれる4つの価値観を宣言し、12の原則を定義したもの。

  • プロセスやツールよりも個人と対話
  • 包括的なドキュメントよりも動くソフトウェア
  • 契約交渉よりも顧客との協調
  • 計画に従うことよりも変化への対応

この価値観に従っているなら、テストなんて無くたっていいんです。
ただし、右側だけをやるというのではなく、左側にも価値があると理解がしています。
つまり動くソフトウェアに価値を置くけれど、ドキュメントに価値が無いと言ってるわけではないです。

原則も含めてわずか2ページなのでぜひ全文読んでみてください。
アジャイルソフトウェア開発宣言

この価値観を指針に状況に合わせて自分たちで考えてやれってことしか無いんです(笑)

変化への対応でテストがあったほうがいいって思えば書けばいいし、必要ないって思えば書かなくていい。
ドキュメントも必要だと思うなら書けばいいし、必要じゃないなら書かなくていい。
ルールを自分たちの事業やプロセスに合わせて定義するんです。ルールがあるから従うのではなく、合うルールを自分たちで定義していく。自分の頭で考えるのがアジャイルと言うことだけです。

草原に放り出された子羊

自分の頭で考えろって言われても無理やんwww
ってなるのが分かっているので、凄い人たちはフレームワークを作ってくれました。

まずはXPが流行り、最近はスクラム開発が流行っていますね。
このテンプレートに従えばアジャイルっぽい開発が出来るよって言うものです。
具体的なプラクティスに落とし込まれているため、実践しやすくなっています。

スクラム開発はアジャイル開発を具体化した1つの方法なだけです。同じレイヤーの話ではありません。
以前、登壇した時につかった図があるので貼っておきます。考え方的にはこのような構造です。

image.png

しかしプラクティスを実行していればアジャイルなわけではありません。
これはあくまでテンプレート。アジャイルであるためには自分の頭で考えることを辞めてはいけません。
テンプレートはカスタマイズするのが当たり前ですよね?チームで常にベストは何かを考えてください。

ユースケースでラインを探す

つまり結局どうするかの答えはない。
なのでテストを書けばいいこともあるし、書かなくていいこともある。

また、放り出された子羊。
そのラインを探るために色々なユースケースをみんなが語ってくれる。

テストという手段の部分にフォーカスすると、変化への対応と動くソフトウェアという項目の価値についての方法に落とし込んだものだ。つまり、長期的なソフトウェアの変化への対応が必要ないときにはテストはいらない。プロトタイプ実装の時など。個人的には少なくとも3ヶ月程度可動する可能性があるなら、テストがあったほうが良いかんと思ってます。
他にはTDDで開発した方が早く作れる時ですね。テストを書くことに慣れればUIからポチポチテストするよりテストコード回したほうがテンポよく開発できます。

スケジュールが厳しかったら、書きませんね。変化への対応をするためにリリース後に書いたりするスケジュールを組んだりすることもあります。変化に対応したいだけなら、リリース前でもリリース後でもいいですよね?
ベストな方法は状況に寄る。コレを言ったら終わりだよってのがアジャイルです笑

テストについては今回、この記事を書くきっかけになったこちらの記事がとても綺麗に言及してくれているので、こちらを読んでみてください。
アジャイル開発において「テストコードは当然」なのか?

ユースケースについて簡単まとめると、状況は千差万別。自分の頭で考えるのがアジャイル。
ユースケースはみんなで参考程度にしよう!って感じですね。
頑張って自分のチームのラインを作ってください。

終わり

一気に勢いで書いてみました。
なにかツッコミや良い情報などあったらぜひコメント下さいな。
もっと、ここのことを知りたいとかの質問などもお気軽に。

12
15
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
15

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?