こうしてふりかえりは終わってしまった / A Demise of a retrospective ふりかえりカンファレンスで一番面白かった発表資料です。 資料をざっくり要約すると ふりかえりは最初は順調に機能するがある段階で停滞し、次第に「効果が出ていないもの」と判断されて廃止されてしまう、という話です。 理由として最初は低コスト高リターンの課題を倒していけるが、それらをすべて解決すると残るのは「リターンはあるが、コストが高すぎて解決できない課題」と「コストは低いがリターンもほぼない課題」だけになります。 開発チームは前者を「コストが高すぎて解決できない」と忌避し、後者だけに打ち込んだ結果、リターンが出ずに振り返り事態を無価値を判断してしまうからです。 ふりかえりを廃止することでチームの成長は停止してしまうでしょう。 これを防ぐために「コストが高すぎて解決できない」課題を解決する方向に頑張
これは Chatwork Advent Calendar 2日目のエントリです。 また、このエントリの公開日翌日に開催される"だいくしーのスクラムBar #1" で取り扱うテーマについての詳細な解説記事も兼ねています。 chatwork.connpass.com スクラムマスターって何をする人なの？ 本項ではこれについて少し考えてみたいと思います。また、ぼく自身が普段どういうことを考えながらスクラムイベントや、その他の仕事をしているか、なども書いてみようと思います。 スクラムマスターは、ソフトウェア開発に関する他の職種と比べても、具体的な職務内容がわかりづらい役割なのかな、と思います。少し乱暴な言い方をしてしまうと、デザイナーがいなければデザインはできないし、プログラマーがいなければアプリケーションコードを書くのはとても困難です。しかし、スクラムマスターがいなくても別に開発はできます。 そ
開発生産性 Advent Calendar 2022 16日目の記事です。 はじめに ペイトナー株式会社の脇田（@shimpeee_）です！『ペイトナー ファクタリング』開発チームでエンジニアリングマネージャー兼スクラムマスターとして、開発生産性と日々向き合っています。 「コード品質？レビュー効率？いや、PR数だ！！！」これは、他の誰でもなく、半年前の自分に声を大にして伝えたい叫びです。 「PR作成数をKPIにすると良い」とは知っていましたが、実は勘違いしていました。 コード品質やレビュー効率が改善された結果、PR作成数が増えると思っていました。ですが、実際は逆でした。 PR数を増やそうとする（つまり、 PRサイズを小さくする）ことで、レビュー効率が改善され、コード品質も高まっていくのです。 本記事は「PRサイズが大きいことが、生産性を落としている全ての元凶だったのか・・・！」と気づくまで
ふりかえりでKPTのようなポジティブ/ネガティブな話題を出すような手法を使っていると、悪いところの掘り下げはサクサクできる一方で、良いところをうまく膨らませるのが意外と難しいように思います。書いた本人に話してもらって、ファシリテーターが「いいですね」とコメントして終わりとか、「コメントないですか」と聞いて誰も話さなくて終わりとか、そういった場面を見たことがある人は多いんじゃないかと思います。悪いところを解決するのは慣れていても、良いところを伸ばすための道具箱が空っぽという状態ですね。 そんなチームの最初の道具として次の質問を贈ります。 それがうまくいった要因は何かありますか？ これです。なんとかのひとつ覚えで良いので、ちょっとでも話が広がらないなと感じたら、まずはこれを聞いてみると良いです。この質問が優れているのは、出来事や本人の経験から単刀直入にプラクティスを抽出できることです。何か聞き
2023年のお買い物、技術書編です。 技術書以外はこちら blog.magnolia.tech とりあえずノータイムで買っちゃえ！損は無いよ！という3冊 他に、類似の本がないか、有ってもこっち買っておけばよくね？という3冊 なっとく！関数型プログラミング なっとく！関数型プログラミング 作者:Michał Płachta翔泳社Amazon Scalaをベースとした関数型プログラミングの学習本。オブジェクト指向言語であり、関数型プログラミング言語であるScalaの特性を生かして、命令型から宣言型のコードの書き方への変え方を学んでいくスタイル。 前半の凄まじい丁寧な学習のステップと、後半の「ここまで一気にやらなくても良くない？」の落差もすごいけど、ページ数の厚さに躊躇せず、前半1/3くらいを時間をかけて丁寧に学習するくらいが良いと思います。 周りに良い先生が居れば別ですが、そうでなければこの本
スクラムガイドに載っていないスクラムのはじめかた - チームでスクラムをはじめるときに知っておきたい5個のコツ - / How to start Scrum that is not written in the Scrum Guide
Scrum Fest Fukuoka 2024にて。 https://confengine.com/conferences/scrum-fest-fukuoka-2024/proposal/19555/5 プロフィールやお問い合わせはこちらからどうぞ！ https://agile-monster.com/profile/ https://agile-monster.com/contact/
会社でScrapboxを使っている。チームごとやプロジェクトごと、話題や趣味ごとにプロジェクトを作っていて、うちのチームは1年3ヶ月くらい使って3000ページほどに達している。 どんどん書いていたのだけど、最近、どこに何があるかわからなくなってきていた。同僚に、ここの仕様はどうでしたっけ、って何度も聞いてしまうことがあったので、これはまずいと思ってちょっと整理していた。 表記揺れを直す One Fact in One Placeということで、どんどんページをマージしていった。ページを同名にリネームするとマージボタンが出現して押すだけなので楽。 よくみるとスペースの有無によって同じ話題のページが2ページに分かれていたり、略称と正式名称と、「(正式名称)まとめ」の3つにわかれたりしていた。情報を探しているときにはどんどんマージしたりしないので、今回マージするぞと見返せてよかった。 サポート担当
これまでエンジニアやスクラムマスターとしてスクラムチームに関わって来ましたが、その過程で何度も「相対見積もり」や「ストーリーポイント」に纏わる悩みにぶち当たってきました。工数や期間での見積もりに慣れていた私にとって、それらは理解も実践もしにくい手強いものでした。 今回は、私が実際に直面した問題と、それらを打破するためチームで取り組んできたことを思い返してみようと思います。 壁1. 「相対見積もり」の考え方を理解できない 壁2. ストーリーポイントが「何を見積もる手段か」を理解していない 壁3. 見積もりをコミットメントと捉えてしまう まとめ 壁1. 「相対見積もり」の考え方を理解できない バックログ上に積まれたユーザーストーリーやエピックを見積もろうとしたとき、私たちは真っ先に「こんなコンポーネントを新規実装するだろう、おそらく2日くらい掛かる」「あの既存機能をいじる必要があるが、複雑な箇
Autonomous Database - Dedicated 技術詳細 / adb-d_technical_detail_jp
【翻訳】あなたのスクラムチームの成熟度は？
みなさんこんにちは。@ryuzeeです。 3月23日に『スクラム実践者が知るべき97のこと』が発売になりますのでよろしくお願いします。 さて、スクラムチームがどれくらいの成熟しているかは、とくにスクラムを始めてまだ長時間たっていない場合には気になるところだと思います。 そこで今回はスクラムチームの成熟度を自己評価して、改善に結びつけるための資料を共有します。 この資料はScrum.orgのトレーナーであるRon Eringa氏がブログで公開しているものです。 このモデルでは、スクラムマスター、プロダクトオーナー、開発チーム（スクラムガイド2020で開発者に改められています）のそれぞれで成熟度を明らかにします。 そして、全体でいちばん低い数字がスクラムチームとしての成熟度になるとされています。 使い方ですが、人事評価や他チームとの比較に使うのではなく、チームとしてどう成長していくべきか、どこ
2013年に「日経電子版」のソフトウェア開発を100%外注から内製化、アジャイル開発に切り替え、開発サイクルやチームの抜本的な改革を見事成功させた日本経済新聞社。その取り組みは、多くの注目を浴び、400以上のはてなブックマーク数を獲得しました。 「あの『日経電子版開発チーム』が内製化とアジャイル開発の成功から6年がたった “その後” を語る！」では、内製化とアジャイル開発の成功体験を他の部署にも応用し、全社をあげて開発改革に取り組んでいる模様を取り上げました。 本記事では、同社が次に取り組む、個人やチームの開発成果と事業成果を結びつけるための「OKR（オーケーアール）」を導入したきっかけと運用、そして、成功したこと、失敗したことについてお伺いします。 ■自己紹介（右から） 情報サービスユニット プロダクトマネージャー 斎藤祐也さん デジタル編成ユニット プロダクトマネージャー武市大志さん
アジャイルなチームをつくる ふりかえりのガイド / A Retrospective Guide
2021/02/19 Developers Summit 2021 （https://event.shoeisha.jp/devsumi/20210218/session/3078/） 19-C-9 『アジャイルなチームをつくる ふりかえりのガイド』の登壇資料です。 ふりかえりが少しずつ認知されてから、様々なところでふりかえりの重要性が叫ばれてきました。ただし、どう始めたらいいのか、どう定着までに至るのか、道のりはあまり述べられてきていません。 ふりかえりは、チーム全員で定期的に立ち止まり、チームがより良いやり方を見つけるために話し合いをして、チームの行動を少しずつ変えていく活動です。COVID-19とリモートワークの加速によって、これまで顔を合わせて働いていたチームも、直接会って仕事をする機会は今後も減っていくでしょう。これから新しくチームを作ることも今まで以上に難しくなっていきます。
10/5 の「ふりかえりの手法をたくさん学ぼう」でいいふりかえり手法をたくさん紹介いただいたので、改めてまとめます。 記事の元になったお話、資料 ここに記載しているのは、以下で紹介された手法です。 ふりかえりの手法をたくさん学ぼう(ふりかえりam #27-28公開収録) - connpass podcast ep.27【#ふりかえりam】ふりかえり手法をたくさん学ぼう（前編）～ 紹介した手法：いっぱい ep.28【#ふりかえりam】ふりかえり手法をたくさん学ぼう（後編）～ 紹介した手法：いっぱい YouTube ふりかえりの手法をたくさん学ぼう ふりかえり手法の確認には、以下が紹介されていました。 ふりかえりチートシート 各手法、簡単に実践方法と効果を書いています。 実践例の記事が見つかったものはリンクを貼っているので、詳細はそちらをご参照ください。 各手法の参考リンクは、適当にググって出
スクラムガイド2020からは、IT以外の分野にも適用してもらいたいみたいなので、ソフトウェアに特化したものはできるだけ排除する（とはいえ、なかなか難しいね） スクラムガイドでは「我々は1990年代初頭にスクラムを開発した」とあるので、まずは当時の状況を把握しておくとよさそう。おおざっぱに言うと、ソフトウェア業界的にウォーターフォールじゃダメだという雰囲気になっていて、何かいい方法がないものか……とみんなが模索していた時代。 そこで、過去の文献を遡り、当時でも使える概念が発掘された。それが、以下の竹内・野中論文である。Jeff Sutherlandはここから「スクラム」という名前を拝借しており、両名は「スクラムの祖父」と称される。 Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard
※ スクラムフェス仙台2023 で登壇した際の資料です。 スタートアップでの開発形態は、ウォーターフォールに依存しがちなJTCと違って、プロダクトバックログやカンバンぽいものを使ったアジャイル風の開発をしていることが多いです。 しかし一方で、そういったスタートアップにはプロダクトバックログはあっても、たいていPBIの1つ1つがやたらでっかくて、1つ1つにしっかり担当者がアサインされてて、何ならデッドラインまで記されています。 これを引き起こすのは、スタートアップ特有の個人分担制です。 多くのスタートアップ企業はたいてい、エンジニア1〜2名からスタートし、個々のエンジニアの馬力で開発をこなしていくところから始まります。このときのバリバリ個人開発なノリが、エンジニアが増えても継続してガチガチの個人分担制に移行しがちです。 このセッションでは、個人開発をこじらせたスタートアップ企業がどうやって個
スクラムやる意味ある？を乗り越えるために
大体2、３ヶ月くらいで次のステージに進んでいることがわかります。また、気持ちい良くらいタックマンモデルに沿ってチームの状態も変わっていることもわかります。 形成期 ここからは、それぞれの段階でチームの状態の詳細、僕の心境と取り組んだことについて紹介します。まずは形成期から。昨年の6月、スクラム開発を採用してチーム開発が始まりました。開発を始める前、僕を含めたチームのメンバーからの声は「スクラムってどうやるんやろう？」とか「初めてやからワクワクするわ」みたいな感じで期待と不安が半々でした。そんな時、ひょんなことからリーダーが僕に「スクラムマスターやってみーひん？」って提案を受け、「やったことないけど挑戦してみよう」と思い、スクラムマスターに挑戦することになりました。 僕の心境は「何したら良いかわからんけどとりあえずスクラムガイドに沿って進めてみたらいいんかな？」でした。ふざけんなって声も上が
アジャイルの「理論」や「理想」だけではない、 実際に実践したからこそ見えてきた「現実」に役立ったヒントを紹介したのは、マネジメントソリューションズ社の渡会氏。「Rebuild our Agile!」をテーマに掲げた「Agile Japan 2023」で、アジャイルのRebuildについて発表しました。全2回。前半は、「選択肢のRebuild」と「ロールのRebuild」について。 開発の考え方をウォーターフォール→アジャイルにRebuild 渡会健氏：みなさん、こんにちは。マネジメントソリューションズの渡会と申します。これから、「アジャイルで実際に困ったからこそアジャイルをRebuildした話」ということで講演させていただきたいと思います。よろしくお願いいたします。 （会場拍手） 最初に、私の自己紹介。この自己紹介の中にも、けっこうRebuildしたことが入っています。 最初の20年は、プ
株式投資にリスクはつきものとはいえ、やはり損はしたくない。特に投資に慣れていない初心者のうちは、なるべくリスクの少ない方法で知識や経験を積んでいきたいところ。30歳を機に真剣に資産形成について考え始めた筆者も、そんな投資ビギナーの一人。調べてみたところ、「初心者には米国株がオススメ」という情報をキャッチした。しかし、国内を飛び越え、いきなりアメリカってどうなんだろう……。 また、資産形成のためだけでなく、環境や社会、ガバナンスを考慮した企業への投資である「ESG投資」にも注目が集まっている。特に米国でのESG投資額は2020年で17兆ドルを超え（Global Sustainable Investment Review 2020より）年々成長しているそう。 そこで、米国株の投資に詳しいスペシャリスト2人に、米国株は初心者向きなのか？ そもそも国内とアメリカの何が違うのか？ また、近年のトレン
すべてがXPになる ─ エクストリームプログラミングで見える開発風景（セミナーレポート） - Agile Journey
アジャイルソフトウェア開発を企業が導入する際に、スクラムと並んで名前が挙がる開発手法にエクストリームプログラミング（XP）があります。ガイドブックや研修が存在するスクラムに対して、ペアプログラミング（ペアプロ）やテスト駆動開発といったプラクティスをエクストリーム（極限的）に実践しようというXPの導入には、どこから始めればよいのかと戸惑う開発組織もあるようです。 2022年6月に開催されたユーザベース主催の勉強会「エクストリームプログラミングで見える開発風景」では、XPの提唱者であるケント・ベックの著作などの翻訳者として知られる角征典さんと、XPを導入しているユーザベースのソフトウェアエンジニアである野口光太郎さんが講演したのち、XPの始め方やエンジニア以外との体制づくりなどについて、視聴者の質問をもとにパネルトークが行われました。 本記事では、組織にXPをどのように導入するか、またスクラム
私たちはスクラムを採用していて、プロダクトオーナーの私と、3人の開発者、そしてスクラムマスターというチームでやっている。 初期段階の頃は、頭の中のユーザーストーリーを開発者に伝えるのをめちゃくや丁寧にやっていた。 リファインメントでたくさん会話して、バイブスを伝えることに多くの時間を費やしていた。 たくさんの会話をしそれを簡潔にテキストに落とし込みバックログを完成させていた。 プランニングの時も開発者の帽子を被り、必要があったら口を挟みつつラジオ参戦していた。 数ヶ月も一緒にやっていると「今ある機能をもっと良くするならこうだよな」というのが開発者の中に思い描けるようになっていたし実際合っているので、リファインメントでたくさんの会話しなくても「あとはお任せ」の様にやれるようになっていた。 バックログを積み、リファインメントで意思疎通できてるな、ヨシ、をシュッと確認して、その後のテキストへの落
こんにちは、STORES ECでフロントエンドエンジニアをしている@daitasuとバックエンドエンジニアをしている@phayacellです。 STORES ECでは、今年の5月よりエンジニア内の大きな体制変更がありました。 その変更では、フロントエンド/バックエンドで分かれていたチーム体制から、デザイナーやプロダクトマネージャーも含めた職能横断型のチーム体制へと変更になったのですが、この記事では、その際に生じた、今まで各チームで行っていた開発の進め方とのギャップや手法をマージしていく上での課題について、またそれらをどのように解決していったのかについてをお話しします。 チーム改善までの背景 組織体制の変更 元々STORES ECでは、フロントエンド/バックエンド/デザイナーは独立したチームとして動いており、PJTとしてメンバーが切り出されてはいますが、活動の主体としては職能で分かれている組
リモートワークでも生産性を上げる！スクラム創始者直伝の実践ノウハウを日本語化して入門者向けにまとめました。 - Qiita
リモートワークでも生産性を上げる！スクラム創始者直伝の実践ノウハウを日本語化して入門者向けにまとめました。プロジェクト管理スクラムリモートワークコミュニケーションコロナウイルス はじめに 認定スクラムマスター(LSM)取得者向けに「Distributed Teams: Mitigating Business Risk in Uncertain Times」と題したウェビナーがスクラム創始者の Jeff Sutherland 氏を交えて3月に行われました。 この投稿はウェビナーの内容を噛み砕き、リモートワーク環境でもスクラムの実践がスタートできる内容を目指しました。チームリーダーやマネージャーとしてスクラムを推進している方や、これから導入を検討している方のご参考になれば幸いです。 まずは結論から リモートワークでより成果を上げる働き方は可能なの？ 可能。→ リモートチームを成功させた企業のユ
スタートアップ企業が実践する「身の丈スクラム」の現在地 / Current State of 'Right-Sized Scrum' Practices in Startups
Scrum Fest Osaka 2024で発表した内容です。 https://www.scrumosaka.org/ https://confengine.com/conferences/scrum-fest-osaka-2024/proposal/20059 ■リンク 後回しにされがちな…
みなさんこんにちは。@ryuzeeです。 よく受ける相談の1つに、「スクラムチームの開発者は複数のチームやプロダクト、プロジェクトを兼任してもよいのか」というのがあります。コーチ業をしている人ならみんな受けたことがあるものだと思いますが、詳しく見ていきます。 まず最初に結論ですが、タイトルにもあるとおり、「スクラムチームの開発者は複数チームを兼任しないほうがよい」です（スクラムガイドには書いていないですが、スクラムガイドは全てを詳細に記したハウツーではありません。あくまでゲームのルールです）。 理由を順番に見ていきましょう。 1. 開発に使える時間がかなり少ないスクラムチームの開発者はスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブといったイベントと、プロダクトバックログリファインメントのような活動に一定の時間を使います。 チームによって時間は変わ
機械学習・データ部 / データチームの @irotoris です。こんにちは。 データチームでは社内で使うデータプラットフォームやデータマートの開発をしています。今日は弊チームの開発スタイルの中から「プレスリリース駆動開発」を紹介します。 データチームの開発スタイル データチームの開発は1週間のタイムボックスで、月曜日にバックログやプロジェクトから今週取り組むタスクを計画し、金曜にスプリントレビューを行っています。デイリーでは夕会を行っています。ベロシティの計測などは今のところできていませんが、いわゆるスクラムっぽい開発です。 その月曜朝の計画会で、まずプレスリリースを書いています。 プレスリリースとはなにか？ 本来プレスリリースは新商品や新サービス、経営・人事などの企業情報を、ニュースとしてメディアに掲載する文書ですが、ここではデータチームが開発・提供する機能や改善をユーザーに伝えるため
Findy 開発生産性 Conference における発表です
みなさんこんにちは。@ryuzeeです。 仕事柄さまざまな会社のいろいろなチームから相談を受けます。 具体的な相談のこともあれば、抽象的な相談のこともあります（内容が具体的になっていればもう解決までそう遠くありません）。 抽象的な相談で多いのは「なんとなくうまくいっていない気がするけど、何を確認したらいいの？」というものです。 今日はこの質問に対して、どう対応しているかを共有したいと思います。 スクラムをベースに書いていますが、スクラムでなくても構いません（その場合は適宜用語を読み替えてください）。 確認ポイント いきなりほぼ結論です。 このような相談を受けたときに、いちばん重要な確認ポイントは 「毎スプリントごとに動作するソフトウェアを作って、チームの外側に見せてフィードバックをもらっているか？」 です。この確認をしないうちに「スクラムイベントは全部やっているか？」とか「プロダクトバック
カンバンボードで業務を可視化・整理しよう - 組織に合ったカンバンの設計・運用をヴァル研究所の実践に学ぶ - Agile Journey
Agile Journeyをご覧の皆さん、こんにちは。ヴァル研究所の熊野壮真 / 小泉翔太です。 私たちの勤務する株式会社ヴァル研究所は、日本で最初に発売された経路検索サービス「駅すぱあと」を中心に、公共交通に関連するさまざまなプロダクトを展開しています。最近では MaaS （Mobility as a Service)）といった、未来の移動のあり方を変えていくような取り組みにもチャレンジしています。 これらプロダクト開発の現場にはアジャイルの考え方が浸透しており、各チームでは現場ごとに合わせたさまざまな形のアジャイルの実践が見られます。その実践手法は多様ですが、各チーム、共通して力を入れているのが「カンバン」による仕事の可視化の取り組みです。こと「カンバン」に関しては開発部門のみならず、バックオフィス部門でも積極的に活用しており、その活用場面の多さ、バリエーションの豊かさは当社の特色と言
AWSを退職してYuimediに入社します
こんにちは。@watildeです。 世界で一人目となるDeveloper Relations Engineer(Mobile)として1年半ほど在籍したAWSを3/31にて退職をして、4月より世界で医療データの利活用を広く推進するYuimediへの入社をすることとなりました。AWS在籍中は@akitsukadaをはじめとする、多くの同僚に温かいご支援を頂いて成果を共創できたことを嬉しく思います。 本日にてAWSを退職しました、お世話になりました！これからのお話はブログにてまた書こうと思いますが、ひとまずご挨拶まで。 pic.twitter.com/lbaapJFwvi — Daijiro Wachi (@watilde) March 30, 2022 この記事では、過去・現在・未来の軸で 1) 何をしてきたのか 2) 今月から何を行うのか 3) 今後は何を目指すのか について共有して関係者、
はじめに 筆者は初めてアジャイルの開発でスクラムを経験。3ヶ月が経つ。 今回チーム内で出た意見を元に、良い気づきを得ることができたので記事にまとめました。 ★フルリモート環境 ★バックエンドとフロントエンドでチームが分かれている ★私を含む新規参画者はスクラム初心者 ★バック、フロントそれぞれスプリントの振り返りが終わった後、 スクラムチーム全員で共通の振り返りという名の雑談タイムがある。（30m～） 雑談の時間っていらなくないですか？ この議題があがり、スクラムチームの意見をいただきました・・・ 最終的な投票結果では、現状のままで良いという結論に至りましたが 雑談のメリット 改善案 新しい手法の提案 色んな気づきを得ることができたので記していきたいと思います。 この議題が生まれた背景 そもそも、開発状況が芳しくない。という所に 新規参画者の方が目をつけてくださいました。 『進捗率があまり
組織はツリーではない - Jim Coplien さんのスケールフリーネットワーク論 - kawaguti’s diary
RSGT2020の基調講演をやっていただく Jim Coplien さんによる、大規模組織のお話がありました。 この話を聞くのは実は三回目(飲み屋、ウィーンでのScrum Gathering、今回)ですし、ありがたいことに、色んな人に日本語で説明することもあるので、周りの人とも話しながら自分なりの認識がまとまってきました。 いや、お前のまとめなんていらないんだよ、とは思いますが、全体をちゃんと書くのは難しいので(ビデオとっとくべきでした)、ざざっと書いておきます。 人々は組織をツリー構造*1で考えがちで、実際に公式な組織アサインはそのように運営されがちだが、末端のノード間やたすき掛けのようなつながりは自然に起きていて、それによって情報流通の効率性が維持されている。これは、兼務をつけて複数部署にマネージャーを頭出しさせるのとも違うし、マトリックス型組織でプロジェクト運営するのともちょっと違う
「入門 継続的デリバリー」は継続的デリバリーを学ぶのに最適な教科書だった. - Lean Baseball
最近読んだ「入門 継続的デリバリー」がとても良かったので紹介しますね, というエントリーです. 入門継続的デリバリー良かったです. 「継続的デリバリー（Continuous Delivery）」とか「DevOps」ってどこから学ぶかわからんな！？ というのは割とあるあるだと思っています, そもそもめちゃくちゃ難しい話なので（ちゃんと学ぼうとすると）. そんな中, 「入門 継続的デリバリー」がよく説明できてて良かったので感想と関連する書籍を紹介できればと思っています. TL;DR 入門 継続的デリバリー 我々はなぜCDをするのか? 具体的なプラクティス 入門後に読むべき良著 Kubernetes CI/CDパイプラインの実装 継続的デリバリー チームトポロジー 結び - 我思うCDとDevOps TL;DR 「入門 継続的デリバリー」は継続的デリバリーの大切さと概念, 手法を現実にありそうな
ビッグバンリリース対策でFeature Toggleを導入したら、開発チームが「デプロイできる状態」をより深く考えるようになった - はてなニュース
ソフトウェア開発において注目されるパフォーマンス指標には、デプロイに関係するものがあります。GoogleがDevOpsの取り組みから発表したFour Keysも、デプロイ頻度のほか、コミットからデプロイできるまでのリードタイム、デプロイにともなう障害発生率とその回復時間と説明されています。 そのためデプロイできるブランチへのマージは小さく、回数を重ねることが推奨されるようになっています。一方で、ビジネス用途のSaaSなどでは顧客との関係から、新機能は適したタイミングで完成度を上げてからリリースしたいという要求もあります。 タレントマネジメントシステム「カオナビ」の開発チームでも同様の課題感を抱えており、その解決のためFeature Toggle（機能トグル）を導入してデプロイとリリースの分離を図りました。その経緯や成果について、導入を主導したCTO室の富所亮さん、サービス開発部で実際にFe
ストーリーポイントではなくアウトカムで開発速度を測る #LayerXテックアドカレ - LayerX エンジニアブログ
こんにちは。LayerX バクラク事業部 バクラクビジネスカード開発チームEMの @shnjtk です。新しいMacBook Proがとても気になっています。スペースブラックいいですね。欲しい。 この記事は LayerXテックアドカレ 13日目の記事です。前回は @itkq による 情報の流通性を上げコミュニケーションを活性化させるNotionデータベース でした。次回は @yossylx が担当します。 今回は、開発チームの開発速度をどのようにして測るかということについてお話します。 ストーリーポイントによるベロシティの計測 ストーリーポイント（SP）とは、アジャイル開発において、開発しようとするユーザーストーリーや機能、その他のタスクの大きさを表す見積もりの単位であり、タスク同士の相対値で表現されます。例えば「この機能はSP 3」、「この機能はSP 5」のように使われます。タスクの完了
「いい感じに成長する」エンジニアのキャリアと学び方 - 2023年オススメPython本を添えて - Lean Baseball
このブログおよび, 登壇・アウトプットはゴリッゴリのエンジニア, 本職はコンサル企業のマネージャーとしてクラウドエンジニアリングのコンサルをやっている者です*1. この記事は, 当ブログの名物である, Pythonのオススメ書籍（と関連する技術書）の紹介エントリーです！ ※去年の記事はこちら. 本年のエントリーでは「今最もいい感じなPython本」の紹介に加えて, キャリアごとに読むべき技術書（と学び方）の選び方 この年末に読んで欲しい技術書（Python本とそれ以外） 「エンジニアのキャリア形成的に期待値の考え方大事だよ」という話 この三本立てでご紹介できればと思います. というわけで, 本年のラインナップは以下の通りです. 要約すると キャリアレベルを考える オススメ技術書籍2023 ジュニア🔰 メンバー マネジメント ボード 結び - キャリアごとの期待値 【番外編】私の推し書籍2
この記事は SmartHR Advent Calendar 2023 2nd の12日目の記事です。 こんにちは、SmartHRでプロダクトエンジニアをしているytakaです。 この記事では、チーム間のコミュニケーションにおける、シンプルかつ強力な手法をご紹介します。 それが「ただ話す」です。 ただ話す 「ただ話す」は、チームの輪読会で読んだ『大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法』にて紹介されていたメソッドです。本書には以下のように記載されています。 大規模なグループで何年も働き、複数チームにまたがる調整テクニックを数多く観察した結果、最も上手くいきそうなテクニックを発見しました。手順は次の通りです。 (1) あなたは、チームBとの”調整が必要”なことに気づきます。 (2) 立ち上がって、 (3) チームBのところに歩い
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（後編）。Agile Japan 2021
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（後編）。Agile Japan 2021 アジャイル開発において開発担当者を外部のベンダに依頼した場合、必然的に発注側の企業とベンダ側の開発者が1つのチームとなり密なコミュニケーションを行います。 すると、発注側の企業がベンダの開発者の業務遂行に対して具体的な指示を行う、いわゆる「偽装請負」とみなされる可能性があるのではないか？ という疑義が以前から呈されていました。 この疑義に対して、どのように対処すれば偽装請負と見なされないか、その指針が今年9月に厚生労働省から「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」として公表されています。 オンラインで11月8日に開催されたイベント「Agile Japan 2021 Day 0」では、この疑義応
ちょっとだけ読んでから積む「積⭐️読タイムアタック」で、タワーと化した購入書籍の未読圧のプレッシャーから解放されました
【資料公開】ベロシティ Deep Dive
みなさんこんにちは。@ryuzeeです。 2024年1月10日〜12日開催のRegional Scrum Gathering Tokyo 2024の登壇資料を公開します。 「ベロシティ Deep Dive」ということで過去のDeep Diveシリーズの続きになっています。 過去のDeep Diveシリーズはこちらからご覧ください。 プロダクトバックログ Deep Dive スプリントプランニング Deep Dive スプリントレビュー Deep Dive セッション資料は以下になります。 結論から言うと、「ベロシティなんかにDeep Diveせず、もっと重要なところに集中しろ」です。 スクラムチームの状況を何らかの数値で表したいという考え自体は尊重しますし、それが役に立つこともあります。 ただし、数字遊びをしたところでプロダクトの価値を生み出せるわけではないので、ほどほどにしましょう。 ス
リーダブルテストコード - Qiita
はじめに よく言われるように、ソースコードというものは書かれることよりも読まれることの方が多く、それゆえ読みやすいコードを書くということが非常に重要です。それはテストコードにおいても同様であり、プロダクトコードと同等に資産として扱う必要があります。 テストコードは具体的な値を用いて記述し、また複数の変数の値の組み合わせでテストケースを起こすため、プロダクトコードと比べて冗長になりがちです。 書籍『リーダブルコード』の14章でもテストコードの読みやすさについて触れられていますが、本稿では読みづらいテストコードをリファクタリングして読みやすくするためのテクニックを紹介したいと思います。 なおサンプルコードはJavaScriptで記述されており、そのテストコードはJest1を用いて書いています。 ソースコードはGitHubにあります。 リファクタリング(その壱) 以下の、決して読みやすいとはいえ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「こうしてスクラムが終わってしまう」前にすべきこと
スクラムマスターって何をする人なの？ - だいくしー(@daiksy)のはてなブログ
「コード品質？レビュー効率？いや、PR数だ！！！」 - Paytner Tech Blog
KPTのKがいまいち膨らまないチームに贈るパワフルな質問 - yigarashiのブログ
2023年買ったもの（技術書とか） - Magnolia Tech
チームのScrapbox3000ページくらいを見返して整理した - hitode909の日記
スクラムチームがぶち当たる「相対見積もり」の壁と、私たちの乗り越え方
スクラムマスターやマネージャーのための信頼構築につながる傾聴の技術
日経電子版開発チームがOKRを8ヶ月運用してうまくいった点とうまくいかなかった点 | Backlogブログ
「ふりかえりの手法をたくさん学ぼう」で紹介された手法まとめ - Qiita
勝手に注釈付き参考文献 | スクラムガイド日本語版
個人分担性がスタートアップの成長を殺す �〜協働でチームがめっちゃ進化する話〜
アジャイルを導入したものの続けられなかったあなたへ 誤解や理解不足で起こる“もったいない”を解消するヒント
企業だけでなく、自分の未来にも投資？投資初心者が知っておきたい、米国株でのESG投資 - はてなニュース
「知識の呪い」、チームメンバーと以心伝心しているという思い込み - #あすみかんの上にあすみかん
職能横断型スクラム体制になってからのチーム改善活動 - STORES Product Blog
なぜスクラムチームの開発者が複数チームを兼任しないほうがよいのか
プレスリリース駆動開発のすゝめ - LayerX エンジニアブログ
組織をスケールさせるための Four Keys とチームトポロジー
アジャイル開発がうまくいっていない気がするというチームに確認すべきこと
振り返り時間の雑談っていらなくないですか？ - Qiita
チーム間コミュニケーションにおける「ただ話す」のすすめ - SmartHR Tech Blog
QAエンジニアがSMに憧れてしくじった話