スクラムガイド | スクラムガイド日本語版
我々は1990年代初頭にスクラムを開発した。世界中の人たちがスクラムを理解できるように、スクラムガイドの最初のバージョンを2010年に執筆した。それ以来、機能的に小さな更新を加えながらスクラムガイドを進化させてきた。我々は共にスクラムガイドを支援している。 スクラムガイドにはスクラムの定義が含まれている。フレームワークの各要素には特定の目的があり、スクラムで実現される全体的な価値や結果に欠かせないものとなっている。スクラムの核となるデザインやアイデアを変更したり、要素を省略したり、スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限される。場合によっては、スクラムが役に立たなくなることさえある。 成長を続ける複雑な世界において、スクラムの利用は増加しており、我々はそれを見守っている。スクラムが誕生したソフトウェアプロダクト開発の領域を超えて、本質的に複雑な作業を必要
7 Different Product Roadmap Formats
[Originally published on my personal site. You can read it there — https://www.antmurphy.me/blog/22/3/28/7-different-product-roadmaps] After writing about ‘8 different ways to organize your Product Backlog’, which has since been transformed into Miro templates, I thought I would write something similar for Product Roadmaps. Here are a few different shapes a Product Roadmap can take. I hope this gi
The New New Product Development Game
In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method—as in rugby, the ball gets passed within […]
勝手に注釈付き参考文献 | スクラムガイド日本語版
スクラムガイド2020からは、IT以外の分野にも適用してもらいたいみたいなので、ソフトウェアに特化したものはできるだけ排除する（とはいえ、なかなか難しいね） スクラムガイドでは「我々は1990年代初頭にスクラムを開発した」とあるので、まずは当時の状況を把握しておくとよさそう。おおざっぱに言うと、ソフトウェア業界的にウォーターフォールじゃダメだという雰囲気になっていて、何かいい方法がないものか……とみんなが模索していた時代。 そこで、過去の文献を遡り、当時でも使える概念が発掘された。それが、以下の竹内・野中論文である。Jeff Sutherlandはここから「スクラム」という名前を拝借しており、両名は「スクラムの祖父」と称される。 Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard
とりあえず 2020年版の Scrum Guide を読んだのでざっくり感想 - TechとPoemeの間
www.scrumguides.org Product Goal という新要素。3つの作成物である Product Backlog, Sprint Backlog, Increment にそれぞれ Product Goal, Sprint Goal, Definition of Done という "Commitment" を設けようという話。 Product を構築する上で、そのプロダクトをなぜ作るのかを意識しないことってそんなに無いとは思う。 けれども、Product Goal が Product Backlog に記載されていることで、「なんとなくこの Product Backlog Item をやりたい」という寄り道をせず、Product Goal の達成のために何をするかに思考を集中させるのだよ、という矯正ができるのは良さそう。 実際、いい感じに Scrum の Sprint がワ
There’s value in the Scrum Values
Gunther Verheyen is an independent Scrum Caretaker on a journey of humanizing the workplace with Scrum. Notice: following is my original description of the Scrum Values. I won’t be touching this description. I have however since the inception of this description (2012) slightly updated the descriptions. Find the latest version at https://guntherverheyen.com/the-scrum-values/ and the international
見積りしないスクラム/No Estimates Scrum JP
Regional Scrum Gathering Tokyo 2020 の資料です。
チームワークあふれる働き方を目指して -サイボウズが歩んだスクラム導入の道-
The document discusses a regional Scrum gathering in Tokyo in 2018. It introduces the speaker and their involvement with kintone and Agile Japan 2018. It then discusses kintone, a web application development platform. The remainder of the document discusses the speaker's experience working with kintone over the past year, including improvements made to their development process through activities
スクラムにおいて欠陥をどのように扱うか
みなさんこんにちは。@ryuzeeです。 スクラムにおける欠陥の扱い方について考えてみました。 スクラムでは欠陥の扱い方には特に規定はないので、以下はあくまで経験を踏まえた個人的なアプローチであることに注意してください。 欠陥の定義欠陥とは、プロダクトバックログアイテムが「完成」した後に見つかった欠陥のみを指すここでいう欠陥とはソースコードのバグと要求実装の欠落の双方を指す双方の具体的な定義や判断基準はプロジェクトによって異なる（欠陥の定義を作ると良い）バグと技術的負債は異なるスプリントで実装中のプロダクトバックログアイテムにおける動作不良や問題は、その時点では欠陥とみなさないなぜなら完成の定義や受け入れ基準に従ったものを開発チームは作る必要があること、プロダクトオーナーは受け入れ確認の際に、欠陥がある場合にプロダクトバックログアイテムを受け入れるか受け入れないかを決めることができるため対
The Humanizing Work Guide to Splitting User Stories
As the authors of the Agile Manifesto said, “We are uncovering better ways…by doing it and helping others do it.” We’ve individually been practicing, writing about, and coaching others on user story splitting since at least 2005. Richard’s story splitting flowcharts have been downloaded hundreds of thousands of times. Working individually with clients, we found very similar patterns for what works
大規模スクラムの失敗から学んだこと #AgileJapan2015
「のどが渇いた」というユーザーに何を出す？ ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ 2022年9月13日 株式会社メンバーズ ポップインサイトカンパニーでのウェビナーのスライドです。「ユーザーが欲しいと言った機能をつけたのに使われない！」という経験はありませんか。プロダクトをつくるとき「ユーザーの心理を理解しよう」とよく言われます。しかし、ユーザーに言われたままやることと、ユーザーが本当に望んでいることは異なります。「UXデザイン・UXリサーチ」は、ユーザーを理解するための専門技術です。ユーザーインタビューやユーザビリティテストを用いてファクトを集めることで、ユーザーの表面的な言葉に惑わされない、本当のインサイトにたどりつくことができます。かんたんなワークも交えながら、体系的に解説いたします。
小さく始める大規模スクラム
2017年1月12日（木）に、「Regional Scrum Gathering Tokyo 2017」で発表させていただいた資料です。 http://2017.scrumgatheringtokyo.org/ メトリクスに関する知見を、学術的視点（Agile2016・SQiP2016）および現場での活用事例から整理し、具体的な取得・活用方法を含めて説明しています。 みなさんのメトリクスの習得・活用のプラスになれば幸いです。
変化の早いソフトウェアにチームで立ち向かうためのスクラム開発｜Goodpatch Blog グッドパッチブログ
この記事はGoodpatch Advent Calendarの23日目の記事です。 私たちの開発チームでは現在、クライアントワークの中でスクラム開発を実践しています。 スクラム開発は、短く反復的に開発するアジャイル開発手法の１つであり、とても人気のあるソフトウェア開発プロセスです。スクラムの定義についてスクラムガイドでは以下のように述べられています。 スクラム（名詞）：複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。 今回は従来の開発プロセスで発生していた問題からスクラム開発を導入する事で改善された事などを記したいと思います。 スクラム開発を導入する前に発生していた問題 プロジェクト初期のフェーズからウォーターフォール型に近い形で開発を進めていました。フロントエンドとバックエンドに開発リーダーを立てて、要
How To Create Your Team's Definition Of Done
Note: My thinking about the definition of done has evolved since writing this. You can find my updated thoughts and advice in the article How To Create A Definition Of Done. Cheers, Chris Sims A scrum team’s definition of done is an important tool that helps the team add new functionality while keeping the product in a releasable state. Here is one way of facilitating the creation and evolution of
物理カンバンの写真10枚（＋勝手レビュー）
みなさんこんにちは。@ryuzeeです。 他の会社やチームで使っているカンバンを見れる機会はそう多くはないのではないでしょうか？ そこでFlickrでCreative Commonsライセンスで投稿されているカンバンの写真のうち、役立ちそうなものを10枚紹介します。 それぞれ写真に対して、写真から読み取れる良い点や改善点をコメントとしてつけましたので、自分のカンバンを改善する役にもたつと思います。 その1https://www.flickr.com/photos/drewm/369319379/こんなにたくさんの項目が貼られると制御しきれないので、タイムボックス等を導入して、定期的にクリアするレーンは線で区切った方が良い付箋が反り返っている。正しい剥がし方をしていないかも付箋の色の違いに意味をつけるその2https://www.flickr.com/photos/dinomite/3219
Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む（Spotifyモデル）
(注)ヘンリックの許可を得てざっくり意訳しました。原文は『Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds』です。訳に対するヘルプも歓迎します。Thanks Henrik, this article is great for me. プロダクト開発をしている組織において、多角的なチーム構成を実現するのはいつもチャレンジな作業だ！ 今まで見てきた中で印象に残っている例がひとつある。それはSpotifyだ。Spotifyは3つの都市にまたがって30以上のチームにスケールしているが、アジャイルなマインドセットをキープし続けている。 Spotifyは音楽産業を一変させている魅惑的な企業だ。創業してから6年しか経っていないのに、1500万ものアクティブユーザーを抱え、400万以上の決済が行われている。また、そのプロダクトは「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
scrum.doc
スクラムを1年回して SREと開発組織がどう変わったのか
http://jp4.scaledagileframework.com/
大規模スクラムにおけるプロダクトの定義 - TechとPoemeの間