「すくすくスクラム仙台　スクラムの始め方」に参加してきました！

はじめに

おばんです、どうも初めまして、仙台在住の田中賢治です！
この度ゲストとして投稿させていただきます。
普段は学生をやっている傍ら、iOS開発で知り合いの方からバイトをいただいて生きていたりします。

そんなワタシは今度の春から新社会人。

「これまでプログラミングは学生時代にやってきたけれど、仕事の進め方に関してはよくわからない...。」
「職場では"アジャイル"や"スクラム"といった方法で仕事を進めているらしいけれど、よくわからない...。」
「早く慣れたい、不安だ！」

そんな不安な気持ちをちょっとでも払拭すべく！
2016-02-04(木)に仙台で開催された「すくすくスクラム仙台　スクラムの始め方」に参加してきました！

 

すくすくスクラム仙台とは？

すくすくスクラム仙台

『すくすくスクラム仙台』は、複雑なプロダクトを開発・維持するためのフレームワークである「スクラム(Scrum:名詞)」を中心に、現場改善のヒントを探求するコミュニティです。
体験による気付きやリアルな現場での知見を参加者のみなさんと共有することを主眼としています。

すくすくスクラム仙台より引用

仙台のスクラムコミュニティです。

言い出しっぺとして認定スクラムマスター、認定スクラムプロダクトオーナー、認定スクラムプロフェッショナルである、半谷 充生(@bangucs)さんがファシリテーター・運営等なさっています。

 

木曜開催だったので、木曜日の猫

今回はビールを飲みながら、自由に意見を交し合う素晴らしいスタイルでした。
スクラムの始め方というテーマでしたが、スクラムとは？という説明からのスタートだったので初心者に優しかったです！

 

スクラムとは？

スクラム（英: Scrum）は、ソフトウェア開発における反復的で漸進的なアジャイルソフトウェア開発手法の1つである。この方法論は「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと」とされる。

wikipediaより引用

ふむ、わからん

こういう説明を見てもちょっとわかりませんですが、参加してわかったこととしては

• スクラムはフレームワークである
• チームが密で素早く動けるのでプロジェクトの変化に強い
• 問題を早期に明るみに出すことを意識する
• 誰がいつなにをしているか、透明性を保つことを意識する

これらを一定のプロセスに基づいてまわしていくのがスクラムのようです。
以下では勉強会で説明のあったプロセスを見ていきます。

 

プロセス

まずスクラムには三つのロールが存在します。

Product Owner

プロダクトの方向づけや品質を管理する人で、実際のお客さんにやってもらうのが良い。
Product Backlogを管理する。
プロダクトを愛さなくてはならない。

Team

作業者。
ソフトウェア開発ではプログラマなど実際に作る人。

Scrum Master

スクラムがうまくまわるようにする人。
スクラムはScrum Masterがいなくともまわるようになることが理想的なので、最終的に「Scrum Masterはクビになって一人前」とのこと。

これを踏まえた上で、以下に6つのスクラムのプロセスを順を追って書いていきます。

1.Product Backlog

直列に並べられた優先順位順のタスクリストで、Product Ownerが管理します。
優先順位順なので上から順番にタスクを消化していきます。
一つ一つのタスクは「設計する」「コーディングする」という粒度のタスクではなく、具体的に「ログインができるようにする」「広告を表示できるようにする」くらいのもので、訓練されたスクラムほどこのタスクの粒度は細くなっていくそうです。
それこそ、コードレベルで「ログイン機能の実装でhogehogeフレームワークを使ってfugafugaなクラス設計をする」というところまで明確化するそうです。

2.Sprint Planning

Sprintというのは、一週間から四週間くらいで区切る一定の区間のことで、この区間ごとに振り返りをしたり製品をお客さんに見てもらったりします。
Sprint Planningはチーム全体で集まって、次のSprintでProduct Backlogの中のどこのタスクまでをこなすかを計画します。
先述した「問題を早期に明るみに出したい」というのはこのSprint Planningをチーム全体で決める際に懸念点を洗い出していくことで実現します。
また、チームが素早く動けるというのもこのSprintごとに区切って振り返りや方針転換をしていく仕組みによって実現します。

