- 買うものが決められない
- コンビニユーザー向けの
- カテゴリ別で話題になっている商品がわかる
- ホットアイテムです！
- 商品の人気度や感想を閲覧でき、
- ツイッターやブログとは違って
- コンビニPB商品一覧とその人気度が一目でわかります。
- 他のメンバーとの連携が「少し」できて嬉しかった。
- 「顧客への価値」と「優先度」がプロジェクト活動の基準として合意されていることは、重要事項に集中しやすいことが実感出来た
- 何の価値があるのかと疑問に思いながら作業することを抑止出来る良い仕組みと実感した
- 不毛な検討を将来のバックログとしていったん棚上げすることがしやすいのもメリットと感じた
- 本に書いてあるような一般的なプラクティスでもやってみるとどうすれば良いか混乱した
- 個人だけでなくチームとしての取り組みであり、enPitのような機会がないと試しにくい
- 8回チャレンジする機会があるのは学習としては取り組みやすかった
- 従来の仕事の仕方・文化と想像以上に乖離があり、習熟するためには実践するしかないと痛感した
- 同時にアジャイルコーチが必要とされる理由も個人的には納得出来た
- 「プロセスやツールよりも個人と対話」の意味と難しさ
- スプリント計画やフィードバック、また「自己組織化」をどうするか等の諸々の活動を通じて、変化するプロジェクトでチームとしての方向性、エネルギーを生み出すのは個人と対話というところは実感できた
- ただ、価値ある対話をするためには信頼感の醸成や合意されたコミュニケーション等、非常に難しいと改めて感じた
- そもそも「プロセスやツール」自体もその背景をチームとして理解・活用していくところには至れなかった
- PBLとしてインプットとアウトプットを同時に回して学びを最大化するよりも、目前のスプリントレビューの体裁を整えることに目がいきがちだったように思う
- スプリント計画やフィードバック、また「自己組織化」をどうするか等の諸々の活動を通じて、変化するプロジェクトでチームとしての方向性、エネルギーを生み出すのは個人と対話というところは実感できた
- レトロスペクティブを有効に機能させることは難しい
- KPTのような広く使われる振り返り手法を与えられても、チームとしての成熟度を高めるツールとして活用しきれなかった
- 対話が不十分だった、レトロスペクティブの活動自体への合意不足、ツールの理解不足ぐらいが原因の候補か
- 共通の組織文化を持たない即席チームでのレトロスペクティブは通常のチームよりも更に難易度が高いようにも感じた
- KPTのような広く使われる振り返り手法を与えられても、チームとしての成熟度を高めるツールとして活用しきれなかった
- 事前学習の扱い
- 事前学習期間において、RubyやRailsの学習しか提示されなかったがスクラムについても課題書籍を示す等あっても良いのでは
- 開始後に提示されるより事前に学ぶ時間がある方が学習効果を高めやすい
- 共通の前提事項が出来上がるためチームビルディングが多少スムーズになるのでは
- 特に短期合宿のインプット量は相当程度あったが、その負荷がイメージしにくく脱落やその消化不良がPBLの学習効果を引き下げる懸念要素となっているように思う
- 非エンジニア層がスクラム以前に技術レイヤーの学習に忙殺・混乱していた印象がある
- 事前学習期間において、RubyやRailsの学習しか提示されなかったがスクラムについても課題書籍を示す等あっても良いのでは
- インセプションデッキの紹介方法
- 全体的にスタートアップを想定した説明になっており、ユーザ企業やSIerの人には刺さりにくい説明だった印象
- 「アジャイルサムライ」のように、受注側と発注側に分かれて顧客をどう巻き込んでいくかという観点の紹介もあった方が、より多くの人に納得感がでると思う
- 特にAIITのように社会人層が多い場合
- 「アジャイルサムライ」のように、受注側と発注側に分かれて顧客をどう巻き込んでいくかという観点の紹介もあった方が、より多くの人に納得感がでると思う
- 全体的にスタートアップを想定した説明になっており、ユーザ企業やSIerの人には刺さりにくい説明だった印象
- スクラムの諸要素について実体験として理解・習得することが出来た
- 本での学習だけでは習得は難しいと感じた
- ユーザーフィードバックをもらいながらプロダクトを育てていくことが実感出来た
- 特に終盤にかけてチームの動きが急激に良くなっていった
- OSS系チーム開発っぽくなってきた
- リモートでチーム開発が出来る手応えを感じた（特に私は仙台からの参加だったので）
- 多種多様な人々と関わりながらの開発は刺激的だった
- GitHub等OSS系のエコシステムを用いた開発に慣れることがある程度出来た
- ユーザーにおける価値についてよく考えるようになった
- その時点時点でどうしたらチームとして最大の効果が出せるかをよく考えるようになった 相互レビューは技術学習としても効果的であることが実感出来た
- プロダクトとして良くなっていかない状況について、チームの方向性転換が遅すぎた
- 早急で細かなマネジメントが重要ということを学んだ
- 事前学習での技術的な底上げがもっと必要だったと感じた（メンバーによりアジャイル開発の体験として不十分だった印象）
- アジャイル開発手法を実体験を通して学ぶことにより、本だけの学習より深い知識と経験が得られた。
- モダンなWebアプリケーション開発のための基盤を活用した開発経験ができた。
- リモートワークが体験できた。
- プロダクトの価値をより高めるためユーザーフィードバックをもらいながら開発したことでよりプロダクトの価値を高めるマインドができた。
- よりユーザー目線を意識できるようになった。
- チーム開発での「自己組織化」の重要性を認識できた。
- 個人での技術的な事前学習が足りなかったため、チームへの貢献度が薄かった。
- チームの方向転換のタイミングを躊躇したことにより後手に回るケースが多かった。
- レトロスペクティブが有効に活用できなかった。
- 振り返りをしてもチームとしてうまく機能できなかった。
- もう少しプロダクトの計画と見積もり（プロダクトバックログ、ユーザーストーリマッピング）の時間が欲しかった。
- スタートアップよりの説明だったので、ユーザー企業向けや外部の開発会社を利用しているシーンでのアジャイル開発の導入事例などが欲しかった。
- 当初は忙しいダイエッターのためのコンビニ商品比較サイトをつくっていて、スペック中心（カロリー、糖質、脂質、食塩）の表示内容だった。
- ３週目ぐらい？でアプリはほぼ完成形になり、この時点でユーザーヒアリングをしたところ、あまりユーザーがいなそうなことがわかった。
- アプリの方向性については第５週目ぐらいに方向転換の案が出てきたが、仕事等でメンバーがそろわず、すぐに決定とはならなかった。
- アプリの方向転換が決まったのは残り２週間（第６週が終わった時点）の時点で、ここから新たにバックログを作り直し、それまで作っていたアプリの一部を使って作り直すことになった。
- Ruby on Railsでの開発は初めてだったが、学びながら開発をすることは難しかった。技術のある人のコードを見て学ぶことも多く、それを真似してコード書くこともできたが、自分ひとりで新たにコードを書 く場合はちゃんとした理解が必要できちんと勉強する必要があった。
- アジャイルのよいところは随時方向転換をしながら開発を進められるということだが、チームの意見をまとめるには時間が必要で、コミュニケーションが重要だった。
- ユーザーからの商品リクエスト機能
- ユーザーが撮影してくれた画像を受け取る機能
- ユーザーの商品に対する評価システムの決定。2016/11/26時点ではボタンを押しただけ評価が上がるようになっている。
- 掲載商品とカテゴリ増やす。
- コンビニ別での順位表示
- 各種並びかえ機能。カロリー別で並び替えとかしたかった。