アジャイルが否定したものを見直そう - arclamp
2014/9/6に開催されたXP祭り2014で「アジャイルを手放して得られたこと」という講演をしてきました。Togetterはこちらから。 元々は「アジャイルのダークサイド」の話がしたくて応募したのですが、その後、いろいろと考えているうちに僕自身にも気づきの多い内容となりました。 さて反応を見てると前半のアーキテクチャとマネジメントの話に興味を持っていただいたようです。なので、このブログでは「なぜアーキテクチャとマネジメントの話からアジャイルの話をしたのか」ということを書いてみます。 アジャイルがさまたげたもの アジャイル開発手法が大きく注目されるのは1999年の「Extreme Programming Explained」の出版であり、2001年の「アジャイルソフトウェア開発宣言」です。1990年代後半から2000年代初頭というのは、IT産業が大きく成長する時代であり、同時に、当時主流で
チケット駆動開発で Pivotal Tracker を上手に使うための4つのポイント | Social Change!
ソフトウェア開発のタスクはどのように管理するのが効率的なのか。ソフトウェアという目に見えないものを作るためにはタスクの見える化は進捗状況を図る重要な指標になります。ソフトウェア開発で発生するタスクを、バグ管理システム（BTS）や課題管理システム（ITS）を活用することで、タスクの状態とワークフローを管理しようというのがチケット駆動開発です。 チケット駆動開発については、以前に記事を書いたので、そちらを参考にしてください。 チケット駆動開発のススメ〜No ticket! No commit チケット駆動開発をうまく実践するためにはツールが不可欠です。不具合管理や障害管理で使うツールを応用して活用することも出来ますが、最近は専用のツールも出て来ています。ソニックガーデンでは、Pivotal Trackerというツールを使っています。Pivotal Trackerでは「ストーリー」と表記していま
アジャイル時代のモデリング: アジャイルチーム拡大のためにはコードの次に何を保つべきなのか
図１．シンプルなスクラム構成 この最小限のフレームワークの中で、チームのインプットとなるのが”ユーザ要求”としての”プロダクトバックログ”です。そして、アウ トプットは”動くソフト ウェア”としてのコード（”製品コード”と”テストコード”）です。 そこには他の設計要素が明示的に現れてはいません。スプリントの中で作られたすべての意図的な設計はチームの財産として実行コートの中に組み込まれるのが 望ましいですが、そこには直接コード化されない情報もあります。スクラムは開発プロセスであり、設計に関しては敢えて何も言及していませんが、設計と設 計活動はチーム内部であいかわらず行われています。 Grady Booch氏は”コー ドは真実ではあるが、すべての事実ではない” と語っています。だから、もしそこにコードで表現又は伝われない情報が残されるとしたら、私達はその情報をどこに格納できるでしょうか？その質
「スクラムを活用したアジャイルなプロダクト管理」はおすすめです。 - kawaguti’s diary
本書はドイツのRoman Pichler氏の本で、有名な本です。プロダクトオーナーの教科書としてお勧めします。特に、"スクラムのプロダクトオーナー"として、実際に開発チームとどのように働くのかについて、コンパクトに説明しています。「塹壕よりScrumとXP」は、チーム側がどのように動くかの教科書ですが、本書はプロダクトオーナー側がどのように動くべきかの明確な定義を与えてくれます。 スクラムを活用したアジャイルなプロダクト管理―顧客に愛される製品開発 作者:ローマン ピヒラーピアソン桐原Amazon 「2.4 シンプル」で触れられていますが、シンプルであること、現在やるべきでないことを削ぎ落とすことは、プロダクトオーナー最大の腕の見せ所だと思いますが、その意味で、本書自体が極めてシンプルにまとめられており、それが価値になっています。日本語もこなれていると思います。翻訳者とレビュワーの皆さんの
SAFe 6.0 Framework
Overview The SAFe Overview is a visualization of the seven core competencies of Business Agility and the dimensions of each. Essential The Essential SAFe configuration provides the minimal elements necessary for ARTs to deliver solutions and is the simplest starting point for implementation Large Solution The Large Solution SAFe configuration is for enterprises building large and complex solutions
第2回スクラムプロダクトオーナー勉強会に参加してきた #postudy - Diary of absj31
9月30日 第2回スクラムプロダクトオーナー勉強会(東京都) 本勉強会では、 「現場でスクラムを実践するためにはどうすればよいか」 という命題に対して、スクラムで定義されている 3つの役割（チーム、スクラムマスター、プロダクトオーナー）のうち、特に ・プロダクトオーナー にフォーカスを当てて、CSPO研修で扱われた内容や スクラムギャザリング東京2011で扱う予定の内容を軸に、 過去の導入事例やワークショップなどを通じて参加者同士で議論を行い、 情報交換をすることで互いに有益な場を作っていきたいと考えています。 タイトル及び概要が示す通り『プロダクトオーナー』によりフォーカスを当てたこちらの勉強会。当日は同じくスクラムのイベントで『すくすくスクラム』も開催されていたのですが、個人的に『アジャイルサムライ読書会 DevLOVE道場』で現在参加エントリ〜チーム作業中(且つ当日のテーマに現状の作
ユーザーストーリーとは？
ユーザーストーリーとは？ 1. ユーザーストーリーとはhttp://www.flickr.com/photos/cannedtuna/4674434821/ 2. 吉羽龍太郎 (@Ryuzee) アジャイルコーチ 認定スクラムプロフェショナル(CSP) 認定スクラムマスター(CSM) 認定スクラムプロダクトオーナー(CSPO) http://www.ryuzee.com/ 野村総合研究所等を経てベンチャーのCTOhttp://www.flickr.com/photos/adforce1/2539903964/ 3. プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外
データモデリングなきアジャイル開発は危ういか？：An Agile Way：オルタナティブ・ブログ
尊敬するDOAの先輩である、渡辺さんがこう書いている。 「データモデルなきアジャイル」の危うさ、より その種のシステム（※引用者補記：販売管理システムや生産管理システムといった基幹系業務支援システム）をアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。 それに対して、稲見さんがこんなコメントをしている。 アジャイル開発と言っても色々で、最近流行りのScrumという手法は、開発の中身に関しては何も言及していません。ですが、私の知っているある人達
野中郁次郎先生と、スクラム、アジャイル、パタン言語、知識創造についてお話しました。：An Agile Way：オルタナティブ・ブログ
野中郁次郎先生を一橋大学に訪問、アジャイル、スクラム、創造、マネジメントについてディスカッションする機会を得ました。 先生はもちろん、ナレッジマネジメント、知識創造経営、そして、Scrumという言葉を生んだ、「The New New Product Development Game」という1986年の論文の著者の一人。もう一人は現在ハーバードの竹内さん。一昨年の AgileJapan 2010の基調講演、昨年は、Jeff Sutherland との対談が Innovation Sprint で実現、ハーバードの竹内さんのクラスにJeff Sutherland が呼ばれたりするなど、アジャイル会との交流が進んでいます。 ぼくが持ち込んだ、顧客を巻き込んだ、見える化された職場のワークスタイルの写真なんかを見ながらお話ししていたら、 PDCAって日本人大好きなんだけど、これは本当に欲しいもの、い
Continuous DeliveryとDevOpsについて考えたこと - Natural Software
Ryuzeeさんの記事をトリガにしてContinuous Deliveryネタが多く回ってきたので、Continuous DeliveryとDevOpsについて考えてみた。なぜDevOpsかというと、日本語だと「継続的デリバリー」や「Continuous Delivery」よりも「DevOps」の方が目的の情報に引っかかりやすいから Continuous DeliveryとDevOps Continuous Deliveryとは 継続的に動作するソフトウェアをリリースすること アジャイル宣言の背景の一番目「価値のあるソフトウェアを早く継続的に提供します」が、まさに「Continuous Delivery」である*1 アジャイル宣言の背後にある原則 Principles behind the Agile Manifesto DevOpsとは 開発と運用の壁をなくし、ともにビジネスの成功に向け
継続的デリバリーの8つの原則
継続的デリバリーの8つの原則1. ソフトウェアのリリースやデプロイのプロセスは繰り返し可能であり信頼性が高い必要がある。このことは2つめの原則にたどり着く。 2. 全てを自動化する！手動のデプロイは決して繰り返し可能で信頼性が高いことには成り得ない。 あなたは繰り返し行う全てのタスクを自動化することについて本気で投資する必要がある。そしてこうすることによって信頼性に繋がっていくのだ。 3. なにか難しかったり苦痛なことがあったら、それを何度もやってみる表面的には、ばかげた話のように聞こえるかもしれない。しかし基本的にこれが意味していることは、苦痛であることを頻繁に行うことは、あなたがそれを改善し、多分自動化する方向に導いてくれるはずだ。そして最終的には苦痛がなくなり容易に行うことができるようになるだろう。 データベースのスキーマをデプロイすることを例にとってみてみよう。もしこれがトリッキー
今すぐフォローすべきAgile界のスーパーエンジニア
たまには便乗してみるよ。 Agile界のすごい人＝スーパーエンジニアと呼ぶのかは疑問もあるけど。とりあえず対象は日本語のつぶやきをする人です。他にも沢山すごい方はいらっしゃるので流量が多めの方を恣意的に選択してます。(○○さんがいない、といって怒らないでください) 平鍋健児さん (@hiranabe) いわずと知れた第一人者。みんな本を読んでるはず 角谷信太郎さん（@kakutani） RubyとXP。アジャイルな見積もりと計画づくりやアジャイルプラクティス 和田卓人さん（@t_wada） TDD。プログラマが知るべき97のこと 倉貫義人さん（@kuranuki） XP。YouRoom等のサービスを社内ベンチャーで開発 林栄一さん（@essence_s） NLPやファシリテーションを使ったAgile導入。すくすくスクラム名づけ親 西村直人さん（@nawoto） アジャイルコーチ。スクラム道
アジャイルマニフェスト10周年 - アジャイルマニフェストはどう生まれたのか - kawaguti’s diary
2001年2月11日に、ユタ州のソルトレイクシティ近郊のスノーバードというところに人が集まって、みんなで考えたのが、アジャイルマニフェストです。 この週末は、その10周年を記念して、同じスノーバードに人が集まってわいわいやっています。(Twitter で #10yragile とか #snowbird10 とかのタグでつぶやかれてます。写真が公開されてます。雰囲気よさそう。) アジャイルマニフェストに至る経緯はいろんな本で書かれているみたいですけど、訳されたり訳されてなかったりなので、ちょっと説明が難しい感じです。 というわけで、Alistair Cockburn の "Agile Software Development : The Cooperative Game" の付録に、ちょっと説明があるので、訳して置いておきますね。 Agile Software Development: Th
プランニングポーカー かんたんガイド 作りました。 - kawaguti’s diary
デブサミで、ご希望の方にプランニングポーカーを有償でお分けしました。一個単位で輸入すると送料がばかにならないのですが、弊社で多めに買ったものをお分けしており、少量でもコスト安く手に入ります。 (2014年現在は行っておりません。アギレルゴコンサルティング社にお問い合わせください。) Mountain Goat 社製プランニングポーカーカード を一個単位でお分けします。 - アギレルゴコンサルティング株式会社 残念ながら在庫が十分に足りず、ご興味を持っていただきながら手に入らなかった方がたくさんいらっしゃると聞きました。弊社の方でもほそぼそとお分けしておりますので、ご興味のある方は、ご検討いただければ幸いです。ほとんど原価販売です*1。 ※2012/2/20追記: 日本マイクロソフトの長沢さんがノベルティとしてプランニングポーカーを配布されていますので、そちらもご参照ください。 使い方の説明
Agile Project Management
Proven project management for successful teams With a shared view of team priorities, a process that fosters collaboration, and dynamic tools to analyze progress, your team will deliver more frequently and consistently. Better organization to get focused Keep your team on the rails. Tracker's shared backlog makes priorities clear so the team can stay organized. Easily visualize scope, focus your t
アジャイルの人たちは自分の優秀さに気づいていない - 設計者の発言
アジャイル手法を実践できるプロジェクトは恵まれている。それは、「理解ある管理者」がアジャイル手法を了承してくれたからではない。管理者がそう判断できるほどに参加メンバーが優秀だからだ。 アジャイルの特徴のひとつが「少数精鋭」である。いっぽう、アジャイルの対立手法として理解されているウォーターフォール型手法では「人海戦術」で進められる点が対照的だ。じつは「少数精鋭」というのはアジャイルの特徴であるだけでなく、あまり触れられたくない弱点でもある。なにしろ「精鋭」しか関われない。 しかしアジャイル手法の推進者は、自分が優秀であることをそれほど意識していない。それどころか彼らは「いえいえ精鋭である必要はありません。じっさい私はアジャイルが大好きですが、凡庸な技術者ですよ」と自嘲的に語るだろう。そしてそれは本心でもあるだろう。なぜなら、彼らは「超」がつくほど優秀な技術者たちがいることをアジャイルコミュ
スクラムの生みの親が語る、スクラムとはなにか？ たえず不安定で、自己組織化し、全員が多能工である ～ Innovation Sprint 2011（前編）
スクラムの生みの親が語る、スクラムとはなにか？ たえず不安定で、自己組織化し、全員が多能工である ～ Innovation Sprint 2011（前編） アジャイルなソフトウェア開発手法としてもっとも広く使われているのが「スクラム」です。このスクラムは、1990年代半ばにジェフ・サザーランド（Jeff Sutherland）氏らによって提唱されたものですが、その考え方の基盤となったのが1986年に一橋大学の野中郁次郎氏と竹内弘高氏が日本企業のベストプラクティスについて研究し、ハーバードビジネスレビュー誌に掲載された論文「The New New Product Development Game」でした。 1月14日にコミュニティが主催し都内で行われたイベント「Innovation Sprint 2011」は、このスクラムの生みの親と言える2人、野中郁次郎氏とジェフ・サザーランド氏がそれぞれ
アジャイルと受託開発
先日、永和システムマネジメント社がアジャイルによる受託開発サービスを発表し、話題になっている。多くの人の関心を引いているのは、アジャイル開発手法を取り入れるということだけでなく、その価格の安さだ。一ヶ月あたりの料金は、もっとも安いものでは月々15万円から、もっとも高額なプランでも月々150万円からとなっている。果たしてそんなので儲かるの！？というのが多くの人がいだいている疑問であろう。自分なりに「アジャイルによる受託開発サービス」について分析してみたので語ってみようと思う。なお、本エントリは永和システムマネジメント社が公開されている資料と筆者の推測に基づくものであるので、より詳細で正確な内容は永和システムマネジメント社さんへ問い合せて頂くよう悪しからず了承いただきたい。 採算割れしないのか？筆者の見解では、たぶんしない。何故か？それは一旦開発が終わったらそうそう頻繁にシステムの仕様を変更し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ディシプリンド・アジャイル・デリバリー日本語公式サイト
Scaled Agile Framework – SAFe for Lean Software and System Engineering