最近の開発フローの改善と、「スプリントおじさん」という取り組み - しるろぐ
ここ最近、自分が見ているプロジェクトの1つで、うまくスケジュール通りに作業が進んでいなかったので、その対策をした。 その中でも特に効果があった2つを紹介する。 背景 簡単にプロジェクトの背景を説明する。 スクラムっぽい開発をしている スプリントの期間は2週間 スクラムマスターはいるが専任ではない すでにリリース済みで運用中のWebサービスである 基本的によくあるスクラムっぽい感じで、2週間というタイムボックスの中にチームが作業可能なストーリーを突っ込んで、ひたすら消化する。 スプリントの最後には、レビューをして、次のスプリントの計画を立てる。 スクラムマスターは、一応自分が担当しているが、専任ではないし、他のプロジェクトも見ているので、注意深くチームを見れていない。 課題 以下のような課題があった。 バグの修正や問い合わせ対応など、計画時に含まれていなかったタスクがスプリント中に増えてしま
天下一クライアントサイドJS MV*レームワーク武道会に参加<しました #ten1club - しるろぐ
天下一クライアントサイドJS MV*フレームワーク武道会 - connpassに参加してきました。 イベント見たときはもう枠こえてて、参加するにはLTしかない！みたいな感じだったので、ドキドキのLT応募。実際はキャンセルが多くて、補欠登録でも大丈夫そうだったけれど、良い経験できてよかった。 話したこと angular X designer - デザイナからみたAngularJS #ten1club 簡単に言うと、HTMLやjavascript周りを専門にやる人が潤沢にいないチームで、エンジニアとデザイナの両方がHTMLをさわると、 エンジニアが組んだロジックがデザイナによって壊される デザイナが組んだデザインがエンジニアによって壊される みたいな悲しい出来事が起きてしまう。 デザイナはIF、ELSEを呪文のようだと思っているし、表示条件を変えたい、みたいなときにロジックが書ける人のサポート
ミーティングを開催する上で大事なこと - しるろぐ
去年の末ぐらいに、社内の後輩向けにちょこっと書いたやつを、やばい表記だけ消してほぼそのままコピペしてみる。 タイトル通りの内容です。 ちょっと不親切過ぎたので、追記した。 M:tGじゃないです！！(2013-09-26追記) 資料を丸コピしすぎてMTGと略語で書いていたら、Magic: the Gatheringがどうのこうのってコメント欄で言われていたので置換しました。 対象とするミーティング (2013-09-27追記) 以下の内容は、企画の詳細詰めなどの「意思決定」や、具体的な議題について話し合う「問題解決」、反省会などの「評価」を行うためのミーティングを対象としています。ブレストなどの「アイデア出し」や、報告会などの「情報共有」は対象にしていません。 具体的に例を出すと、「来月からやるイベントのたたき台を考えてきたんだけど、今から話すので意見ください、そしてしっかり固めてスケジュー
YAPC::Asia Tokyo 2013でボランティアスタッフしてきました #yapcasia - しるろぐ
先週の木金土に開催されたYAPC::Asiaにボランティアとして参加してきた。初ボランティア。 YAPC自体は、2011年にPerl系の会社に入社してからずっと参加していたけれど、毎年とても刺激的でおもしろい。特に参加したあとの、あれもやりたいこれもやりたい、よしやるぞ！！的な気分は何物にも代え難い貴重な感情だ。 今年は参加3年目ということもあり、ただの参加者として気合いをもらうだけでなく、何か恩返ししたいなと思ってスタッフに応募してみた（あと、スタッフの打ち上げに参加してみたかった）。 ボランティアスタッフは主に当日作業を手伝うことになるのだけれど、直前まで本当にやることがなくて、自分がやれることあるのだろうか……と心配していたけど、全くの杞憂だった。 前夜祭（木） ノベルティは前夜祭でも配るので、前夜祭が始まる何時間か前に集合して、せっせと準備をする。やったことある人は分かると思うけれ
GREE Tech Talk: GitHub:E Casual Talk に行ってきた #greetech02 - しるろぐ
2013年1月23日に開催されたGREE Teck Talk #02 : GitHub:E Casual Talkに行ってきたのでメモ。 全体の感想 ちょっと導入を考えていたので、勉強になった。そして、ちょっとくじけた。 PullReqとかGHEの恩恵とかを理解していれば全然高くはないと思うんだけど、最初の導入時のハードルがでかいかなという印象。今のままでいいじゃん、って声が多分たくさんあがる。お金さえあれば、「まあまあ、試しに使ってみてよ」ってのんびり検証しつつ徐々に移行とかできそうだけど、そうでないなら、ちゃんとした計画立てないとつらそう。 ということで、本気で人やプロジェクトが多くなって「レビューつらい」と思うまではちょっと待っても良いかなという結論に落ち着いた。 19:00 トラブルシューティングから見るGitHub:E運用の勘所 グリー株式会社 大場光一郎 内容と感想 greeが
#cross2013 で継続的サービス改善について話してきました - しるろぐ
エンジニアサポートCROSS 2013の「継続的サービス改善のゲンバのハナシ」というパネルディスカッションに参加してきました。 実はこういうイベントで話すのは初めてで、すごい緊張してしまい、質問に答えるだけでいっぱいいっぱいだったのですが、何かひとつでも参考になる話ができていれば嬉しいです。 セッションオーナーの@tagomorisさん、一緒に登壇した@kentaroさん、@oranieさん、@tokorotenさん、ご来場の皆様、ありがとうございました。 話した内容 質問は結構範囲が広かったので、簡単にまとめづらいですが、一言でいうと「ユーザをちゃんと見る」ということを中心に話していました。サービス改善に限らず、集団でプロジェクトを動かすと、政治的なしがらみとかいろいろ面倒なことがあると思います。そんな中でプロジェクトの方向を定める一番の指標はユーザです。ユーザに価値を提供できるか、ユー
isucon2に参加してきました #isucon2 - しるろぐ
NHN主催のisucon2に参加してきました。 チーム名は「飲兵衛ズ」。チームメイトは、@karupaneruraと@masasuz。 livedoor Techブログ : 【締め切りました】第３回NHNテクノロジーカンファレンス番外編 #isucon2 の参加者募集開始と詳細決定のお知らせ livedoor Techブログ : #isucon2 リアルタイムフォトレポート 更新終了 結果 惨敗でした。 午前中すぐに1000チケット超えて、しばらく1位だったのですが、いろいろ試してたらスコアが落ちてしまって、最終的に午前の記録を抜くことができませんでした。その間に他のチームにあれよあれよと抜かれてしまいました。 やったこと 太字が自分がやったことです。 後半、情報共有がおろそかになって、記憶を頼りに書いているので、誰が何やったとかちょっと曖昧。 10時 @karupaneruraがIRCと
Aiming Study 6 「Unity アプリを HTML5 に移植してみた」に行ってきました #aimingstudy - しるろぐ
2012/10/24に神保町（インターネットイニシアティブ本社 会議室）で行われた、Aiming Study 6 「Unity アプリを HTML5 に移植してみた」に行ってきたのでそのメモ。 ロードオブナイツの移植の話でした。 会議室が広かったので発表と同時に資料公開は嬉しかった。 例によって、資料に書いてある内容はたまにメモるのさぼるので資料みてくだしあ。というかどっちも資料がしっかりしてるし、公開されてるしで、後半メモるの諦めてる。 大規模JSの設計と実装と実際 @mizchi 普通のweb技術を使う理由 普通だからキャッチアップできる 普通だから人員追加できる CoffeeScriptはいい 書いてて気持ちいい/面白い BadPartsでないJSを出力する 古い記事(2005年)は参考にならないので、本を読もう The Little Book on CoffeeScript を読も
一般社員がマネージャーの気持ちで動いたり動くことを期待するのは間違ってるんじゃないか - しるろぐ
この間友達と飲んでいたのですが、与えられた立場とは別の立場に立って物事を考えて行動するのはおかしい気がするという話をしました。 「現場（一般社員）層」「マネージャー層」「経営層」という三層構造の会社で、現場の人間がマネージャー的な視点で仕事をして良いのか、とか、「開発」「企画」に分かれているのに開発が企画の立場に立って、企画が開発の立場に立って仕事をするのはどうなのか、とかそういう話です。 違和感を感じるところ 「キミ現場ね」って言われているのに、現場以外のマネージャーや経営の立場に経って物事を考えてそれを元に仕事をしたら褒められるのに激しく違和感を感じます。会社はあなたに現場としての行動を期待している（と思う）のに、それ以外の視点で行動したら違うんじゃないのと。 もちろん、現場なりにマネージャーの意図を汲んだり、マネージャーだったらこうするだろうなと考えること自体は問題ないですし、重要な
タスクの書き方 - 終了条件と却下条件で判断を迅速に行う - しるろぐ
2年目の新人が去年1年間を振り返りつつ今年の新人にアドバイスする、という勉強会を社内でやっていて、拙いながらもそこで発表してきました。 いくつかアドバイスしたことがあるのですが、社内の機密情報なども含まれるので、一部だけ取り出してブログ用に書き直したいと思います。 今日のテーマは、タイトルにもあるとおり『タスクの書き方』です。 タスクを書くときに「○○をする。□□ができたらオッケー」という終了条件や、「○○をする。ただし△△になったら不要」という却下条件を書くと、タスクの選択や確認、棚卸しが捗るという話です。 大量のタスクがあると良く分からなくなる 仕事をしていると、次から次にやりたいことが沸いてきて、頭の中だけで整理するのは難しくなってきます。大抵の人は、やりたいことを紙にリストアップしたり、webサービスなどで管理したりすると思います。 しかし、何も考えずにタスクを追加していくと次のよ
X回やれば必ず当たると思ってしまう確率の幻想について - しるろぐ
昔々あるところに、何度引いても確率が変わらない魔法のガチャガチャがありました。 そのガチャガチャは12星座をモチーフにしたキーホルダーがあたるガチャガチャで、山羊座の太郎君は、どうしても山羊座のキーホルダーが欲しいと思いました。 太郎君は、考えました。 キーホルダーの出る確率がすべて1/12なら、12回引けば山羊座のキーホルダーが手に入るだろう、と。 そこで、太郎君は、300円×12回 = 3600円のお金を用意してガチャガチャに挑みました。 果たして太郎君は望みどおり山羊座のキーホルダーを手に入れられるか ここで問題です。 12回やれば、山羊座のキーホルダーがあたる、という太郎君の予想は正しいのでしょうか？ 普通に考えると、1/2と言ったら2回に1回はあたる、1/3と言ったら3回に1回はあたるような気がします。 でもちょっと考えてみてください。 コインを何度投げても表しかでなかった経験あ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
