初めに

アジャイル開発のプロジェクトへ参画することが度々あります。
しかし、これが本当にアジャイル？というプロジェクトも
多々見ることがあります。
この記事では自分が思うアジャイル開発の理想と
実際にどんなものなのかを調べてまとめたいと思います。
※個人の見解がありますので、これが正解という訳ではありません。

アジャイル開発って？

検索で「アジャイル開発とは」で調べてみました。
アジャイル（Agile）とは、直訳すると
「素早い」「機敏な」「頭の回転が速い」という意味。
アジャイル開発は、システムやソフトウェア開発における
プロジェクト開発手法のひとつで、大きな単位でシステムを区切ることなく、
小単位で実装とテストを繰り返して開発を進めていきます。
従来の開発手法に比べて開発期間が短縮されるため、
アジャイル（素早い）と呼ばれています。

文章的にはこう紹介されています。

実際の経験談（プロジェクト開始時）

実際に経験して分かりましたが、
最初に述べた通り、
アジャイル開発と言いながら、そうではない案件があったり、
その通りにやっている案件があったり様々でした。
ただ、流れはそれなのかな？という感じですかね。

ストーリーポイントで作業量を見積もる
スプリント（以下SP）単位で設計、開発、テストと行うので、
ある程度範囲は決めないといけません。
その作業の範囲を決める為に、ストーリーポイントというので
見積を行いました。
実際の動きはこんな感じです。

見積時は、各作業に対してストーリーポイントを割り振りました。
各作業を見積もる
次に、各作業に対しての見積を行います。
ストーリーポイントに収まるかどうかが大事です。

割り振った後、お客様に報告。
この後、スプリントが始まり、作業が開始されます。

各スプリントの最終日
各SPの最終日はお客様とのレビューを実施しました。
筆者が体験した案件では、実際の成果物をお客様に
見せる形での報告でした。
以下の図のように作業Aに対する機能が実現できたことを
お客様に対して報告しました。
終わらなかった作業は？
実際に間に合わなかった作業については、申し送りという形で
次のSPに持ち込むこともありました。
もちろん、申し送りするにしても、正当な理由を説明しなければなりません。
筆者の場合は、テスト工程でのテスト用のプログラム作成が
間に合わないことがありましたね。
単体試験自体は完了していましたが・・・
ちゃんと理由を説明して次SPに持っていくように承認してもらいました。
※品質担保の為に、テストプログラムのカバレッジを出していたので、
それが時間かかりましたね。。。
最終的には、全SPが終わるまでに全てを提出できるようにしました。
次のSPに向けて
冒頭の方で記載したストーリーポイントでの作業量の見積を行う前に
各作業自体にどれくらいのストーリーポイントを要するか
それ自体の見積を行いました。
それによって、与えられたストーリーポイント内で作業が
完了するかどうかの判断も行ってきました。
実際に経験して
開発者にとっては、見積もったストーリーポイント内で
作業をする訳ですから、そこまで負担が大きくかからない感じでした。
とはいえ、案件の開始直後は、他チームとの開発環境の足踏み、
アーキテクチャとの開発相談など、やることが多くて
プロジェクトの波に乗るのが難しかったです。
案件内で無駄作業も結構ありましたね。
波に乗ることができたのは、ある程度開発環境が整ってからですね。

ストーリーポイントとは
実装するのに必要なコストを見積もるための単位のこと

ユーザストーリーとは
システムがユーザーにとってどのような
価値をもたらすのかを示すもの

実際の体験談（プロジェクト半ば～終盤）

プロジェクトも進んでいくと、
アジャイル開発での案件も大分慣れた感じでした。
後半はある程度出来上がった物に対する要望や
不具合の改修などを行うことが多かったですね。

前半では
とりあえず、建前上、機能的に要件を満たしているものができました。
とはいえ、何気なく作った訳でもなく、
SPの終わりにお客様とレビューで実物を見てもらい
お客様と一緒に形にしていったものが出来たという感じです。
作業の見積について
チーム毎のストーリーポイントは決まっています。
その中で、優先度が高いものからストーリーポイントを消化していきます。
ただし、何でもかんでも優先度が高いものから解決するのではなく、
あくまでストーリーポイントに収まる範囲で見積もります。
ですので、この時点では、余ったストーリーポイントで
優先度中小をこなしていった感じでした。
後の流れは、前半と変わらず、テスト工程も同じようにやっていきました。
プロジェクト入った感想
結果的には色々ありましたが、プロジェクトは無事に終了。
運用後も、アジャイル開発と同じ流れで不具合の改修や改善要望
更には、追加機能の開発などお客様と長い付き合いになったり
ならなかったりですかね。
筆者はテスト完了と同時に退席しましたが。

理想なアジャイルとは？

個人の見解もありますが、自分にとっては
先ほどの説明したものが理想的なアジャイルと考えます。
１チーム辺り、７～８人。
残業も時と場合ぐらいで、最初からフルであった訳ではなく、
月の稼働時間も180時間以内に収められたかなと思います。
とにかく、運用としてはベストでゃないでしょうか。

アジャイル・・・？

人それぞれと言ってしまえばそれまでかもしれませんが、
これはアジャイルなのか、と感じるプロジェクトもありました。

期限があっての見積
確かに依頼があってのモノづくりに対しては期限はあります。
そこは当たり前だと思います。
そもそも、期限があっての作業なのでしょうか？
その為のストーリーポイントがありますので、
ストーリーポイント内に収まらない作業に対しては、
きちんと報告し、タスクのスケジュールの見直しをするべきと考えます。
決して「じゃあ、この期限でよろしく」というのが
アジャイルではないと思います。
ウォーターフォールではない
アジャイル開発とウォーターフォールの違いは以下の図の通りです。

上の図が、ウォーターフォール、下はアジャイルの作業の流れです。
違いは、部分ごとにリリースをしているところです。
ここから分かることは、部分的にリリースをしているので、
上位クラスの方も進捗を把握していることです。
決してスパンの短いウォーターフォールという訳ではありません。
このリリース部分がアジャイルでは大事な部分だと思います。

お世話になったツール

アジャイル開発をする上で助けてもらったツールなどを紹介します。

Jira
公式サイト
アジャイル開発する際に課題管理をするのに便利でした。
課題の管理はタスク毎に管理できるのでスケジュール把握にも優れています。
confluence
公式サイト
開発や環境構築のナレッジを貯めたり、成果物の管理、
会議の議事録を残すなど知識やノウハウをwikiみたいに
残すのに便利なものでした。
プランニングポーカー
チーム内でストーリーポイントを見積もる時に
どれくらいのポイントがいいかチーム全体で話し合うときに利用しました。
AWS
ご存じ、アマゾンのサービスです。
Gitと連携してソースコードをレビュー、コミットなどに利用してきました。

他にも色々な便利なものがあると思いますが、
筆者がアジャイルで使ったことがあるのはこちらのものでした。

まとめ

今回、アジャイルを経験して学んだことをまとめました。
慣れていない部分もあり、実際に運用するのは
なかなか一筋縄ではいかないと思います。
いざ、自分が上級な立場になった時は
今回のまとめたことを参考に、良い部分は真似をして
悪い部分は反省点として活かしたいと思います。