【翻訳】ストーリーポイントを使うのをやめよう - PoohSunny's blog
はじめに このエントリーは、Industrial LogicのCEOで、モダンアジャイルの提唱者としても知られるJoshua Kerievskyの「Stop Using Story Points」というブログポストを許可をえて*1翻訳したものです。2012年と古いものですが、今でも有益な内容だと考えています。原文はこちらになります。 www.industriallogic.com 誤訳等あれば優しく指摘していただけるととても助かりますし喜びます。 ユーザーストーリーを使うのをやめよう ハンバーガー、ポテトそしてコーラがファーストフードのシンボルであるように、スプリント、朝会そしてストーリーポイントは、アジャイルの方法論のシンボルになりました。 アジャイルハッピーセットの準備はできていますか？ おそらくNoでしょう。 ファーストフード研究者のように、我々はアジャイルハッピーセットに、アジリテ
「アジャイルは死んだ」以降に残るものは何か -リーンソフトウェア開発を再評価し、自工程完結で全体観点で改善する - - Qiita
その結果、自分はすっかり言及の減ってしまったリーンソフトウェア開発や、それらの源流であるトヨタの生産方式、トヨタが現在取り組んでいる自工程完結を評価するのがよいのではないかと思い至った。本稿は、そういうポエムである。 本稿でいうリーン（ソフトウェア）開発とは何か？ 2003年にメアリー・ポッペンディークとトム・ポッペンディークにより提唱されたトヨタ生産方式を源流とするリーン生産方式をソフトウェア開発に適用した原則集。以下を指す。 リーンソフトウエア開発～アジャイル開発を実践する22の方法～ リーン開発の本質 エリック・リース氏のリーンスタートアップやオライリーのリーンシリーズとは異なるので注意いただきたい。 きっかけとしてのアジャイル方法論の違和感：結局、アジャイルでも多くの課題が残る。 「今回のプロジェクトがやりにくいのはウォーターフォールでやっているからだ」、「今回のプロジェクトが適当
What is Enterprise Agile
『 エンタープライズアジャイル、海外動向と日本の現状』 2014/10/15 エンタープライズアジャイル活用勉強会 2014/12/17 IPAエンタープライズアジャイルのセミナー 2015/01/06 匠Method追加 概要： アジャイル開発宣言から14年。海外の小規模チームではアジャイルがもはや主流となりました。現在の議論は、エンタープライズでのアジャイル適用や組織変革にテーマが移りつつあります。一方で、独自の産業構造を持つ日本では、なかなか進まなかったアジャイル採用がWeb企業を中心に最近急速に進んでいるように見えます。しかし、従来のユーザとベンダーに分かれたシステムインテグレーション領域では問題も残ったままです。本セッションでは、海外でのアジャイルの動向、エンタープライズアジャイルのSAFeとDADの概要を解説した後、日本のアジャイル開発の現状としてIPAから発表された調査やIT
アジャイルが否定したものを見直そう - arclamp
2014/9/6に開催されたXP祭り2014で「アジャイルを手放して得られたこと」という講演をしてきました。Togetterはこちらから。 元々は「アジャイルのダークサイド」の話がしたくて応募したのですが、その後、いろいろと考えているうちに僕自身にも気づきの多い内容となりました。 さて反応を見てると前半のアーキテクチャとマネジメントの話に興味を持っていただいたようです。なので、このブログでは「なぜアーキテクチャとマネジメントの話からアジャイルの話をしたのか」ということを書いてみます。 アジャイルがさまたげたもの アジャイル開発手法が大きく注目されるのは1999年の「Extreme Programming Explained」の出版であり、2001年の「アジャイルソフトウェア開発宣言」です。1990年代後半から2000年代初頭というのは、IT産業が大きく成長する時代であり、同時に、当時主流で
スクラムでの初期の見積り
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 よくスクラムで初期見積りってどうやるの？って聞かれますので、思ったことをツラツラと書いておきます。 ちなみに見積りはあたらないので（もちろん当てる努力はしますし、当たった方がいいのは勿論ですが）、そのつもりで考えたほうが良いでしょう。 例えば競馬で一点買いして毎回的中すると思う幸せな人はあまりいませんが、一方で開発の見積りは毎回当たると考えちゃうのはどうかしてるということです。 1. 開発初期に全体を見積もるそもそも一発であたる見積りをするのは不可能であるのは不確実性コーンのグラフ等を見れば分かります。 だからといって見積りをしなくてよいわけではありません。 この時点では、分かってい
アジャイル導入コンサルタントという名前でスクラムだけを導入しようとする人は死ねばいいのにと思った - 水まんじゅう2
この文章中で表現されるアジャイルとはアジャイルソフトウェア開発宣言に沿ったものとします。 なぜか定期的にアジャイル開発をしようとしている人を食い物にしようとしている人のお話を聞くので。 タイトルですべてです。それ以上のことはない。 スクラムはアジャイルな開発を実現するためのプラクティスではあるけれども、スクラムをしてもアジャイルになるわけではないという事実。 それだけなのですが。 今まで見たり聞いたりしてきたアジャイルの失敗例 突き詰めると以下の二つではないかと思っています。 設計ができない 失敗ができない 設計ができない アジャイルだから設計書を作らなくてもよいよね。という人たちはいまだにいるらしい。 設計書という体裁では不要の場合もありますが、設計は必要です。 思いつく限り書き上げると以下の通り。 プロダクトオーナー(お客さん)との合意形成のため 全体で何を作るのかを明確化するため 必
パターンに機能と型を取り戻す(アジャイルにおいてアーキテクチャを表現するDCI)
パターンに機能と型を取り戻す アジャイルにおいてアーキテクチャを表現する DCI James O. Coplien （著） 和智 右桂 Growth xPartners Inc. （翻訳） Copyright c 2010 Gertrud & Cope. All rights reserved. はじめに 本稿は James O. Coplien 氏の論文「Restoring Function and Form to Patterns」（http: //www.software-architect.co.uk/slides/sa10-JimCoplien Patterns.pdf）の全文を、氏 の許可を得て翻訳したものです。 要約 15 年以上前、我々はソフトウェア・パターンの規範のための基盤を築いた。—この規範は後に長 いこと、ソフトウェア・アーキテクチャにとっての中心になったものであ
「正しいアジャイル」でなくてもいい
34. スケジュール 先行開発チーム 仕様策定チーム 開発チーム １ヶ月 ２ヶ月 ３ヶ月 ４ヶ月 ５ヶ月 ６ヶ月 ▼先行開発 ベースラインアーキテクチャの策定やコア機能を先行で開 発。何度となくハマったが、難易度の高い部分に取り組んだ ことによって早期に多くことを学習できた。 顧客 １０年戦士 ５年戦士 13年5月26日日曜日 35. スケジュール 先行開発チーム 仕様策定チーム 開発チーム １ヶ月 ２ヶ月 ３ヶ月 ４ヶ月 ５ヶ月 ６ヶ月 ▼既存システム調査 既存システム要件／機能を分析し、随時「仕様策定チーム」 と連携。テスト仕様書に積極的にフィードバックし、仕様書 の精度を上げていった。 顧客 １０年戦士 ５年戦士 13年5月26日日曜日
アジャイル開発は工事進行基準と相性が良いという仮説 - プログラマの思索
アジャイル開発は工事進行基準と相性が良いという仮説について考えたことをメモ。 【元ネタ】 Twitter / z200: スクラムを例に取ると、リリース（および検収）と売上・請求フローを組み合わせることは可能かと。開発で試したことはありませんが、制作現場では有効でした。 RT @akipii: そういう考え方もあるのか RT @z200: アジャイル開発は、工事進行基準との相性も良さそうだな。 【続報】ソフトウェア開発の売上げ計上タイミング：むささびの視線：ITmedia オルタナティブ・ブログ ソフトウェア開発の売上げ計上タイミング：むささびの視線：ITmedia オルタナティブ・ブログ 販売管理～売上の計上時期（売上計上基準） 【1】ソフトウェアの受託案件が一括請負契約の場合、例えば1年間頑張って作った後、ユーザの受入検収が完了して初めて売上計上されるのが普通。 作って納品しておしまい
アジャイルがそんなにダメだと思わない7つの理由 - haradakiro's blog
鈴木雄介さんが、「アジャイルがダメだと思う7つの理由」というすごいブログを書いてくれたので、がんばって返答を書いてみる。どこかでディスカッションできるといいなぁ。 1. 全体スケジュールにコミットできない コミットメントって何だろう。コミットメントは約束なのか。約束であったら、破った場合のペナルティも受け入れるのか？受け入れたところでバッファが巨大になるだけではないのか？そして、そのバッファは見えないところで食い尽くされる。 全体を見えずに計画したところでうまくいくはずはない。アジャイルがタイムボックスで計画、実施を行うからといって、全体を計画しないわけではない。むしろ積極的にやるべきである。 全体を計画する上では、なるべく漏れがないように、実施可能なように最大限の努力をする。ただ、それに時間を掛けすぎるのは無駄だ。そして、神ならぬ人間が計画するのであるから、以下を認めなければならない。
アジャイルがダメだと思う7つの理由 - arclamp
1.全体スケジュールにコミットできない アジャイルはタイムボックス型（一定期間で棚卸しをして、それを繰り返す）のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ
情報処理推進機構：ソフトウェア・エンジニアリング ｢アジャイル型開発におけるプラクティス活用事例調査｣の報告書とリファレンスガイドを公開
2013年3月19日公開 独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター 概要 インターネット販売サイトやSNS(ソーシャルネットワークサービス)等のシステムでは、その構築において要件のすべてが明確にならなくても開発に着手し、要件の明確化や変更には開発と並行して対応します。それは、いかに早くサービスを提供するかに、ビジネスの命運がかかっているからです。 こうした要件の変化に柔軟に対応できる開発手法として、「アジャイル型開発」があります。これは、ビジネス上の優先度が高い順に、短いサイクルで機能単位の開発を繰り返す手法です。 このアジャイル型開発手法は自社開発（内製）が中心の米国で発展したものであり、要件を決めて外部に開発を委託することが多い等、受発注環境が異なる日本でアジャイル型開発を適用するのは難しいと考えられています(*1)。 「アジャイル型開発」には、
いつまで開発のやり方ばっかり語ってるの？ #sgt2013
DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ........................................
こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
ソニックガーデンに入社して変わった3つの印象 - give IT a try
はじめに 先週からソニックガーデンのオフィスにて研修を受けています。 まあ研修といってもかっちりとカリキュラムを組んでやっているわけではなく、浅く広く色んなことをやって仕事の進め方や考え方を身につけてもらおう、みたいなスタンスです。 とはいえ、こちらもこの業界で長年やってきているいい大人なんで、手取り足取り教えてもらわなくても自分で吸収できることは自分で吸収していこうと思っています。 ところで入社報告時のブログにも書きましたが、選考期間中から一緒に仕事っぽいことをやってきているので、「わ〜、なんて新鮮！！」みたいな感覚が今さらあまりわかないんですよね〜。 とりあえず一週間が過ぎましたが、環境の違いに戸惑ってくたびれてしまうこともなく、楽しみながら研修を受けている感じです。 研修はそんな感じで進んでいますが、選考期間中から感じていたことも含めて、実はソニックガーデンってこんな会社だったのか！
この世でアジャイルから一番遠い会社 - カレーなる辛口Javaな加齢日記
「NTTデータ、3年間で社員1000人をアジャイル開発人材に育成」http://itpro.nikkeibp.co.jp/article/NEWS/20120417/391290/ プレスリリース： http://www.nttdata.co.jp/release/2012/041700.html アジャイルソフトウエア開発技術者検定試験準備委員会を設立: http://www.nttdata.co.jp/whatsnew/2012041300.html メモ NTTデータとNTTデータユニバーシティは2012年4月17日、同社グループの主に入社3年から5年の若手社員を対象に、「アジャイル開発」と呼ばれるソフトウエア開発手法の研修を5月から実施すると発表した。今後3年間で約1000人のアジャイル開発人材の育成を目指す。 若手というより新人．しかもプログラミング未経験者に理解させるのは絶望的
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スクラムガイド - Scrum Guides 2016
Questioning if Agile Works in Asia
Agile Project Management
DeNA流Scrumとcommのチームビルディング
