jiigのREDOブログ

やったことや考えたことなどを不定期に書き残していきます

スクラムの進め方補足

認定スクラムマスターになり、社内でも実践したり勉強会を開催したりするなかで気になって調べたこと、勘違いしていたことなどを整理して備忘録として残しておくことにした。

 

スプリントレビューについて

プロダクトオーナーにお披露目するのではない。プロダクトオーナーがステークホルダーにお披露目する場。

受入条件(Acceptance Criteria)の確認はすでに終わっていて、Doneの定義を満たしているものをお披露目することになる。

プロダクトオーナーによる確認は、スクラムチームの一員として、随時行っているべきもの。

スクラムガイドにちゃんと書いてありました。よく読まないといけないですね、、)

品質について

社内でよく聞かれるのが、「品質はどう確保するのか?」ということです。

アジャイル開発は品質が悪くて、ウォーターフォールなどの重量プロセスは品質が良いモノができる、というのは誤りです。これは、Doneの定義を明確にして、ちゃんと運用しておけばよい。

とりあえず動くレベルのものをスプリントのインクリメンタル(成果物)としてしまうと、この問題が起こる。もちろん、プロダクトのフェーズや特性によっては、とりあえず動くレベルをスプリントのインクリメンタルとすることもあり得るが。

受入条件と完成(Done)の定義について

受入条件は、個々のバックログアイテムの満たすべき要件(主に仕様面)。完成の定義は、プロダクトバックログやインクリメンタルが、何を持って「完成」とするかプロジェクトルールとして定めたもの。つまり、バックログに関していうと、“受入条件を満たしていること”とか、“受入条件を満たしていることをプロダクトオーナーが確認済みであること”とかが含まれる。それに加えて、“ソースコードと、対になるテストコードがコミットされていること”だったり、“〇〇仕様書に仕様が反映されていること”なんかを完成の定義に含めることもある。

つまり、完成の定義をどう定めるか、がスプリントのインクリメンタル(および付帯するドキュメントなど)の品質に大きく影響する。

単に作るだけ、を考えたときと、完成の定義を満たすレベルを考えたときとでは、スプリントで実装できるバックログの量が大きく違ってくるので注意が必要。

スクラムのはじめ方

プロジェクトでスクラムを採用した場合、実はいきなりスプリントが開始することはない。なぜかというと、初期のプロダクトバックログがまだ無いはずだし、完成の定義も定まっていないから。

まずは、準備期間やスプリントゼロ、という位置づけで、これらを整える必要がある。

こちらのブログエントリでも少し触れました。アジャイル開発における初期設計について - jiigのREDOブログ

最低限やっておくべきことには、以下のようなものがある。

 

他にも出てきたら書き足していきたいと思います。

アジャイルソフトウェア開発宣言をかみくだく

アジャイルソフトウエア開発宣言は短い文章で完結に表現したがゆえに、ともすると誤った理解につながるため、自分なりに補足したメモ。

原文

日本語

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは
以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、
私たちは右記のことがらにより価値をおく。

Kent Beck,Mike Beedle,Arie van Bennekum,Alistair Cockburn,
Ward Cunningham,Martin Fowler,James Grenning,Jim Highsmith,
Andrew Hunt,Ron Jeffries,Jon Kern,Brian Marick,Robert C. Martin,
Steve Mellor,Ken Schwaber,Jeff Sutherland,Dave Thomas
© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。

英語

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Kent Beck,Mike Beedle,Arie van Bennekum,Alistair Cockburn,Ward Cunningham,Martin Fowler,James Grenning,Jim Highsmith,Andrew Hunt,Ron Jeffries,Jon Kern,Brian Marick,Robert C. Martin,Steve Mellor,Ken Schwaber,Jeff Sutherland,Dave Thomas

© 2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.

 

かみ砕いてみた

個人的に気になるのが、より価値をおくことがらの4行の部分。

Individuals and interactions over processes and tools

