現在の開発の流れ
受付中
回答 2
投稿
- 評価
- クリップ 1
- VIEW 975
退会済みユーザー
現在の開発手法を教えていただきたいです。
現在アジャイル開発などで、行うところが多いと思うのですが、具体的にどのような道重を辿って完成に至るのか教えていただきたいです。
アジャイルでもウォーターフォールでもプロトタイプでもいいので、最初はこれをして次にこれをしてというふうなことを知りたいです。最初はヒアリングだと思いますが。
UMLを用いたモデリングとかはがっつりしたりするのでしょうか？
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
+4
ざくっとですが
- 要件定義＝何を作るのか
- 設計＝どうつくるのか
- テストを書く＝何が正しいのか
- 実際の開発＝ものづくり
- テスト＝正しくつくられているか
を回していく形ですね
もちろん粒度を小さくしてこれらのループを再帰的に回していくのは言うまでもありません
いろんな見解があると思いますが、それを
- 大きいスパンで回す(ウォーターフォール型)
- 小さいスパンで回す(アジャイル型)
みたいに考えれば、どっちが正しいとかはないと思います
大きな予算を取ってってなるとウォーターフォール型開発でないと依頼主が納得しないでしょうし、継続的に予算を確保できるならアジャイル型開発で小さく産んで大きく育てるなんてことも可能でしょう
ただ何でもかんでもアジャイル型でってすると、依頼主の上層部から「で、システムはいつ完成するんだ」的な収束しない事態に陥る可能性もあるでしょう
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
+2
開発が「完成する」という発想で、何をしたらいいか順番に・・と考えると、単純にウォーターフォールの開発になります。
dojikkoさんのステップを2年で1回まわせばウォーターフォールで、2週間で50回まわせばアジャイルでそれは間違いないですけど、2年と2週間では実際の作業は全然違います。
2週間で1回がまわるようにするには、UMLは・・なんて呑気なこと言ってないで、1日目のヒアリングである程度動くぐらいでないと、たぶん14日後=10営業日で本番にのせるのは無理です。プログラマーはその場にいて最初からコードがわかる必要があります。各種の場合分けに対応し、例外を織り込んで、テストして確認をとってリリースしたら10日はすぐ終わります。
「手順？いいからコードを書け！」みたいな感覚が伝わるかと思います。
UMLが不要とは言いませんが顧客が必要としたら「後で」作るものとなります。作業報告だったり、スケジュールのガントチャートだったり開発に必要なくても、作らなくてはいけないものは出てきます。
50回の20回目を想像していただきたいのですが、だいたい40回あたりで何が起こるかはわかるようになるのです。
顧客側もリズムをつかむので、要求の大きさと予測される開発速度がわかるようになります。無理をいってもできないというのが理解されます。プログラマーができないとその場で言えば、できないものはできないので、やり方を考えようという話になります。また予算が一定になるので、長く続けるなら契約は同じ内容同じ金額で更新するだけなので、大規模な開発でも安心して続けられる状態になります。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
