ハッカソンでボロボロにされた話2
ハッカソンでボロボロにされた話の続きです。
前回書いた時形式を決めないで自由に書いてしまったため、何を言いたいのか明確ではありませんでした。
今回からその辺りを意識して相手に伝わりやすいように書くことを目指します。
前回モチベーションのことだけを書いたので今回は個人的な反省点を述べていきます。
ハッカソンでの反省
目次
- タスクの振り分け
- 要件定義の甘さ
1.タスクの振り分け
まず自分たちが初心者であるにもかかわらず、話し合いがあまりにも少なかったのです。
その上で1日半という時間制限がある中、1人1つの画面を担当しようと決めてしまいました。
その結果メインの画面1つ、サブの画面3つと分けていることでそれぞれの画面の進捗に差が出てしまいます。(5人いますがもう1人はかなり技術力が高いのでサポーター役です。)
メイン画面のほうがタスクの量が多いため時間が足りないまま時間オーバーとなってしまいました。
自分がやる!といったのに量が多いため1人ではやりきれなかったです...。
じゃあどう改善すればいいのか。
そこでタスクの細分化です。
1人一画面なんて大きすぎます。
であれば、まずはメイン画面の機能をWBSで分析し、タスクの振り分けをしたら効率が上がったのかと...。
この反省を活かして....
今制作中のアプリではWBSを使ってエクセルにまとめて共有してあります。
タスク名、優先度、担当、工数など....決めてアジャイル開発で行なっています。
2.要件定義の甘さ
要件定義は1番目に書いた内容とだいたい同じですが、
これはハッカソン絶対勝つマンの大先輩から助言を頂いたので忘れないうちにアウトプットしておきます。
自分たちは話し合いが少ないと上記で述べました。
これは本当に重要で、ハッカソン絶対勝つマンの大先輩は(大会によって異なりますが)5、6時間使ってでも要件定義をしっかり決めるそうです。
他のチームが開発し始めていても話し合いをしているそうです。
それでは開発する時間がないのでは?!
それを考慮した話し合いだそうです。
そして今回の自分たちが考えたアプリでは問題提起が弱かったと思います。
また、自分たちの改善点はしっかり話し合いした上で要件定義をし、タスクの振り分けをする事で上手くいったのかと思います。
しかし、要件定義ほど重要なものはないなぁと今回にハッカソンでは実感しました。
Fuya