日々の意思決定の積み重ねを記録するアーキテクチャ・デシジョン・レコード / Architectural Decision Records2023年7月27日「Developers Summit 2023 Summer」にて 「日々の意思決定の積み重ねを記録するアーキテクチャ・デシジョン・レコード」というタイトルで「ADR」について発表した資料です
経営層に開発生産性向上へのコミットについて理解してもらうためには
@stormcat24 です。先日社内で各部署からパネラーを招き開発生産性に関する勉強会を開催したところ、参加者から「技術的負債のことを経営陣に理解してもらうコツはありますか？」という質問がありました。 また、本日開催の開発生産性Conferenceにおいての基調講演で、「LeanとDevOpsの科学」の著者であるNicole Forsgren氏が登壇しましたが、こちらのセッションでもQ&Aでも同様の質問が出ていました。 『LeanとDevOpsの科学』著者登壇！開発生産性Conference (2023/07/13 09:30〜)# 開発生産性Conference 2023 エンジニア不足が叫ばれるなか、開発生産性が今注目を集めています。 インターネット・テック企業はもちろんのこと、大手企業における内製化の取り組みも生産性を上げる1つの手段として向き合う企業が増えてきています。 一方で、
プロジェクトのスコープ調整を考える - 開発チームが信頼を獲得し変化に対応するためのアプローチ - Agile Journey
日々、懸命に開発にあたっていても、スコープ調整は否応なく発生します。Agile Journeyの読者の方も、「予定していた機能開発を削らないといけない」と判断せねばならない経験をお持ちかもしれません。こうした判断をネガティブなものではなく、「変化への対応」と捉えて前向きにプロジェクトを進めるためには、なによりも信頼が必要、と語るのは、10年以上、アジャイルコーチとしてさまざまなチームに関わってきた安井 力さんです。安井さんが信頼を積み重ね、「変化に対応できる」チームになるために必要なことを解説してくれました。 プロダクト開発の中で「あれがほしい」「いつまでにほしい」「もっと早くほしい」とリクエストされることは珍しくないでしょう。また一方で、開発側から「これは難しい」「それまでにはできない」「思ったよりも時間がかかる」と伝えないといけない状況も、これまた珍しくはありません。さまざまなツールや
Pull Requestのセルフレビューでやっていること
この記事は LITALICO Engineers Advent Calendar 2021 その2 の7日目の記事です。 Pull Requestを作るときに割と入念にセルフレビューしてからレビュー依頼するようにしており、また他メンバーのもののレビューをしているときに「これは事前にセルフレビューして修正しておいてほしいなぁ」と思うことがあり、セルフレビューの重要性を感じるこの頃です。 レビュー時に都度指摘してもよいのですが、意外と観点が多いこともあり、思考の整理がてらアウトプットしてみるか、という試みです。 なぜ自分でレビュー？ まず、そもそも自分で書いたコードを何故自分でレビューするのか？という点について書いておきます。 よくプログラミング一般の議論で「N日前のコードは他人のコード」と言われます。ということは、Pull Requestを作成した時点の自分から見て、該当コードを書き始めた時
チームで品質を考えるレビュー / team's review for quality
2021年1月22日（金）JaSST Hokuriku 21にて。
『超入門 失敗の本質』を読みました - 下町柚子黄昏記 by @yuzutas0
この記事では、下記書籍を読んで「計画を立てるときに意識したい」と私が思った項目を列挙しています。 「超」入門 失敗の本質 作者:鈴木 博毅発売日: 2012/09/14メディア: Kindle版 もくじ もくじ どのような書籍か なぜこの書籍を読んだのか この書籍から何を学べるか 逆算思考 リスク管理 偶発依存からの脱却 情報収集 変化への適応 まとめ あとがき どのような書籍か 『失敗の本質』を平易に解説した書籍です。日本が太平洋戦争（大東亜戦争）で敗戦した原因を分析しています。本書では「逆算思考」「リスク管理」「偶発依存からの脱却」「情報収集」「変化への適応」といった観点で「見立てる力」の弱さが指摘されています。 なぜこの書籍を読んだのか まさに自分の弱みが指摘されていると思ったからです。多くの人を巻き込むプロジェクトなのに、出口から逆算できていない、リスクを洗い出せていない、想定外の
開発チームとともに歩むSREチームが成し遂げたいこと | メルカリエンジニアリング
こんにちは、メルカリMicroservices SREチームでEngineering Managerをしている@m4buyaこと渋谷です。 メルカリでは、昨年6月にSREチームの一部をマイナーアップデートし、プロダクトチームに寄り添いSREとしての専門性を活かし信頼性に貢献していくMicroservices SREチームを発足しました。本記事では、そうするに至った背景、何を目指しているのか、これまでに出来たこととまだ出来ていないことを振り返り、今後の展望についてご紹介します。 背景 メルカリでは、2015年よりSREチームを立ち上げ、お客様が安心・安全にメルカリサービスを利用していただくためのシステムの信頼性の維持向上に取り組んできました。年々プロダクトとして成長を続け、トラフィックも増加する一方のメルカリサービスに求められるスケーラビリティ向上において、メルカリSREチームは大きな役割を
アジャイルな開発とチームづくり - Mitsuyuki.Shiiba
社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて
技術的負債とステークホルダと説明責任と / The Debt
Talked at CloudNative Days Spring 2021 Online #CNDO2021. https://event.cloudnativedays.jp/cndo2021/talks/801
アフターコロナ時代を想定して分散アジャイル開発について調べてみた（Agile Software Development with Distributed Teams） - 勘と経験と読経
ウィズコロナなのかアフターコロナなのかはよくわからないけど、今回の新型コロナ感染拡大の事態を踏まえて分散アジャイルについての勘所について整理しようと思って、いろいろな調べてみた。世の中にはTips集と精神論ばかりが溢れている気がする。知りたいのは戦術だ。先人たちの知見から学ぶことはあるのだろうか？ Agile Software Development with Distributed Teams: Staying Agile in a Global World 以前に「A Practical Guide to Distributed Scrum」という本を読んでいる（DAD本で紹介されていた）。 agnozingdays.hatenablog.com この本は基本的に「複数のグローバルなサイトに分散されたチームでのスクラム」について書かれていたと記憶している（若干自信はない）。今回読みたい
WordPress local dev tips: DB & plugins
Hi, I'm Mark Jaquith, a provider of freelance WordPress services, and a lead developer of the WordPress personal publishing platform. This is my blog for all things WordPress. Go to my digital hub at markjaquith.com for links to my other online presences. Running a WordPress site on your local machine is a great way to do development. I’ve taken advantage of this to do development while on flights
iOS&Androidアプリのデザインをする人に知っておいてもらいたいこと - Qiita
知り合いのデザイナーさんから「iOS&Androidアプリをデザインする時に何か知っておくべき事ってありますか？」と質問を受けたので、思い浮かんだ事をずらっと書いてみました。他にも何かありましたらコメントお願いします！ツッコミも歓迎(´ﾛ｀) モバイルアプリデザインの原則とiOS 量が少し多いが、公式のiOSヒューマンインターフェイス ガイドラインは必読。(※ダウンロードに時間かかるので注意) iOSだけに限らず、モバイルアプリのデザインをするにあたって重要な事がまとまっている。 載っていること ヒューマンインターフェイスの原則 アプリケーション設計戦略 iOSテクノロジーの使用に関するガイドライン 標準で用意されている各UI要素(タブやツールバー等)の使い方 マルチスクリーン対応 どのような違いがあるのかを把握する 画面密度(ppi)や画面サイズなど 参考：iPhone, iPod to
1日に175回もGitHubはデプロイしているだとぉ…！？ | Act as Professional
GitHubは普通の会社とどう違うのか？ リリースマネージャーがいない（いる必要がない） 週次のデプロイセットもありません（この週にこれだけの機能をまとめてリリースとかがない） 開発者とデザイナーは、早く提供できるように自分たちでデプロイする（できる）作った人達が自ら確認できて、サクッとデプロイできるのであれば、さっさと作って、ささと出してしまった方が良いに決まっています。これを実現させるために様々な工夫がされているようです。 GitHubの基本的なワークフロー The basic workflow goes like this: Push changes to a branch Wait for the build to pass on our CI server Tell Hubot to deploy it Verify that the changes work and fix a
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クライアントワークのお作法
愛せないコードを書くには人生はあまりにも短い