循環する学び～現場とコミュニティの境目で考える～/Learning Cycle between a team and a community
スクラムとデッドライン壊れゆくチームをつなぎとめるもの/Scrum and Deadlines
循環する学び～現場とコミュニティの境目で考える～/Learning Cycle between a team and a community
他者と働き、チームで成果を出す方法- 人との関係からみるカケハシ -/KAKEHASHI of the relationship between members
他者と働き、チームで成果を出す方法- 人との関係からみるカケハシ -/KAKEHASHI of the relationship between members
ストーリーポイントではなくアウトカムで開発速度を測る #LayerXテックアドカレ - LayerX エンジニアブログ
こんにちは。LayerX バクラク事業部 バクラクビジネスカード開発チームEMの @shnjtk です。新しいMacBook Proがとても気になっています。スペースブラックいいですね。欲しい。 この記事は LayerXテックアドカレ 13日目の記事です。前回は @itkq による 情報の流通性を上げコミュニケーションを活性化させるNotionデータベース でした。次回は @yossylx が担当します。 今回は、開発チームの開発速度をどのようにして測るかということについてお話します。 ストーリーポイントによるベロシティの計測 ストーリーポイント（SP）とは、アジャイル開発において、開発しようとするユーザーストーリーや機能、その他のタスクの大きさを表す見積もりの単位であり、タスク同士の相対値で表現されます。例えば「この機能はSP 3」、「この機能はSP 5」のように使われます。タスクの完了
1リリース6,108行から18行へ。ビッグバンリリースを改善した話 - CARTA TECH BLOG
CCI の小坂です。 担当プロダクトの中で、以前からの課題だった ビッグバンリリースを改善したことについて書きます。 開発システムの概要 やってることはCCI の社内システムの開発で、媒体社から提供された媒体資料をもとに、原稿規定を データベース化しています。 データベースをもとに、原稿素材の規定チェックから管理までを行うことができるツールです。 技術スタックとしては バックエンドがJava,Spring Bootフロントが Vue.js,Nuxt.js を使ってます。 これまでの開発フローと課題感 リリースは2-3ヶ月ごとのリードタイムがあった 開発周りのお話です。以前の開発フローは以下です。 - ユーザー要望を issue に起票 - 1-2 ヶ月で開発を行い、ステージング環境で動作確認 - その後にリリース判定 - ビジネスサイドにリリース時期を共有し調整 - リリース この流れを
Project IDX
These days, launching applications means navigating an endless sea of complexity. We felt this pain at Google, so we started Project IDX, an experimental initiative aimed at bringing your entire full-stack, multiplatform app development workflow to the cloud. Project IDX starts with a web-based workspace that'll feel familiar for coding but fresh. And we're just at the beginning of this journey. W
A Modern C Development Environment
Sometimes, C/C++ projects have a long development cycle. When working on such a project, it can be easy to take our development environment for granted, and forget about the effort invested in its bring-up. The build environment works like magic, the test framework is neatly integrated, and the CI/CD pipeline relieves us of tedious, repetitive tasks. For me, all it took was a simple thought: How d
開発チーム間の情報を遠回りさせてる - Mitsuyuki.Shiiba
いまの会社では、エンジニアどうしの距離が近いので、他のチームのエンジニアと一緒に開発に取り組んでたりする。 のだけど僕からは 「この部分はディレクター（社内でスクラムマスター的なロール）さんから、あのチームのディレクターさんに共有してもらってもいいですか？」 って自分のチームのディレクターにお願いしたり 「この部分はプロダクトマネージャ（社内のプロダクトオーナー的なロール）さんから、他のチームに確認してもらってもいいですか？」 ってプロダクトマネージャにお願いしたりしてる。エンジニアどうしで話をして、お互いに状況を理解しているのに、公式なルートとしては、情報を遠回りさせているのだ。 そんなお願いをすると、一瞬（え？エンジニアどうしで話して認識合ってるのに？）って反応をされるし、僕自身も（大企業っぽいかなぁ？）って思ったりするのだけど、自分の気持ちを説明すると「たしかにそうね。おっけー！やっ
フロー効率を重視して「2年半でエンジニア2名→35名」の急拡大組織で高い生産性を実現した話
https://dev-productivity-con.findy-code.io/ 株式会社SODAのセッション資料です。
【追記 2023/06/26】 テックリードに求める役割と適切なチームサイズについて - pospomeのプログラミング日記
自分はDMMプラットフォーム内のマイクロサービスアーキテクトグループという組織の責任者をしているが、 最初に比べると組織がそれっぽく拡大したこともあり、 ここ最近テックリードを立てる機会が増えてきた。 一度自分がテックリードに求める役割と適切なチームサイズについてアウトプットしてみようと思う。 DMMプラットフォームのマイクロサービスアーキテクトグループとは? pospomeがテックリードに求める役割 技術領域をリードする プロジェクトマネージメント 他チームとのコミュニケーション チームメンバーの評価 なんだかんだで総合力 pospomeがテックリードに求めない役割 ピープルマネージメント よく分からない政治的なコミュニケーション 適切なチームサイズについて 新規チーム設立を考慮する場合 おまけ：テックリードに求める役割と適切なチームサイズ以外のあれこれ No.2 の重要性 立場が人を作
プロダクトオーナーを兼務する技術、あるいはその反省 - SmartHR Tech Blog
みなさんこんにちは。ジメジメとした日が続きますがいかがお過ごしでしょうか。SmartHRのプロダクトマネージャーryopenguinです。 今回は、私が複数のプロダクトチームを経験して学んだ「兼務のコツと反省」をお届けします。 「プロダクトに対してPMが少ない」「PMの採用に苦労している」といったみなさまの参考になれば幸いです。 なぜ兼務をはじめたか 2022年9月から、私はタレントマネジメントプロダクト「従業員サーベイ」と、現在未公開の新しいプロダクトのPMを兼務しています。 弊社では、単一のプロダクトに注力するのではなく、連携を前提に複数のプロダクトを提供する「マルチプロダクト」化を進めています。昨年の夏ごろ、とある新規プロダクトが必要と判断され、開発チームを組成することになりました。 弊社の新規プロダクトはSmartHR基本機能との連携が前提であり、その基礎的な知識が必要です。さらに
違和感のつかまえかた - CAT GETTING OUT OF A BAG
ソフトウェアテスト #2 Advent Calendar 2018 - Qiita 24日目の記事です。 qiita.com はじめに 医用機器（自社製品）のソフトウェア開発に従事して、あと数年で３０年になります。うち１５年くらいはプログラマー、現在はテスターとして日々奮闘中です。 私は開発現場で感じるちょっとした『違和感』を大切にしています。風邪のひきはじめに「なんとなくだるい」「鼻がツンとする」「喉が痛い」「寒気がする」というような違和感を感じた時、症状がひどくならないよう行動を変えるのではないでしょうか。それと同じようにソフトウェア開発の現場で感じる違和感も『注目すべきシグナル』と捉え、活動のきっかけにしています。 この記事では 何を見て違和感をつかまえているのか 違和感をつかまえやすくする工夫 違和感をつかまえたあとのこと 違和感をつかまえるために知っておくと良いこと について記載
最短時間で読めるように、認知負荷が高すぎないコードを書く( 『リーダブルコード』『プログラマー脳』) - nakaoka3の技術ブログ
コードは他の人が最短時間で理解できるように書かなくてはいけない。 『リーダブルコード』 p3 今週、機能開発をしているプロダクトのコードを読んでいて、理解が難しく時間がかかってしまい、頭を悩ませていました。 何かヒントになるものはないかと『リーダブルコード』を眺めていて、「コードは他の人が最短時間で理解できるように書かなくてはいけない」という一文を見つけました。 www.oreilly.co.jp コードが「読んで理解できるか」にとどまらず「最短時間で理解できるか」という、積極的な目標になっているのが気に入りました。 既存のコードベースに機能追加するとき、既存のコードで理解に時間がかかるコードがあっても、目的の変更には直接影響しないし、そこを改善するには後回しになっていました。 その結果、リファクタリングはしたいと思っているものの、リファクタリングに使う時間を確保できないということがよくあ
雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
新チームに異動したら、とりあえずPull Request を作るのがよさそう - nakaoka3の技術ブログ
新しいチームに入ったとき、最初に軽めのタスクをもらえると、Pull Request を作ってCIのテストが落ちることで、開発に必要なことが色々と知れるので便利です。 会社で異動があって、2/1付で別のチームに異動になりました。 軽めのタスクをもらって、とりあえずこの辺を変更したらいいかな？くらいで変更して Pull Reqeuset を作ると、CIで実行しているテストが失敗して、このファイルの変更をしたらスナップショットを更新しないといけない、GraphQLのスキーマファイルを変更するとGraphQL Code Generator で型生成をしないといけない、というようなことを指摘してくれます。 最初に全部の説明を聞くのは疲れるし、聞くだけで理解するのは大変です。説明する方も大変だと思います。作業しながらテストが落ちる様子を見ながらやると、手を動かしながら、コードを見ながらなので頭に入って
「ゆみみみっくす」発売30周年メモリアルページ
竹本泉先生原作のメガＣＤ用ゲーム「ゆみみみっくす」が発売されて30年になります。 このページでは、「ゆみみみっくす」開発当初の思い出を書いてみたいと思います。 私は基本プログラマーなので技術的な話が中心になりますがご了承ください。あと、これは非公式な文章なので映像資料はありません。長い文章になりますが楽しんで頂ければ幸いです。 ＣＤ-ＲＯＭゲーム前夜 メガＣＤが出る前のゲームアーツでは、ソフトはほとんどフロッピーディスクで販売していました。 その容量の少なさは誰の目にも明らかで、当時ゲームアーツの社長だった宮路洋一氏も早くからCD-iに興味を示していました。 しかしＣＤになると今度は容量が大きすぎ、それまでのゲームとは全く別なコンテンツ作りが求められるとも予想していました。宮路洋一氏も当時、「大容量プログラムを作るのは大変だけど映像なら埋められる」と言っていました。 ＣＤ-ＲＯＭ搭載のゲー
「ユーザーテストガイドライン VERSION 2.0」を公開しました！ –
都では、令和3年9月にユーザーテストガイドラインを公開し、「テストしないものはリリースしない」を合言葉に、都庁内でサイトやアプリ、システムなどのデジタルサービスを開発する時は、ユーザーテストを実践する取組を進めてきました。 より良いサービスを創るには、利用者の声を聴き、それを反映させるサービスデザインの取組を徹底することが大切です。この取組を更に進めるため、この度、「ユーザーテストガイドラインVERSION 2.0」としての改訂を行いました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Bringing Open-Source Brilliance to Scrum Teams: �A Guide to Enhanced Collaboration
Linear – A better way to build products
推論のはしご: よりよい意思決定をする方法 [2022] • Asana![推論のはしご: よりよい意思決定をする方法 [2022] • Asana](https://cdn-ak-scissors.b.st-hatena.com/image/square/7ed8b4612586d98952d3a39f8f39e87aa3f20325/height=288;version=1;width=512/https%3A%2F%2Fassets.asana.biz%2Fm%2Faadad52f17d60a2%2Fwebimage-article-leadership-ladder-of-inference-2x.jpg)
チーム開発における様々なボトルネックの整理 / Organization of bottlenecks in Team Development
