22
18

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.

アジャイル開発をよく知らない人たちが勘違いする項目をあげようと思います。

注) 質問内容に対して端的に回答はせず、これに乗じて好き勝手な蛇足文が付与されています。これらを楽しめる人が読んだら良いかなと思います。

Q & A

Q. アジャイル開発は早く開発できる?
A. そうとは限りません。アジャイルの主眼は変化に強いことです。
刻々と変わる市場の変化、ユーザのニーズ、そして開発を進めていくことで分かる課題やよりよい方法の発見。
それらを受け入れるフレームワークです。
全ての変化を取り込むことを決めれば、開発スケジュールが伸びることもあるでしょう。

Q. じゃあ、変化にずっと対応していたらアジャイル開発はいつまでもリリース出来ないの?
A. 逆です。常にリリースできる状態を保った最小の機能単位を切り出し、それを使って進捗管理をし、リリースをします。
リリースは全ての機能が完成してからではなく、常にリリースできる状態になっていることがアジャイル開発の重要な要素です。

Q. アジャイル開発はドキュメントを書かない?
A. 必要なドキュメントは書きます。ただし、開発に困らないレベルのドキュメントしか書きません。
例えばアーキテクチャ図をかいた場合、話し合いでホワイトボードで書いたなら、記録は写真を取ってドキュメント管理ツール(Qiita:Teamなど)にアップするだけなどです。
形式を整えるのではなく、目的をとらえて、そのレベルでの情報共有をします。
アーキテクチャ図も常に変化するものです、ドキュメントを常に最新に保つことはコストが掛かります。
アーキテクチャ図を設計がしたいために書くのか、引き継ぎメンバのために残すのかで、どの水準で書くかは変わります。
前者なら先程の手法、後者であればLucidchartやPlantUMLなどを使って、変更に強いドキュメント化をした管理をする必要があります。
WordやExcelには書かないで下さい。

Q. アジャイル開発だからスケジュールを立てないよね?
A. そんなことはありません。必要であればガントチャートを書くこともあります。
また、ベロシティを計測することでチームがどのくらいの作業をいつまでにできるかを可視化することにコストを払うこともあります。

Q. マネージャがアジャイル開発が出来るって言ってました。スクラムマスタが進捗管理をすると言っていました。
A. 十分な知識を得ずにアジャイル開発をしている人は大抵アジャイル出来ていません。アジャイル開発宣言では手法は書かれていません。
手法はスクラム開発やXP開発などになります。この名前が出てこない場合はニワカなアジャイル開発チームである可能性が高いです。
アジャイル開発導入は正しい観点を持って実行しなければ、ただの場当たり開発になっているだけで、アジャイルな状態にはならないことが多いでしょう。
"場当たり開発"と聞いてうまくいくと思うでしょうか? いいえ、失敗は約束されたようなものです。
"場当たり開発"と"アジャイル開発"の違いがちゃんと分かるようになってからチームに導入しましょう。
しっかりと知識を得て、チームの状態に合わせたプラクティス選んでから実行しましょう。

Q. アジャイルだから仕様はいつ変えてもいいよね?
A. はい。いつ変えても大丈夫です。ただし、そのコストは掛かります。
コストを考えながら設計を行うことは当たり前です。何を目指すべきかを最初に想定して最低限変化に強いアーキテクチャでシステムを作るところからアジャイルは始まっています。
変化に強いソフトウェア、CI、CDなども含めた開発環境もアジャイルの一部です。
ここも場当たりにならずに、アーキテクチャの変更は大きなコストを払うことになるため、しっかり設計してから実装を行う必要があります。
つまり、仕様の洗い出しは出来る限り最初に行うべきです。ただし、ウォーターフォールのように全ての機能の仕様が出来るまで開発をしないというわけではないです。
開発する機能に関わる部分の見通しが立ち、チームで合意が取れれば、その最小機能は実装を初めて構わないです。
このチケットサイズの運用こそ、アジャイル開発を上手く行かせるためのポイントの1つでしょう。

Q. アジャイル開発をするとモチベーションが上がる?
A. ウォーターフォールも正しく行えば素晴らしい開発手法です。
何が良くて、何が苦手なのか。特にSIのシステム開発では納品機能とスケジュールが契約によって縛られているため
アジャイル開発との相性はあまり良くありません。
どのような契約形態でユーザ企業とSI企業が契約するのかというところから、すでに十分なアジャイル開発の活用が出来るかどうかが始まっています。
ユーザ企業の中のシステム開発部門、もしくはWebサービス開発そのものがコア事業となっている会社の場合はアジャイル開発は合致するでしょう。
アジャイル開発は価値に焦点をおいた手法です。契約に焦点を置かれた状況ではウォーターフォールがマッチするケースは多いです。

勘違いアジャイルとは?

ものすごくシンプルに知識不足のケースが多いと思います。
適当に始めるのではなく、まずは勉強するところから始めてみましょう。
少なくとも3冊くらいアジャイル関連の本を読んでからが良いかなと思います。

少しだけおすすめする本を載せておきます。

アジャイルサムライ−達人開発者への道− http://amzn.to/2volRcv
おすすめ理由: アジャイル開発の基本的な考え方を全体的に簡単な言葉でまとめてくれていて読みやすい。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
http://amzn.to/2vdKY1v
おすすめ理由: 見積もりとはどういうものなのか、生き物のように動く見積もりをどのように管理するのかがとても良い

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術
http://amzn.to/2vdNnck
おすすめ理由: スクラムという手法についてと、それをベースとしたプラスアルファの観点

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング
http://amzn.to/2w1tGlC
おすすめ理由: XPという手法について

他にも色々良い本があると思うので、おすすめがあったらコメントで頂けると嬉しいです!

22
18
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
22
18

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?