3.Sprint Backlog

Product Backlogの優先順位の高いものから1Sprint中にこなすものをそのまま棚卸ししてきたリストがSprint Backlogです。Sprint Planningでどこまでやるかというものがこれになります。

4.Daily Scrum

開発チームで集まって1日に一回、または半日に一回くらいのペースで行われます。
前回のDaily Scrumから現在抱えているタスクの進捗状況の共有や、少し困っていることを報告してそれに対して助けを求めたり、効率的に動けるようにします。
誰がいつなにをしているか、透明性を保つことに役立ちます。

5.Sprint Review

Product Ownerにリリース可能な状態の製品を見てもらいます。
できたものでお客さんにドヤァする。

6.Retrospective

振り返り。
ここの振り返りを次のSprintで活かします。
1Sprintでこなすタスクの量はどうだったか、Sprint Reviewしてみてお客さんからの反応によって製品の方向性をどうしたほうが良いかなど。
ここまでで一通りのスクラムの流れとなります。
振り返りのあとはまた1から戻って次のSprintについて決めて、流れを繰り返します。

  こうしてまとめてみると、スクラムは細かい区切りをルールとして都度設けることによって方向転換や振り返りによる学習を素早く行っていくことが特徴のようですね！

その他話題に上ったこと

Q.Product Backlogのタスクに依存性がある場合はどうするの？

依存度順に解決していくか、タスクの切り方が間違っているのでそこを見直す。
タスクは解決したい問題、「◯◯ができるようになる」などの切り方をする。

Q.人によって遅いとか、人によって状況を報告してくれないとかがある

人を憎まず仕組みを憎め。
報告しやすいような雰囲気作りや仕組み作りはScrum Masterの仕事なので、そここそ腕のみせどころ！
それは進捗度合いを透明化できていないことに問題がある。

Q.受注でScrumってできるの？

できる。難しい場合は内部的にだけやったりもするけれど、できるだけお客さんを巻き込んでProduct Ownerになってもらうことが理想。

Product Backlogのタスクのサイズについて

タスクサイズは相対見積もりで決める。
なにか一つのタスクを基準を決めて、フィボナッチ数列の順で大きさを決める。
この時タスクサイズの単位は単に数字での扱いでも良いけれど、モチベーションアップのためにチームで共通認識をしやすいものに決めたりしても良い。
1ガ◯ダムとか3ザ◯とか。
でもチームの平均年齢が若いとガンダ◯がわからないので仕方なくエヴ◯になるという話も。w

相対見積もりにおけるスキル差について

相対見積もりをする時に新人と熟練では認識に差が出る。
「以前のプロジェクトではこれくらいだった」という基準からでも良いけれど、この時にあえてスキル差のある人同士でやると認識のズレを埋める機会になったり、熟練の人でも意識せずに多くのことをできてしまうがゆえに考えていないこともあったりするので、改めて考える機会を作ることになるので良い、という意見もありました。

受託でのスクラム

お客さんとしても「一括で請け負ってものを作ってもらったけどなんかコレジャナイ」ということが経験としてある。
だからこそ徐々に作りながら、ものをお客さんにも見てもらいながら進める方式を受け入れてもらえているという話がありました。

最後に

今回参加してみてスクラムがどんなものなのかがなんとなくわかりました。 チーム全体で振り返りの機会を多く持つようにしているのはコミュニケーションが必然的に増えて面白そうなのでやってみたいと思いました。

入社の折に先輩社員さんから「スクラムっていうのは・・・」と説明されそうになったら「ああ、スクラムですね、わかります（ﾄﾞﾔｧ」ってしたいですね！

今後実際にやってみる機会があればまたまとめてみようと思います！