自分が思うアジャイル開発とは？

初めに

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

アジャイル開発って？

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

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

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

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

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

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

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

• 各スプリントの最終日
  各SPの最終日はお客様とのレビューを実施しました。
  筆者が体験した案件では、実際の成果物をお客様に
  見せる形での報告でした。
  以下の図のように作業Aに対する機能が実現できたことを
  お客様に対して報告しました。
  

• 終わらなかった作業は？
  実際に間に合わなかった作業については、申し送りという形で
  次のSPに持ち込むこともありました。
  もちろん、申し送りするにしても、正当な理由を説明しなければなりません。
  筆者の場合は、テスト工程でのテスト用のプログラム作成が
  間に合わないことがありましたね。
  単体試験自体は完了していましたが・・・
  ちゃんと理由を説明して次SPに持っていくように承認してもらいました。
  ※品質担保の為に、テストプログラムのカバレッジを出していたので、
  それが時間かかりましたね。。。
  最終的には、全SPが終わるまでに全てを提出できるようにしました。
  

• 次のSPに向けて
  冒頭の方で記載したストーリーポイントでの作業量の見積を行う前に
  各作業自体にどれくらいのストーリーポイントを要するか
  それ自体の見積を行いました。
  それによって、与えられたストーリーポイント内で作業が
  完了するかどうかの判断も行ってきました。

• 実際に経験して
  開発者にとっては、見積もったストーリーポイント内で
  作業をする訳ですから、そこまで負担が大きくかからない感じでした。
  とはいえ、案件の開始直後は、他チームとの開発環境の足踏み、
  アーキテクチャとの開発相談など、やることが多くて
  プロジェクトの波に乗るのが難しかったです。
  案件内で無駄作業も結構ありましたね。
  波に乗ることができたのは、ある程度開発環境が整ってからですね。

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

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

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

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

• 前半では
  とりあえず、建前上、機能的に要件を満たしているものができました。
  とはいえ、何気なく作った訳でもなく、
  SPの終わりにお客様とレビューで実物を見てもらい
  お客様と一緒に形にしていったものが出来たという感じです。

• 作業の見積について
  チーム毎のストーリーポイントは決まっています。
  その中で、優先度が高いものからストーリーポイントを消化していきます。
  ただし、何でもかんでも優先度が高いものから解決するのではなく、
  あくまでストーリーポイントに収まる範囲で見積もります。
  ですので、この時点では、余ったストーリーポイントで
  優先度中小をこなしていった感じでした。
  後の流れは、前半と変わらず、テスト工程も同じようにやっていきました。
  
  

• プロジェクト入った感想
  結果的には色々ありましたが、プロジェクトは無事に終了。
  運用後も、アジャイル開発と同じ流れで不具合の改修や改善要望
  更には、追加機能の開発などお客様と長い付き合いになったり
  ならなかったりですかね。
  筆者はテスト完了と同時に退席しましたが。

理想なアジャイルとは？

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

アジャイル・・・？

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

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

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

お世話になったツール

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

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

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

まとめ

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