個人開発のやっていき方
2017年7月20日に行われた Rails Developers Meetup #3 の発表資料です。
「スクラムでは割り込みはできません！」って言わなくていいような仕組み - Mitsuyuki.Shiiba
昨日は、娘達とクッキーを作ってて、余った白身でラングドシャクッキーを作って美味しかった。ども。椎葉です。 F-team, L-team 牛尾さんの記事にF-team、L-teamってあるんだけど、これ、今僕のいるチームでやってることだー。って思った。Microsoftさんの最先端のチームと同じ思想に辿り着いてたってことで、なんか嬉しいなー。 simplearchitect.hatenablog.com Fチームというのは、新しい機能を作るチームだ。Lチームは、顧客からの要望だったり、緊急対応、リリース後出たバグの対応をするチームだ。それぞれのチームに対してKanbanが存在している。 だいたいは同じなんだけど、ちょっと違う部分があるのでそれをメモしておく。以前からの流れでOps TeamとDev Teamって呼んでるんだけど、今流行りのDevOpsとは関係ないので注意ね。 Ops Team
【翻訳】プロダクトマネジメントトライアングル - ninjinkun's diary
original: The Product Management Triangle (by Dan Schmidt) (translated by ninjinkun, reviewed by Kosuke) はじめに プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、「プロダクトマネジメント」を正確な言葉で定義することは驚くほど難しい。自らを「プロダクトマネージャー」と呼ぶ人々は、企業ごとに全く違うことをやっている。彼らは異なるタイプのプロダクト、異なるタイプのチーム、異なる組織構造の中で働いている。このプロダクトマネジメントの立場の違いは、とても不毛だ。外の立場から見ていると、同じ肩書きの仕事を参照する際に、誤解を引き起こしているように見える。全てのプロダクトマネジメントの仕事を統合して、共通の話題を抽出しようとすると、価値を説明しようとし
【資料公開】強いチームの作り方(デブサミ2016版)
こんにちは。@ryuzeeです。 2016年2月19日に目黒雅叙園で行われたDevSumi 2016で「強いチームの作り方」というテーマで登壇してきましたので資料を公開します。昨年11月くらいに公開したものから基本的には変わっていませんが組織やチームのカイゼンにご利用いただければ幸いです！ なお、本講演の再演、トレーニング(半日/1日)を提供しておりますので、ご興味のある方はお気軽にお問い合わせください。 アジャイルコーチングやトレーニングを提供しています株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。 詳細はこちら
「コンバージョン数を2倍にしてくれ」と言われた時の対処法
PV/UUは増えてもメディアの売り上げが伸びない、 そんなとき、エンジニア＆デザイナーでチーム全体を巻き込んでコンバージョン（売上）をアップするための...
強い現場はDiffに対して向き合っている
この記事は DevLOVE Advent Calendar 2015「diff」の12月23日分の記事です。 昨日のエントリー「今年衝撃的だった3つのdiff」の書き手であるshidaさんからのバトンを受けて書かせてもらいます。 自己紹介 2014年4月よりギルドワークスという会社を仲間と共に立ち上げて、スクラムやチームビルディングやファシリテーションを武器に様々なクライアント様の現場で現場コーチをやっています。 コミュニティではDevLOVE関西をやっています。 これまでのDevLOVE Advent Calendarでは2013年「現場」というテーマで「いろいろな現場に深く関わっていく」を、2014年 「越境」というテーマで「「ええやん」と思ったらやっていこう」を、それぞれ書いていますので、良ければそちらもお読み下さい。 現場コーチの現場で見かける「Diff」 現場コーチの現場では、色
コードの品質を維持したまま開発スピードを上げる | POSTD
高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://go.gov.sg/ethos-issue-21
System of Record と System of Engagement
30年かけてたどり着いた、私のとっておきのプログラミングスタイル
組織にテストを書く文化を根付かせる戦略と戦術
「Diff」 DevLOVE Advent Calendar 2015 - 今年衝撃的だった3つのdiff - | ブログ | 株式会社ビー・アジャイル
レガシーな開発環境をモダン化している話
FINAL FANTASY Record Keeperのマスターデータを支える技術
⼤企業で実現するイマドキの内製開発