『個人と対話を』となっているが、withではなくandなので、individuals との interactionではなく、〜およびとか〜というニュアンス。interactionも対話というより、(対話も含む)交流とか相互作用とかのほうがしっくりくる。

Working software over comprehensive documentation

『動くソフトウェア』という訳について、誤解してしまいそうだが、executableとかrunningではなく、workingなソフトウェアです。なので、きちんと動く、機能するという意味合いが含まれていると思います。イテレーションの途中では、『なんとなく』動く、『とりあえず』動くソフトウェアで確認をしつつも、イテレーションの成果物としてはきっちりと『working』ソフトウェアに仕上げるということだと、思っています。

 

というわけで、“アジャイル開発では、とりあえずでいいから動くものをどんどん作って、品質は後回し”、という誤解(私の周りにはそう思っている人がいる)は、日本語版の訳から生まれているかも、という話。

アジャイル開発における初期設計について

ほぼ自分向けのメモ。

アジャイル開発と設計

もともと、アジャイル開発(私の場合はスクラム)やるとき、データベース設計っていつやるんだろう?と思ったのがきっかけです。 データベース設計も、スプリントのたびに考えるのかなぁ、でもそれはさすがにやばそうだなぁという感触があって、実際のところ答えは無いけど今の見解、というか個人的な気持ちを書いてみた。 高リスク制約という考えがあるらしい。それによると、以下のようなことは「とりあえずやっておいて、あとから考えよう」とした場合に高くつくよ、ということ。

データモデリングは最初に考えておくべき。ただし、完全なデータベース設計というよりは、概念データモデルレベル。 エンティティと関連、多重度のモデリングすることで、対象ドメインの整理・理解を助けることにもなる。

スプリント0

で、スクラムではスプリントを開始する前に、準備期間としてスプリント0(ゼロ)という期間を設けて、上で述べたような意思決定をしたり、技術的な調査(スパイクという)をしたり、初期のプロダクトバックログを用意したりすることがプラクティスとして存在している。 スプリントゼロで明らかにすること、決めておくことはプロジェクト問わずある程度共通にできそうなので、リスト化しておくと良さそう。

余談。ER図作成ツールだと、そもそも論理モデルと物理モデルを分けることができないものが多く(私の使った事のある範囲では)、RDBMSの制約によって必要になる「関連テーブル」まで定義することになるので困る。

これからはフルスタックエンジニアとマルチロールエンジニアになりたい

自分自身のキャリアについて、何かにすごく特化した専門分野があるかって考えたとき、個々のスキルで見たらどれも超一流では無いかもなって悩んだ。

でも、IT系の新規事業開発を考えたら、霧が晴れた気がした、そんな話です。

エンジニア→フルスタックエンジニア→マルチロールエンジニアという道です。

フルスタックエンジニア

フルスタックエンジニアとは?

システム開発のすべてを自分ひとりで行えるエンジニアのこと。

システムエンジニア、ネットワーク、データベース、サーバー構築、アプリケーション開発(フロントエンド+バックエンド)

要件定義から設計、実装、テスト、リリースを、すべてやれるエンジニアのこと。

自分に当てはめてみる

要件定義から設計、実装までひととおりやれる。スペシャルでない部分もあるができないフェーズはない。

フロントエンド開発→Vue.js、Bulma

バックエンド→ Node.js 、AWS Lambda

データベース→大好物。OracleMaster、データベーススペシャリスト

インフラ、ネットワーク→AWSネットワークスペシャリスト

モバイル→Android開発

デスクトップアプリ→C#.NET

うーん、ハードに近いところは難しい(RaspberryPi、Arduinoにセンサーつなぐレベルが限界)が、わりとカバーしている気がします。

マルチロール

エンジニアという職種を越えた活動。

企画、マーケティング、ユーザーインタビュー、営業、+エンジニアリングと、なんでもやれる人。

自分に当てはめてみる

