Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
Help us understand the problem. What is going on with this article?

アジャイルを経験してから、ウォーターフォールを経験して

More than 1 year has passed since last update.

はじめに

今年の途中まで、アジャイル型のプロジェクトを経験。
昔も、どちらかと言えばアジャイル寄りのケースが多かった。
今は、Web系でウォーターフォール寄りの開発をしている。

書きたい事は、すでにWikipediaにだいぶ書かれていた。

アジャイルソフトウェア開発-Wikipedia

https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA

なので、個人的な経験を中心に書きます。
機密保持の関係で、抽象的な表現が多くなりますが、お察しください。

「基本みんなコードを書く」文化からのカルチャーギャップは感じた

今主に担当している案件が、エンド(顧客)へのヒアリングや折衝、それを要件としてまとめて外国籍のブリッジSEに伝えるような仕事がメインなので、そこから先のシステムを設計してコーディングしてー という部分は他の人が担当することになります。

最初はもどかしさを感じた

今までは、コードやチケットさ仕様書といった文化も多かったので、細かい仕様書を用意して、自分は作らない・・・という部分で、自分ならすぐ改修できるはず。というもどかしさを感じた事も多々ありました。

各工程に専念するから、それぞれの担当パートでパワーを発揮できる面もある

もどかしさを感じた反面、開発が始まると進みが早い。

私は、顧客の考えを噛み砕いて案を出し、何を作れば良いかを導き出す事に専念する。
ブリッジSEは、その仕様を海外のプログラマが進めやすいように整理する。
海外のプログラマは、確実に動く物を作ることに専念する。

比較優位や最適化問題などの言葉も思い浮かぶ。
(それぞれの得意分野や、コストを考えたら誰が何をするかの解も出てくる)

このケースでは、積極的にアジャイルを採用する必要はなかった 

以下のような事情もあった。

  • 一部を除けば、仕様を固めてから開発する事ができた。
  • 開発済の部分に与える影響は少ない。
  • だから、部品事にドカンドカン作っていく方法を採用できる。
    • 作る側に取っては、その方が作業しやすい事も多い。
  • メテオフォール 影響の大きい仕様変更の危険が少ない。

口直しに、明らかにアジャイル型のチーム体制が向いているケースを

個人的には、やっぱり「運営中の」ゲームアプリなんじゃないかな?と思ったり。

  • ソフトウェアが直接的に人命を危険に晒さない。 - 財布に致命的なダメージを与えるケースはあります。
  • 仕様変更は頻繁にある。細かいところで言えば、微妙なパラメータ調整とか。 - 今の時期、クリスマスキャンペーンとかね・・・。
1stMinos
サーバサイドの処理をメインにやってます。 Ruby、PHP、JSなどを使ってます。
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away