Hatjitsu :: Online Scrum Planning Poker for Agile ProjectsActivity…
【翻訳】スクラムは抽象クラス
みなさんこんにちは。@ryuzeeです。 スクラムはフレームワークです。ロール、作成物、イベントが決められていますが、それを具体的にどうやってこなしていくのかは定義されておらず、それぞれの環境にあわせてやり方を考えていく必要があります。 それを分かりやすく説明したのが、Scrum is an abstruct classという記事です。 今回、記事を執筆したPaddy Corry氏に快諾いただきましたので、和訳にてご紹介します。 なお、誤解のないように言っておくと、スクラムはアジャイル開発を進める上での唯一のフレームワークでは決してありません。 つまりスクラムのフレームワークで既定されていることを止めた場合、それはスクラムではありませんが、だからといってアジャイルでなくなることとイコールなわけではありません。 自分たちにとって良いやり方があれば、それをやればいいのであって、スクラムに厳格に
アジャイルの破綻―原因、そして新たな提案 | POSTD
2001年、17人のメンバーによって アジャイル宣言 が発表されました。私はその立案者そして著者の1人であることに誇りを感じます。この出来事は、何かをする上でより良い方法を導き出すことへの期待、そしてソフトウェアを開発することで世界をより良くするといった、私自身の活力の源となり、極めて重要なターニング・ポイントとなりました。 あれから14年が経ち、私たちは行き先を見失っています。”アジャイル”という言葉はスローガン化してしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまったとすら言えます。2～3のソフトウェア開発のプラクティスを、不十分に生半可に試みるといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重ねるといった、口先だけのアジャイルの 狂信者 がたくさんいるのです。 更にひどいのは、アジャイル開発手法その
Agile2014に参加してみて分かった昨今の世界のアジャイル事情 - The HIRO Says
先日参加してきた Agile2014 の、社内向けレポートを公開しても良いことになったので、共有させていただきます。 Agile2014 Report: As a Speaker and a Reporter of the latest Agile in the world from Hiroyuki Ito 本当は帰国時（8/4）の飛行機の中で書き終えており、帰国次第即公開しようとしたのですが、社内手続きなどの都合で公開が遅れていました。 また、公開まで期間が空いたので、レポートを書いた当時は理解できなかった点についてもある程度理解が追いつくようになったのですが、帰国時の雰囲気をそのまま伝えたいと考えたため、あえて追加修正をしないでの公開とさせていただきました。 英語で書いたということもありますが、説明足らずの部分も多々ありますので、可能な範囲で追加説明をしてみようと思います。 ３つのト
目標ベロシティとベロシティのインフレ | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 現実から得られるベロシティの実績値をもとに、次のスプリントでそれよりも大きい目標ベロシティを設定することはおすすめしません。 それは以下の理由からです。 そもそもチームの実績としての指標データであるベロシティが目標値として設定されることによって、チームがその目標に到達しなかった場合にチームに何か問題が発生しているようにとらえてしまうもちろん継続的な改善によってチームのベロシティは一般的には初期のスプリントから中盤にかけては向上する傾向にはありますが、それはあくまで結果としての指標データです目標ベロシティを決めて、かつ、それをコミットしてしまった場合、往々にして、数字を満たすために、テストの手抜きをしたりリファクタリングするのをやめて目先の数字を追ってしまうことが多々ありますいくつかのスプリントをこなせばチームとしての生産力は見えてくるので、数字をコ
20140131 万葉帰社日発表 チーム積み重ね 公開版
2014年3月の発表資料 2014年7月の資料 => http://www.slideshare.net/hiroosak/ca-36830962
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!
「アジャイル」という言葉が一人歩きしてしまっていて、たまに話をしていても通じないときがあります。 それくらいアジャイルという言葉が広く知られるようになったんだと思う一方で、かえって話が通じなくて、もどかしく感じることもあります。だからといって、そこで「正しいアジャイルとは」みたいな議論をしたい訳でもないのです。 広まれば広まるほど、そういった言葉の認識の齟齬が出るのは仕方ないですね。その正しい定義みたいなところを追求するのもナンセンスなので、そんなつもりはないですが、ただ自分がどう考えているかについては書いておいても良いかな、と考えました。ここは私のブログですしね。 そこで、この記事では、私の考えるアジャイル開発の本質について、そしてウォーターフォールとの違いについて書きました。 アジャイル開発では機能を全部つくらない これまで私の中で、アジャイルと言えば当たり前の前提がありました。それは
受託開発でアジャイルソフトウェア開発を始める - @ledsun blog
はじめに 「ディシプリンド・アジャイル・デリバリー 〜アジャイル開発の現実解〜」に参加してきました。#devlove - HOW TO GO というブログエントリに 受託でアジャイルはどうなのか？ という記述がありました。世の中には受託でアジャイルをどうやって始めるのか悩んでいる人がいるらしいので、体験談を書きます。 ざっくり言うとハイブリッドアジャイル*1です。 請負契約でアジャイルっぽくやるための方法です。 業務委託で契約できるなら（開発側は）リスクが低いのでその方がおすすめです。*2 それから「ディシプリンド・アジャイル・デリバリー」は未読です。読んだ人には釈迦に説法かもしれません。 三回以上の分割納品 始めるのは簡単です。お客さんにスケジュールを提示する際に納品を3回以上にすればOKです。 最初に提示すれば納品回数を一回に変更したがるお客さんはいません。 同じメンバーで同じシステム
アジャイル開発において、技術と品質の重要性は不可欠だ（後編）。Agile Japan 2013
年に一度行われるアジャイル開発のイベント「Agile Japan」が今年も開催されました。今年の基調講演は、アジャイル開発の中で品質の重要性をあらためて位置づける目的で、James Gernning氏が「“Demand Technical Excellence”アジャイルにおける技術と品質の重要性」という題で行っています。 （本記事は「アジャイル開発において、技術と品質の重要性は不可欠だ（前編）。Agile Japan 2013」の続きです） 品質を作り込むプロセス コンピュータサイエンティストとして有名なEdsger Dijkstraは、信頼性の高いソフトウェアが必要であれば、最初からバグを避ける方法を探さなければならないことに気づくだろう。と言っています。 つまり、バグを作り込まない、品質を作り込むプロセスにすることで、大事な時間をデバッグに使われないようにするのです。 テストドリブン
情報処理推進機構：ソフトウェア・エンジニアリング ｢アジャイル型開発におけるプラクティス活用事例調査｣の報告書とリファレンスガイドを公開
2013年3月19日公開 独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター 概要 インターネット販売サイトやSNS(ソーシャルネットワークサービス)等のシステムでは、その構築において要件のすべてが明確にならなくても開発に着手し、要件の明確化や変更には開発と並行して対応します。それは、いかに早くサービスを提供するかに、ビジネスの命運がかかっているからです。 こうした要件の変化に柔軟に対応できる開発手法として、「アジャイル型開発」があります。これは、ビジネス上の優先度が高い順に、短いサイクルで機能単位の開発を繰り返す手法です。 このアジャイル型開発手法は自社開発（内製）が中心の米国で発展したものであり、要件を決めて外部に開発を委託することが多い等、受発注環境が異なる日本でアジャイル型開発を適用するのは難しいと考えられています(*1)。 「アジャイル型開発」には、
リーンスタートアップの方法論とアジャイルの方法論の違い - レベルエンター山本大のブログ
リーンスタートアップは、このブログでも何度も取り上げた本で、僕らの会社が製品開発をする上で非常に参考にしている本です。 リーン・スタートアップ 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二出版社/メーカー: 日経BP社発売日: 2012/04/12メディア: 単行本購入: 24人 クリック: 360回この商品を含むブログ (95件) を見る この本を精読するのは2度目ですが、サービスを実際に手がけるようになってから読んだので改めて考えさせられるポイントが多くて、立ち止まってサービスへの展開や次のアイデアなどに思いが散って、2回目の方が1回目よりも先に進まない状態でした。 リーンスタートアップの中核は以下の「フィードバックループ」というものです。 ■「構築―計測―学習」のフィードバックループ リーン・スタートアップは具体的には、「構築―計測―学習」のフィードバックル
Fearless Journey – the game that gets your team unstuck
The Fearless Journey game highlights your Team’s hard-to-reach Goal and inspires new Strategies to reach it. (No team at the moment? Check out Fearless Solitaire) The Fearless Journey Game is a low-risk way to hack a culture that’s stuck in a holding pattern. It’s an invitation to look at well known problems through new lenses, and to imagine new approaches using resources already at hand. Players
Fearless Journeyかんたんガイド
Fearless Journeyのルールや準備・進め方をまとめた資料を作りました。 2012/05/21追記 1. ちょっとだけ改訂しました。 2, 私が作ったpngファイルは印刷するには解像度が低すぎました… 印刷したい方は次のリンク先にあるpdfをご利用ください。 https://docs.google.com/open?id=0Byh-cIUeiW9wRV9IVmVCZ3o2Zjg ◇Fearless Journeyって何？ ゲームです。 目的の妨げとなっている障害を、いかにチームで克服するのかを学ぶためのものです。 障害を取り除くための戦略をFearless Changeという本の48のパターンから持ってきているのが特徴です。 詳しくは以下のリンクをどうぞ。 公式サイト http://fearlessjourney.info/ @kdmsnr様のスライド http://www.sl
ワンクリックデプロイ 〜いつまで手でデプロイしてるんですか〜 #devsumiA
2013/2/15に目黒雅叙園で行われたデブサミ2013 15-A-7セッションの資料です。Read less
「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ
「アジャイルがダメだと思う7つの理由」という刺激的なタイトルのエントリを、先週木曜日、3月21日にグロースエクスパートナーズの鈴木雄介氏が公開してから、アジャイル開発に関する議論の波紋が広がっています。 おそらく、これだけさまざまなブログを通じてアジャイル開発の議論が活発化したことはこれまで国内ではなかったのではないでしょうか？ ここでは現時点での議論をまとめますが、興味のある方はぜひここを起点にそれぞれのエントリを読んでみていただきたいと思います。 発端は鈴木雄介氏（id:arclamp）のブログarclampにポストされた「アジャイルがダメだと思う7つの理由」というエントリ。以下がその7つの理由として挙げられたものです。 1.全体スケジュールにコミットできない 2.アーキテクチャ上の無駄が生じる 3.コーチって何だよ 4.変化ヲ抱擁スルために固定化している 5.実証主義的な説明に過ぎな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム＆リーンスタートアップ導入)について #devlove #devlove創
Agile is Dead (Long Live Agility)