ソフトウェア開発で学んだが使わなかったもの

開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守

[atsuizo]

学ぶことは否定せず、教条主義・原理主義に陥らず。端的にいうと「いいとこ取り」なんだけど、ある程度スキルがないと、教条主義よりパフォーマンス落ちるのが怖いところ。

[koheisg]

まさに「教条的になり過ぎないこと」だな。 しかし学ぶことを否定はしていないのがいいエントリーだと思う。

[kusigahama]

15時からのミーティングを朝会と呼び続けると「朝」が再定義されてしまう問題はあった

[dekokun]

"「それらは、そこから学ばなくてもわかるだろう」と言われるかもしれない。いいんだよ、人生遠回りで"

[modal_soul]

思想は大事だけど、思想家になっちゃおしめぇーよー。ただ、思想家になったほうが地位を築きやすい、というのがあってどうにも。。

[takahashim]

守破離の守がトップダウンマネジメント、というのは意味がわからなかった

[justgg]

開発手法ってなぜか宗教的になってしまうからなあ。/ソフトウェア開発の生産性の伸びって昔より緩やかになってきてるのかな？覚えることが多いわりには劇的な向上につながる変化って無い気がしてる。

[Songmu]

わかる

[awkad]

おおむね同意できるが、DDDはやっぱりよいよ。突き詰めるとそうなるなあと思う。ただ、超大規模開発でないと旨味がないかも。スタートアップでやる小規模開発なら確かにこだわる必要はない。

[miholovesq]

katzhangがいうのはなんかわかる

[ilyaletre]

katzchangさんの「結果から学ぼう」って感じのスタンス、好き

[luccafort]

同意は出来ないけどチームに馴染まないと感じたのなら無理に導入する価値はないし学んだうえでやらないと判断したのならそれは正しいと思う。ただトップダウンのくだりは主張したいことが理解できなかった。

[sawarabi0130]

使うこと(手段)が目的になっていないかということを常に意識すべし。チームや案件に合った手法であることが最重要。

[kenichi_odo]

こんなよあるよーってぐらい

[ardarim]

役に立つかどうかは別にして、知識として知っておくのはありなんじゃないかな。今は使いどころがなくても考え方が応用できることもあるかもしれない。

[DustOfHuman]

“権威に基づいた意思決定はことごとくトップダウン”

[naqtn]

破の話

[june29]

ご自身の体験をベースにご自身の言葉で語られているので読みやすかったです。同じ内容を「スクラムは」「TDDは」と断定口調で書いたら燃えそう。

[te2u]

DDDは自分の設計や実装の考え方を大きく変えた。ドメインの考え方やエンティティと値オブジェクトの違いは、なんとなく理解していたことを明確にしてくれた。自分にとって大きなインパクトを与えてくれた概念。

[kabukawa]

なるほど。/ 「見積もりよりも、どう作るかのほうが大事。いい見積もり現場では、数値よりもどう作るかについて議論が深まるらしいよ。」

[chintaro3]

「権威に基づいた意思決定はことごとくトップダウンなのだ。」

[peperon_brain]

“いい見積もり現場では、数値よりもどう作るかについて議論が深まる”

[otchy210]

前のマネージャから「うちのアジャイルは本に書かれた固有名詞の Agile じゃなくて一般名詞の agile だから、型にはめるんじゃ無く必要に応じてどんどんアレンジしていくべきだ」という話をされた事を思い出した。

[utahta]

"いいんだよ、人生遠回りで。"

[hisaju]

いい話だ。経験が浅いなか技術にこだわりを持ちすぎる人ほどこういうものに盲信的になりがちなので、気をつけたほうがいいよ。

[yetch]

学んだからこそ、"使わない"とか"使ってない"とか判断出来る。

[tuki0918]

自分の力で噛み砕く力が無いと難しい

[shiro_goma]

良さがある

[yu_wasama]

しょっぱながスクラムで笑っちゃうわね

[nnhrsk]

“そういえばDBマイグレーションツールとかプロビジョニングツールとかも調べたものは色々あれど、結果使わないほうが多い。”

[udzura]

見積もり周りのお話しわかりティある

[tockri]

スクラムでいう自律的な行動ってトップダウンが完全に無い状態を指してるのとは違うので、気にしすぎなんじゃないかなー。いい感じに回るとこまでがかなり遠いので生存期間が短いチームには向かないと思うけど。

[hush_puppy]

スクラムはプロダクトオーナーによってトップダウンで運用されるのが苦手。

[aceraceae]

とりあえずスクラムは実践すると結果として無駄にストレスをかけるだけになりがちなんで、そういうストレスフルな環境で能力を発揮する人以外はやらないほうがいいと思うし、わたしも嫌だ。

[progrhyme]

ただし、学ぶことは否定しない、と。

[igrep]

"「それらは、そこから学ばなくてもわかるだろう」と言われるかもしれない。いいんだよ、人生遠回りで。"

[eerga]

結果はある程度納得できるんだけど、判断理由がしっくりこないな。文章が悪い？

[y-shinozw]

いい見積もり現場では「どう作るか」への理解が進む←これ本当だと思う

[digo]

状況似たカンジ

[MasaoBlue]

“「ちょっと」「まあまあ」「たくさん」で見積もる。”これを全ての見積もりで使いたい。お客さんと話をする上で金額の合意が必要なのは分かるけど開発する前から予算を提示する行為自体に無理があってやりたくない