URL

「大規模システムの保守における技術的負債とチームのモラル」のグラフ

大規模システムの保守における技術的負債とチームのモラルhttp://www.infoq.com/jp/news/2016/02/technical-debt-team-morale
月のグラフ

コメント

(2017/12/12 13:44:42 更新)
  • “品質を主張すること、警告をあげること、「正しい」ことをするよう主張するのは私たちの仕事です。それは、例え上位組織がそうすることに対して長期的な価値を見いだせなくてもです。”:aroma_black2016-03-10 09:56:38
  • 243: “現実には「あとで」は「決してやらない」ことを意味します”:garage-kid2016-02-11 10:22:49
  • "「あとで技術的負債を解消しよう」という考えは製品側の人たちを幸せにするかもしれませんが、現実には「あとで」は「決してやらない」ことを意味します。":k0yoshitsugu2016-02-09 14:25:13
  • これまだ成果でてないやつでは?:warufuzaketaichi2016-02-04 23:24:15
  • “現実には「あとで」は「決してやらない」ことを意味します。”:chezou2016-02-04 09:20:02
  • "「あとで」は「決してやらない」ことを意味します。":tyabe2016-02-04 09:14:05
  • “技術的負債はコントロールできるし、早い段階からコントロールすべきです","現実には「あとで」は「決してやらない」ことを意味します。”あああああ:a2ikm2016-02-04 03:26:19
  • 「あとで」は永遠に来ないのはわかる。そうなんだけど、正しいことをやってもいいものができるわけではないところがジレンマ:hs_hachi2016-02-03 22:27:13
  • “ 価値観の面では、何年もかけて築き上げた熟達から彼ら開発者を解放し、未熟者として別のやり方で問題解決にあたってほしいと思っていました。”:onigra2016-02-03 22:13:56
  • 和訳が悪いのもあると思うけど具体的に何をやったのかがさっぱり分からない:beerbeerkun2016-02-03 20:07:02
  • "「あとで技術的負債を解消しよう」という考えは製品側の人たちを幸せにするかもしれませんが、現実には「あとで」は「決してやらない」ことを意味します。" あばばばば:motchang2016-02-03 19:54:15
  • 大規模システムの保守における技術的負債とチームのモラル お仕事のために…φ(..)メモメモ:azumaon2016-02-03 19:37:13
  • 自ら分かってくれる偉い人は稀なので技術的負債を数値化して説得する努力は必要と思う:airj122016-02-03 19:13:39
  • "本当の解決策は抜本的にアーキテクチャをリファクタリング、すなわちモノリシックなサービスを分解して複数の独立したサービスにすることと、まったく異なるスタックにしていくことでした":harumaki_net2016-02-03 19:07:27
  • "「あとで技術的負債を解消しよう」という考えは製品側の人たちを幸せにするかもしれませんが、現実には「あとで」は「決してやらない」ことを意味します":golden_eggg2016-02-03 18:41:37
  • ぐっちゃぐちゃの長大なバッチ処理PGばかり修正させられたおかげで、コード解析・テストによる動作仕様定義・マトリクス整理の各スキルが上達するって副産物が。皮肉だけど苦労したことって身につくし忘れないのよね:bell_chime_ring2382016-02-03 18:37:05
  • だよなあ。品質をコントロールできるぐらい余裕を持ったビジネスサイドへのコミットメントと、それを全うする力と信頼関係を築くことの大事さ。:ae067102016-02-03 18:35:32
  • あとでのお化け出たことねぇ、と良く親に言われてたなぁ:kaipu12242016-02-03 17:22:16
  • ↓あっ、そうなんだ。1単語でどっちの意味も含んでるんだとばっかり思ってたw 「「モラル(moral:倫理)」でなく「モラール(morale:士気)」」:babelap2016-02-03 17:03:43
  • やれるんだ!という心強い話 / ところで「モラル(moral:倫理)」でなく「モラール(morale:士気)」ですよ:masaru_b_cl2016-02-03 16:35:33
  • “本当の解決策は抜本的にアーキテクチャをリファクタリング、すなわちモノリシックなサービスを分解して複数の独立したサービスにすることと、まったく異なるスタックにしていくことでした” 良い知見だなあ。:manFromTomorrow2016-02-03 16:21:47
  • “簡単に言うとやりませんでした。~テストのカバレッジを増やそうとも最終的な解決策とはなりません~本当の解決策~サービスを分解して複数の独立したサービスにすることでした”:shiracha_rikyu2016-02-03 16:21:46
  • そっとあとで読むチェックをつけていくおれ:vanish_l22016-02-03 16:06:07
  • 肝に銘じる:tokoyax2016-02-03 15:44:18
  • 「ソフトウェアエンジニアとして経験する感情の中で最悪なものの1つです。」とあるけど、その通りだと思う。:rtryoda2016-02-03 15:24:02
  • 大規模システムの保守における技術的負債とチームのモラル: 大規模システムの保守における技術的負債とチームのモラル 作者: Ben Linders , 翻訳者 吉羽 龍太郎 投稿日…:kilminwq2016-02-03 14:45:47
  • " 技術的負債はコントロールできるし、早い段階からコントロールすべきです。" これだよー!:joker10072016-02-03 14:44:34
  • システムの像:kenzy_n2016-02-03 13:53:24
  • “製品を2度根本から作り変え、そのたびに同じような結果になった”:yo_waka2016-02-03 13:49:54
  • (訳した):ryuzee2016-02-03 13:48:52
  • そんなに大きくも歴史もないシステムに致死量の負債が溢れてるのを見た時は規模とか歴史的経緯とかの逃げ道がなくてとりあえず心の残機が一機死ぬ。:taguch12016-02-03 13:47:15
  • 「後でやる」は「決してやらない」、すごい共感できる話だ(自戒:sue4452016-02-03 13:44:21
  • “あとで技術的負債を解消しよう」という考えは製品側の人たちを幸せにするかもしれませんが、現実には「あとで」は「決してやらない」ことを意味します。”:torounit2016-02-03 13:39:46
  • うん "現実には「あとで」は「決してやらない」ことを意味します。":mizchi2016-02-03 13:31:01
  • 素晴らしい。そういうことなんだよー。 / "システムのテストカバレッジを増やすためにどんな順番で進めたのでしょうか? Bradford: 簡単に言うと、やりませんでした。":kyon_mm2016-02-03 13:07:49

関連エントリ