これらの実践する中で、必然的にマルチロールになってきた。

単一のスペシャリストでは無い道。

新規事業をやろうとすると、最初のうち、Product/Market Fitまではコスト的にもコミュニケーション的にも、小さいチームで進める方が良い。スピードも出る。

意思決定に関わる人、邪魔する人、説明をしなければならない相手が少ないほど早く進めることが出来る。体制×期間が人件費やらの形でコストに直結するので、同じコスト内でより多くの仮説検証を回せる。

そう考えると、新規事業開発にこそ自分のスキルセットや経験が活かせると思うし、そこに必要な知識とスキルを備えれば、それはそれでスペシャリストだなぁという結論で腹落ちできた。これからの当面はそこを目指して必要なスキルを獲得していこうと思います。

 

同じような話を、私が一方的にリスペクトするi2keyさんのブログで見つけました。

ビジネス貢献するためのエンジニアリングの話をデブサミでしてきた #devsumi - @i2key のBlog

読書記録

せっかく読んだ本を少しずつ記録として残しておこうと思います。

2019/01/19 更新

 

ユーザーストーリーマッピング

ユーザーストーリーマッピング

ユーザーストーリーマッピング

 

新規事業をリーンスタートアップを参考に進めていて、プロトタイプやらMVP開発なんかのシステム開発スクラム導入後し始めたとき、ユーザーストーリーの書き方とかもやもやしたので読んだ本。

すごく良著。

 

amazon 世界最先端の戦略がわかる

amazon 世界最先端の戦略がわかる

amazon 世界最先端の戦略がわかる

 

Amazonのビジネスについてはある程度知っているつもりだったが、まだまだ甘かった。意図してなのか結果的になのかは分からないが、事業戦略としてすごく興味深い示唆がたくさんある。

 

アントレプレナーの教科書

アントレプレナーの教科書[新装版]

アントレプレナーの教科書[新装版]

 

リーンスタートアップ関連をざっとまとめて勉強した。そのうちの1冊。

いろいろ読んで自分なりに理解を深めるのが1番だとは思っているが、最小限で、となると、この本+『RUNNING LEAN』を読んだあと、『起業の科学』に進むのが良いと思っている。

 

起業の科学

起業の科学  スタートアップサイエンス

起業の科学 スタートアップサイエンス

 

なんというか、リーンスタートアップ全部入り、とい感じである。著者もそう言っているとおり、いろんな本を読んだが、スタートアップの全体を体系的に網羅したモノが無かったので、スライドにまとめた、とある。この本はそれらスライドの書籍版。

概念よりも、かなり具体的なやり方を中心に記載されているので、何度も参照しながら社内の新規事業開発を進めている。

 

リーンスタートアップシリーズ

リーン・スタートアップ

リーン・スタートアップ

 
Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

 
リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES)

リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES)

 
Lean Analytics ―スタートアップのためのデータ解析と活用法 (THE LEAN SERIES)

Lean Analytics ―スタートアップのためのデータ解析と活用法 (THE LEAN SERIES)

 

最初にRUNNING LEANを読み、興味を持ったのでその他シリーズも読み進めた。

青本リーンスタートアップと、RUNNING LEANで全体像をつかんだあと、顧客発見あたりは『リーン顧客開発』を参考にインタビューを実施し、Problem/Solution Fitを達成してMVPを有償で提供するあたりから、『LEAN ANALYTICS』を参考にKPIを追いかけるイメージで考えている。

正直、初めて読んだときはLEAN ANALYTICSは理解できなかった。だが、リーンスタートアップを読んで革新会計を学んだあとで再読すると、しっくりきた。

 

カイゼン・ジャーニー

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

 

アジャイル開発(スクラム)を社内で少しずつ導入した著者の経験に基づくリアルなストーリー。すごく共感できるし、これを読んで、自分もまずは小さいところから始めないと、と思うきっかけになった。

あと、ギルドワークスさんのサイトにいろいろ共感

