Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス(スタートアップが迷った時に読む Paul Graham から...Takaaki Umada
Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス(スタートアップが迷った時に読む Paul Graham から...Takaaki Umada
ストーリーは「ユーザーストーリー」とも呼ばれ、要件またはリクエストをエンドユーザーの観点から簡潔にまとめたものです。 エピックは、より小さなストーリーに分割できる、まとまった作業です。 イニシアチブは、共通の目標達成のためのエピックの集合体です。 アジャイルのストーリーとエピックは、映画や文学のストーリーとエピックに似ているところがあります。映画や文学では、内容を簡潔に示したものがストーリーで、相互に依存する関連ストーリーをまとめたものがエピックです。これはワーク マネジメントにも当てはまり、関連するストーリーを完了することでエピックが完了します。ストーリーは完了した一連の作業を示すのに対し、エピックは 1 つの目的の概要を示します。 アジャイル チームは、ストーリーを 1 週間から 2 週間のスプリント内で終了することを約束します。大体、開発者は 1 か月に数十件のストーリーを処理します
「アジャイルな見積りと計画作り」の著者マイク・コーンさんがブログで、「ストーリー」と「エピック」の使い分けについて説明していましたので、だいたい訳して載せておきます。 ちょうど最近、ストーリーとエピックについてご質問をいただいたので、これを参考にしていただけるとうれしいです。 ストーリー、エピック、テーマ ( STORIES, EPICS AND THEMES by Mike Cohn) http://blog.mountaingoatsoftware.com/stories-epics-and-themes 最近、「ユーザーストーリー」「エピック」「テーマ」の違いがわからないというメールを受けることがだんだん多くなってきている。今回はこれらの用語を説明する事を通じて、基本的な(でもとても役立つ)領域に立ち返り、確認していく。 まず、この用語にはあまり深い意味はない。この用語には、プログラ
ソフトウェア開発の見積もりと納期について言及されたブログ記事を見て違和感があったので掘り下げてみた記事。ソフトウェア開発の「見積もり」というと少なからずSIer臭がする。しかしSIerや日本のソフトウェア開発の現状を憎悪するからといって、見積もりというアクティビティの重要性は変わらないし、軽視してよいものではないというのが個人的な考え。 ウソ:ソフトウェアの納期見積もりは、星占いレベルのものである 論点を単純化するための釣りタイトルだと思うのだけれども、ソフトウェア開発における「不確実性のコーン」はスケジュールではなく、スコープ(工数、コスト、機能)の見積もりに関する分析であって、納期、スケジュールに関する分析ではない点には注意が必要である。 この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と
昔から習慣として「週報」を書くということをしている。最近発売された「 SOFT SKILLS 」という本を読んでいたら週報を書くことについて言及されていて面白かったので、「週報」についての自分の考えなどを整理してまとめてみた。 新しい会社に入るたびに私がまずしていたのは、何に時間を費やし、その日に何を達成したかを日録に書くことだ。その内容をもとに、毎週金曜日に週間サマリーを書いて上司に送ったのである。私はこれを自分の「週報」と呼んでいた。(中略)この週報は、私の存在をアピールするために役に立っただけでなく、人事考課の時期には自分自身にとっても役立つ資料となった。週報を読み返して、その年の主要な達成を拾い出せばよかったのである。自己評価を書くとき、私はその年にしたことを日付とともに正確に書けたのである。 SOFT SKILLS ソフトウェア開発者の人生マニュアル/第9章 出世階段の上がり方
書籍「アジャイルソフトウェア要求」の読書メモ。いわゆるエンタープライズアジャイルに関する方法論の一つであるSAFe(Scaled Agile Framework)の解説書。ソフトウェア要求の本ではあるが、事業戦略からデリバリーまでの全ての範囲を含んでいるというのが肝であり、興味深い点である。 アジャイルソフトウェア要求 (Object Oriented SELECTION) 作者:Dean Leffingwell発売日: 2014/02/11メディア: 大型本 事業会社向け エンタープライズアジャイルというキーワードだと、本書と別にDAD(Disciplined Agile Delivery)もある。こちらも今読んでいるところなのだけれど、本書と比較すると、SAFeは事業会社向けの方法論であり、DADはSIer向けの方法論というように思えてくる。 ディシプリンド・アジャイル・デリバリー エ
code_review_basics.md コードレビューの基本 一番大事な事 ソースコードはプロジェクトの共同所有物である 誰かだけが触れるコードを無くす 自分だけが持っているコードを無くす 自分だけが触っている時間を短くする コードレビューで大事な事 コードレビューは... 相互学習型のプロセスである メンバが成長することが大事 相互学習とは レビュアーとレビュイーが、お互い学び合うこと 考え方を共有すること 質問することで学ぼう 一番できる誰かだけが教えるのではない 知識や経験の少ない人が何に躓いているのか学ぼう メンバの成長 同じミスをチーム内で繰り返さないことが成長 ミスを繰り返さないために 本人の問題にしない 明日はわが身 仕事の正しい手順を覚えよう 道具の正しい使い方を覚えよう コードレビューの心構え 伝えることが大事 改善するまでがレビュー レビューにコストをかけ過ぎない
EngineeringContext aware MySQL pools via HAProxyAt GitHub we use MySQL as our main datastore. While repository data lies in git, metadata is stored in MySQL. This includes Issues, Pull Requests, Comments etc. We also auth… At GitHub we use MySQL as our main datastore. While repository data lies in git, metadata is stored in MySQL. This includes Issues, Pull Requests, Comments etc. We also auth aga
私が出会ってきた良いマネジャーは、殆どの人が 「もっとヤル気出せよ」 「成長しないとダメだぞ」 といった「説教」をしなかった人ばかりだ。 説教自体が悪いのではない。 だが、おそらく皆、説教にほとんど意味がないことを知っていたのではないかと思う。 例えばあるwebサービス運営会社のマネジャーは、「説教したって、人は変わらないですよ。」と言った。 またある商社のマネジャーは「こちらが言っただけで考え方を変える人なんて、見たことないです」と言った。 コンサルティング会社の30歳そこそこのマネジャーは「説教でなんとかしようっていうのは、要するに手抜きか頭が悪いだけですよ。」と言った。 彼ら有能なマネジャーは説教をしない。 ではどうやって人に対して影響を与えるのか。行動と考え方を示すのか。 実は彼らは皆、部下に「ツール」を与えていた。しかも単に与えるだけではない。部下が進んで使いたくなるように工夫を
SREチームの@cubicdaiyaです。今回はnginxによるTCPレイヤーでのロードバランスについて解説します。 ロードバランサーとしてのnginx nginxはHTTPやTCP、UDP等の複数のレイヤーでロードバランサーとして稼働させることができます。(TCPロードバランサーは1.9.0以降、UDPロードバランサーは1.9.13以降で利用可能です) また、ngx_http_ssl_module や ngx_stream_ssl_module を利用することでそれぞれのレイヤーでTLSを有効化することも可能です。 TCPロードバランサー用のモジュールを有効にする HTTPレイヤーでロードバランスするためのモジュールはデフォルトで組み込まれますが、TCP(とUDP)レイヤーでロードバランスするにはnginxのconfigureスクリプトに--with-stream(あるいは --with
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く