タグ

2024年2月25日のブックマーク (3件)

  • 開発組織の貢献は売上として直接語るのはやはり無理があるのではないかという考察

    先日サーバントワークスさんが公開した 計測によるスクラムチームのパフォーマンス向上 を読んで、 以前自分が書いた 開発の改善はKPIに翻訳しなければいけないのか をもうちょっと言語化することができそうだったのでメモ。 TL;DR 結論としては、開発の改善はKPIに翻訳しなければいけないのか でも書いた通り 開発組織はビジネスの実現を担っている職能であり、理想的には 「永久に持続性がある状態」で 「0秒 でしかも 並列数を無限」 でモノが実現されて、「不具合やパフォーマンスの劣化は 0」 であってほしい。もちろん現実世界ではどれも実現できないのでそこにいかに近づけるかということを目的に改善を実施すればよく、売上などのKPIに翻訳する必要性は必ずしもない から考え方は変わってないが、改めて整理して 開発組織は、Ability to Innovate と Time to Market 2つのケイ

    huusen20
    huusen20 2024/02/25
  • (翻訳) GitLab 社で働くのはどのようなものだったか - forest book

    稿は Yorick Peterse 氏によって書かれた次の記事の日語翻訳です。著者に翻訳の許可を得て公開しています。 yorickpeterse.com また稿は DeepL Pro を使って下訳したものに手を加えています。日語翻訳の不具合または誤訳については Yorick Peterse 氏ではなく、稿のコメント欄にお願いします。 ここから文です。 GitLab 社で働くのはどのようなものだったか 私は2015年10月に GitLab 社に入社し、6年あまり働いて2021年12月に退社しました。 前に GitLab 社を辞めて Inko に取り組んでいることは書きましたが、2015年から2021年までの間、GitLab 社で働いていたことがどのようなものであったのかについては触れませんでした。理由は2つあります。 燃え尽き症候群に苦しんでいて、(当時は) 自分の人生の最後の6

    (翻訳) GitLab 社で働くのはどのようなものだったか - forest book
    huusen20
    huusen20 2024/02/25
  • デプロイ再考2024/reconsidering-deploy-in-2024

    現在 estie では、デプロイの改善・統一に取り組んでいます。複数プロダクトのそれぞれの技術スタックが大きく違う中、どう考えたら効率的なデプロイを組めるのか。2024年のデプロイの原則について、あらためて考えてみました。

    デプロイ再考2024/reconsidering-deploy-in-2024
    huusen20
    huusen20 2024/02/25