【翻訳】ストーリーポイントを使うのをやめよう - PoohSunny's blog
はじめに このエントリーは、Industrial LogicのCEOで、モダンアジャイルの提唱者としても知られるJoshua Kerievskyの「Stop Using Story Points」というブログポストを許可をえて*1翻訳したものです。2012年と古いものですが、今でも有益な内容だと考えています。原文はこちらになります。 www.industriallogic.com 誤訳等あれば優しく指摘していただけるととても助かりますし喜びます。 ユーザーストーリーを使うのをやめよう ハンバーガー、ポテトそしてコーラがファーストフードのシンボルであるように、スプリント、朝会そしてストーリーポイントは、アジャイルの方法論のシンボルになりました。 アジャイルハッピーセットの準備はできていますか？ おそらくNoでしょう。 ファーストフード研究者のように、我々はアジャイルハッピーセットに、アジリテ
ex-mixiのその後 - KAKKA is not 閣下
こんばんは！12月になったのでブログを開設しました。 というかこの記事はex-mixi Advent Calendar 2017 - Qiitaの2日目担当の記事なので、そのためにブログ開設したと言っても過言ではありません。 1日目のmasartzさんお疲れ様でした！ ex-mixiつまり株式会社ミクシィを卒業した人のくくりなので、多分少しくらいエモい話は入りますよね。 なので技術的な話オンリーならばQiitaに書いていたのですが、Qiitaでこの記事書くとちょっとあれなので。 自己紹介 2011年にmixiに新卒入社し、日記やつぶやき機能の開発エンジニアとして働いていました。 学生のころはずっと理系で、音声や雑音抑圧に関する信号処理を研究していたので、プログラムは書いていましたが、WEBエンジニアというくくりではほぼ初心者で入社しました。 入社当初は本当にもうどうしようかと思うくらい意味
何もコミットしないスプリントで各自好きなことをする
何もコミットしないスプリントで各自好きなことをする インクリメントの完成に高いコミット意識をもって毎スプリント取り組んできている CS 開発チームがいくつか大きなリリースを終えたので、スクラムマスターと相談して今日からの1週間スプリントは「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良いことにしました。 リファクタリング・技術的負債の返済・開発環境の整備や、調査・学習・ドキュメントの整理など、いつものスプリント中にはなかなかできないことを各自でしてよい1週間です。 普段から持続可能なペースを意識してスプリントプランニングしていますが、それでも頑張り続ければストレスも溜まってくるでしょう。適切なタイミングでブレイクを挟むことで、バーンアウトを防ぎ長期的にデリバリーし続けられるチームでいられればと思っています。 ちなみにこの取り組みは去年別のチームが unw
Scrum Tools / Scrum Software | Scrumwise
The easiest Scrum tool you'll find Scrumwise lets you focus on your Scrum project, instead of getting lost in a complex tool Try Now Free Coordinate your teams The easiest way to make your Scrum teams productive and happy. Manage who does what and keep track of how things are going. Manage your Scrum projects Create and manage your backlogs. Plan releases and sprints, or use Kanban boards. Predict
【資料公開】アジャイル開発プロジェクトの始め方
みなさんこんにちは。@ryuzeeです。 これからアジャイル開発を始めるときには、気をつけておいた方がよいことや、実際にスクラムでスプリントを回す前にやっておいた方がよいことが色々あります。 それについて使っている資料がありますので参考までに公開しておきます。 これもやった方がいい、こういう時にはどうするの？などありましたら是非[Twitter](https://twitter.com/ryuzee)などでお知らせいただければと思います。それでは。 アジャイルコーチングやトレーニングを提供しています株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。 詳細はこちら SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発著者／訳者：
たとえば、CTOになる計画をたててみる - クックパッド開発者ブログ
クックパッドで広告領域の企画や実装などを担当している大野です。 2015年期から広告領域ががふたつの事業部に分かれ、私は「新規広告開発部」に所属しています。この事業部は、新しい顧客や販路から収益を上げることと、既存を含む広告の配信を技術的に最適化して収益効率を向上させること、のふたつの目的から新設されました。 事業部に所属するメンバーは、営業やエンジニアといった職種に関わらず、それぞれ収益に対してコミットしています。そして、収益源やビジネスモデルはそれぞれ異なっています。 今回は、特にエンジニアがこうした環境において、やることおよびその優先度をどのように議論して決定しているかを紹介します。やりたいことやアイディアをどう出していくかについては本稿では議論しません。 ちょうど25日に公開された成田による議論 が参考になります。 優先度 = 回収可能額 * 必要投資規模 いきなり結論めいた話です
自己組織的なScrumチームの目指し方
Scrum & Trac By Certified Scrum Master In Shibuya.Trac-2009/07/12Kazumasa EBATA
SCRUM/アジャイル開発の入門資料を全力でまとめてみた
『アジャイルサムライ－達人開発者への道－』に続いて、アジャイル開発のバイブル的書籍『SCRUM BOOT CAMP』を読みました。SCRUMの実践的な知識を漫画をおりまぜながら、本当にわかりやすく書いている良本でした。これから何度も読み直して、アジャイルの習得に努めます！ ということで、今回は書籍を読む過程で集めたSCRUMやアジャイル開発に関するスライドやPDF、ブログ記事などをまとめていきます！ 🗽 アジャイル開発手法特論 From Agile-development-course-advanced-1-2 産業技術大学の2013年2Qの講義『アジャイル開発手法特論』の資料だそうです。SCRUM BOOT CAMPの著者の一人であるながせ☆みほさんの作です。ちなみにながせさんのブログ上に#6までの資料がアップされています。ほかのスライドもかなりのボリュームで読み応え抜群です！ 😀
Sqwiggle が良いという話、またはリモートでアジャイル開発をどう進めるか - naoyaのはてなダイアリー
KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team
ユーザーファーストを実現するmixiの開発プロセス - mixi engineer blog
デザインユニットUXデザイン担当の酒井です。 mixiでは昨年来、最重要キーワードとして「ユーザーファースト」を掲げ、ユーザー様のご意見やご利用状況に基づいたサービス施策の実現を素早く行えるようになるために、開発プロセスの改善を継続的に行なっています。今回は、この「ユーザーファースト」なmixiを実現するための取り組みについて、具体的にご紹介していきたいと思います。 なぜ今、ユーザーファーストなのか？ 昨年11月に開催した『ユーザーファーストウィーク』で笠原社長からもご説明させていただきましたとおり、mixiというサービスが大きく成長したこれまでの数年の間に、いつのまにかユーザー様と私達との間に「ギャップ」が生まれてしまったという強い反省があります。mixiを取り巻く外部環境の変化に対応していく中で、これまでもユーザー様にとっての「心地よいつながり」とは何なのかを真摯に検討し、時流に合わせ
スクラムはもうだめぽよ!新しい開発手法『パワープレイ』をお姉さんが教えてあげちゃう!
2013/3/9 NADECで講演した内容です。 都合上、やったみた結果の一部内容は省きました。 何かあればTwitterで @arimamoto までお願いします (^^)/
Scrum Gathering Tokyo 2013 Scrum the Next Generation 参加レポート
Scrum Alliance Regional Gathering Tokyo 2013 2日目の基調講演の裏で行われたセッション Scrum the Next Generation に参加してきました。メモを共有します。 目次 前座 なんでここに来たの？ 吉羽龍太郎氏 いつまで開発のやり方ばっかり語ってるの？ 吉羽龍太郎氏 スクラムはフレームワークか？ 原田騎郎氏 ON MY WAY TO THE TIMELESS WAY OF PROGRAMMING 角谷信太郎氏 スクラムを壊すな エマーソン・ミルズ氏 アジャイルサムライは当たり前になるか？ 西村直人氏 感想 前座 なんでここに来たの？ 吉羽龍太郎氏 京王線と銀座線が遅れていたため、前座で15分くらい @ryuzee さんによる会場を巻き込んだセッションがありました。テーマは「会場間違えてない？なんでここに来たの？この講演に期待するこ
5分で分かる、「スクラム」の基本まとめ
5分で分かる、「スクラム」の基本まとめ：開発チームを改善するためのスクラムTips（8）（1/2 ページ） 「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。 これまで、アジャイル時代のチーム・マネジメント手法として主流になっている「スクラム」の手法を紹介してきました。今回は総集編として「スクラムの基本」をコンパクトにまとめます。 そもそもスクラムとは スクラムは、一言でいえば「チームで仕事の進めるための枠組み（フレームワーク）」です。 もともとはソフトウェア開発プロジェクトを成功させる仕組みですが、技術的な要素は取り除かれ、多くのチーム作業に共通して適用できる要素だけが残りました。そのため、ソフトウェア開発以外のチームにも適用できるのが特徴です。 ●バッ
＠ITイベントカレンダー
平素よりイベントカレンダー＋ログをご利用いただき、誠にありがとうございます。 イベントカレンダー＋ログは「IT・製造業・ビジネス関係のイベント（セミナー・展示会・勉強会・コンテスト・Webイベントなど）を開催する企業・コミュニティが登録したイベント情報のポータルサイト」として約7年間運営をしてきました。これまでサービスを続けることができたのは、イベントカレンダー＋ログのコンセプトに共感をいただき、適切なイベント情報をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、イベント情報の入手方法の多様化やイベント紹介サービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年6月30日（火）15:00をもちましてイベントカレンダー＋ログのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知ら
ユーザーストーリーのReadyの定義
みなさんこんにちは。@ryuzeeです。 Definition of Readyが参考になる記事だったので抜粋・意訳にてご紹介します。 アジャイルな開発では（そうでなくてもですが）完成の定義は非常に重要です。 人によって仕事が完了していることの理解が異なっていると、「本人は終わったつもりだったが他から見ると終っていない」とか「本人は終わっていないつもりだったが、他からみるととっくに終わっている」という状態になりやすくなります。 前者は品質上の問題を抱えることが多く、後者は時間をムダにします。 さらに言えば、そもそも着手するのに十分な状態でなければいけません。 以下では着手するのに十分であることを確認するためにReadyの定義をしています。 簡単に言えばユーザーストーリーを実装開始してよいかどうかを判断するためのチェックリストです。 開発チームはユーザーストーリーの実装をしてステークホルダー
DeNA流Scrumとcommのチームビルディング
Scrum Alliance Regional Gathering Tokyo2013でDeNA貝瀬、高坂、坪田が発表した際の資料です。
プロダクトオーナーやプロダクトバックログに関するよくある質問と答え (1)
みなさんこんにちは。@ryuzeeです。 プロダクトオーナーやプロダクトバックログに関してよく頂く質問についてまとめました。 スクラムではフレームワークとして定義されているものをどのように実装するかはスクラムチームに任されているので以下の僕の回答はあくまで僕個人の見解です。 プロダクトバックログにはバグは乗せないのか？A. スプリントの作業の一環として行ったテストで発覚したバグは載せません。 それは単にスプリント内で解決すべき項目であり、バグが残っている状態ではプロダクトバックログアイテムが完了とならないだけだからです。 既にリリースされているもののバグであればプロダクトバックログに載せて、対応の順位付けをします。 ただしプロダクトバックログに載せるまでもなく、すぐ修正が終わるようなものはとっとと終わらせてムダに追跡をしない方がよい場合も多いでしょう。 スプリントプランニング時にデザインが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
小さく始める大規模スクラム
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム＆リーンスタートアップ導入)について #devlove #devlove創
