アジャイル開発

はじめに

バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

「アジャイル開発」っていうとなんかカッコいいしモダンっぽいというイメージをおそらく持っている人もいるでしょう。(私を含めて)

逆に「ウォーターフォール開発」はなんか古臭いし、どこぞの金融系ぷ r、、おっと誰か来たみたいなのでこの辺で。

とまあ、もてはやされたアジャイル開発ですが、フタを開けてみれば「要件定義 → 設計 → 実装 → テスト」の全工程を１つの単位として反復するという手法なのです。

反復する期間はチームやプロジェクトによってまちまちですが、1 週間〜4 週間ほどです。

ってことはですよ、V 字モデルのウォーターフォールを短いスパンで回してるだけ？、、それウォーターフォールじゃねぇか！！

、、というヤジも分からなくはありませんが、ちゃんとメリットがあります。

だってそうですよね。ウォーターフォールでは全工程を段階的に進めていくのでリリースまでに時間がかかってしまいます。

対してアジャイルでは前工程を１つのサイクルとして反復するのでリリースまでの期間が短く済みます。

しかもアジャイルは、開発サイクルが短い分、仕様変更や追加機能の対応がしやすいというのもあります。

ウォーターフォールだと、段階的に進めるので、１つの仕様変更があった場合、工程を戻すことになり、、おぉ、、考えただけでも恐ろしいですね。

これも納得ですね。

リリースが早い分、クライアント(ユーザー)に効率よく素早く提供できる → クライアント喜ぶ → 褒められる → 嬉しい=うまい?

(これは数合わせです)

手法は以下の３つです。

この中で私が経験したのは、スクラムのみです。(2020/07 時点)

どのサイトでも言われている通り、この開発手法ではメンバーとのコミュニケーションが非常に重要です。

そのイテレーション(スプリント)でリリースする機能も複数人が関わっていたり、メンバー間での連携が必要な機能だったり。。

極めつけは１つのアプリの全機能を全メンバーが把握しているのがヨシとされるので、知らない機能は教えたり教わったりしないといけないからです。(これは私のチームだけなのかは知りませんが)

、、とすごく大変そうに見えますが(実際に大変ですが)、スクラムならではの団体戦みのある開発でまあうまく回せるんではないでしょうかというのが感想です。

表紙イラスト：Loose Drawing