開発健全性(生産性ではないよ)のメトリクスを設計して運用してみた
この記事は、Magic Moment Advent Calendar 2023 22日目の記事です。 こんにちは、Magic Moment で QAE をやっている yano です。 本記事では、開発チームの健全性を示すメトリクスを設計し、計測と運用を始めて3ヶ月ほど経とうとしているタイミングなので、振り返りを兼ねて気づきをまとめさせていただこうと思います。 なぜ生産性ではなく健全性のメトリクスなの? 最初は生産性メトリクスの設計を考えていましたが、例えばコードの記述量や、スプリントにおけるベロシティなどアウトプットの質を度外視して量だけを追っていくような、ビルドトラップに繋がりかねないメトリクスを計測することは回避したかったという考えがありました。 一方で、 “If you can’t measure it, you can’t improve it.” の考え方にもあるように、カイゼン
開発速度と品質のトレードオフの判断基準の合意 - Hatena Developer Blog
Webサービスの開発は、ユーザ/顧客へ価値を早く届けるため、競合より早くリリースするため、人的リソースを無駄使いしないためなど、とにかく素早く進めたいものですね。一方で、開発を急ぐあまり品質を犠牲にすればかえって価値が失われたり、技術的負債が溜まって長期的なコストが大幅に増大する可能性もあります。開発速度とプロダクト品質は基本的にはトレードオフの関係にあるのでしょう。 開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なるとおもいます。この状況の認識がチームメンバー間でずれていると、チームのパフォーマンスを最大限に発揮できないばかりか、チーム内の関係悪化も招きかねません。エンジニアたちとプロダクトオーナーの間の対立のようなありがちな問題の原因の一つかもしれません。 そこで、開発速度と品質のトレードオフをどう判断すべきかの基準を明確にして、原則それに従
Go で API サーバーを開発してきて1年が過ぎました | カメリオ開発者ブログ
白ヤギの開発者の森本です。 白ヤギでは Go 言語でニュース記事のキュレーションをする カメリオ API というサービスを開発しています。約1年2ヶ月前、Go を使って開発し始めたときに当時調べた内容を整理して以下の記事を書きました。 Go言語で API サーバーを開発する 1年以上に渡り開発を継続してきて変わったこと、変わってないことなどをざっくばらんにまとめてみます。たまたま過去の記事のはてブコメントを見返していて 以下のコメント を見つけました。 最近 golang 導入事例増えて来たけど、導入後一年くらいのメンテナンスフェーズな事例について聞いてみたい。継続的デリバリーみたいなの。まだ早いのかな？ まだまだメンテナンスフェーズにはなっていなくて現在も活発に開発中ですが、継続的デリバリーについて白ヤギでは特別なことをしてなく、ansible を使ってデプロイしているのみです。Go 1
Grunt/Gulpで憔悴したおっさんの話 | MOL
先人たちが1年前に通った道で、いろいろいまさらかよって話なんですが。基本的に以下の記事読んだら分かります。要はGulpとかGruntといったモノ使わずにnpm run hogehogeでビルドしよーぜって話です。 task automation with npm run オレ的Gruntに対する最新の気持ち - from scratch Node - npm で依存もタスクも一元化する How to Use npm as a Build Tool // package.json "scripts": { "start": "npm run start-serve & npm run watch", "test": "stylestats public/files/css/maple.css", "start-serve": "browser-sync start --server publ
オレ流 Pull Request 作業フロー - 詩と創作・思索のひろば
チームで作業する同じリポジトリの中で Pull Request を送り合うのではなく、オープンソースプロジェクトに外部から PR がやってくる場合の話です。 最近のフロー 送られてきた PR に対しては、大まかには仕様の話、実装方針の話、具体的な実装の話を詰めながらマージできるように持っていくわけだけれど、それがほとんど満足いく状態になっていてマージしたいと思うタイミングになっても、変数の名前付けだとか、ちょっとした処理の書き方だとかで、相手にお願いするよりは自分で手を加えてからマージした方が手っ取り早いことがある。そういう時は PR 元のブランチを手元にチェックアウトして、そのブランチを自分の変更で進めた上で master にマージするようにすると、push 時に PR も閉じられて便利です。 motemen/lgtm.sh#1 の例。分かりにくいれど、PR にさらに 1 コミット足して
クソコードと呼ばない - ppworks.jp
新しい現場にはいったときに心がけていること、クソコードと呼ばないこと。 誰かのコードを読んでいるとそりゃまあクソコードを見つけることがある。その時どう立ち向かうかという精神論の話。 例えソレがそうであってもソレを口にするとネガティブが蔓延する。思ってもイイ、でも言ってしまってはならない。あるフェーズに置いては必要だった し、現に動いていて価値を提供している のだ。あるべき姿を叫ぶの簡単だ。あるべき姿を見ているなら行動しないといけない。見つけたらリファクタだ。出来るところからやるんだ。 Shut the fuck up and write some code & 許可を求めるな Pull Request せよ— 🌈KOSHIKAWA (@ppworks) 2014年5月23日 クソはクソと言える空気や文化は大事。良くないものを指摘できるようにはしたい。口の前に手を動かそう。プログラマーなら
UX に真面目に取り組める組織づくりについてのスライドを公開しました - つきあたりを右に
と、いうわけで転職しました 本来の職種は相変わらず 「前例の無い事をなんとか形にして」をなんとかするデベロッパとしてですが、 「UX Developer として組織的に UX とかそういうの強くして」というのも兼任しております で、入社して1週間経って、早々と「じゃあ、出来る UX デザイナー/ディレクター/エンジニア を社外から引っ張るとか、採用募るとか、属人性の高い他力本願にしないで、組織として体制を整える方向で行きましょうよ」ということで作ったのがこのスライドです このスライドについて 昨今、割とどのソフトウェア・Webサービス開発の現場でも「UI/UX デザイナーを募集します」と求人出しています。 しかし、求人出してるところって、そもそもそういう人材が不在で、受け入れ態勢整ってない事多いのが実情です。 そして、その後どうなるかというと、その人の属人性に大きく依存した働きのみが期待さ
Chocolatey - The package manager for Windows
Resources Watch videos, read documentation, and hear Chocolatey success stories from companies you trust. View Resources Events Find past and upcoming webinars, workshops, and conferences. New events have recently been added! View Events Courses Step-by-step guides for all things Chocolatey! Earn badges as you learn through interactive digital courses. View Courses Join our monthly Unpacking Softw
DockerでオレオレVPSを作った話 - Masteries
Docker Advnet Calendar 2014の6日目の記事となります. 今日は, ｢DockerでオレオレVPSを作った話｣というタイトルで, 最近作った｢Pocker｣という名前のアプリケーションを紹介したいと思います. どうしてそのようなアプリケーションが必要になったのか, その中でのDockerの使い方や, 利用したテクニックなどについてお話できれば, と思っています. あらすじ 自分は昔から｢さくらのVPS｣を愛用していて, 趣味で作った小規模な自分用ウェブアプリのようなものを, VPSの上に複数個設置していました. さくらのVPSは非常に安価で, しかも価格が固定という事もあり, 小規模なウェブアプリを共存させるには最適だったのですが, 1つのVPSに複数のWebサービスを設置してくると, ｢ゴミが溜まってくる｣という問題が出てきます. つまり, うまく管理していないと
Composer を倍速にした、たった 1 行のコード
まだ 12 月早々ですが、PHP ユーザに素敵なクリスマスプレゼントが届きました。 いまや使うのが当たり前となった Composer ですが、複雑な依存解決に実行時間がかかるのがネックでした。 これは日本国内だけでなく、海外のユーザも同じで、皆がしょうがないと思いつつも、小さな不満を持ちながら使っていました。 そんな、ある�日、わずか 1 行のコードが追加されたことで、実行時間が、わずか半分になるという現象が起こりました。 Composer を倍速にするには？ composer self-update を実行して、最新版にするだけです。 $ composer self-update 実際の効果 このコードの効果を見てみましょう。composer コマンドの --profile オプションを使って、実行時間と使用メモリ量を出力します。 $ composer update --dry-run
Building the Future of Shipping
Built on Docker Swarm, Shipyard gives you the ability to manage Docker resources including containers, images, private registries and more. Shipyard differs from other management applications in that it promotes composability and is 100% compatible with the Docker Remote API. Shipyard manages containers, images, nodes, private registries cluster-wide as well as providing authentication and role ba
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
