スクラムで陥りがちな罠24個
みなさんこんにちは。@ryuzeeです。 Agile Adviceの24 Common Scrum Pitfalls Summarizedより、スクラムで陥りがちな間違い24個がまとめられていたので、抜粋・意訳にてご紹介します。 スクラムはフレームワークとしてはそんなに複雑ではないですが、実践するのは結構難しいのが実情です。 よく聞くのがデイリースクラムが15分では終わらずに1時間かかるとか、出荷可能な製品をスプリント毎に作れないとかいったものです。 そして多くの組織において、基本としてのスクラムを実現できない（という思い込み）が故に、何かを変えたり、本来のスクラムの価値を失った間違ったやり方をしています。 以下にあがっているような症状があるのであれば、もう一度原理原則に立ち返って考えなおしてみるべきでしょう。 過剰な準備や計画作成：スクラムにおいては定常的な大きな前払いの計画作成は必要で
プロダクトオーナーの重要な役割トップ７
プロダクトオーナーはチームにビジョンを伝え、プロダクトバックログにおける作業を説明することでチームをリードする。 プロダクトオーナーは、チームと直接コミュニケーションをとって、プロダクトバックログアイテムの優先順位付けを視覚的に行うことでプロジェクトをドライブする プロダクトオーナーはビジネス価値に基づいて作業を優先順位付けする。 スクラムは開発の意思決定をエンピリカルなデータに基づいて行うという点でユニークである プロダクトオーナーはチームと作業について交渉を行う。 各スプリントの最初にチームとプロダクトオーナーはそのスプリントで何に取り組むかを決めるために会う。 しかしこの取り組む作業は、プロダクトオーナーが単に割り当てするのではなく交渉によって決められる。 そしてプロダクトオーナーはチームが出しているベロシティいついては尊重しなければならない プロダクトオーナーはチームの質問に答えた
チケット駆動開発で作業管理はしないほうがいい - arclamp
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
私がアジャイル崇拝をやめてウォーターフォールを愛するようになった7つの理由 - カイゼンにっき。
アジャイルがダメだと思う7つの理由 - arclamp にインスパイアされて、自分なりの考えをまとめてみました。一部SI前提で書いています。 制作（および詳細設計・結合テスト）フェーズの全体スケジュールを見通しやすい 確かに、全体スケジュールの完全なコミットメントは不可能です。しかし、少なくとも、信頼性の高い見通しは必要です。そもそも予算が下りません。顧客側組織の予算編成・執行体制を変えるべきだ、何て寝言を言えるはずもありませんし、見通しもなしに予算を出すべきだとも思えません。 ウォーターフォール型の開発プロセスでは、開発プロジェクトの大部分を占める制作（および詳細設計・結合テスト）フェーズの全体スケジュールを、先行する計画・設計のフェーズでじっくりと吟味します。 ウォーターフォール型の開発プロセスは、問題があった時に調整が効かないかのように言われています。しかし、ウォーターフォールにはフ
アジャイルをダメにしないためにすべきこと - arclamp
「アジャイルがダメだと思う7つの理由」をエントリしてから一週間が経ちました。まさかPublickeyにまとめが載るとは思いませんでしたよ。 内幕を正直に書くと、あの日の昼に「アジャイルも普及してきて妙に執着する人が増えたよね」と茶飲み話していており、それを「受託開発に真面目に取り組むマネージャーが、知り合いでアジャイルにハマった人に久しぶりに出会って『時代はアジャイル』と熱くねちねちと語られているうちに、どうにも納得できなくてキレた」という設定で書いたものです。刺激的な表現もあってお騒がせしました。 反応していただいたBlogは「アジャイルがダメだと思う7つの理由」に追記してあります。その他の反応ははてブでも見てもらえればと思います。 職業アジャイラーの皆様からは同意と反論が混ざった反応をいただいております。ご意見がある方は引き続きBlogで書いて頂ければ幸いです。あのエントリは仮想人格が
情報処理推進機構：ソフトウェア・エンジニアリング ｢アジャイル型開発におけるプラクティス活用事例調査｣の報告書とリファレンスガイドを公開
2013年3月19日公開 独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター 概要 インターネット販売サイトやSNS(ソーシャルネットワークサービス)等のシステムでは、その構築において要件のすべてが明確にならなくても開発に着手し、要件の明確化や変更には開発と並行して対応します。それは、いかに早くサービスを提供するかに、ビジネスの命運がかかっているからです。 こうした要件の変化に柔軟に対応できる開発手法として、「アジャイル型開発」があります。これは、ビジネス上の優先度が高い順に、短いサイクルで機能単位の開発を繰り返す手法です。 このアジャイル型開発手法は自社開発（内製）が中心の米国で発展したものであり、要件を決めて外部に開発を委託することが多い等、受発注環境が異なる日本でアジャイル型開発を適用するのは難しいと考えられています(*1)。 「アジャイル型開発」には、
10月18日〜19日 ジェフ・パットン 情熱プロダクトオーナー研修 - アギレルゴコンサルティング株式会社
2011年10月に続きジェフ・パットン氏 (Jeff Patton) が再来日します。 氏の考えるアジャイル時代の要件定義は、ビジネス・ユーザ中心設計・開発者 の３条件を揃えた "全部入り" のチームで行います。そのため、どの担当でも意図が分かり、かつ軽量に作成できるドキュメントを壁などを使って作り上げていきます。大事なのは共通理解。そして、より早くフィードバックを受け、プロダクトの方向性を修正していく「探索」にあります。プラグマティック・ペルソナ (pragmatic personas)ユーザーストーリー・マッピング (user story mapping)デザイン・ステューディオ (design studio)協調ワークショップ (collaborative workshop) 尚、本コースは、Scrum Alliance 認定スクラムプロダクトオーナー(CSPO)研修として行われます
スクラムに関する無料の日本語資料のまとめ | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 スクラムを学習するにあたって参考になる【無料】の資料を以下にあげておきます。 僕がコーチングする際は上２つの資料については事前に読んでもらった上で、トレーニングを実施したりしてます。 スクラムガイドスクラムの父であるジェフ・サザーランド氏とケン・シュエイバー氏が書いた公式のルールブック。 これを読まないでスクラムをやるのはマズイです。 http://www.scrumguides.org/日本語版は、多くの本の翻訳をされている角さんが訳されてます塹壕よりScrumとXP昨年開催したScrum Gathering Tokyoで基調講演をされたヘンリック・クニベルグ氏によるScrumとXPの実践事例。 どういう問題がおきてどう改善したかも分かる。 http://www.infoq.com/jp/minibooks/scrum-xp-from-the-t
こくちーずプロ - 無料で使えるイベント・セミナーの告知・集客サービス
個人から法人まで幅広い主催者の方にご活用いただいています。 イベント主催者7万人以上 チケット販売520万枚以上
アジャイル開発の実態調査(State of Agile Development Survey Results) (1)：An Agile Way：オルタナティブ・ブログ
毎年注目している、VersionOne社の State of Agile Development Survey Results ですが、昨年の結果が発表されています。この調査はもう６年続いていて、ぼくも毎年追っかけているものです。ここ数年は同じ傾向が続いているのですが、いくつか解説したいと思います。（たぶん連載） 結果のソース⇒http://www.versionone.com/state_of_agile_development_survey/11/ まずは利用されている方法論。これは、昨年とほとんど変わっていなくて、やっぱりScrumとXP+Scrumを足すと70%に近い。Scrumの圧勝だ。XP単独というのは2%まで下がっている。今年の大きな変化は、Kanbanが認知されたことだろう。3%にまで上がってきている。それでもまだ3%というのがScrumの強さを物語る。また、Custom
Agile概論(大学生向け)
Agile概論(大学生向け) 1. http://bit.ly/rtUk6LAgile概論 2011/9/30 Ryutaro YOSHIBA 2. 吉羽龍太郎アジャイルコーチhttp://www.ryuzee.com/ 3. よろしくお願いします 4. http://bit.ly/ptKnqR1. 企業のおかれた状況 5. ビジネスをとりまく環境の変化 6. IT投資は業務効率化から戦略実現へ 7. 以前の競争http://bit.ly/rioQDZ 8. 現在の競争 競争の速度の変化 9. 迅速な 意思決定 が必要http://bit.ly/pccwAN 10. 意思決定から素早く具現化する必要 http://bit.ly/r1ziWL 11. ビジネスモデルの賞味期限が短縮 12. 変化への対応“事前に綿密” にたてた計画を“長期間遵守” して大丈夫なのか？
OGIS Scalable Agile Method の真髄（前編） | オブジェクトの広場
［技術講座］ OGIS Scalable Agile Method の真髄 前編：日本でアジャイル開発の普及を阻む 7 つの不安と OGIS Scalable Agile Method （株）オージス総研 技術部アジャイル開発センター 藤井 拓 アジャイル開発手法スクラムだけでは実現できないことや日本でアジャイル開発の普及を阻んでいる 7 つの不安を解消するためのフレームワークが OGIS Scalable Agile Method (以降 OSAM と略す)です。今月と来月の 2 回に渡り、OSAM の概要を紹介します。今月号では、アジャイル開発手法スクラムを補うために OSAM が用いているアジャイルUPを中心に OSAM の開発手法としての側面を説明します。なお、本記事に挿入したいくつかの漫画は同僚の正木氏が作成したものです。 本記事の背景 本記事は元々 3 部構成の白書として執筆さ
Agile Conference tokyo 2011 参加レポート｜オブジェクトの広場
Agile Conference tokyo 2011 参加レポート 株式会社オージス総研 アドバンストモデリングソリューション部 浅井 良 Agile Conference tokyo 2011概要 7月20日に江東区文化センターホールにて行われたAgile Conference tokyo 2011に参加してきました。 Agile Conference tokyo 2011 - イベントTOP 株式会社テクノロジックアートにより主催・運営されるAgile Conference tokyoは今回で3年目を迎えます。「回を重ねるごとに来場者数も伸びており、アジャイル開発がいよいよ日本国内で本格的に広がっていくのではないかという期待を抱かざるをえません。」と書かれているように、400名の定員に対して参加希望者が殺到して抽選制になるほどの人気で、特に、午前中のマーティンファウラー氏の基調講演
E-Agility Conference
アジャイル開発が広がりを見せ、E-Agility Conferenceのテーマである企業システムの俊敏で軽快なシステム開発が、次第に現実のものとなりつつあります。 しかしながら、ユーザー企業の現場には、アジャイル開発が役に立つのか、どうすれば成功するのかを考えて、一歩が踏み出せない人たちがたくさんいるのも現実です。 そこで、今回のメイン講演では、これまで日本のアジャイル開発のリーダー的役割を果たされ、 現在は楽天株式会社でご活躍中の川口恭伸氏をお招きし、ユーザー企業でのアジャイル 開発の事例と成功の勘所をじっくりとお話ししていただきます。 事前登録性となりますので、ご登録はお早めに。 皆様のご来場を心からお待ちしております。 13:20 受付開始 13:40-14:00 開演/協議会からのご挨拶（20分） 講演者： 依田 智夫（株式会社シナジー研究所 代表取締役社長・プリンシパルコンサルタ
アジャイルコーチングで学んだ78のこと
みなさんこんにちは。@ryuzeeです。 78 Things I Have Learned in 6 Years of Agile Coachingの記事が素晴らしいので、78個の項目を意訳にてご紹介します。 「私が6年間のアジャイルコーチングで学んだこと」というテーマでアジャイルに関する経験談がまとめられています。 アジャイルについて説明させてくれるように頼む人の数＝アジャイルメンタルモデルの数±2分散した開発では各サイトのチームごとに愛とスクラムマスターが必要だフットボールテーブルはあなたの最良のアジャイルなツールのうちの1つかもしれない地理的分散はタイムゾーンの違い以上の問題がある。その場合はインフラのサポートが必要だローカルのイベントやオンラインのメーリングリストやカンファレンスやカジュアルな集まり等を通じてアジャイルコミュニティに精力的に関わることには十分な価値がある。プロダクト
マイルドなアジャイル開発手法 AMOP | オブジェクトの広場
今回は, アジャイルモデリングを実践するためのベースとなるアジャイル開発手法として筆者らが考案したAMOP (Agile Method for Ordinary Projects) [1] という開発手法を紹介します. AMOP は, 既存の開発のやり方に慣れた開発者や管理者に受け入れられやすいものであることを目指したアジャイル開発手法です. 今回の記事では, まずスクラム [2] の短所や難しい点を説明し, 次いでそれらを XP (eXtreme Programming) [3] のプラクティスでどのように補おうとしたかについて説明します. さらに, AMOP を２つのプロジェクトに適用した結果を紹介します. 1. スクラムの短所や難しさ 前回の記事では, もっともシンプルで取り入れやすいと筆者が考えるアジャイル開発手法スクラムを紹介しました. その記事では, スクラムの長所を中心に説明
アジャイルプロジェクトの契約に関する私見
みなさんこんにちは。@ryuzeeです。 ソフトウェアを構築するときに締結する契約は、大別すると請負契約と準委任契約、そして派遣契約（今回は割愛します）があります。 請負契約は、完成させるべきものを事前に規定し、それを満たすものを納品することで代金が支払われます。 一方で準委任契約は、発注者の代わりに自身の裁量で業務を遂行する契約であり、働いた時間に応じた代金が支払われるのが一般的です。 アジャイル開発では、顧客やユーザーのフィードバックを得て作るものを変えていきます。 つまり事前に詳細なスコープは確定しません。 それにも関わらず請負型の契約を行った場合、事前に決められた「完成させるべきもの」に加えて、フィードバックへの対応が必要になってしまいます。 事前に決められた内容によって期間と費用が固定されるため、このような変化は開発側としては避けなければいけないものになります。 その理由は、単純
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Microsoft – 長沢智治のブログ
Agile in 30mins - 30分でだいたいわかるアジャイル開発
