気に入った記事をブックマーク
- 気に入った記事を保存できます
保存した記事の一覧は、はてなブックマークで確認・編集ができます
- 記事を読んだ感想やメモを書き残せます
- 非公開でブックマークすることもできます
note.com/simplearchitectエントリーの編集
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント75件
- 注目コメント
- 新着コメント
peperon_brain
請負開発の場合だが、WFというか納期と納品物が先に決まるのって楽なんだよね。営業と契約が。開発よくわからん客の稟議を通しやすい。そうやって隠蔽された不確実性が後で火を吹くわけだけど。/内製に限る。ほんと。
devrabi
みんなが知りたいのはプラクティスじゃないと思うんですよね。請負で顧客がフェーズ毎の確認を求め、外注を使うことが前提の現場でどうすれば良いのという話で。そんな現場からは逃げろで終わりならそれはそれでOKで
MtAsuka
「チームはかなり個人商店の集まり」とあるように自律的で優秀なメンバーが集まっていればアジャイルが正解だけど、日本の多くの業務システム開発ではそれは望めない中の次善策がWFだって理解してから書いてほしい
suikyojin
下記のように、ウォーターフォールの基となっているWinston.W.Royceの論文さえ、繰り返し等が必要となっていた。四半世紀前には再発見されているのに。(抜けてた) https://simplearchitect.hatenablog.com/entry/2016/06/20/080807
aike
毎回思うけど、この人は多くのJTCやSI企業が抱えているシステム開発に関する課題を解決した実績もなければ、解決する気もないんだよね。記事を読むとそのスタンスはわかるけど、誤解を招くタイトルは不誠実。
manaten
優秀な人はだれに言われずとも最適な開発手法を自分でアレンジして取り組めるし、優秀じゃない人はアジャイルに手を出したら大ヤケドするしで、この手のエントリが誰向けなのかわからなくなってきた
circled
そうかそうか、でもアジャイルを採用したプロジェクトの失敗率は他のプロジェクトよりも268％も高いぞ？ https://gigazine.net/news/20240607-higher-failure-rates-for-agile/
getcha
マーケティング屋やキラキラエンジニアが、ウォーターフォール vs アジャイルの対立を演出したせいで、開発規模や対象によってどっちが必要かは変わってくる。という辺り前の事を知らない人が増えた。
mohri
誰が辞めても困らないように属人的な仕事をなくしていくと人材は交換可能な部品に近づいていくが、逆にインターフェースが合っていれば仕事の中身はどれだけ属人的でもいいみたいな考え方もあるのかなとか考えた
tarakotarakotarakotarako
一貫した操作性が求められる画面をアホほど作るようなとき完全な適応型アプローチだと辛くない？って思ったけど、そもそもそういう要件のプロダクトが減ってるとかもあるのかな
sds-page
業務でAzure導入しようとしたらやる気のない担当出てきてよくわからん協力会社に丸投げして協力会社も全然連絡してこないでやる気なさげで立ち消えになったんだけど日本でAzure売る気あんの？
notojin
これ大事。日本ではコード書けないくせに態度と給料だけでかい無能マネージャがいて困る ＞ マネージャで技術を知らない人は一人もいなくて、自分よりレベルの高いエンジニアがマネージャになってくれる感じです
Shin-JPN
WFは現状のソフト開発では適用領域がほとんど無いという意味では事実上糞と言っていい。だが発注者が糞な場合アジャイルでは糞すら作れない。ユーザー企業の問題である以上絶望的に非効率な現状が最善の状態なのだ
hate1229
アジャイルの方が失敗率が高いというがWFは失敗を認めないで、アジャイルは失敗しないことに越したことはないが、早く失敗して方向を変えようって開発だから比較にならん。一方でWFの方が日本式の予算を組みやすい
hamamuratakuo
"フェーズも見積も無い" → 確かに、納期も費用も完全に予想できる人なんていないよな～。納期は延びるし、案件を取るために安い値段を提示しても後で破綻するし、理想と現実のギャップが大きすぎる！？
dorapon2000
“それよりも、マネージャの仕事は、「アンブロック」です。開発メンバーが開発中にブロックされたらそれを助けてくれます。例えば、PullRequest作ったけど、レビューしてくれる人が居ないからマージできない。”
nakama00
MSDN blog が消滅したのでサルベージ。https://web.archive.org/web/20190108101007/https://blogs.msdn.microsoft.com/nakama/2016/06/24/waterfall/ 特定の方法論に固執せず、良いところを積極的に取り込んで進化させ続けることが大切ですね。
aike
毎回思うけど、この人は多くのJTCやSI企業が抱えているシステム開発に関する課題を解決した実績もなければ、解決する気もないんだよね。記事を読むとそのスタンスはわかるけど、誤解を招くタイトルは不誠実。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
いまの話題をアプリでチェック！
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
ウォータフォールはやめて2024年の開発をやろう！｜牛尾 剛
今回の記事は特に私の意見であり、所属会社の意見ではないことをお断りしておきます。 最近になってまた... 今回の記事は特に私の意見であり、所属会社の意見ではないことをお断りしておきます。 最近になってまたウォータフォール vs アジャイルの議論を見かけることが多くなってきたので、私が勤務する米国の世界規模のクラウドプロバイダーでは2024年現在どんな開発をしているのかをご紹介したいと思います。私はこれが「正解」といいたいのではなく、何らかのポイントが皆さんの何らかの参考になったらいいなと思って筆をとりました。 ちなみに、2016年時点で私のウォータフォール開発に対する考え方は下記のブログの通りで今も変わっていません。ただ、2024年現在だからといってアジャイルをやるべきと思っているわけでもありません。 もし、今ウォータフォールをやっている人がいたら「そんなこと言ってもどうしたらええねん」となると思うので、自分なりの解決方法も考えてみました。 最初に自分的な結論を書いておくと「2024年の開発と
ブックマークしたユーザー
すべてのユーザーの
詳細を表示します
詳細を表示します
note.com/simplearchitect
note.com/simplearchitect
note.com/simplearchitect
note.com/simplearchitect
www.itmedia.co.jp
zenn.dev/udonj
www.sponichi.co.jp
mainichi.jp
gendai.media
anond.hatelabo.jp
blog.kushii.net
note.com/shi3zblog
nintendoevery.com
dev.classmethod.jp
rocketnews24.com
jp.reuters.com
write.co.jp
jp.reuters.com
jp.reuters.com
jp.reuters.com
2024/06/18 リンク