【翻訳】ストーリーポイントを使うのをやめよう - PoohSunny's blog
はじめに このエントリーは、Industrial LogicのCEOで、モダンアジャイルの提唱者としても知られるJoshua Kerievskyの「Stop Using Story Points」というブログポストを許可をえて*1翻訳したものです。2012年と古いものですが、今でも有益な内容だと考えています。原文はこちらになります。 www.industriallogic.com 誤訳等あれば優しく指摘していただけるととても助かりますし喜びます。 ユーザーストーリーを使うのをやめよう ハンバーガー、ポテトそしてコーラがファーストフードのシンボルであるように、スプリント、朝会そしてストーリーポイントは、アジャイルの方法論のシンボルになりました。 アジャイルハッピーセットの準備はできていますか？ おそらくNoでしょう。 ファーストフード研究者のように、我々はアジャイルハッピーセットに、アジリテ
スクラムでの初期の見積り
みなさんこんにちは。@ryuzeeです。 よくスクラムで初期見積りってどうやるの？って聞かれますので、思ったことをツラツラと書いておきます。 ちなみに見積りはあたらないので（もちろん当てる努力はしますし、当たった方がいいのは勿論ですが）、そのつもりで考えたほうが良いでしょう。 例えば競馬で一点買いして毎回的中すると思う幸せな人はあまりいませんが、一方で開発の見積りは毎回当たると考えちゃうのはどうかしてるということです。 1. 開発初期に全体を見積もるそもそも一発であたる見積りをするのは不可能であるのは不確実性コーンのグラフ等を見れば分かります。 だからといって見積りをしなくてよいわけではありません。 この時点では、分かっている要求をプロダクトバックログに落として、それぞれのプロダクトバックログアイテムをラフに見積もっておきます。 もしプロダクトバックログがないようであれば、そもそも何のため
アジャイル導入コンサルタントという名前でスクラムだけを導入しようとする人は死ねばいいのにと思った - 水まんじゅう2
この文章中で表現されるアジャイルとはアジャイルソフトウェア開発宣言に沿ったものとします。 なぜか定期的にアジャイル開発をしようとしている人を食い物にしようとしている人のお話を聞くので。 タイトルですべてです。それ以上のことはない。 スクラムはアジャイルな開発を実現するためのプラクティスではあるけれども、スクラムをしてもアジャイルになるわけではないという事実。 それだけなのですが。 今まで見たり聞いたりしてきたアジャイルの失敗例 突き詰めると以下の二つではないかと思っています。 設計ができない 失敗ができない 設計ができない アジャイルだから設計書を作らなくてもよいよね。という人たちはいまだにいるらしい。 設計書という体裁では不要の場合もありますが、設計は必要です。 思いつく限り書き上げると以下の通り。 プロダクトオーナー(お客さん)との合意形成のため 全体で何を作るのかを明確化するため 必
いつまで開発のやり方ばっかり語ってるの？ #sgt2013
DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ........................................
DeNA流Scrumとcommのチームビルディング
Scrum Alliance Regional Gathering Tokyo2013でDeNA貝瀬、高坂、坪田が発表した際の資料です。Read less
最適化した開発チームは3～10人で美しく回る
「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。 今回の内容 ●課題：課題： チーム運営を改善する ●スクラムのプラクティススクラムのプラクティス チームのベスト人数は3～10人 あなたが所属する「チーム」はどんなチームですか？ チームのスタイルは千差万別です。メンバーがそれぞれ独立して仕事するチームもあれば、全員の作業状態を共有しているチームもあります。 良いチーム運営をするために、スクラムのプラクティスは有効です。スクラムの核心は、「コミュニケーションコストをなるべく上げず、有機的なチームを作ること」にあるからです。 チームミーティングの「人大杉」問題 毎週のチームミーティングで話す「内容」を思い出してください。 今週行ったことの報告 問題の共有 同
ワンクリックデプロイ勉強会に参加してきた #ocdeploy - Diary of absj31
connpass-ワンクリックデプロイ勉強会 (資料公開)ワンクリックデプロイ勉強会 #ocdeploy | Ryuzee.com 2011/12/20 ワンクリックデプロイ勉強会 #ocdeploy - Togetter (写真：講演終盤、ワンクリックデプロイを実演中の@Ryuzee氏。) 開催までの経緯 まずはこちらのつぶやきやり取りを。 …という様な感じでつぶやきのやり取りがなされ、この日に晴れて『ワンクリックデプロイ勉強会』が開催されました。 開催場所は日本マイクロソフト品川本社。私自身この日が2回目のマイクロソフト本社での勉強会だったのですが、開始前のモニターには何とTV画面が。勉強会とは関係無いところでちょっとした驚きでした(笑) イベント発起人であるkatzchang(TwitterID:@katzchang)さんによる前説的トーク、会場をご提供頂いたTomoharu Nag
アジャイル導入のよくある間違い
原文(投稿日：2010/11/14)へのリンク たくさんの解説者がアジャイル導入のよくある誤りとアンチパターンについて書いてきた。彼らはさまざまな組織におけるアジャイル導入の誤りを避けるためにすべきこと「トップX」を投稿している。 Target ProcessのMichael Dubakov氏は、“10 Most Common Mistakes in Agile Adoption” (Part 1 & Part 2) という2つのブログ記事を書いた。彼は「企業はアジャイル導入において何度も同じ間違いをしている」と主張している。 彼が挙げたよくある誤りは以下の通りだ。 1. ツールから始める アジャイル開発はそうではない。ツールは即座に効果が現れるものではなく、ツールがあっても問題はほとんど解決しない。さらには、より重要な目標に目をつぶって、あなたはツールの導入に励んでしまう。 2. プロ
誰にでも心当たりのありそうな、アジャイルが失敗する理由7＋11
コンサルタントであるMartin Proulx氏のブログ「Analytical-Mind」に、「 Seven wrong reasons to adopt Agile」（アジャイルを導入する7つの間違った理由）」というエントリがポストされています。読んでみると、なんだかドキっとするようなことが書いてあります。 次の7つの理由、心当たりのある人も少なくないのでは？ We recently attended a conference and Agile is becoming more popular. If others are doing it, so should we. 最近カンファレンスに参加したところ、アジャイルが人気らしい。他でやっているのなら、うちでもやるべきではないか Because Gartner and Forrester say so. ガートナーやフォレスターがそう言
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スクラムガイド - Scrum Guides 2016
技術的負債、マネージャの視点