FJORD BOOT CAMPでスクラム開発のプラクティスを終えることができました
はじめに
あいも変わらずFJORD BOOT CAMPで粛々と勉強を続けている私ですが、先日スクラム開発のプラクティスで最後のPRにOKをいただけたので、無事スクラム開発プラクティスを完了することができました。
記録を見ると2月からスクラム開発のプラクティスに参加したので、終了するまでに約3ヶ月間かかってしまいました。
スクラム開発のプラクティスを振り返ってみると、失敗したと感じることや、もっとこうしていればと感じることが多かったです。 今後実務に当たった時に、改善できるようにするために、まとめたいと思います。
スクラム開発のプラクティスの流れ
まず、前提としてどのような流れでプラクティスが進んでいくのかということをお伝えしておきたいと思います。
以下が現在、FJORD BOOT CAMPで使われているアプリです。 このアプリ上で受講生は勉強を進めていきます(日報を書いたり、提出物を出したり、Q&Aを書いたりなどです)。
そして、プロジェクトメンバー各人にissueが割り振られます。issueはプランニングポーカーで、プロジェクトメンバー全員でポイントを見積もります(このポイントというのは、ブートキャンプのプロジェクトでは、完成までにかかる時間と定義されています)。
そのポイントが20ptになれば、このプラクティスを終えることができます。
最初はアプリ上の文言の修正などといった小さい変更を積み重ねて、プロジェクトに慣れた頃にどんどんと割り振られるissueがレベルアップしていきます。
このプラクティスで出したPR一覧
以下が私が出したPR一覧になります。
自分の反省点とそこから学んだこと
デモの準備は入念に行うこと
スクラム開発のプラクティスでは、1週間(1イテレーション)に一度振り返りミーティング、計画ミーティングが行われます。
ここでは、プロダクトオーナー(非エンジニア)に向けて、このイテレーションにおける自分の成果をデモしていきます。ここでの成果を上手く伝えられるかどうかが自分の評価に直結するところだと思うので、とても重要な場だと理解しています。
しかし、実際に自分の実装をデモした時にバグを発見してしまったことがありまして、「やってしまったー」と天を仰いだことがあります。
そのため、そのようなことを2度と繰り返すまいと、デモで話す内容、手順をメモしておき、リハーサルを行うなど、デモの準備をより入念に行うように意識するようになりました。
考えるべきはチームとしてのベロシティをいかにして上げるのかということ
スクラム開発のプラクティスの中で、私はチームとしての意識を持つことがあまりできませんでした。
具体的にどういうことかというと、自分に割り振られたissueは「自分の力だけでやらなければ」と強く思いすぎてしまい、他の方にヘルプを求めることが遅くなってしまったということです。
issueに取り組んでいる中で、チームとしてベロシティを高めようと考えるのであれば、自分の分からないところ、悩んでいることはチームのメンバーに教えてもらったりして開発に取り組んだ方が自分のissueの解決速度が上がります。
自分のissueの解決速度が上がるということは、チームのベロシティが上がるということです。
そのことを考えることができませんでした。全て自分の力で理解、解決しようと思いすぎてしまい、ヘルプを出すことに抵抗感がありました。
それが原因で、一つのissueを解決するのに何イテレーションもかかってしまったため、個人ではなくチームとしての意識を持っていきたいと思いました。
自分が全く分からないことは、分かる人に教えてもらうことが大切
これは上記のベロシティを上げるというところにも関係しているのですが、自分が全く何も分からないところについて質問する際に、「分からないことは自分である程度理解してから質問したい」と強く思っていました。
具体的には、「分報機能がほしい」というissueでAction CableとVue.jsという2つの分からない技術があったのですが、これがある程度分かるようになるまで1ヶ月ほどかかってしまいました。
そのため、これらの技術が分かる人に概要を聞いたり、参考になる資料を教えてもらったりすることで、技術を理解する時間を短縮することができたのではないかと思います。
私は「まとまりのない質問をしてはならない」、「自分の仮説がない状態で質問してはいけない」と思ってしまいがちなのですが、やはりチームとしてのベロシティを上げるという観点からは、そのような考えは一旦置いておいて、他の人にヘルプを求めるという方が良いのかもしれません。
実装の方針の確認をもっとしてもらえば良かった
振り返ってみると、途中経過の段階でコードを見ていただくことをお願いしたり、実装の方針の確認をお願いしたりということをしていませんでした。
それにより、実装方法について自分の頭の中だけでグルグルと悩んでしまった時間が非常に多いと思いました。
そもそも、自分のように経験がない中でグルグルと悩んでもベストプラクティスなんてものは一生わからないので、悩むようであれば、実装の方針の確認をしていただくべきでした。
扱う技術については、シンプルな環境で動かして概要を把握してから実装する
「分報機能がほしい」というissueの中ではAction CableとVue.jsを用いて実装することが固まっていました。
特にAction Cableについては触ったことがなかったので、自分の手元でシンプルなチャットアプリを作ってみて概要を理解するように努めていましたが、肝心のVue.jsとの連携については理解していませんでした。
「Vue.jsは触ったことがあるからなんとかなるだろう。Action Cableとの連携については少ないながらも参考記事があるからなんとかなるかも」とタカを括ってしまっていました。
しかし、実際に連携させようとした時に、Vue.jsについての理解の浅く、Action CableとVue.jsの連携のさせ方が全くピンときておらず、長時間ハマってしまうこととなりました。
いきなり、複雑なソースコードの中で連携させようとするのではなく、自分の手元でAction CableとVue.jsの連携のさせ方を把握してから、ソースコード上に書いていくという手順を踏んだ方が効率が良いと実感しました。
最後に
総じて、チームで開発するということが全然意識できていなかったということが反省点です。
自分の開発スピードを上げるということは、チームのベロシティを上げるということ。チームのベロシティを上げるためには何をして、何をしない方が良いのかということまでを考えられませんでした。
このプラクティスで学んだこと、反省点を改善して、実際の現場でチームに貢献できるようなプログラマーになりたいと強く思いました。
