アジャイルとウォーターフォール 2022

松下正嗣 @masatsugumatsus

@nagise あと、統合ですね。コンポーネント間インタフェースを厳密に定義しなくても良くなった

なぎせ ゆうき @nagise

@masatsugumatsus ちょっとニュアンスが掴めてないのですが、この「統合」というのは因果の原因側です？結果側です？

松下正嗣 @masatsugumatsus

@nagise 原因ですね。複数人やチームで開発したコンポーネントを毎日繋げつづける。昔は結合テストやろうとしたらそもそもコンパイルできないとかあったかと。だから、詳細設計書が必要だった、という仮説。テストなくてもそれだけでも違う

きざみねぎ @rabbitchi_no

@saorisuganbaru チーム開発においては如何にメンバー間での齟齬をなくすかが時間の短縮に繋がります。 また、予めしっかりと要件定義や設計をしておけばあとの修正が少なくなる他、修正自体もそこまで大変ではない(顧客のわがままを除く)のでできるだけしたほうが良いです

SUZUKI Masaki@クラウドエンジニア @makky12

@WjgotINrU14Z1fB 要件定義や基本設計が割と明確になっているいる(作るものが割と明確になっている)なら、アジャイルよりスムーズ、とかですかね。もちろん元リプの通り、手戻りリスクはありますが

寺野 克則（ITだけど営業視点のアカ） @WjgotINrU14Z1fB

@makky12 身も蓋もねー話だけど、明確なケツ置いて「やらせ」ないと、進まねーチームが多いんだと。

なぎせ ゆうき @nagise

@masatsugumatsus ふむー。まだピンと来てないですね……。 コンポーネント間の結合のためのバージョン管理がGitによって利便性が増し下支えしているみたいな感触はありますが

なぎせ ゆうき @nagise

@masatsugumatsus コンポーネント間の接続のためのドキュメントは結局現代でも必要であろうとは思うわけで

松下正嗣 @masatsugumatsus

@nagise バージョン管理もありますね。まあ、言いたいことは、テストがそんなにちゃんとなくっても相当大きな意味があるってのと、ウォーターフォールでどうしてあんなにドキュメントが必要だったのか、という仮説です。当時は意味があったはず

なぎせ ゆうき @nagise

@masatsugumatsus 現代はそもそもそこまでのドキュメントいらんやろ、当時はなんで必要だったんだ？ということですね。

松下正嗣 @masatsugumatsus

@nagise 詳細な関数レベルでは不要かな、と。

Keita Software Engineer @w_keita_1023

寄って集って新人に嘘を教えないで…。どこの書籍にウォーターフォールの利点が書いてあるのよ…。20年以上前からウォーターフォールはソフトウェア開発に使うべきでは無いって結論出てるのに…。 twitter.com/saorisuganbaru…

さおりす @saorisuganbaru

大規模開発の規模感があまりイメージできてなかったですが、コメント読んでいくと思ったよりもウォーターフォールも悪いものではないことがわかりました。

2022-04-28 07:51:10

松下正嗣 @masatsugumatsus

@nagise ですね。

カジハラ @prog_evolution

@w_keita_1023 横からごめんなさい！ 20年前からウォーターフォールを使うべきではないと言われているのは知らなかったです！ 当たり前のようにシステム開発はウォーターフォールで進んでいくものだと思っていました…

杉本啓 @sugimoto_kei

スキルがないという問題は、アジャイルにしたからといって癒されないよね。ウォーターフォールだとしんどいとか、オーバースペックになって却ってコストがかかるといった場合はあるにせよ、W/Fだから失敗するということはそんなにないと思う。スキルがないのを手法の問題にすり替えているだけ。

Keita Software Engineer @w_keita_1023

@prog_evolution 米国は2000年くらいにはもうアジャイルじゃないとダメじゃね？ってなっていたみたいなんですよね。かなり日本は遅れています。

杉本啓 @sugimoto_kei

W/Fを基本形とし、どうやってそれを実践的に崩していくか、と考えた方がよいように思う。 弊社では、変更案件を小さめに区切り、それごとにユーザー側と開発側のメンバーが組になって、業務要件定義→システム仕様の設計→実装／テスト→受入テストというようにW/F的に進めるということを始めている。

gizumon@Webエンジニア @gizumon5

@saorisuganbaru 日本だとシステムが外注なことが多いので、作る前に期間と成果物をがっちり決める必要があったりするのかなと思います！ ケースバイケースですが、 内製で開発されているところなどは、アジャイルの方が上手く進むこと多いと思います。

Kumakichi @Mr_Kumakichi

@saorisuganbaru ウォーターフォールも昔みたいなガチガチの一方通行って減ってきている気がします。 しかし、要求定義者と仕様書を最初に作り込んでおかないと手直しの幅が大きくなってしまう、ということが往々にしてあります。 あとはプロトタイプを適時作っていくのが多いように思います。

杉本啓 @sugimoto_kei

小さなスコープにW/Fを適用し、多少の仕様変更は許容しながら、でも最初に考えた根幹を崩さずに、目的にかなった、動くソフトウェアと業務のシステムを作り出すことができる、というのがすべての基本だ。これをできないひとがアジャイルならーとか言っても意味ない。

komitsubo @komitsubo

これはまさにそうで、結局ウォーターフォールは分析して、設計して、実装して、評価するといってるだけで、これはおかしな話じゃない。大事なのはこのサイクルを環境、状況によってフレキシブルに変える事って話のはずなのにゼロサム理論が多いは残念な話だとしみじみ思う。 twitter.com/sugimoto_kei/s…

KEI @isheik8

これは本当に感じる。アジャイルが長期でしっかり回るのかはエンジニアのスキルありきで積み上げをちゃんとしていける……デザインパターンなどを適切に使って拡張性が高いコードが書かれていることが前提だと思う。 そうでないとどっかで行き詰まり積み上げたものを捨てる必要に迫られそう。 twitter.com/komitsubo/stat…

komitsubo @komitsubo

ウォーターフォールでもアジャイルでも結局大事なのは参加者のエンジニアとしてのレベルな訳なんですが、分業化も想定されているウォーターフォールよりアジャイルの方が求められているスキルレベルは高いのに、アジャイル界隈の人はそこに触れずに良さだけを伝えているのはどうなのかなと思う。

2022-04-27 11:35:05

松下正嗣 @masatsugumatsus

@yattom まあ、そういう見方もあるって程度と思っていただければ。あと、CIその他のプラクティスの前提になっている気もしてます

izoc @izoc

仰る通り非効率で過去の産物です。利点というよりウォーターフォールでやらざるを得ない構造だからかと。バッチ廃止してマイクロサービス化して他のシステムと足並み揃えずにバラバラにリリース出来るようにしないと無くならないですね。 twitter.com/saorisuganbaru…

さおりす @saorisuganbaru

ウォータフォール開発って無駄にしか思えないんだけど 誰か利点とか教えて! 先に設計図作っちゃうと、小回り聞かないから完成後にドキュメント作った方がいいんじゃないかと思ってしまう。 #駆け出しエンジニアと繋がりたい

2022-04-27 17:43:11

カルロスわらふじ @RyoMa_0923

なんかこれを思い出すツィートを見た simplearchitect.hatenablog.com/entry/2016/06/…