Vue.jsでHighchartを使う(しかもビルドシステムなしで)

サンプルとかあまり見つけられず、苦労したので備忘録としてメモしておこうと思います。

highchart vue.jsラッパーを入手

まず、Highchart公式GitHubリポジトリから、highcharts-vueを入手する。リポジトリ丸ごとダウンロードかcloneするが、使用するファイルは、 「highcharts-vue-master/dist/script-tag/highcharts-vue.min.js」だけです。 ※dist/module/配下にあるやつは、モジュールとしてロードする用です  (普通はこっちを使うと思いますが、今回はタイトルにもあるとおり、ビルドシステムを使わず、htmlファイルからscriptタグで読み込むので。。。)

GitHub - highcharts/highcharts-vue

index.html(本体のHTML)

bodyタグの最後で、以下の順でスクリプト読み込み。

new Vue() する前に、Vue.useでプラグインを登録する。書き方に注意が必要です。

Vue.use(HighchartsVue.default);

※HTMLのscriptタグで読み込んでいるので、Vue.use(HighchartsVue)ではダメです

グラフ描画に関して。 Highchart公式には、さらっと1ページ書いてあるだけ(しか見つけられていない)。

Highcharts Vue Wrapper - Highcharts

こんな感じになるらしい

data() {  
  return {  
    title: '',  
    points: [10, 0, 8, 2, 6, 4, 5, 5],  
    chartType: 'Spline',
    seriesColor: '#6fcd98',
    colorInputIsSupported: null,
    chartOptions: {
      chart: {
        type: 'spline'
      },
      title: {
        text: 'Sin chart'
      },
      series: [{
        data: [10, 0, 8, 2, 6, 4, 5, 5],
        color: '#6fcd98'
      }]
    }
  }
},

ここで、chartOptionsが、チャート描画に使用するデータです。 ただし、vue.jsラッパーのポイントとして、pointsと、chartOptions.series[0].dataとに同じ値が入っている。 使い方としては、直接chartOptionsを触らずに、いったんpointsにグラフデータをセットする。pointsの変更をwatchして、変更後の値をseries.dataに代入することで、リアクティブにチャートが更新されます。。 この辺は、Chart.jsのVueラッパーであるvue-chart.jsとはアプローチが異なるので、最初は少し悩みました。 vue-chart.jsでは、mixinしたうえでreactivePropやらを使うので、どっちが分かりやすいかというと人それぞれかなぁ。

認定スクラムマスター(LSM)になりました

Scrum Inc. 認定スクラムマスター研修というものを受講してきました。さらに、そのあと受験できる試験に合格して、認定スクラムマスターとなることができました。

動機としては、独学オンリーのなんちゃってアジャイルなままではなく、きっちりと理解したものを社内外に導入したかったからです。

 

認定スクラムマスター

スクラムマスターの認定資格には、Certified Scrum Master(CSM)というものと、Licensed Scrum Master(LSM)があります。他にもあるかも知れません。CSMのほうが昔からあるようで、日本ではスクラムマスター資格というと、こちらの方が多いようです。これからはLSMが多くなりそうですが。

LSMは、スクラムの創案者のひとりであるJeff Sutherland博士により設立されておりScrum Inc.という会社が提供しています。

Scrum Inc. Japan #TeamworkMakesTheDreamWork

 

スクラム

用語説明や詳細はたくさんサイトがあるので、簡単に自分のリマインドとして書いておく。

スクラムチーム

プロダクトオーナー(PO)、スクラムマスター(SM)、チームメンバーで構成する。

スクラムチームにとって大事なことは、自己組織化機能横断的である、ということ。

自己組織化

チームが誰かに管理されているのではなく、自らを管理できていること。進捗や課題の管理、プロセス改善などの活動を自分たちで適切に行えていること。

スクラムマスターは、プロジェクトマネージャやプロジェクトリーダーのように管理をするのではなく、チームメンバーが自分たちで管理できるように促す。

