Scrum.orgスクラムガイドは、非常に簡潔に記載されているので、スクラムを理解するために非常に有効です。

Scrum フレームワークの全体像

しかし逆に、短い表現で記載されているがために、スクラムの役割・イベント・作成物のそれぞれの用語を、それぞれがまだ説明されていない段階で、それらの用語自体を使って説明しているため(わかってしまえば分かりやすいのですが)用語の意味が分からない段階で読んで理解するのはなかなか難しく、スクラムガイドだけを読めば理解できるとはいかないのがツライところです。

また、スクラムガイドには当然、ツールやシステムの使い方の解説は含まれていないので、「じゃぁ、具体的にはどうやってそれを実現すればいいの?」という部分がイメージしづらいところがあります。

そこで、スクラムガイドのフレーズを図解しながら、その場面での Azure DevOps の使い方はどうなのか?というのを解説する記事を書いてみることにしました。

このページは、この連載記事をスクラムガイド順に読むための、目次的なページです。

連載はスクラムガイドの順番とは異なります。連載順に読むには アジャイル・DevOps カテゴリページを見ていただければと思います。

続きを読む

スクラムチーム(Scrum Team)はプロダクトバックログ(Product Backlog)というリストの一番上の項目を、次の(あるいは最初の)スプリントで開発して完成させます。ごくごく簡単に言うと、「このスプリントで作ると決めたプロダクトバックログ」が、スプリントバックログです。

Scrum.orgスクラムガイドによると、スプリントバックログについて次のように書かれています。

スプリントバックログは、スプリントゴール(なぜ)、スプリント向けに選択されたいくつかのプロダクトバックログアイテム(何を)、およびインクリメントを届けるための実⾏可能な計画(どのように)で構成される。

スプリントバックログは、開発者による、開発者のための計画である。スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで⾏う作業がリアルタイムに反映される。

https://www.scrum.org/resources/scrum-guide

これによると『「作ると決めたプロダクトバックログ」だけがスプリントバックログではない』ということがわかります。その他に、スプリントゴールと計画を合わせてスプリントバックログと呼びます。

なぜ作るのか?何を作るのか?どのように作るのか?を合わせてスプリントバックログバックログなのですね。

この「計画」については Azure DevOps などのシステムを使っているスクラムチームであれば、特に意識していなくても扱うことになると思いますが、「スプリントゴール」については意識していないスクラムチームが多いかもしれません。また、バックログの選択の仕方やタスクの扱い、リアルタイムに更新できているかどうかについても、慣れるまではなかなか難しいところがあります。それぞれのポイントについて、もう少し詳しく見てみましょう。

続きを読む

スクラムチーム(Scrum Team)はプロダクトバックログ(Product Backlog)というリストの上から順に開発を行います。

Scrum.orgスクラムガイドによると、プロダクトバックログについて次のように書かれています。

プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの⼀覧である。これは、スクラムチームが⾏う作業の唯⼀の情報源である。

https://www.scrum.org/resources/scrum-guide

この文章に Scrum チームがどのように「作りたいもの」を管理して、開発を行っていくか?ということが、とても明確に表現されています。ただ(スクラムガイド全般にそうですが)、Scrum を理解してから読まないとピンとこないくらい短い文章になっていますよね。それぞれのポイントについて、もう少し詳しく見てみましょう。

続きを読む

スクラムチーム(Scrum Team)のプロダクトオーナー(Product Owner)は、これから作るプロダクトがどうなっていればユーザーにとって価値があるか?ということを考え、開発者に示す役割です。プロダクトオーナーは開発者(Developers)にプロダクトゴール(Product Goal)を示すことで、プロダクトの価値を高めていきます。

Scrum.orgスクラムガイドによると、プロダクトオーナー(PO)について次のように書かれています。

プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化することの結果に責任を持つ。

プロダクトゴールを策定し、明⽰的に伝える。

https://www.scrum.org/resources/scrum-guide

またスプリントゴールについては次のように書かれています。

プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画のターゲットになる。

https://www.scrum.org/resources/scrum-guide

つまり PO は、プロダクトが将来どうなっている状態が良いのか?を考えて、スクラムチームに伝える役割ということになります。

続きを読む

スクラムチーム(Scrum Team)の開発者(Developers)は、インクリメント(Increment)を開発します。開発者がスプリントごとに作成するものがインクリメントです。スプリントごとに、前のスプリントで作成したものに追加していくことから「インクリメント=増分」と呼ぶのですね。

Scrum.orgスクラムガイドによると、開発者について次のように書かれています。

各スプリントにおいて、利⽤可能なインクリメントのあらゆる側⾯を作成することを確約する。

https://www.scrum.org/resources/scrum-guide

このシンプルな説明文の1行だけでも、かなり重要なポイントがあります。

スクラムがなんとなくうまくいかない時や、スクラム・アジャイルに対する誤解が大きい時には、この部分のイメージがうまくできていないのかもしれません。

続きを読む

スクラムチーム(Scrum Team)は機能横断型(cross-functional)で自己管理型(self-managing)です。

Scrum.orgスクラムガイドによると、スクラムチームについて次のように書かれています。

スクラムチーム内には、サブチームや階層は存在しない。

スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えている。
また、⾃⼰管理型であり、誰が何を、いつ、どのように⾏うかをスクラムチーム内で決定する。

https://www.scrum.org/resources/scrum-guide

スクラムチームが機能横断的でなければならないというのは、とても分かりやすい話です。必要な全てのスキルを全員が持っていなければならない、というわけではないのですが、必要なスキルを少なくともチームの誰か持っていなければ、さすがに開発することができません。

一方で、スクラムチームが自己管理型であるというのは、実はなかなかイメージがしづらいように思います。

続きを読む

スクラムチーム(Scrum Team)は、プロダクトオーナー(PO)とスクラムマスター(Scrum Master)がそれぞれ1名ずつと、数名の開発者(Developers)からなる小さなチームです。

スクラムガイドの図解:スクラムチームの構成とプロダクトゴール

Scrum.orgスクラムガイドによると、スクラムチームについて次のように書かれています。

スクラムの基本単位は、スクラムチームという⼩さなチームである。
スクラムチームは、スクラムマスター1 ⼈、プロダクトオーナー1 ⼈、複数⼈の開発者で構成される。
これは、⼀度にひとつの⽬的(プロダクトゴール)に集中している専⾨家が集まった単位である。

https://www.scrum.org/resources/scrum-guide

はじめてスクラムをやってみるときには、まずここが難しいですよね。

続きを読む

YouTube 動画に登場する(予定の)、Blender を使って作成した3DCGキャラを紹介するシリーズです。

5人目は Shiori Kashiwagi(柏木 史織)さん、女性のキャラクタです。

続きを読む

Blender でレンダリングした画像・動画を素材として使うには、背景を透過(透明)にしたいです。

デフォルトだと背景はグレーでレンダリングされます。地面を透明にして影だけレンダリングするのも追加の設定が必要です。たいていの場合、これらの手順は最初に全部用意してしまって、そのファイルを使ってずっと作業をしているので、私はこの手順を覚えられなくて毎回調べているような気がします。そこで今回は、この手順をちゃんと記録しておこうと思います。

この方法は執筆時に Blender 3.5.0 で使用しています。

続きを読む

Blender のバンプマップは面がザラザラしてしまうので、より滑らかに表示されるノーマルマップを使いたいのですが、私はノーマルマップを直接描くことが出来ません。そこで、バンプマップを描いた後、バンプマップからノーマルマップを変換して作りたい!と思います。

この画像は Blender 3.5.0 の Eevee でレンダリングしました。

続きを読む