Redmineをつかったスクラム開発のはじめの一歩
科学的に裏付けされた12ステップの幸福を紹介し、ムービングモチベーターズ（Moving Motivators）というManagement 3.0のツールを体験することで、自分の価値観と人の価値観は微妙に認識が違うことを学べ、チームの本質的なモチベーションの中で重要なものを見つけるヒントを得ようと思います。 これをすることで、本質的なリーダーシップのトピックに取り組む準備をし、幸福のための行動計画を作成できるよう促します。 高性能チームの成功の鍵は自己組織化ですが、大小さまざまなワークショップを通して、日本企業をアジャイル・リーダーシップやManagement 3.0のイノベーション実践に適切な改変できるようにします。
ぐるぐる DDD/Scrum というワークショップをやってきました - haradakiro's blog
東北デベロッパーズコミュニティにお招きいただき、DDD/Scrumのワークショップをやってきました。 ワークショップは、DDD のモデリングのうずまきに、スクラムのワークショップでよく使うタイムボックス縛りを組み合わせて、Agile でいうところの Swarming という状態になれないかな、という目標で設計しました。 正直、１時間の枠組みで、シナリオ書いて、モデル描いて、コードも実装するのは、だいぶ大変だったと思います。ご参加いただき、ありがとうございました。 ただ、１時間を二回廻すだけでも、チーム内で駐車場を語る語彙、モデル、設計実装案は、だいぶ共有できたのではないでしょうか。そのまま、プロジェクトに突入できる訳ではありませんが、わからないことがわかっているというのは、プロジェクトを始めるときには非常に役に立つでしょう。 参加された方は、各チームの発表したモデルの中心(コアドメイン)が
DDDをScrumで廻す あるいは ScrumをDDDで廻す
QConTokyo 2013 で講演させていただいた DDDとScrumのお話の資料です。 簡単なライブモデリングもありましたが、モデリングのネタは、ワークショップのお楽しみということで、お願いします。
DeNA流Scrumとcommのチームビルディング
2022年9月13日 株式会社メンバーズ ポップインサイトカンパニーでのウェビナーのスライドです。「ユーザーが欲しいと言った機能をつけたのに使われない！」という経験はありませんか。プロダクトをつくるとき「ユーザーの心理を理解しよう」とよく言われます。しかし、ユーザーに言われたままやることと、ユーザーが本当に望んでいることは異なります。「UXデザイン・UXリサーチ」は、ユーザーを理解するための専門技術です。ユーザーインタビューやユーザビリティテストを用いてファクトを集めることで、ユーザーの表面的な言葉に惑わされない、本当のインサイトにたどりつくことができます。かんたんなワークも交えながら、体系的に解説いたします。
【資料公開】Doneの定義虎の巻
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 10月28日に日本オラクルさんで行われたスクラム道EXPOに登壇しましたので資料をさらしておきます。 登壇時間が20分ということで非常に駆け足でDoneの定義について話をしました。 大事だと思うことは最後にまとめておきましたが、これについて補足しておきます。 プロジェクト開始時点で決める完成の定義の内容によってプロジェクトの所要期間や見積りは影響を受けます。たとえばプロダクトバックログアイテムの完成の定義でテスト対象ブラウザを定義することを考えてください。Mac上のChromeだけでテストする場合と、IE、Firefox、Chrome、Safari、OperaでテストしてさらにWindows7とWindows8とMacとUb
スクラムでの初期の見積り
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 よくスクラムで初期見積りってどうやるの？って聞かれますので、思ったことをツラツラと書いておきます。 ちなみに見積りはあたらないので（もちろん当てる努力はしますし、当たった方がいいのは勿論ですが）、そのつもりで考えたほうが良いでしょう。 例えば競馬で一点買いして毎回的中すると思う幸せな人はあまりいませんが、一方で開発の見積りは毎回当たると考えちゃうのはどうかしてるということです。 1. 開発初期に全体を見積もるそもそも一発であたる見積りをするのは不可能であるのは不確実性コーンのグラフ等を見れば分かります。 だからといって見積りをしなくてよいわけではありません。 この時点では、
5分で分かる、「スクラム」の基本まとめ
5分で分かる、「スクラム」の基本まとめ：開発チームを改善するためのスクラムTips（8）（1/2 ページ） 「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。 これまで、アジャイル時代のチーム・マネジメント手法として主流になっている「スクラム」の手法を紹介してきました。今回は総集編として「スクラムの基本」をコンパクトにまとめます。 そもそもスクラムとは スクラムは、一言でいえば「チームで仕事の進めるための枠組み（フレームワーク）」です。 もともとはソフトウェア開発プロジェクトを成功させる仕組みですが、技術的な要素は取り除かれ、多くのチーム作業に共通して適用できる要素だけが残りました。そのため、ソフトウェア開発以外のチームにも適用できるのが特徴です。 ●バッ
スクラムに関する無料の日本語資料のまとめ | Ryuzee.com
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 スクラムを学習するにあたって参考になる【無料】の資料を以下にあげておきます。 僕がコーチングする際は上２つの資料については事前に読んでもらった上で、トレーニングを実施したりしてます。 スクラムガイドスクラムの父であるジェフ・サザーランド氏とケン・シュエイバー氏が書いた公式のルールブック。 これを読まないでスクラムをやるのはマズイです。 http://www.scrumguides.org/日本語版は、多くの本の翻訳をされている角さんが訳されてます塹壕よりScrumとXP昨年開催したScrum Gathering Tokyoで基調講演をされたヘンリック・クニベルグ氏によるSc
【Knowledge Co-Creatingセミナー】Scrum基本のキ/Head Firstインセプションデッキ
アジャイル開発の中でもスクラムに焦点を当て、スクラム開発の基本的な考え方を分かりやすい例と演習を通して学びます。 アジャイル開発への一歩を踏み出すきっかけを作る場として活用いただけます！ アジャイル開発手法の一つにScrumがあります。Scrumとはマネジメントのフレームワークであり、そこで規定されている活動はシンプルですが、実際に導入しようとした際には、いろいろな課題が浮かび上がります。 本セミナーでは、そのような課題に向きあうために、Scrumの特徴や各用語の解説、重要視しているポイントに焦点をあて、基礎知識を学びます。 また、プロジェクトを成功させるためには、プロジェクトの方向性を関係者で正しく合意しておく事が重要です。 プロジェクトの方向付けを行う手段の一つとして、インセプションデッキというScrumで用いられるプラクティスを体感しながら学びます。 ※本セミナーは有料です。詳
スクラムがうまくいっている兆候
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 昨日Twitter上で@yujioramaさんから「これは成功すると思えたスクラム導入の兆しとか読んでみたいです!」という要望を頂いたので個人的な見解を書いてみたいと思います。 なお、僕は基本的に、技術力とかツールの話以前の話としてチームの態度や周りとの協調関係を重視しているので、主にそういう観点が多いことを念頭においておいてください。 プロダクトオーナープロダクトオーナーが明確なプロダクトバックログアイテムを書いている自分が書いたプロダクトバックログアイテムに責任をもっている。開発チームがプロダクトプロダクトバックログアイテムの中身についてプロダクトオーナーに確認できる開
プロダクトバックログ項目の明確化の必要性 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 プロダクトバックログ項目からタスクにうまく分割できないので、あればそのコツが知りたいと@riskriskさんからリクエストを頂いたので解説したいと思います。 まずは以下の図を見てください。 これはスクラムにおいて、プロダクトバックログからスプリントバックログへの流れを会議体とともに示したものです（パワーポイント版はこちら）。 実はほぼこの中に全て答えがあります。 まずプロダクトバックログ項目（ストーリーなど）からタスクにうまく落とせない場合は、以下のようなことが原因として考えられます。 そもそもなんのためにそのプロダクトバックログ項目があるのか分からないプロダクトバックログ項目の内容が曖昧または抽象的すぎて、作るべきものが分からない。または人によって著しく成果物のイメージが異なるプロダクトバックログ項目に受け入れ条件がないため、何ができたらそのバッ
スクラムにおいて欠陥をどのように扱うか
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 スクラムにおける欠陥の扱い方について考えてみました。 スクラムでは欠陥の扱い方には特に規定はないので、以下はあくまで経験を踏まえた個人的なアプローチであることに注意してください。 欠陥の定義欠陥とは、プロダクトバックログアイテムが「完成」した後に見つかった欠陥のみを指すここでいう欠陥とはソースコードのバグと要求実装の欠落の双方を指す双方の具体的な定義や判断基準はプロジェクトによって異なる（欠陥の定義を作ると良い）バグと技術的負債は異なるスプリントで実装中のプロダクトバックログアイテムにおける動作不良や問題は、その時点では欠陥とみなさないなぜなら完成の定義や受け入れ基準に従っ
(非公認) スクラムフレームワークかんたんガイド 作ってみました。 - kawaguti’s diary
今日、大学の学生さんにスクラムの説明をしに行くのですが、せっかくなので、A4一枚でざっくり説明する、かんたんガイドを作ってみました。以前、プランニングポーカーのかんたんガイドを作ったのですが、思いのほかご好評いただきましたので、調子に乗りました。すみません。 スクラムのフレームワークのうち、本当に基本的なところをさっと見ていただけることを目指しました。一方、語れていない要素もたくさんありますので、そのへんはご理解の上、ご利用いただければ幸いです。 PDF版はこちらにあります。 なぜ非公認？ 誰の公認も受けていないからです。非公認スクラムチェックリスト へのオマージュです。 ぜひご意見お願いいたします。 おかしな点などありましたら、ぜひご指摘お願いいたします。
Scrum changes an organization
Le document traite de la méthodologie Scrum et de ses phases d'implémentation. Il souligne les défis rencontrés en matière de responsabilité et de planification, tout en expliquant comment Scrum peut aider à les surmonter. Des détails sont fournis sur les pratiques de rétrospective et de démarrage, ainsi que sur l'utilisation d'outils comme Jira pour faciliter la gestion Scrum.
[Scrum]Scrumではコードレビューをどうやっているか？ | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 よく一緒に議論したり大学行ってワークショップをしたりしている原田さんが、スクラムでのコードレビューについて書かれましたので、僕も過去数年コーチとして色々な現場に行った際のことや、自分で受託開発をスクラムでやった際のことを踏まえてスクラムにおけるコードレビューのやり方を書いてみます。 レビューのやり方早期から頻繁に僕自身は小規模で頻度の高いインクリメンタルなレビューを好んでいます。 かつて大きなSIerにいてウォーターフォール型の開発をしていた際に、パートナーさんから出てきたソースコードを見ると、コピーペーストの嵐だったり、変数名がデタラメすぎたり、インデントがぐちゃぐちゃだったり（以下思いつく全ての「えーーー」を適当に想像してください）して、かつ工程の後半にレビューしていたので、直すに直せないというような悲惨なことも経験しました。 （注）ウォーター
![[Scrum]Scrumではコードレビューをどうやっているか？ | Ryuzee.com](https://cdn-ak-scissors.b.st-hatena.com/image/square/a31e0bf93e286adee40dad5e291b096b09a3fb0d/height=288;version=1;width=512/https%3A%2F%2Fwww.ryuzee.com%2Fcontents%2Fblog%2Fimages%2F4588%2Fthumbnail.webp)
Scrum ではコードレビューをどうやっているか？ - haradakiro's blog
森崎先生のソフトウェアレビューの講演を聴いて、今やっているレビューの方法をまとめときたいと思ったので、まとめてみます。今回は、コードレビューの話です。Scrum ではといっていますが、レビューのやり方はチームによって違うので、あくまでも例ですよ。PBI とか、仕様、ドメインモデルのレビューの話はまたこんど。 レビューの目的は、もちろん作成するプロダクトの品質向上です。障害を検出するのも、もちろん目的ではあるのですが、それ以降のスプリントで作成されるコードで同じ障害を作り込まないのが目的としては大きいです。そのため、レビューはプロジェクトもしくはチーム立ち上げ後、数スプリントで重点的にやります。後はスプリントの振り返りでレビューをやりたいが出てきたら、チームで決めます。 レビューのやり方 基本はチーム全員で集まってやります。最大２時間。それ以上やっても集中力が続かないので。プロジェクタで対象
スクラムマスターとして考えることリスト(ドラフト) - かっぱっぱ
スクラムマスターをする時に考えることって何だろうと思って書きだしてみた。 まだまだ足りない気がするが、とりあえずこんなところ。ササっと書いたのでtypoや重複等あるかと思います。 その人なりのハラオチした答えがあると良いと思う。このなかには僕なりの答えがないものもあるけど。 この中からピックアップしてみんなで議論してみるのも面白そう。スクラム禅問答と名付けようw 追記希望とかあればぜひ〜 チームのこと チームはどこを目指そうとしているのだろう? チームは本当はどんな開発がしたいんだろう? みんなはどういうチームの状況を働き易いと思うのだろう? このチームで何を達成することを「一番」大切だと思うんだろう? このチームでまず「一番」最初に直すべきところはどこだろう? チームが一番生産性を発揮できるのはどんなときなんだろう? チームが一番品質を向上していけるのはどんなときなんだろう? 何故やる気
認定スクラムマスタ研修に参加して感じたこと、自分のチームに戻ったらやりたいこと
2012年1月12日〜13日に、Jim Coplien 氏の認定スクラムマスタ研修に参加しました。 アギレルゴ アジャイル研修 研修で行ったこと、感じたこと、自分のチームに戻ったらやりたいことをまとめました。 目次 心に留めておきたいこと 座学 ワークショップ チームに戻って、スクラムマスターとしてやりたいこと 自己組織化について思うこと Great Scrum Masterになるには 心に留めておきたいこと ２日間の座学、ワークショップ、参加された方との会話を通して学んだ、心に留めておきたいことです。 スクラムマスターがチームをリードする（指示し管理するのではない）スクラムマスターはチームのために尽くす無駄なことは何か意識する。次のスプリントもまた同じ無駄なことをしないようにスクラムで規定されていないことは、自分たちで考える。場・状況はそれぞれ違うスクラムマスターは時にはチームを突き放し
スクラムで陥りがちな罠24個
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 Agile Adviceの24 Common Scrum Pitfalls Summarizedより、スクラムで陥りがちな間違い24個がまとめられていたので、抜粋・意訳にてご紹介します。 スクラムはフレームワークとしてはそんなに複雑ではないですが、実践するのは結構難しいのが実情です。 よく聞くのがデイリースクラムが15分では終わらずに1時間かかるとか、出荷可能な製品をスプリント毎に作れないとかいったものです。 そして多くの組織において、基本としてのスクラムを実現できない（という思い込み）が故に、何かを変えたり、本来のスクラムの価値を失った間違ったやり方をしています。 以下に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ユーザーストーリービギンズナイト at 第11回すくすくスクラム
