-
Tanaka9230
- 20216
- 118
- 74
- 47
-
- いいね！47
トミナガ・ジョージ
@leavethesier
ナアナアな開発して、後でいつの間にかすごい規模になってて、運用過渡期に嫌になってトンズラする人たちは、大抵WFやりきったことがない人が多い。新規開発だけで食いつなげるなら良いけど、そろそろ買収や淘汰の波で収束すると思う。
2022-04-28 00:19:20
GarnetConsulting
@gcltd_cons
@WjgotINrU14Z1fB きちんと要件定義出来てて設計も済んでいたらめっちゃ速度出ますよね あとは、アジャイルより作業分担しやすいとかですかね？
2022-04-28 00:19:21
トミナガ・ジョージ
@leavethesier
スタートアップに逃げても同じ道を辿ることになる。伸びる事業ならいつかは大規模になるし、品質を求められる。最近、大きくなったweb系が露骨にSIer出身者を採用するのはそのため。規模感はかなり巨大になりつつあります。
2022-04-28 00:24:28
幻鳥@沼先案内人
@2nd_junkey
人間の把握出来る範囲って限られてるから、ある程度のサイズを超えると「考えなくていい領域」を作らないと破綻する。 で、全体を切り分けていく方法がウォーターフォール だったんだけどなぁ？(横車に轢かれる twitter.com/saorisuganbaru…
2022-04-28 00:27:13
さおりす
@saorisuganbaru
ウォータフォール開発って無駄にしか思えないんだけど 誰か利点とか教えて! 先に設計図作っちゃうと、小回り聞かないから完成後にドキュメント作った方がいいんじゃないかと思ってしまう。 #駆け出しエンジニアと繋がりたい
2022-04-27 17:43:11
ふれーむ
@ditflame
@saorisuganbaru 先に設計図を作ると小回りが効かない ではなく、小回りを効かせる必要が無いぐらいまで設計を事前に作り込んで一気に実装・テストまで駆け抜けましょう という作戦ですね。仕様が明確であればトータル開発コストは低くなります。（理論上はね…）
2022-04-28 00:27:54
山慎
@yamashinn
@WjgotINrU14Z1fB ある程度の規模になると手法に関わらず、設計書、というか言語化された共通認識がないと、それぞれがこうなるつもりだったの差が埋まらなく、要求事項の担保が難しくなりますねー。気にされている点は手法の話ではない気がします。
2022-04-28 00:29:05
riraosan
@riraosan_0901
@saorisuganbaru オールドタイプですけど、今、アジャイル（スクラム）開発で試験をしています。 ウォーターフォールは今となっては何の利点もありません。超非効率なオワコンプロセスです。（すでに知っていると思いますが。） おそらく人間が神になって、全てを過不足なく予想出来るなら成り立つプロセスです。
2022-04-28 00:30:06
rikuyam
@ripry_
型とテストとコードだけで十分な情報量になるから、これでウォーターフォール的なフローと向き合えるようになればかなり強いなぁと思ったり
2022-04-28 00:31:48
寺野 克則（ITだけど営業視点のアカ）
@WjgotINrU14Z1fB
@yamashinn ウォーターフォールの利点がわからんって話でしたので。 まあ、MVCすら無駄な、小規模開発の文化か。もしくは『その手の宗教の方』からの薫陶を受けた、若手の方かなあと。 いずれにしても、中規模以上の話ではなさそうな印象ですね。実際ドキュメントが不要なんでしょう。
2022-04-28 00:46:01
山慎
@yamashinn
@WjgotINrU14Z1fB ほんといろんな世界があるんだなと感銘をうけますが、もうちょいしたらプログラミングネイティブな世代も入ってきますし、不幸な人が増えないよう業界の環境整備してあげてほしいですねー。
2022-04-28 00:54:02
豚野郎
@TechPig2019
でかいプロジェクトだとウォーターフォールじゃないと辛いよなぁ。。。 映画のコンセプトアートのようなものでみんながみんなが走り出せるなら良いと思うけど。。。 twitter.com/saorisuganbaru…
2022-04-28 01:35:15
康平🇩🇪エンジニア
@kotsuka701
@saorisuganbaru 経験から言うとシステムが複雑なほどコーディングする前に設計をしないとチーム間の摺り合わせが難しいし、工数の見積もりや計画をするのも難しいと思います。
2022-04-28 01:50:47
chio
@chio_pkmn2gen
わかる 僕も三年目ぐらいの頃は 「アジャイルさいっきょ！」 と思ってた （共産主義と一緒で、若者が一度は憧れるものかと） 端的に言うとこれです ・品質を積み上げることが結局は近道 ・ドキュメントは開発体制の維持で必要 ・不明点を先回りで潰す、問題点を後戻りで潰す、ぐらいの柔軟性も必要 twitter.com/saorisuganbaru…
2022-04-28 06:12:17
えび＠プログラマー
@ebiebi_pg
業務系の現場では「アジャイル開発」って非現実的 スキルがどうのこうの以前に文化が違う もし業務系の現場で「アジャイル開発」という言葉を聞いたら「あー、工数減らしたいだけなんだな」くらいの認識で捉えておかないと痛い目を見る
2022-04-28 07:21:59
なぎせ ゆうき
@nagise
契約とか計画に目を向けるとウォーターフォールにしたくなるんだろうなあ…… 試行錯誤という計画も予算取りもしづらいのものが開発の核心であって……
2022-04-28 07:46:22
なかじ@DIGITAL Forward
@nakajima3371
@saorisuganbaru 大規模で何十人何百人も開発者がいるプロジェクトを考えてみるといいよ。 例えばビルを建てるのに設計書を後から作るって有り得ないでしょ。 とはいえ、今どきのプログラミング言語はオブジェクト指向だからアジャイル的なやり方をとるケースは確かに増えてるかもね。
2022-04-28 07:46:46
T.Sax@ES
@T_SaX_From_Tp
組み込みだとハードと足並み揃えるにはウォーターフォールの方がやりやすいのよね。 ・ハードができないと評価を進められないことが多い ・ハードを作ってる間に設計とコーディングが進められる。 ・ハード評価は仕様制限をかけれないことが多い。(未完成部分があると困る) twitter.com/saorisuganbaru…
2022-04-28 07:50:33
さおりす@いつか道を極めし者
@saorisuganbaru
大規模開発の規模感があまりイメージできてなかったですが、コメント読んでいくと思ったよりもウォーターフォールも悪いものではないことがわかりました。
2022-04-28 07:51:10
T.Sax@ES
@T_SaX_From_Tp
実際は設計、コーディング、評価の大筋な流れはウォーターフォールだけど、評価に入ると仕様追加や変更が出てきてアジャイルみたいに回すことが多いですね。
2022-04-28 07:53:14
なぎせ ゆうき
@nagise
テストのコストが下がることで初めて継ぎ足し継ぎ足しの開発が可能になった…… twitter.com/masatsugumatsu…
2022-04-28 08:05:15