DesignAssembler

備忘録に近い

アジャイル

アジャイル

少人数かつ短い期間(イテレーション)でプロジェクトを回していく開発。
この1イテレーションには実装テスト修正リリースが含まれています。

スクラム

アジャイル開発手法の1つで、チーム開発のためのフレームワークです。

デイリースクラム

  • 今日やること
  • 昨日やったこと
  • 今の問題 この3点を明らかにします

振り返り(KPT)
各スプリント(イテレーションのこと)の終わりにはKPTで振り返ります

  • 良かったこと
  • 問題点
  • 挑戦したいこと

継続的インテグレーション(CI)

イテレーションを回すために自動化が必要。
インテグレーションとはビルドとテストを行うプロセスのことで、CIはこれをいつでも行う事です。

以前のウォーターフォール開発だとインテグレーションは開発作業終了後のテスト期間に初めて行われていたが、これだと困難な場合が多い。これを避けるためにこまめにインテグレーションを行うのがCIです。

つまり、コマンド1つでテストを実行できるようにすればいいということです。

xDD

x Driven Developmentのことです。日本語だと「◯◯駆動開発」になります。

テスト駆動開発(TDD)

仕様のテストを先に書く。コードの量は増えるが、核となる機能を確実に実装でき、その後細かい部分を組めばいいので素早く開発できます。

「TDDをする」と「自動テストのコードを書く」は別物のようです。TDD用のテストは素早く機能確認をするためのテスト(細かく書かない)で、自動テスト用は時間をかけて保守用に書くコードのようです。

DHHが「TDDは死んだ」と言った事が話題になりましたが、これには続きがあって「TDDは死んだ。だがテストは生き続ける」です。

TDDを行った時にぶつかった7つの壁 - Qiita

振る舞い駆動開発(BDD)

BDDはTDDの流派です。

TDD同様BDDもテスト駆動なのですが、テストの書き方が少し違っていて「振る舞い」に重きを置いてテストを書きます。

ここでいう「振る舞い」は、アプリケーションの機能(ユーザーから見た機能)のことです。この「振る舞い」はUXに直結しています。

BDDでは以下の2点が重要視されます。

  • Test as Documentation

テストを仕様書に出来るように書くこと

  • Specification by Example

テストではなるべく具体的なデータを入れること

RubyRSpecはBDDの代表的なフレームワークの1つです。

ドメイン駆動開発(DDD)

関連するデータと機能を1つにまとめてクラス化します。例えば、Railsなら機能ごとにEngine化します。

開発順はドメインモデル→データベース→テスト→アプリケーションです。

ドメインモデルに業務ロジックを集めるのでコードが減ります。

ドメイン駆動設計 ( DDD ) をやってみよう

素晴らしいスライドたち

いろいろとスライド上がってますが、内容が内容なので分かりやすいスライドにするのは難しそうです(スライド数も100超えが多いです)。以下はそんな中でも自分が素晴らしいと思ったスライドたちです。

www.slideshare.net

www.slideshare.net

アジャイルではなくチーム開発のスライドです

www.slideshare.net

参考

www.nec-nis.co.jp

www.atmarkit.co.jp