47. • • SM×1 IA×2 ×2 ×2 • • PO×1 SM×1 ×4 6 ×2 ×1 2 • 20
Scrum changes an organization
47. • • SM×1 IA×2 ×2 ×2 • • PO×1 SM×1 ×4 6 ×2 ×1 2 • 20
ソフトウェアは完成しても価値はない 〜 アジャイル開発は何を解決するのか | Social Change!
「アジャイル開発を、お客さまに導入してもらうにはどうすればいいですか？」 そんな相談を受けることがあります。私はどんな優れた提案も相手にニーズがなければ通らないことを知っています。喉が渇いていない人に水を売ろうとしても売れないのです。そもそも提案する前に、まずはニーズに気付いてもらう必要があります。そして、そのお客さまは、本当にアジャイル開発に対するニーズがあるのでしょうか。 私の考えるアジャイル開発の本質は「アジャイル開発では当初に想定した機能を”全部”つくらない」ことだと考えています。（参考記事：アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは） この「全てを作らないことで、変化に対して柔軟に開発していく」というソリューションを求めるニーズがあるのであれば、アジャイル開発のメリットを伝えれば採用されることでしょうし、そういうニーズがなければ、何を言っても受け入れられま
どうすれば小さなチームでも大きな成果を出せるのか
スクーの授業で使った資料です。 ソフトウェア開発をしていく中で、沢山のリソースやお金をつぎ込んで開発するのではなく、どうすれば少人数のチームで低コストな中で開発を続けていくことで、大きな成果を出す為の考えかたについて説明しています。Read less
スクラムはもうだめぽよ!新しい開発手法『パワープレイ』をお姉さんが教えてあげちゃう!
2013/3/9 NADECで講演した内容です。 都合上、やったみた結果の一部内容は省きました。 何かあればTwitterで @arimamoto までお願いします (^^)/ Read less
スクラムで陥りがちな罠24個
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 Agile Adviceの24 Common Scrum Pitfalls Summarizedより、スクラムで陥りがちな間違い24個がまとめられていたので、抜粋・意訳にてご紹介します。 スクラムはフレームワークとしてはそんなに複雑ではないですが、実践するのは結構難しいのが実情です。 よく聞くのがデイリースクラムが15分では終わらずに1時間かかるとか、出荷可能な製品をスプリント毎に作れないとかいったものです。 そして多くの組織において、基本としてのスクラムを実現できない（という思い込み）が故に、何かを変えたり、本来のスクラムの価値を失った間違ったやり方をしています。 以下にあがってい
WBS は、作業分解構造ではないのよ。 - haradakiro's blog
ちょっと大人数で行うプロジェクトに参加したことがある人なら、WBS (ワークブレークダウンストラクチャー) を目にしたことがあるだろう。 日本語だと作業分解構成と説明されることが多い。Work(作業) Breakdown(分解) Structure(構造) というわけだ。日本語の説明では、そういう説明が主流のようだ。 でも、WBS の Work は実は作業ではない。 WBS を定義した標準の最新版MIL-STD-881Cを見てみると、"A product-oriented family tree composed of hardware, software, services, data, and facilities." 「WBS の定義は、ハードウェア、ソフトウェア、サービス、データ、設備などからなる成果物指向の分解ツリーである。」 ここでいう Work は、成果物のことだ。Workb
ゲーム業界から見たアジャイル開発
1. 長久 勝 as @mnagaku 国立情報学研究所 GRACEセンタ 特任技術専門員 早稲田大学 メディアネットワークセンタ 非常勤講師 日科技連SQuBOK開発領域チームメンバ 技術者として働くかたわら、非常勤講師やライターとして、ソフトウェア開 発技術の普及にもあたってきた。現職では、学術クラウドの構築・運用・ 普及促進と、社会人向けソフトウェア工学教育プログラム「トップエス イー」に携わっている 「生物の生きるしくみを応用する免疫アルゴリズム」、Cマガジン、2004年 「『金枝篇』にみるパターンランゲージ」、AsianPLoP2011 （予稿集はワシが作った） SQiPシンポジウム2012 SQuBOK関連セッション 「種まく人」、XP祭り2012 Copyright 2012 GRACE Center All Rights Reserved. 1 3.
ストーリーポイントの見積りは何故時間の見積りより良いのか
みなさんこんにちは。@ryuzeeです。 よく聞かれるネタではあるのですが、スクラムの父ジェフ・サザーランド氏がストーリーポイントの見積りがなぜ時間の見積りよりも良いかについて過去にブログに書かれたものを意訳・抜粋にて紹介します。 以下の訳文は原文にしたがって、CC BY-NC-SAとします。 原文はこちら 左図: 不確実性コーン 右図: マイクロソフトによるストーリーポイント見積りの正確性 ストーリーポイントを使うとより正確な見積りを得られ、計画の時間を劇的に減らすことができ、リリース日をより正確に予測できるようになり、チームのパフォーマンスの改善の助けになる。 時間を使った見積りは、よくない見積りとなり、システムに大量のムダを生み出し、プロダクトオーナーのリリース計画の妨げとなり、どのプロセス改善が本当に役立っているのかチームがわからなくなる。 新たな興味深い調査結果が公開された。 ス
海外でなぜアジャイル開発が普及しているのか？ IPAが分析と提言
海外ではなぜアジャイル型開発が普及しているのか、IPA（独立行政法人情報処理推進機構）が継続的に行っている非ウォーターフォール型開発についての調査や提言活動の一環として、海外でのアジャイル開発の背景などについての報告書「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書 （非ウォーターフォール型開発の海外における普及要因編）」が公開されました。 調査対象国は、アメリカ、イギリス、中国、ブラジル、デンマークです。アメリカはアジャイル宣言が行われたアジャイル開発先進国として、イギリスもアジャイル開発の先進国として選ばれ、中国は日本のオフショア先であり新しいソフトウェア開発市場が起こりつつある国として、ブラジルはアジャイルコミュニティが活発化しており、デンマークは政府がアジャイル開発を推進している国として選択されました。 報告書のハイライトを紹介します。 海外でなぜアジャイル
蒼と碧の幻想 プロジェクトマネジメントのノウハウ（2011/4）
受託系ソフトウェア開発チームのリーダーをやり続け、現在までにおおよそ２０プロジェクト全勝・・は言い過ぎだけど、とりあえず無敗とは言えそう♪ 最初の会社では「なんでそんなにうまくいくのかさっぱりわからない」と言われ続け、今の会社ではチームと個人の賞を独占したノウハウをタダで公開♪ -- ●リード １）プロジェクトの成功には、短期的な成功と中長期的な成功をがある。両方を意識すること。 ２）プロジェクトの短期的な成功は、お客さんを満足させて利益をあげること。 ３）プロジェクトの中長期的な成功は、メンバーが成長することとメンバー同士がまた一緒に仕事したいなと思い合うこと。 ４）リーダーとメンバーがフラットでオープンな関係を築けなかったプロジェクトは、中長期的には失敗する。 ５）ほとんどの人にとって仕事はあくまで生活の手段。生活のイベントより大切な仕事のタスクなんてない。 ●フラット １）リーダー、
アジャイルが語る。価値あるソフトウエアを届けるために必要な12の価値観 - 基本へ帰ろう
私は日頃から「価値あるソフトウェアを提供したい」「開発スピードを向上したい」「顧客も開発者も幸せな環境を作りたい」、そう思いながら開発を行なっています。それらを達成するために必要だと感じているのが、”顧客とプロジェクトメンバー全員”で「価値観（大切だと思うこと）を共有して納得すること」だと思っています。極端な話ですが、もし顧客が「予算も仕様も開発期間も開発メンバーも固定だ。遅れたら土日祝日を使って取り戻せ。残業代はもちろん支払わないぞ。そしてソフトウェアが役に立たなかったら買い取ってもらうからな。フハハハハ！」という価値観をもった顧客と契約（約束）できるでしょうか？価値観というのはとても大切なのです。 私はアジャイルについて、以前から興味を持っています。例えば下記のエントリーがその現れです。 RubyKaigi2010で「本当のアジャイル」を学んだ - 基本へ帰ろう アジャイルな見積りと計
アジャイルなインフラのつくり方とデータマネジメント - メソッド屋のブログ
さて、今日２発目のブログは、多くの人に書いてくれ〜と言われて約束していたネタです。 目下最近の私の２大関心毎は「Lean Startup/UX」と「Continuous Delivery」です。Lean Startupは書きましたので、何で「Continuous Delivery」か？というのは、理由があります。 最近実は企画フェーズのコンサルの中でプログラムを書いています。JQuery Mobile + Ruby on Rails on EC2 という感じです。インフラからアプリケーション、そしてUX的な要求開発なんかもやっています。チームは企画フェーズのアジャイルなので小さいですが、今回のアプリケーションを作っていて思っていることですが、Agileに加えてRailsやJQuery Mobileを使うとかなり開発って加速するのですが、どうしてもめんどくさい事があります。１つはインフラ構築
10 Most Common Mistakes in Agile Adoption. Part I - DZone
They did it again. Companies are making the same mistake during agile adoption over and over again. We’ve made some of these mistakes as well. If by any chance you see something familiar in the list below, read on and find out why it is a mistake. 1. Start With a Tool It is not always bad to start with a tool. If you want to dig a pit, you most likely want to find a shovel first. You can dig manua
情報処理推進機構：ソフトウェアエンジニアリング：非ウォーターフォール型開発に関する調査結果公開
SECは、短サイクルで設計からシステム稼動までを"機敏"に繰り返し、ニーズへ迅速へ対応するといわれる非ウォーターフォール型開発について、事例を含む適用分野や規模などの調査を行いました。あわせて、有識者に参画していただいて研究会を実施し、現状・動向の把握と課題の整理を行いました。その資料を公開します。 ・非ウォーターフォール型開発に関する調査 調査報告書 ・非ウォーターフォール型開発に関する調査 研究会報告書 ・非ウォーターフォール型開発に関する調査 エグゼクティブサマリー
アート・オブ・アジャイル デベロップメント 社内読書会＃３−１ - noire722 の日記
長い章ので数日に分けて追記していきます。 XPを理解する XPには要件・設計・テストという段階的なフェーズがない。 ※１ チームのオンサイト顧客がプロジェクトの方向性を管理する。 設計とコーディングはTDDで行う。 ※２ ペアプロを行う。 ※３ バージョン管理システム、自動ビルド＆テストツールを導入する。 各イテレーションの終わりにソフトウェアを導入（リリース）する。 所感＆補足 ※１ たとえばプロジェクトの納期が１年だとするとウォーターフォールは１年全体に計画・分析・設計・開発・テスト・導入を割り当てる。XPでは１〜３ヶ月の短いイテレーションの中でそれら全てをほぼ同時に行い、繰り返す。大事なのはXPが要件・設計・テストを軽視しているわけではないということ。大事だという認識があるから常に行う。（それは要件を把握している顧客がチームにいるから可能になる？） ※２ TDDで書くテストと品質テス
第11回すくすくスクラム――ユーザーストーリービギンズナイトで講演してきました。 - capsctrldays(2010-02-25)
■1 第11回すくすくスクラム――ユーザーストーリービギンズナイトで講演してきました。 講演といってもワークショップ形式なので、あまりしゃべってないですけれども。 2時間という長時間でしたが、原メソッドのおかげでピッタリ時間通りに終わりました。ご参加いただいたみなさん、ust参加者のみなさん、スタッフのみなさん、どうもありがとうございました。 今回は、ワークショップへの参加者として思ってたことを2つ実践してみました。 （参加者同士の）自己紹介なんて必要なくね？ 模造紙って非日常的だから使えなくね？ もちろん異論はあるでしょうけれど。 ustの録画は以下。 ちゃんとした録画は、このへんにアップされるんじゃないかなあ。 http://www.microsoft.com/japan/powerpro/developer/agile/community/suc3rum.mspx 資料も、いずれこの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルマネジメントとは？
DeNA流Scrumとcommのチームビルディング
File:XP-feedback.gif - Wikimedia Commons
http://capsctrl.que.jp/kdmsnr/diary/20100601.html
