Recomendados
Recomendados
Más contenido relacionado
Similar a POStudy Day 2012 in Okinawa - 振り返り結果
Similar a POStudy Day 2012 in Okinawa - 振り返り結果 (15)
Más de 満徳 関
Más de 満徳 関 (20)
Último
Último (10)
POStudy Day 2012 in Okinawa - 振り返り結果
- 1. POStudy Day 2013 Spring in Tokyo 振り返り結果 2012年12月01日（土）POStudy @fullvirtue Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. POStudy Day in Okinawa
- 2. 振り返り結果ご紹介 気づき – 最初はコンテンツで引き寄せて、最後に自己紹介する – 否定から入らないことの大切さ – いろんな分野の勉強がしたいと感じた – 仕様を受けるのと伝えるのは全然違う – 社外の人と話すのは楽しい – 発散と収束は別々の日に – 自分の態度や言葉づかいが強引でないか、客観的に 見る必要性 – 会社とは違う形で話すことで、違う発想が出来た – 「わからない」とちゃんと伝えることから生まれる 展開がある – 仕様を伝えるのは難しい – 見積の難しさ – マシュマロでの無理なトライが仇となる – 運が与える影響の大きさ – マシュマロ重い – マシュマロチャレンジを通して、1つのことに 力を注ぐことの楽しさを感じた – 意志の共有どんな時でも大切 – 全員の意志を共有することは難しい – ワークショップの大切感を再認識 – 伝えることの難しさ – 大きな紙のテープでの止め方 – 課題や方向性を指摘するのがとても大切 – 可視化大切 – 少ない時間では作戦よりも実際にやってみる ことの大切さ – みんながApple – 初対面の方々との会話は楽しい – 付箋紙の大切さ – ユーザーストーリーマッピングでの ユーザーが求める価値 Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 2
- 3. 振り返り結果ご紹介 気づき – マシュマロチャレンジ 一人一人の役割を明確にする – 共有することの大切さを改めて知った – ビジネスモデル構築はエキサイティングで面白い遊び だ – マシュマロチャレンジ 仮説を立てることが大事 – The Specification Exercise 前提を確認することが大 事 – チームビルディング大切 – マシュマロチャレンジ 成功体験を手に入れる →そこから発展 – フィードバック、確認が大事 – マシュマロチャレンジ 土台が大切だった – ユーザーストーリーマッピングにおいて、Doneの定義 は超重要 – 細かい機能の完了条件を決めるのはいいと思った – チームでの決まり事の重要性 – フィードバックの重要性と忘却性 – チームでの作業はコミュニケーションが難しい でも重要 – Doneの定義 – 相対的な作業量見積はチーム内の作業認識合わせ にも超有効 – 仕様書の認識を作業者同士でも合わせる努力が 必要 – 同じ言葉を使っても認識は人それぞれ – 認識の違い – 大きな仕事に向け、小さなTryを積み重ねること も重要 Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 3
- 4. 振り返り結果ご紹介 感想 – 実際の開発に取り入れてみたいと思った – ユーザーストーリーは難しい – ワークショップは楽しい – マシュマロ楽しい – 所長がこない – 良い経験をしたけど、無料でいいのかな？笑 – もっとITについて知りたくなった – 長い時間でもリラックスして楽しく参加できた – あっという間に終わった – 各チームの個性が良く出ていて面白かった – Japan guide.com 凄かった ユーザー増える例 – いろんな情報を得ることが出来た Startup Weekendなど – 社会人・学生の交流はWelcome Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 4
- 5. 振り返り結果ご紹介 Keep – 指摘されたことは感情的にならずに受け止める – 意見の共有をすること – 頭にある情報の共有化、可視化、大切さ – 相対的に見積もる – まず手を動かす – プロタイプをたくさん作ろう – 良いイメージが見えた案は試してみる – いきなり完成品を作るのではなく試作品を作ってみる – 普段から無駄を考える – ポストイットは横にはがす – 誰の為、何の為に作るのかを共有することの大切さ – Doneの定義を意識する – メンバーの構成によって自分の役割を積極的に担う – Doneの定義をすることで相手との食い違いがないよう にする – 自分の限界を知っておく – 全体から物を見る大切さ – 面白かった – 討論するのが楽しい – プレゼンのシナリオをイメージ出来た – ゲーム感覚で勉強できてすばらしい – いろんな人と話ができた – 発散の日と収束の日を分ける – 見積の探り方 – フィードバックは大切 – リーダーってやっぱり大切 – ピザが美味しかった – どうやったら、どう伝えたら伝わりやすいかを 意識する – 仕様のフォーマットを決める – スクラムの基本説明があってわかりやすかった – 振り返りが細かくあってよかった 5
- 6. 振り返り結果ご紹介 Keep – 最後の振り返りで関さんの種明かしがあってよかった – プロトタイプ とりあえず動く物を作る！を再認識で きた – 自己紹介は自分が出来ることをアピールする場 それによって次に繋がる – ごちゃごちゃ言わず、まずはやる – まず最低限の物を作る それからアップデート – ロジック的な組み立て – 共通認識を確認する – Doneの定義 – ピザ美味しかった – 仕様の前にGoalを決める for who / for why – 作りながら考える – 反省をメンバーで共有し、生かす – 役割分担 – チームの情報共有化 – 案件の大きなイメージからチーム内で共有してい く – ストーリーの発散と収束 – ポストイットのはがし方 – プレゼンするときのテクニック – 方向性の確認 6
- 7. 振り返り結果ご紹介 Problem – 発表するのがニガテ – 絵が1つだけと思い込んでいた – 問題があると感じていたことを勢いで流して 結果ゼロになった – 論理的に話せてない – 相手が分かるように話せない – 会場が初めてで迷った – POとしての視点の理解不足 – 名刺持ってくればよかった – プロダクトオーナーとは何かがまだいまいち理解 できていない – 名刺もっとけばよかった – まだちゃんとスクラムの手順や理論が落とし込めて いない – プログラミングの知識がなくて認識がずれてしまった – 自分の知っていることを知らない人に伝えるのが上手 くいかない – ITの知識がなさすぎる – コミュニケーションフィードバックが少なかった – ワークショップの時間が短い 7
- 8. 振り返り結果ご紹介 Try – 問題を感じた場合は、あいまいに流さず納得出来る ように共有する – もっとスクラムを知りたい – 思い込みは捨てる – Keepに載っているものは定着するように努力する – 理解の順番を考えて物事を伝える – 人前で増やす機会を増やす – 目的を決め、ゴールまで進む – 案件に対してルールを決める – 相手に伝えることの難しさと技を認識して製作に アプローチする – チームでゴールを設定して定着化させること – 沖縄でスクラムを行っている企業はどのぐらいあるの か？ – 自分の頭にある物をどう共有するのか – 自分の武器は何なのか？ – 人見知りだったけど案外話が出来たと思う もっとたくさんの人と話す – POの立場を理解する – 相対見積 – 会社もしくはビジネスモデル作成 – 帰ってアジャイル関連の本を読んでみる – 日常生活にスクラムを取り入れる – リーン、英雄的構造など、気になった言葉を 調べて見る – 自己紹介出来る力をもっとつけたい – 相手のモチベーションの事を考えて接する – 無理はしない（マシュマロチャレンジ） – 会場の事前確認が必要 – 皆が付箋マスターにw – 付箋の使い方 – 自己紹介をもっとやりたかった 8
- 9. 振り返り結果ご紹介 Try – 自分と相手の認識がちゃんと同じかチェックする – 伝わるように相手にあわせる – 書籍を読んでみようと思う – マシュマロチャレンジ とりあえず作って見る 完璧を目指さない – ワークショップで見たスクラムの説明を資料で欲しい – 無駄をなくす – 英雄的構造がたくさん作れる人になりたい – アジャイル・スクラムの流れを押させる – 開発者と仕様を伝える人を1回交代してやりたかった – 簡単な言葉でしゃべる – 自己紹介では強みをアピール – プロダクトバックログを組んでみる – チームの連携 – プランニングポーカーの基準値を見直す – 小さいことからはじめてみる 挑戦する – スキルレベルを統一する – 目的の確認 – 伝えるときは全体像と案件毎にわける – フィードバック（コミュニケーション）を もらって、より良い物を作る – 成功体験の後、急激な拡大は危険 – 常にチーム全体の動きを確認 – 前提条件を見直す – 時間配分を見直す 9