2017/08/14 14:19:05
katzchang
書いた
2017/08/14 14:26:47
kkotyy
“どうせ伸びる。”
2017/08/14 14:47:58
koheisg
まさに「教条的になり過ぎないこと」だな。 しかし学ぶことを否定はしていないのがいいエントリーだと思う。
2017/08/14 15:00:25
atsuizo
学ぶことは否定せず、教条主義・原理主義に陥らず。端的にいうと「いいとこ取り」なんだけど、ある程度スキルがないと、教条主義よりパフォーマンス落ちるのが怖いところ。
2017/08/14 15:01:17
Songmu
わかる
2017/08/14 15:15:26
tofu-kun
こういう振り返りと共有は大事な気がする
2017/08/14 15:30:16
dekokun
"「それらは、そこから学ばなくてもわかるだろう」と言われるかもしれない。いいんだよ、人生遠回りで"
2017/08/14 15:54:11
koogawa
“スクラム開発はおすすめしていないが、スクラム開発を学ぶことはおすすめしている”
2017/08/14 15:58:43
arata3da4
いい話だった
2017/08/14 16:37:25
UDONCHAN
いい話
2017/08/14 16:57:12
takahashim
守破離の守がトップダウンマネジメント、というのは意味がわからなかった
2017/08/14 17:23:45
otihateten3510
全部思想だけ理解したけど本は読んで無いな。本で書かれるようなことは大抵重くて実行性に欠ける。思想だけどう抽出するかが重要だけど、抽出されず「こんなもんクソだ」と投げ捨てられてるケースが多い気がする。
2017/08/14 17:42:51
modal_soul
思想は大事だけど、思想家になっちゃおしめぇーよー。ただ、思想家になったほうが地位を築きやすい、というのがあってどうにも。。
2017/08/14 17:59:24
masaru_b_cl
「型」は学んだが使ってない。わかる(気がする)。
2017/08/14 18:30:47
hotu_ta
いいとこ取り大切だ
2017/08/14 18:44:32
psfactory
ソフトウェア開発で学んだが使わなかったもの – @katzchang – Medium
2017/08/14 18:47:01
slkby
学ばなかったが使っているものを語るとこの平和なブコメが戦場になる予感がする。
2017/08/14 18:56:10
rjge
“「それらは、そこから学ばなくてもわかるだろう」と言われるかもしれない。いいんだよ、人生遠回りで。” 学んだことを使わず活かすのって愚直に実践するより難しいが、こういう気持ちが大切なんだろな
2017/08/14 19:00:04
wkwkhautbois
このひとは能力高めな人で、凡人はとりあえず学んで使ってみないと要点の抽出もできないかも。
2017/08/14 19:05:34
maname
今更朝会とか呼んでる人がいるんですかwwwww(うちは昼会だった危なかった)
2017/08/14 19:08:01
kikuchi1201
人生遠回りわっしょい
2017/08/14 19:08:03
oooooooo
雑な守破離、いいよね
2017/08/14 19:10:11
itouhiro
「スクラム開発は実施するつもりはないが思想から学んだことは多い。テスト駆動開発(TDD) ドメイン駆動開発(DDD) 開発工数見積もり手法」
2017/08/14 19:34:56
happy_siro
馬鹿がプラクティスをそもそも理解できなくて、適当なアレンジを加えて実践することのいいわけにこの記事が使われる未来が見えた。
2017/08/14 19:48:06
reoring
大事なのは手段ではない
2017/08/14 20:12:28
kusigahama
15時からのミーティングを朝会と呼び続けると「朝」が再定義されてしまう問題はあった
2017/08/14 20:20:00
moyabi
実感だ(自分の実感とも乖離が小さい)
2017/08/14 20:32:57
syossan
こういった一歩引いて良いプラクティスだけつまみ食いするやり方好き
2017/08/14 20:52:19
lotasty
逆に開発手法で取り入れてるものがあるなら聞きたいところ
2017/08/14 21:09:41
miholovesq
katzhangがいうのはなんかわかる
2017/08/14 21:12:47
synbizmix
学んだから使わないという選択も取れた。ベストは人、チームによって違いますからね。/“ソフトウェア開発で学んだが使わなかったもの” by @katzchang
2017/08/14 21:28:02
carrotsword
結局どこにも辿りつけなかったし、たどり着けないんだな…
2017/08/14 21:30:34
kantei3
これくらいしか頭に入らんし、実践で有効なのは限定的だよな。
2017/08/14 21:53:32
ngsw
会社の数、部署の数だけ開発手法はあるだろうし、そこを模索していくことが重要なことという大事な話。たとえ最終形は同じ形であったとしてもそこに至る道程はそれぞれ違うので淡々とやっていきたく思いました。
2017/08/14 22:04:51
lifeisadog
学んだものをいいとこ取りしないで、真面目に頑なに「正しいやり方」を貫こうとすると、大概失敗する。
2017/08/14 22:05:19
dev0000_1
読んだ本の仕事術、全部使うわけでなし。
2017/08/14 22:06:13
tumo300-500
良いスタンス
2017/08/14 22:07:30
mgrstr
結構同意。実現したい目的を明確にして、その実現のための手段としてこれらの理論を状況に応じて実践に落とし込まないと何も始まらない
2017/08/14 22:18:21
snowcrush
各メソッドについてそれぞれ大体同じような感想を持ってたので安心した
2017/08/14 22:24:05
nunux
ソフトウェア工学 開発手法 スクラム開発 テスト駆動開発 ドメイン駆動開発
2017/08/14 22:27:11
endo_5501
まあ、そんな感じ
2017/08/14 22:28:23
masudaK
なかなか現実的じゃないのかな
2017/08/14 22:51:36
cowbee
マイグレーションツールとプロビジョニングツールを使わなかった理由も知りたい
2017/08/14 22:54:48
htnmiki
(/ω・\)チラッ >いまだに「朝会」って言ってる人いないよね?
2017/08/14 22:59:13
awkad
おおむね同意できるが、DDDはやっぱりよいよ。突き詰めるとそうなるなあと思う。ただ、超大規模開発でないと旨味がないかも。スタートアップでやる小規模開発なら確かにこだわる必要はない。
2017/08/14 23:14:10
justgg
開発手法ってなぜか宗教的になってしまうからなあ。/ソフトウェア開発の生産性の伸びって昔より緩やかになってきてるのかな?覚えることが多いわりには劇的な向上につながる変化って無い気がしてる。
2017/08/14 23:27:58
foobar_nobody
あぁー…(泣)
2017/08/15 03:39:52
natu3kan
使えるかどうかも、覚えてみないと区別付かないから
2017/08/15 03:43:37
turanukimaru
"権威に基づいた意思決定"ってそれは違う。意思決定には共通の基盤が必要でそれは省略できないから「守」であるって話だ。「素直に実装しろ」にしても単に素直に実装しろって言っても分からないから基盤にあるものが
2017/08/15 05:31:03
baronhorse
諦めよ過ぎるのでは
2017/08/15 06:46:21
nilab
ソフトウェア開発で学んだが使わなかったもの – @katzchang – Medium
2017/08/15 07:16:27
FunnyBunnyDizzy
スクラムはアジャイルを「ドキュメント書かなくて良いんでしょ?」とかいう間違ったノリでやってクソみたいになるののアンチパターン集と思ってる。クソアジャイルのアンチであってベストプラクティス集じゃない
2017/08/15 07:46:02
fuktommy
確かにほとんど何も使わなくなったなあ。 “ソフトウェア開発で学んだが使わなかったもの” by @katzchang
2017/08/15 08:09:24
hiroshe
知ってるのと知らないのとでは、だいぶ違うだろうなあ。
2017/08/15 08:27:08
raitu
教養の話
2017/08/15 08:43:05
MasaoBlue
“「ちょっと」「まあまあ」「たくさん」で見積もる。”これを全ての見積もりで使いたい。お客さんと話をする上で金額の合意が必要なのは分かるけど開発する前から予算を提示する行為自体に無理があってやりたくない
2017/08/15 08:56:09
digo
状況似たカンジ
2017/08/15 08:59:33
y-shinozw
いい見積もり現場では「どう作るか」への理解が進む←これ本当だと思う
2017/08/15 08:59:50
eerga
結果はある程度納得できるんだけど、判断理由がしっくりこないな。文章が悪い?
2017/08/15 09:01:39
igrep
"「それらは、そこから学ばなくてもわかるだろう」と言われるかもしれない。いいんだよ、人生遠回りで。"
2017/08/15 09:23:04
progrhyme
ただし、学ぶことは否定しない、と。
2017/08/15 09:27:25
aceraceae
とりあえずスクラムは実践すると結果として無駄にストレスをかけるだけになりがちなんで、そういうストレスフルな環境で能力を発揮する人以外はやらないほうがいいと思うし、わたしも嫌だ。
2017/08/15 09:50:15
hush_puppy
スクラムはプロダクトオーナーによってトップダウンで運用されるのが苦手。
2017/08/15 09:53:04
tockri
スクラムでいう自律的な行動ってトップダウンが完全に無い状態を指してるのとは違うので、気にしすぎなんじゃないかなー。いい感じに回るとこまでがかなり遠いので生存期間が短いチームには向かないと思うけど。
2017/08/15 10:37:30
udzura
見積もり周りのお話しわかりティある
2017/08/15 10:47:39
nnhrsk
“そういえばDBマイグレーションツールとかプロビジョニングツールとかも調べたものは色々あれど、結果使わないほうが多い。”
2017/08/15 11:18:33
yu_wasama
しょっぱながスクラムで笑っちゃうわね
2017/08/15 11:22:53
stormcat24
学びだ
2017/08/15 11:22:57
shiro_goma
良さがある
2017/08/15 11:25:18
tuki0918
自分の力で噛み砕く力が無いと難しい
2017/08/15 12:14:53
yetch
学んだからこそ、"使わない"とか"使ってない"とか判断出来る。
2017/08/15 12:30:54
hisaju
いい話だ。経験が浅いなか技術にこだわりを持ちすぎる人ほどこういうものに盲信的になりがちなので、気をつけたほうがいいよ。
2017/08/15 12:33:58
ka2hik0
うん
2017/08/15 12:37:15
utahta
"いいんだよ、人生遠回りで。"
2017/08/15 12:52:50
otchy210
前のマネージャから「うちのアジャイルは本に書かれた固有名詞の Agile じゃなくて一般名詞の agile だから、型にはめるんじゃ無く必要に応じてどんどんアレンジしていくべきだ」という話をされた事を思い出した。
2017/08/15 15:51:05
hisomura
DBマイグレーションツール使ってないプロジェクトに入った結果開発と本番でスキーマの同期取れて無くて大変な苦労したことがあるから絶対必要だと思う。プロジェクトの最初から使えばコストもかからないと思うが。
2017/08/15 16:51:18
peperon_brain
“いい見積もり現場では、数値よりもどう作るかについて議論が深まる”
2017/08/15 21:57:26
chintaro3
「権威に基づいた意思決定はことごとくトップダウンなのだ。」
2017/08/16 08:40:02
kabukawa
なるほど。/ 「見積もりよりも、どう作るかのほうが大事。いい見積もり現場では、数値よりもどう作るかについて議論が深まるらしいよ。」
2017/08/16 09:23:41
sai0ias
試してみて合う合わないっていうのは絶対にあるからまず知る・試してみるってのが凄く大事だよな
2017/08/16 12:09:00
te2u
DDDは自分の設計や実装の考え方を大きく変えた。ドメインの考え方やエンティティと値オブジェクトの違いは、なんとなく理解していたことを明確にしてくれた。自分にとって大きなインパクトを与えてくれた概念。
2017/08/16 13:10:04
tmd45
学んで損はない
2017/08/16 17:21:19
june29
ご自身の体験をベースにご自身の言葉で語られているので読みやすかったです。同じ内容を「スクラムは」「TDDは」と断定口調で書いたら燃えそう。
2017/08/19 07:45:18
naqtn
破の話