0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

1人でアジャイル開発やってみる(Sprint4とりあえず完成)

Last updated at Posted at 2022-03-07

前回はナビゲーションバーによる導線の確保とゲームの拡充を行いました。
今回はクイズの拡充とトップページの構築を行います。そこまでできればひとまずサービスとしては最低限の形を成すかと思いますので、今回のスプリントで開発いったん終了としようと思います。

今回できたプロダクト

今日のアイスブレイク(最新)
今日のアイスブレイク(Sp4終了時点)

前回のスプリント後に

前回のスプリント完了後に職場の人に作ったアイスブレイクアプリを見てもらいました。ほとんど時間がなかったので十分意見をもらえなかったのですが、アイスブレイクのネタを探す画面(一覧画面など)がないのがイメージつきづらいようだったので、今回そのバックログの優先順位を上げました。

スプリントプランニング

今回は開発3件、トータル9ストーリーポイントです。
image.png

クイズを出題できる(複数フリー回答式)

出題できればOK。データ作成だけなので10分

クイズの答えを1つずつ見られる(複数フリー回答式)

例えば好きなカップラーメンランキングTOP10をお題として、回答者はそれを当てる。当てたパネルを空けることができる。「テーブル形式で答えを表示する」「1つずつ回答を開く」という2つができれば、ほかは既存の仕組みが使えそうです。40分

アイスブレイクネタの4つ見られる

・画面上に4つのアイスブレイクネタが表示される
・表示されているアイスブレイクネタを押下すると詳細画面に遷移する
90分

アイスブレイクの一覧をランダムにみられる

・表示はランダムで完全に同じネタは表示されない
・ボタンを押すと表示内容を更新
60分

※上で貼ってあるボードとバックログが違うじゃん、と思った方。最初は以下のバックログにしていたのですが、結構大きな対応になりそうだったのでバックログを分割しました。こんな風にバックログの分割は積極的に行うべきです。通常はリファインメントで行うことが多いですが、今回はリファインメント後に優先順位を上げたので分割するタイミングがプランニングになりました。
 スクラムイベント外の出来事で優先順位が変わるのはイレギュラーですが、スプリントレビューを行った結果、優先順位が変わることは往々にしてあります。

アイスブレイクの一覧をランダムにみられる

受入条件としては以下の通りとします。
・画面上に4つのアイスブレイクネタが表示される
・表示はランダムで完全に同じネタは表示されない
・ボタンを押すと表示内容を更新
・表示されているアイスブレイクネタを押下すると詳細画面に遷移する

その他

プランニング15分+リリース10分の25分見込みです。
最後のスプリントにしようと思うのでリファクタリング、レビュー、レトロはなしにします。次回の記事で前回を振り返ることはしようと思います。

トータル3時間50分です。

クイズを出題できる(複数フリー回答式)

出題できればOKと記載しましたが、ナビゲーションバーにも表示される必要がありますね。前回対応したバックログによる影響をこの爆ログに反映できていませんでした。
今回のは大した修正じゃないのですが、実開発で発生すると結構ハレーションでかいことがあります。とはいえ最初にすべてを見込んでおくことはできないので、開発後期に進むにつれてこの手のリスクが発生しやすくなることを見込んでおく必要があるかと思います。

ナビゲーションバーの出来上がりはこんな感じです。複数回答式としていましたが、ランキングを当てるという内容に変更しました。
image.png

クイズの答えを1つずつ見られる(複数フリー回答式)

これは思っていたより簡単にいきました。やはりデザインライブラリ入れているとまだ扱っていないUIを作るのも簡単でいいですね。
image.png

アイスブレイクネタの4つ見られる

ゲームを4つ表示するようにしました。
image.png

苦戦した点

以下のエラーが発生することがありかなり苦戦しました。結局原因は4つのネタを表示するために4回Firebaseにデータを取得に行っているのですが、非同期処理が4回流れるため実行順序によってエラーとなっているようでした。
3回目まではレンダリングさせないようにして、4回目のデータ取得が完了したタイミングでレンダリングするように修正したらエラーが発生しなくなりました。

client.js?06a0:103 TypeError: Cannot read properties of undefined (reading 'title')
    at eval (index.vue?4d15:187:1)
    at Proxy.renderList (vue.runtime.esm.js?2b0e:2646:1)
    at Proxy.render (index.vue?4d15:184:1)
    at VueComponent.Vue._render (vue.runtime.esm.js?2b0e:3569:1)
    at VueComponent.updateComponent (vue.runtime.esm.js?2b0e:4070:1)
    at Watcher.get (vue.runtime.esm.js?2b0e:4495:1)
    at Watcher.run (vue.runtime.esm.js?2b0e:4570:1)
    at flushSchedulerQueue (vue.runtime.esm.js?2b0e:4326:1)
    at Array.eval (vue.runtime.esm.js?2b0e:1989:1)
    at flushCallbacks (vue.runtime.esm.js?2b0e:1915:1)

アイスブレイクの一覧をランダムにみられる

出来上がりは以下の通りです。
image.png

苦戦した点

 これが意外と苦戦しました。というのも実装する際に「クイズ」「ゲーム」「ランキング」はある程度共通化しつつも実装を分けており、データの保有の仕方に関しては共通化を図っていません。スプリントごとの断面を残したかったため、「ゲームのデータを追加すると、前スプリントのナビゲーションバーにもゲームが表示されてしまう」といったケースを避けるためある程度冗長なつくりにしていました。
 通常の開発では同じケースは発生しないでしょうが、リファクタリングは常について回る問題です。アジャイル開発では全体最適化した状態で開発が始まるわけではないので、ウォーターフォールと同様の考えでリファクタリングを軽視していると、初期リリース時点で10年は保守したんじゃないかというような負債を抱えていることすらあります。個人的には技術的負債を積まない取り組みはウォータフォールよりもシビアに考えるべきだと思っています。

その他

リリース

以下のサイトをリリースしました。
http://ay5399.e2.valueserver.jp/sp4/

終わりに

今回はランキングを当てるゲームをできるようにし、トップページを作成しました。まだまだプロダクトとしてはやりたいことがたくさんあるのですが、もともとNuxt.js / Vue.jsの学習として始めたことだったのである程度目的は満たせたかと思いますというかそろそろ飽きてきた。開発は続けるかもしれませんが定期的に記事を更新するのは次回が最後になります。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?