機能横断的

スクラムチーム外の誰かに頼らずにバックログをDONEにできるチームであること。また、チーム内での役割も完全な縦割り専任主義ではなく、T字型に役割を担えることが理想(コーディング担当、テスト担当とか専任にしない)。

これは、現実はなかなか難しいなーと感じました。やっぱりコーディング出来ない人はホントにできない(やろうともしない)ので。。

ただ、機能横断的であることが理想的なことは理解、共感できる。

プロダクトオーナー

プロダクトの仕様決定者。複数人いないほうがよい。どうつくるか、ではなく『何が欲しいか』をプロダクトバックログとして定義する。

自社プロダクトではない受託開発の場合、顧客側の人間がプロダクトオーナーになるか、もしくは顧客側の要求を深く理解しているメンバーが担当する。スクラムマスターとの兼任は避ける。

スクラムマスター

スクラムがうまく機能するように支援する役割。スクラムについては一番詳しく、プロダクトオーナーやチームメンバーをコーチする(開発そのもののコーチではなく、スクラムのコーチ)。

スクラムマスターはメンバーを兼任しても良い。

プロセス

スクラムでは、スプリントいう単位で価値創造をくり返しながら漸進的に開発を進める。各スプリントの期間(長さ)は固定化する。最長でも一カ月。チームによっては、半日スプリントという短さでやっているところもあるらしい。

スクラムでは、さまざまな活動にタイムボックスという概念で制限時間を設定している。

 

スクラムイベント(活動)

スクラムにはいくつかのイベント、活動が定義されている。さらに、それぞれについてタイムボックスが決められている

  1. スプリントプランニング
  2. デイリースクラム
  3. スプリントレビュー
  4. スプリントレトロスペクティブ
  5. プロダクトバックログリファインメント
  • スプリントプランニングでは、そのスプリントで実現するバックログをピックアップする。選択したプロダクトバックログアイテムと、それらを届ける計画を合わせてスプリントバックログという。
  • デイリースクラムは、前日の作業、本日の作業の確認を行う。抱えている課題や、乗り越えた課題なども共有する。毎日同じ時間と場所で行い、リズムをつくることが大事。
  • スプリントレトロスペクティヴ(振り返り)では、改善案を出し合い、次のスプリントで実施する案を決める。さらにそれをスプリントバックログに加える
  • プロダクトバックログリファインメントとは、スクラムガイドに以下のように定義されている。

プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プロダクトバックログのリファインメントと呼ぶ。これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスである。プロダクトバックログのリファインメントによって、アイテムのレビューと改訂が行われる。いつどのようにリファインメントをするかは、スクラムチームが決定する。リファインメントは、開発チームの作業の 10%以下にすることが多い。

タイムボックス早見表

スクラムガイドでは、タイムボックスは一カ月をベースに記載されており、逆算すると以下のような配分となる(使って良い時間の最大値)。

  • デイリースクラム:15分(固定)
  • スプリントプランニング:5%
  • スプリントレビュー:2.5%
  • スプリントレトロスペクティブ:    1.875%
  • プロダクトバックログリファインメント:10%
スプリント期間ごとの早見表
スプリントが一週間の場合
  • デイリースクラム:15分
  • スプリントプランニング:2時間
  • スプリントレビュー:1時間
  • スプリントレトロスペクティブ:45分
  • プロダクトバックログリファインメント:4時間
スプリントが二週間の場合
  • デイリースクラム:15分
  • スプリントプランニング:4時間
  • スプリントレビュー:2時間
  • スプリントレトロスペクティブ:90分
  • プロダクトバックログリファインメント:8時間
スプリントが一カ月の場合
  • デイリースクラム:15分
  • スプリントプランニング:8時間
  • スプリントレビュー:4時間
  • スプリントレトロスペクティブ:3時間
  • プロダクトバックログリファインメント:16時間