新メンバーが多い大型プロジェクトでの不確実性との戦い方 - スタディサプリ Product Team Blog
ペアプロ・モブプロ、スキルマップ、1-on-1等々… チーム開発にまつわる各論・方法論・話題をよく見る昨今、関心の高まりは歓迎さるべきことながら つまるところそれらが現実のどのような問題を解決していくのか？ どのように相互作用するのか？ これらが有機的に結びつくことで現実のどのような問題を解決していくか？ こうした疑問に答えたり、具体例とともに記した記事はさほど多くないのではと思います。 本記事では昨年度に筆者のチームが約7ヶ月携わったプロジェクトにて、プロジェクト特性に起因する不確実性と我々がいかに戦ったかを記します。チーム開発を行う方にとってこの記事が実りあるケーススタディとなれば幸いです。*1 なお、本記事では以下のことは本旨とは逸れるため割愛させていただきます。 プロジェクトの機能的側面 技術的不確実性 各取り組み単体の詳細 はじめに / プロジェクトの雰囲気を伝える図 この記事で
Mirrativにおける低遅延配信への取り組みについて【開発中】 - Mirrativ Tech Blog
こんにちは ハタ です。 Mirrativで開発中の低遅延配信機能について、ある程度形がまとまってきて、開発段階から品質チェック段階になりましたのでちょっとだけどんな感じになるか紹介させていただきたいなと思います。 なお、今回紹介するのは開発中のものからピックアップさせていただくので 実際にサービスにリリースされるものとは異なりますのでご留意お願いします。 言葉の定義 まず先に、世の中には「低遅延」という言葉の意味が沢山あるのですが 僕らのいう「低遅延」配信とはざっくり一言でいうと 「配信中の画面がインターネットを超えて視聴画面に見えるようになるまでの早さが短いもの」 としています。 つまり配信画面に映ってるものが視聴端末にすぐ(1秒未満)に再生されるようにする事が目標となっています。 配信した時刻にどれだけ近いか、を示す言葉として低遅延と呼んでいます まずはどんなものを作っているのか 開
土善旅館で最高の開発合宿をしような - だるい
11月23日から26日にかけて三泊四日、友人のVimmer達と合わせて7人で開発合宿をやってきました。私だけがEmacs使いでした。 そんで、利用した土善旅館という宿の開発合宿プランが最高だったのでもっと儲かってくれ〜という思いを込めて宣伝します。 土善旅館の開発合宿プラン概要ここ見てください。一泊二食付きで6,200円（土日祝は6,700円）で、宿泊部屋とは別に別途開発用の部屋を用意してもらってプラス500円です。祝日に利用しても1日あたり合計7,200円（税別）ですよ。ありえんくらい安い。 土善旅館の立地は超閑散とした場所なので周囲に観光するような所はなさそうですし、温泉も露天風呂みたいな豪華な感じではないし、宿の建物自体も割と古めです。ただし開発合宿に必要なのは新しくて見た目の良い宿でもなければ豪華な露天風呂でもありません。必要なのは進捗を生み出す環境です。土善旅館にはそれがある。
Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む（Spotifyモデル）
(注)ヘンリックの許可を得てざっくり意訳しました。原文は『Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds』です。訳に対するヘルプも歓迎します。Thanks Henrik, this article is great for me. プロダクト開発をしている組織において、多角的なチーム構成を実現するのはいつもチャレンジな作業だ！ 今まで見てきた中で印象に残っている例がひとつある。それはSpotifyだ。Spotifyは3つの都市にまたがって30以上のチームにスケールしているが、アジャイルなマインドセットをキープし続けている。 Spotifyは音楽産業を一変させている魅惑的な企業だ。創業してから6年しか経っていないのに、1500万ものアクティブユーザーを抱え、400万以上の決済が行われている。また、そのプロダクトは「
本当はすごいKPTで強いチームを作る for エンジニア - Qiita
この通り、KPTはみんなでやるデバッグ作業です Problem -> Try -> Keepと全てはつながっています 繋がっていないKeepは？ ナレッジ共有と捉えると良いと思います ただ、その場合もはじめに何かしらの問題があって〜からスタートすることが多いのではないでしょうか KPTすごい これで何となく伝わりますかね？ KPTが毎週上手く回っている ＝ 毎週バグを潰している １年続けると KPTが回っている → テスト53回、デバッグ53回行って、チケット消化しつづけ改善してる状態 KPTが回っていない → テスト0、デバッグ0、チケット消化数0 KPTを上手く回すには 伝わったとしたら幸いです それでは次にKPTを上手く回すことを目標にします そもそも上手く回ってる、良い状態ってどんな感じでしょうか？ 良いKPT＝良いデバッグ エンジニアならもう既にわかるはずです 良いProblem
レトロエンジニアのための近代Webフロントエンド事情 - Qiita
フロントエンド開発という言葉があちらこちらから聞こえてくる。 「反対語はバックエンド開発だから、サーバとかCUIじゃない、アプリとかGUIあたりのことを指す広い意味の言葉だよね。」 ・・・とか思ってたらとんでもない。 世の中ではJavaScript界隈を限定している風な使われ方をしている。 私のような C/C++ メインのレトロエンジニアは肩身が狭くなるばかりである。 本文は、近年のWeb技術に追いつこうと調査した結果のメモ書きである。 n番煎じの内容だが、Web業界にいない人間の視点 なので、私と同類のレトロエンジニア等、一部の人には新しい気付きが与えられるかもしれない。 詳しい人の添削・ツッコミは大歓迎。 詳細はリンク先に任せ、私が思う「わかりやすい順序」で、調べたことをざっと紹介していく。 きっかけ 読み飛ばしてもよい。 Reactを使うとなぜjQueryが要らなくなるのか 数年前、
プログラマーが「ネットワーク怪しくない？」と思った時に覚えておくと便利なことまとめ - LIVESENSE ENGINEER BLOG
インフラエンジニアの中西です。 最近プログラマーからこのような話を耳にします。 「ネットワークって難しい/よくわからない」 最近ではAWS,GCPをはじめとするクラウドサービスが充実しているのでWeb界隈のエンジニアはなおさら気にするシーンが少なくなったように思います。 今日は最低限これだけ覚えていたら有事の際にちょっとは役に立ちますよという話が出来たらなと思います。 書式統一のため sudo を省略しています。ご容赦下さい。 コマンド編 ping ping です。疎通確認を行う時のコマンドです。 さすがに分かると聞こえてきそうですね。 例えば、192.168.1.1 というサーバに通信を確認したい場合はこうです。 $ ping 192.168.1.1 繋がる場合はこうなります。 $ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 d
フロントエンドへの複雑化について、一つの視点 - mizchi's blog
これらの件 最近のフロントエンドへの違和感 - nobkzのブログ 日本のWebエンジニアの大半が、変化に対応しきれなくなっている件について。 - 日々、とんは語る。 前提 去年は勝手Reactエヴェンジェリスト(自称)として、日本に複雑化するフロントエンド技術の海外の動静を紹介をし続けていた。 僕としても、フロントエンドは複雑化してると思ってるし、それは「目的の複雑化に対して必要なもの」だったと思っている。ここでいう目的とはSPAの構築であって、普通のウェブサイトは含んでいなかったが、普通のウェブサイトも当たり前のようにリッチ化目指しているのが現在なので、境目は曖昧ではある。 僕もフロントエンドの複雑化がだれにでも必要なものだとは思っていない。が、定期的に情勢を整理して、交通整理するのを心がけてきたし、春からはじめるモダンJavaScript / ES2015 - Qiita みたいな記
開発の見積もりとスケジュール管理 - クックパッド開発者ブログ
こんにちは。会員事業部の丸山です。 エンジニアが開発を開始する時にはタスクの見積もりとスケジュールを作成行って、実装を進めていくと思います。 しかし1ヶ月を超えるような規模の開発をする場合、なかなか予定通りの期日に終わらなかったりすると思います。 そして大抵の場合、増える方向になりますよね。 今回はそういうことにならないために、私が気をつけていること・実践していることをいくつか紹介したいと思います。 見積もりとは まずは「見積もり」とは何なのかを正しく理解したいと思います。 一般的には「見積もり」＝「全タスクとその工数を洗い出す」というものだと思います。 しかしここで以下のことに気をつける必要があります。 見積もりとスケジュールとコミットメントは違う 見積もりとはあるタスクがどれだけの工数(規模)なのかを算出することです。 対して、スケジュールとはあるタスクがどれだけの工期(期間)なのかを
一休.com におけるフロントエンド開発 // Speaker Deck
3.29 Sansan✕一休.com 勉強会での発表資料です
ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術選定の審美眼 / Understanding the Spiral of Technologies
片手間MySQLチューニング戦略
技術的負債と向き合う
System of Record と System of Engagement
PHP7 で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016
https://ubiteku.oinker.me/2015/12/22/elixir%E8%A9%A6%E9%A3%B2-1-%E4%BB%8A%E3%80%81%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E%E3%82%92%E9%81%B8%E3%81%B6%E3%81%A8%E3%81%84%E3%81%86%E3%81%93/
開発組織マネジメントのコツ - Speaker Deck
harold-spm.com
あなたのチームの「いい人」は機能していますか？
