アジャイルを考えたやつの死を願うスレ Part.5
ウォーターフォールでも人が少ないければ1人アジャイル状態だからな
でも1番違うのは責任の所在がちゃんと組織の上の人間になること
これがアジャイルだと開発者のせいにされて実質責任丸かぶり
ウォーターフォールはきちんとテストをしてなかった場合は上の人間の責任になるから アジャイルは基本、1人要件定義、1人開発、1人テストだから
誰かと情報共有したり説明したりするための
しっかりとした資料を作らなくてもいいんだよね
そのかわり継続、保守性は全くない >>22
違うよ。例えばWindowsの開発とかにアジャイルが使われてる。
マイクロソフトにおけるアジャイル開発はこんな風に進められている
https://www.publickey1.jp/blog/10/post_107.html なるほど
だからいつまでたってもバグだらけなんだ
2022年になってもまだハングアップするExcelとかだしな >>24
マイクロソフトを超える製品作れない時点で
説得力なしｗ 落ちないアプリで比べるなら
マイクロソフトの製品よりもずっと落ちない
フリーウェアを作ってるけどな(笑) そのフリーウェアはマイクロソフトのOSが落ちない前提で動いてると言うね（笑） まさかアプリを作った程度でOSを超えたとでも思ってるのか？ 話の論点がずれてるよ
アジャイルだったらコーチにぼろくそに言われるよ >>31
末端の開発者が頑張るのがアジャイルだって
説明してる本持ってこいよ >>31
うちの現場もそう
ひたすら開発者がいろんなことやらされている
>>
午前4時半にレスとかあんたは社会人じゃないよね >>33
ウォータフォールの会社で
人生壊された元プログラマですが何か？
開発が遅れたのはあとから仕様変更しまくったからだろ
使ってみなきゃわからないって言うなら
ウォータフォールやるなっての。責任押し付けるな。 >>31
いまアジャイルでやってるけど、俺もそれ感じる。
1案件が2週間程度と短すぎて、先の作業見通しが立たないわ。 だからアジャイルは長期プロジェクトで使うものだって
なんで日本って小さいものに使おうとするのかね？
短期間なら何度もこれでいいかって顧客に確認する必要ないやろ SI指向の場合、作ったソフトウェアが使えるかどうかは関係ないからな
重要なのはカットオーバーに間に合わせるだけ
これが自社開発だと、作った後に利益を出さないといけない
結果ウォータフォールは使えないものばかりができる >>40
あってるぞ。
ウォータフォールは、使えるソフトウェアを作るかどうかなんて考えず
ただ、カットーバーに間に合わせるだけだから使えないものができるんだ 稼働前の並行稼働期間やユーザの受け入れテストって知ってる？
そこでオーケーがもらえないとカットオーバーやリリースできないんだよ
知らなかったでしょ？
アジャイルは全くやらないまま、2、3項目のテストだけでリリースするけどね ウォーターフォール
受け入れテストでok出たから以降は別契約でお願いします
アジャイル
お客様の満足を求め続けます なにその奴隷
ビジネスじゃないね
統一教会の人かな(笑) >>42
オーケー貰えるとリリースできるよｗ
ほとんどの人は、不満があってもリリースできない、または
手戻りで倍ぐらいコストがかかるとなると
諦めてオーケーするんだよｗ >>43
コーチ「お客様のために」
開発者「お客様のために！」
コーチ「満足を求め続けます」
開発者「満足を求め続けます！」
コーチ「それが私たちのミッション」
開発者「それは私たちのミッション！」 これがアジャイルの末路
2022.06.06 PlayStation®4版『けものフレンズ３』サービス開始！
ttp://mac16.sitemix.jp/rurl/?lmth.dgt5dm3e495700/liated/ofni/pj.3-sdneirf-onomek//:sptth
2022.06.16 PlayStation®4版にて正常にログインを行えない不具合について
ttp://mac16.sitemix.jp/rurl/?lmth.iBMzsQ3Q476700/liated/ofni/pj.3-sdneirf-onomek//:sptth
2022.08.02 PlayStation®4版『けものフレンズ３』サービス終了のお知らせ]
ttp://mac16.sitemix.jp/rurl/?lmth.k7EHRwc4798700/liated/ofni/pj.3-sdneirf-onomek//:sptth 属人化した開発者がとんずらして
ニッチモサッチもいかなくなったんだろうね アジャイルはアメリカでも日本と同じ問題があるね。動画向けとは言え発音が聞き取りやすい
https://youtu.be/OosYzkP-pLk >>51
最初だけ聞き取った
プロダクトオーナーが無数のバックログを積み上げ
その中から次のスプリントでベストを取り上げるのはアジャイル性がない
アジャイルでなくウォーターフォール バックログが滝を使用する必要がある可能性を示す７つの場合
使用指標がない
各スプリントの最後にソフトウェアをリリースしない
バックログが各スプリントの前に並べ替えられない
無駄な機能がバックログから削除されない
フィードバックに基づいてリリース後に新機能が追加されない
すべてのユーザーストーリーに見積もりと受け入れ基準がある
リリースされたもののビジネス上の成果でなく開発チームの生産性によって成功を測定する >>43
>アジャイル
>お客様の満足を求め続けます
前にいた案件がこれで夏休みも3日、年末年始も3日の休みしかもらえなかったよ
全てはお客様システムの運用のためにためにずっと人力で見張ってたよ
今はウォーターフォールの案件に入ってこの夏休みは1週間もらえる
ほんとアジャイルは、仕事しか生きがいのない気違い奴隷のすくつだよ アジャイルは主力の開発者が疲れて辞めた時に、
ガタガタガタガタガタ〜と崩れていくイメージがある
本来のアジャイルは弱者を排して強者だけで開発を回すためのものだけど
現実のアジャイルは一人の有能に無能が大量にぶら下がり足をひっぱる形になりやすい
すると一人か二人の有能に負担が集中する。そして最後には磨耗して辞めていく >>54
うちは逆だな
ウォータフォールの案件でもう2人死んでるよ それウォーターフォールに見せかけたアジャイルだから はぁ？予定の期限半分で作れって言っといて
どこがアジャイルんだかｗ ウォーターフォールで立てた予定は
だいたいいつも半分で終わらせるもんだけどな
もしかするとあんたが超絶な無能なだけかもしれないな
アジャイルに行くと、脳内お花畑のリーダーに
2日で作れとか言われるんだぜ アホやなｗ
最初の予定の半分になるって話で
上流工程が無能なだけだ >>59
おれなんて納期を過ぎるまで上流が仕様決められずにグダグダやって
納期翌日にやっとペラ2枚の仕様書なるものが出てきたと思ったら
「あとはアジャイルで間に合わせろ」と言われて
結局は運用開始3分前にデプロイしたことあるぞ
今でも顧客企業と上流さん達は毎年集まって交流会してるらしい
おれたち「アジャイル部隊（）」は存在しないことになっているらしい
もう二度と関わり合いたくない連中だ 上流「アジャイルなんで3日もあれば動くものができますからね
リリース後も頻繁に改善していきますからね、安心してもらっていいですよ」 ただしリリース後の作業にお金を払うつもりは毛頭ない上流であった アジャイルは案件ごとの契約なんてしない
月極でひたすら開発者を使いたい放題
ギガ制限なしのスマホのようなもの
1日20ギガ使っても問題ない POはアジャイルと言っているがウォータフォールの案件にいる
10月中稼働目標と言っているがデザインすら決まって無い時点で無理って分かって欲しい
デザインは別会社ね なんか一向に中小企業や人に技術が蓄積していかないような
麻薬を用意された感じだなって今は思ってる
スポンジのように吸収して、スポンジのように全部掃き出し、また次のものをスポンジで吸収
何も残らなくてそのうち破けて終わる >>66
それって上流のないウォーターフォール
すなわちアジャイルだよね
>>67
うんうん、アジャイルではよくあること 流行りの技術とライブラリに依存するとほんと後で捨てるしかなくなるよな
かといって素のJsで書いても非推奨コードにもなるしマジ答えが無くて困った ある程度の依存はどうしようもない
書いてから10年動けばいいよ アジャイルだとオープン型のライブラリやフレームワークをガリガリ使いまくってて
脆弱性が発見されると何の躊躇もなしに本番環境でもアップデートしてくんだな
案の定動かなくなって驚いちゃったよ(笑)
こんなの銀行やライフラインを構築するシステムじゃありえないよ アジャイルはイレギュラー対応が極めて弱いからな
緊急対応などはウォーターフォールの方がやりやすい オライリーのユニコーン企業の秘密って本では「アジャイルとかもう古いよ、次だ次」って出だしから始まる
内容は知らん 時代はだいたい30年周期で繰り返すから、2010年代に勃興したアジャイルも
プログラミングが始まりだした1980年代を繰り返してるだけなんだよな
最初は仕様書なし、プログラミングが好きなやつが熱中して作れ、だったのだが
前の周期に当てはまらない人たちが考えると、やっぱり同じことの繰り返しなるんだよ ウォーターフォールは顧客の課題解決のためでなく契約を守るためにある
よって使えないゴミができる
必死こいて作ったものが実は誰も使ってませんはよくある いいじゃない
それでがっつり金がもらえるんだから
本当にプログラミングをやりたければ
自分でアプリを作るよね 契約は打ち切られる上に使えないもの作る会社に二度と発注されない 受注アジャイルで納期遅延で訴訟問題になるのとどっちがマシってだけ 最近、アジャイルが主流のモバイル回線系やゲームサービスが
軒並み障害やサービス終了になってるね
いわゆる立ち上げ期を過ぎて継続期に入るわけだけど
ここで突貫工事で作り上げてきたアジャイルが破綻し始める
ゲームサービスならさっさと終了してしまえば良いけど
回線系はこの先もずっとサービスを維持していかなければならない
おそらくこれからも障害はどんどん多発していくだろう アジャイルでサービス始動期をのりきったら
それとは全く別のコードベースで継続期用のコードを書くべきなんだがな
WF時代の大手SIerはだいたいそうやって2バージョンをリリースしてた
アジャイルでイケてる技術コンサルとかは知らない世界 創造と破壊を異常な速度で繰り返してるだけ
アプリが消耗品であるように中の人もPGも消耗品や アジャイルの要件定義
コーチ
じゃあ、ホテル建てようか
高さは50メートル位、部屋数は50位でいいんじゃない
アジャイルの開発フェーズ
コーチ
じゃあ、細かいことは全部開発者で決めて
わかんない事は全部顧客に聞いていいから
スキルアップのためがんばってね >>86
プログラミングは設計なのか建築なのか？
それで解釈が変わりそうだ >>86
そして九龍城のようなシステムが出来、
壊しては作り直してまた九龍城になり、
を永遠に繰り返すのがダメアジャイル 仕様変更が重なると
ウオーターフォールでもそういうことになるけど >>86
要件定義はコーチの仕事ではないぞ
単に無知を晒してどうする 正確な定義は仕事ではないが
方向性の確認となぜそうするのか
意図はなんなのかを明確にしておくのは
コーチの責任
いきまわかっててる情報で勝手にゴーサインをだすのは
コーチの仕事ではない >>91
そうなんだけどね
コーチと要件定義者を2人雇うほど余裕がなくてね
じゃあどっちのスキルが高い人間を雇うかというと
なぜかコーチスキルの高い方なんだよね(笑) >>82
できるならそうしたいけど、
中小企業だと現状のシステムを保守するメンバーの他に
新規開発するためのメンバーを別チームで作る人的な余裕がない >>93
ずっと言われてるがもはやアジャイルでもなんでもないな アジャイルの開発チームは若い
そしてリーダーも若い
若いと言う事はビジネス経験が少ない
経験が少ないと言う事は相手の言いなりになる
つまり
アジャイル開発とは客の飼い殺しの屠殺場になる
さらに
メンバー全員の経験が少ないので
自分たちが飼い殺しされていることに気がつかない まぁ、このスレだいたい昭和40年か50年代の生まれだよね・・・ アジャイルの若者が最新だと思ってるやり方は
だいたい20年前にはSIの現場で定着していた
単にカタカナの用語に名前を変えただけ いや俺も20年やってて両方やってるけどそうではないんじゃないかな 「アジャイル（Agile）」が広く知られるようになったのは、2001年に「アジャイルソフトウェア開発宣言」が出されてからです。
2000年以前に開発された比較的歴史の長いアジャイル開発手法には次のようなものがある。
スクラム (1986)
Crystal Clear
エクストリーム・プログラミング (XP) (1996)
Adaptive Software Development
ユーザ機能駆動開発 (FDD; Feature Driven Development)
Dynamic Systems Development Method (DSDM) (1995) まあそりゃそうなんだけどさ
日本の開発の現場で20年前なんてやっとOOPの阿鼻叫喚がマシになってきてウォーターフォールなんてちゃんとやってりゃマシな方くらいだから 日本にウォーターフォールの時代はない
行番号BASICerやCOBOLerが手探りビルドでなんちゃってアジャイルをしてたのがはじまりであって
今現在までずっと続いている
外形的にはウォーターフォールに見えるように資料やスケジュールを書くかもしれない
しかし、中身はアジャイル（けして胸を張れるほど立派なものではないが）に分類される開発手法だ
日本人がアジャイルを喜んで歓迎したのは、まるで自分たちのやり方に名前がついたように感じたからだ
今まで「本当はウォーターフォールが正解だけど自分たちは未熟だから違う方法をとっている」と思っていたのに
「あなたたちがやってる事こそ最新なのです」と言われた（ように錯覚した）のが日本におけるアジャイルの見え方
少なくとも昭和生まれにはそう見えたんだ >>103
あのさあ、
2000年以前の日本のソフトウェア産業には
BASICとCOBOLしかなかったと思ってるの？
なんともはや… >>104
TurboCやVCでちまちまやってた頃じゃん
ACOSやUNIXやってた人でも結局は出自は行番号BASICとかアマチュア無線やってた層
当時の仕様書みたって当時現役だった人に聞いたってウォーターフォールやってたとは思えないよ ここで話してるような現在アジャイルじゃない何かをやっている程度のところは知らんけどデータの大規模案件の話なんか聞くと完全にWFだったけれど
俺自身は外資だけど2010くらいまではWFでクリティカルパスがどうのこうのとかやってたよ >>107
知的障害者発見
何が間違ってるか言うべき まず「これがアジャイルだ」といえるほどの教科書がない そもそもその状況にかなりフレキシブルに合わせるのがアジャイルなので教科書通りというのが合わない
もちろん原則的な部分ではあるけれども それ以前にアジャイルというのはアプローチでしかなくて
特定の方法論を指すものではないし
今はやたらスクラムが流行してるけど、正直、あれがアジャイルとは思えない
作業を細かく分割してワーカーを常時稼働させてるだけで
理解の共有なんて全然できない
わざわざ人数かけて頑張ってる感を演出してるだけ いかに人を張り付かせて
働き続かせることができるか
これがアジャイルの本質 >>111
自分のプロジェクトの問題が
１. ワーカーを稼働させてるだけ（で生産性は低い）
２. 理解の共有が全然できない
３. 人数をかけてるのに頑張ってる感を演出しているだけ（で生産性が低い）
だとわかってるなら直せば良いのでは？ アジャイルやろうぜ、とチームで意思共有される時に
「そもそもアジャイルとは〜」なんて滔々と語り出す奴がいれば、
キチ扱いされると思うけど
いまだかつてリアルでは見たことない >>115
え？
新しい言語を使うのにちゃんとリファレンス読まずに
なんとなくでコード書いちゃうタイプ？
それ、周囲がいい迷惑だから、もうちょっと「学ぶ」ことをしたほうがいいよ >>114
アジャイルアジャイルうるせーやつ外したら正常に戻ったよｗ 
