アジャイルを考えたやつの死を願うスレ Part.5
このスレのアジャイルに対する誤解と偏見がすごいな
いまだにウォーターフォールに固執してる感じもやばい
アジャイルが主流のアメリカがITで圧倒的な結果を出しているのをみればどちらがよいか明らかだろ >>701
アメリカのアジャイル率の統計データを見たこと無いだろ？ 日本固有の
目的も意図もない
上がいうからしかたなくシステムを発注する
という文化
これはどんな方法論を持ってきても駄目では? >>702
IT企業は9割以上一般の企業のITでも8割とかでいまマーケティングとかそのあたりの部署も使い始めてるレベルやで >>702
見たこと有るよ
ググれば色々出てくるが例えば
https://www.zippia.com/advice/agile-statistics/#:~:text=At%20least%2071%25%20of%20U.S.,more%20successful%20than%20waterfall%20projects.
要約は
・最低でもアメリカの71%がアジャイルを用いている
・アジャイルは64%のプロジェクト成功率。ウォーターフォールは49%
。アジャイルはウォーターフォールより1.5倍プロジェクト成功率が高い
・アジャイルに適用後、平均60%利益が伸びる 日本もウォーターフォールの採用率は80%以上で
そのうち95%が成功してるよね まあ海外のデータだとウオーターフォールでも8割程度は使えるものは出来てるんだけど
6割くらいは炎上してて炎上なしで綺麗に納品までいくのはわずか2割程度
残りの2割は納品さえされない or 納品されたけどクソすぎて使えない、文化シヤッターのような失敗例
炎上するのが通常営業でまあこの板の怨嗟を見てもそんなもんだなという感じやな
アジャイルも1割程度は失敗例あるけども5割程度は炎上せずに普通に納品できている
それでも5割だし1割近く使えるものが出来てないわけでどうなんだってのはあるけどちゃんとやれていれば
はるかにマシではある 受託が一番ウォーターフォールだから
アジャイルならGAFAみたいに受託なしでやるしかない 日本のプロジェクトは80%が受託なので
そもそもアジャイルで受託すると破綻しかない ウォーターフォールのプロジェクトだって炎上してるがな 炎上というか関係ないものができてしまうんだよな
そういう使い方はしないだけうとか、とうぜんひつな機能がなかったり
で、そッチの方が本質ということがよくある
これだとウオーターフォールて゜うまくいかない
スタートにのと゜かられ 使えないのを即刻クビにできる環境ならアジャイルのほうがよく回るかもしれん あのね
使える人間はみんながっつり捕まえてるの
だから次に雇っても
結局使えない人間しかやってこないの でも会社があやしくなってくると
使える人間からやめていくからなあ
そういうのを捕まえられる可能性はある くそったれなアジャイルプロジェクトから足を洗って丸一年
スッキリ健全なウォーターフォール開発で身も心も充実してるよ ウォーターフォールって不確実性が低く無いと成り立たないよな
要するにルーティーンワークだろ
そんな事やってても産業は成長しないわw 多層下請け構造できっちり契約で縛られてるからね実質ウォーターフォールしかできないんでしょ
結果ゴミしか量産できない ま、アジャイルやってる現場しか行かないわ
老害クソゴミ野郎達と一緒に働きたく無い アジャイルにつかると50、60になっても下っ端のプログラミングや
ログと格闘する保守ばっかりやらされるよ お前らの言ってるプログラミングってどの程度よ
githubのリンクはれよ >>726
無資格です
競プロやらないです
数学わかんないです
でもプログラミングしてるんです！ アジャイル現場
リーダー「使える有能が足りないの助けて！」
有能「こんな現場、ずっとやってたらおかしくなるわ、じゃな」
新しく人が入ってきても
有能な人ほど見切りが早いな 平均的な頭しか持たない日本人にアジャイルは無理だぞ ならぬものはならぬ
教育がステレオタイプの産業廃棄物を量産した
兵隊にアジャイルは無理
有能だけで集まってやるからお前らはウォーターフォールでゴミ作っとけ そうそう
うちも有能だけで土日も深夜もつぶして開発保守やっている
しかもくそ安い単価で アジャイルってほんとゴミだな
ウォーターフォールが最強だわ 経験不足のメンバーばかり集めて始まるアジャイルはリーダーがきついんじゃないかと思う。おれは絶対やりたくなかったけど流れでそうなって抜け出すタイミングも遅れてしまい適応障害になった。いまだに社会復帰できていない。みんなあとはよろしくな。 >>752
ログと格闘する保守は、イメージに反してスキル高い気がする
場所によるんだろうけど 現場ではみんなスラックで2ちゃん用語連発してるから
おそらくこのスレも見てるんだろうな
お前だよ、そうお前
ほら、ミーティング始まるからさっさとオンラインの準備しな アジャイルソフトウェア開発宣言の日本語訳もダメだな
それがダメプロダクト量産してる
そもそもそれすら読まないでアジャイル騙るアホが多いし アジャイルって小学生が考えた
「ぼくのかんがえたさいきょうのしすてむかいはつ」
でしかなくて
世の中を支えるいろんなソフトウェアの開発現場と
かけ離れているんだよな
この考えに感化された人たちが
そっくりそのまま現実の現場にやらせようとして
どの現場も破綻している
(もしくは支える開発者たちが奴隷化している) >>740
たびたび書き込まれてるけどウォーターフォールの弱点を克服しようとした結果、ウォーターフォール以前の無秩序開発になってしまった感 過剰な柔軟性のせいで、割を食う人が有能技術者が出てくるイメージがある
俺の前の職場の一番できる人にタスクが集中しすぎてヤバかった
見ていて辛い気持ちになる 普通はパンクする量のタスクが集中しても乗り切れる人に
無理やりタスクを投げまくるような形になりやすいのがネックかな
最後にその人が潰れて万事休す 恥ずかしながら昔は期待値を超えられるように最大限努力するのが良いと信じてた。しかもそういうのにどこか楽しさも感じてたから優秀ではなかったと思うけど色々飛んできてたなぁ。
壊れてからはやっぱり身の丈に合った立ち位置でやってくのが良いと思えるようになった。
自分は使えないおっさん。それで良い。 アジャイルが最高のソフトウェア請負業務だと信じて疑わないS君は
アジャイルガラパゴスと化したこのプロジェクトが終わると
どうやって生きていくんだろうな
全て自分の思い通りに動いてくれる奴隷開発者たちがいない現場で
まるで小学生が駄々をこねるみたいにわめき散らすんだろうな 請負うのがすでにウォーターフォールだよ
その下は何をどうしてもウォーターフォールにしかならない DevOpsはアジャイルの言い換えじゃない？
マイクロソフトは改行コードLNをCRLNに言い換えたように既存のものを少し改変して自分のものにしようとする説 >>749
重箱だけどLNじゃなくてLFだと思うゾ つか、CRはタイプライターの先頭戻し、LFは用紙の改行送り
だから二つでやっと目的の動作になるんだし
勝手に解釈したらダメ ソフトウェア工学におけるアジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、人間・迅速さ・顧客・適応性に価値を置くソフトウェア開発である[1]。典型的なアジャイルソフトウェア開発では、チーム主導で設計・実装・デプロイを短期間に繰り返してユーザーが得た価値を学習し適応する、すなわちトライアルアンドエラーで開発が行われる。アジャイルソフトウェア開発を可能にする開発手法にはエクストリーム・プログラミングやスクラムなどがある。
人間、迅速さ、顧客、適応性
って翻訳やばいし
トライアンアンドエラーってなんだよ、トライアンドエラーやろ 人月見積もりしか出来ないのにアジャイルとかできんの？ >>753
「トライ・アンド・エラー（試行錯誤）」は和製英語で、英語ネイティブは使わないのです。英語では、正しくは 「 trial and error （トライアル・アンド・エラー）」になります。
www.quicktranslate.com/blog/2017/09/「トライ・アンド・エラー」は間違い！-会議で使/ びっくりするくらいバカなやつがいる
検索したら一瞬でわかることで間違った知識を修正できずにいる
間違ってもウィキペディアのページを編集しようとするなよ
おまえには絶対ムリ >>754
1人月で無制限働き放題だよ
実績管理もしないし
アジャイル現場にいた時は契約奴隷とは
ほんとにこのことだなと思ったよ 開発者「ドキュメント書かなくていいんだ！不具合あっても実装さえしておけばいいんだ！」
管理者「開発者を無限に労働させることができるぞ！」
顧客「仕様変更したい放題なんだ！」
勘違いアジャイルでもみんなwin-winかと思いきや大変なのは開発者であった 開発者には当初想定の工数の金しか渡さずに無限開発だからな アジャイルではそうはいかない
一人一人が独立して1人前の仕事を強制的にさせられる
そう「人材を育てる」と言う名目で
管理者の雑用までやらされる え？仕様と違う？
この場合はいらないですって設計書に仕様が書いてない仕様漏れでしょ？ 実装さえしていればいいなら実装が正しいんです
できたものにつべこべ言うな！ うちはアジャイルとウォーターフォール両方の案件やってるけど
うつ病になって退職、休職が多いのは断然アジャイルのほう。 地方出身、普通の家から苦学して東大、京大の理系出たけど
東京に人脈なくて新卒の就職で失敗して残念な人生送ってきたオッサンフリーランスに対する、
東京生まれ育ち中高有名私立卒のキラキラな正社員たちのイジメが陰湿すぎて笑う。
特に実家が太い中高からのKO大SFCの女子のスクラムマスター。
高学歴ダメおっさんのプライドを傷つけるのが絶妙に上手いし、
わざと不得意なことややったことない仕事アサインして、
年下のFラン社員に頭下げて「教えて下さい」と
聞いてまわらないと進められないようなことばかりやらせる。
その間、理系脳としては数段劣る中堅私立の理工系とか高専しか出てないけど若いイケメンに
データサイエンティスト系の花形になれる仕事与えて彼らからの点数を稼ぐ。
そしてそのうち技術力でも中堅私立に抜かれる、ワードプレスのサイトメンテばかりやらされてきた東大京大おっさんたち。
悲劇ですな。喜劇ともいう。 高卒だし数学ほとんど知らないけど
やったことない仕事やったり
相手の年関係なく頭下げるのはフツーな気がするゾ うんうんフツー
つか、この業界にいて学歴ど一のこーのと
言ってるあたり相当なバカと思う 東大出てようが京大出てようが田舎出身のどこの馬の骨ともわからん理系崩れの男が
中学あたりから慶應で実家の太い女子に対等な人間として扱ってもらえるわけがない。
そんなことは、
階層の固定化したいまのこの日本で生き残ろうと思ったら処世の知恵として常識レベルだろ、そんなもん スクラムマスターできるような女の子いるだけでうらやましいけどな これをやってるならアジャイルだと言える最小限の要素はなに？ 同じアメリカ現地企業でプログラマーやってる人でも、
酒井潤さんとかは充実したエンジニア人生送ってるっぽく見えるんだけど？ アジャイルなのにやたら細かいWBSや日程管理をする気違いリーダーがいてな
夕方4時
リーダ「今日中に出来るよな」
開発者「は、はい…」
リーダ「わかった。あと、この後ミーティングな(2時間)」
そりゃ、開発者は3ヶ月持たずにコロコロ入れ替わるわな
他人のことを虫けらのようにしか思わないサイコパスじゃないと
アジャイルのリーダーは務まらない >>777
そのくらいじゃないとリーダー側が精神崩壊しかねないからな
技術力足りないメンバーを詰めまくってほぼワンオペ化に持っていって快適に開発してるオッサンいたわ 委託前提の仕事に対して相性クソ悪いんだよな。
お前ら今作ってる機能がマネタイズするかどうかなんて考えてやってるか？ >>777
それの何が悪いんだ？
細かく管理してるやついたら便利じゃん >>780
スプリント期間が定められてて、そして
全てのタスクが１スプリントでリリースされるのが前提のプロジエクトじゃね？
あと、メンバー全員が等しくコードの読み書きが出来る事も。 情報を隠すことでマウントする陰湿な社会
日本では無理だと悟った hnavi.co.jp/knowledge/blog/sprint-development/
そこで登場したのが、「アジャイル開発」です。
アジャイル開発は以下の手順で開発が行われます。
理想
→現実
1.顧客満足を最優先に動く
→顧客の無茶振りに振り回される
2.ソフトウェアを素早く提供する
→バグで致命的な損害を与える
3.クライアントと開発者がプロジェクトにおいて協力して動く
→無限に増え続けるクライアントの要求にひたすら追われる
以下のようなメリットがあります。
最低限の機能を持ったプロダクトをすぐローンチできる
→ユーザから「こんなん使えねーよ」とダメ出しされる
柔軟な変更も含めた計画立案、開発作業実行が可能
→突貫で作ったプログラムとシステム設計で改修に手が出せなくなる
こまめにユーザーの声をフィードバックして機能を調整できる
→担当者が変わるたびにオレオレ仕様に対応させられる アジャイルで失うもの
それは開発者の人生
アジャイルで得るもの
それはリーダーの人生 >>768
うちの会社だとアジャイル推奨して導入した本人が鬱で退職してたよ
問題を全部他人のせいにする奴だったが、環境に合ってない開発手法に変えたのが根本原因だろうと 開発プロセスやアプローチを
柔軟にしてもね
普通の開発者はそんな柔軟に仕事したくないねん 自由にコントロール出来る側になった時だけ楽しいのがアジャイル
1人の幸せのために99人を不幸にする開発体制 お客様のためにテストは適当にやります
お客様のためにバグが直せません
お客様のお金かかりますので アジャイル開発だと複数人が同じ箇所に関わると効率が悪くなる
１メソッドが例え１万行になったとしても共通処理を安易に切り出すのは得策ではない
メソッド単位で担当者がアサインされるからこそソースの衝突が発生しないのだ
皆さんもきっとあると思う
「あの関数なぜ修正したの？こっちで使ってるのに！！」「こっちだと修正しなきゃいけないから仕方ない！」「だったら別関数にしてよ」
みたいな共通関数に対する不毛なやりとり
過去の開発手法は１人の天才が全てをコントロールするために生まれた手法なのだ
現代では複数の凡人が限られた箇所にコントロールを制限されるべきだとされている
つまりソースの書き方も現代的でモダンでなければならない
チーム開発では担当領域をいかに排他的に設定するのが重要課題の１つである
旧来から良しとされていた「共通処理は共通関数に書こう」というやり方ではどうしても担当領域が重複してしまう
「共通処理は修正してはならぬ」というルールでも作らない限り、１つの修正が１つの成果と９つの不具合を呼ぶのだ
アジャイル時代の開発では共通処理はつくってはならない
例え１つのメソッドが１万行になったとしても恐れてはならない
それはソースがコンフリクトする事に比べたらはるかにマシなのだ
共通処理をつくってしまうからアジャイルの参加人数が１桁で限界などという運用になってしまう
担当範囲をを垂直分割できればたとえアジャイルといえども大人数による並行開発が可能なのだ getDate
getDate2
getDateFormat
getCalenderDate
getDateYYYYMM
getDateCustom
そうそう
アジャイルだとこうなるんだよな笑 >>795
極論やね
スキルないエンジニア沢山並べてるのかな？
まあ、同じようなコードが乱立してメンテ不能になるパターンが見えてる >>795
共通化しすぎる奴もいたり、共通化と言いながら汎用性がないもの作る奴もいる
そして人間デッドロックが起こるｗ
メンバーにある程度のスキルも必要だが、さらに思想まで似たような人をアジャイルだと揃える必要性があるから現実的ではないね アジャイルなんだかから、
メンバー全員コード読めるわけで
相互に作成されたコードを認証しているプロセスがレビューなわけで、
>>0796
みたいなのは、アジャイルが出来ていない証みたいなもんだな
隣のアジャイルチームは
他人が書いたコードの説明を
チーム内の他人にさせてたよ
出来るでしょ？あたりまえだよねって アジャイル自体には問題がないが
アジャイルを曲解して変な事してる奴は万死に値する メンバー全員が設計から開発までできないとアジャイルって無理だよなぁ
設計だけして下請けに実装を投げる日本型製造業の慣習ヲ継いだ日本のIT企業には難しそう 
