スクラム開発チームに入ったデザイナーのお話
こんにちは。デザインチームの寺田です。
去年からキズナコネクトのスクラム開発チームに参加しています。
今回は私のしくじりとその改善についてお話したいと思います!
スクラム開発とは?
スクラム開発はこんな感じでやってます
私のしくじり
箇条書きします
スプリントレビューでうまく話せずしどろもどろ
既存デザインと既存実装に差異があることに気づかず開発にお渡し
デザイン作成し展開するも様々な仕様考慮漏れ
そして仕様がふわっとしたままリファインメントに入り仕様議論時間が長引く
まだまだ色々ありますがこのへんにしときます。。
しくじり改善と結果
○スプリントレビューうまく話せずしどろもどろ
時よ早くすぎれな気持ちで話していたので他職種の方々にもあまり伝わらず。。
そこでレトロスペクティブなどで開発メンバーからアドバイスをもらい改善していきました!
その場で共有するだけでなくXDリンクを貼った議事録を事前に共有しデザインデータをさわってもらう
変更前と変更後のデザインを見せる
機能改善の背景を説明する
見てもらいたいところはゆっくり話す
オンラインMTGで他職種の反応がわかりづらいこともあるので、成果物に問題がなければ画面越しにグッドのハンドサインをしてもらう👍
議論が長引いたら一旦ゴールを確認、答えが出なかったら持ち帰る
こうして以前よりもデザインの意図や改修点をスムーズに伝えられ、他職種の方々との議論も長引くことは少なくなりました。
○既存デザインと既存実装に差異があることに気づかず開発にお渡し
歴史的な経緯もあり実装とデザインの差異が多く、どっちを基準に実装すれば良いの?と開発メンバーの手をとめてしまう現象が多々ありました。。
デザインに合わせるも影響範囲が大きく実装が難しかったり、実装に合わせるも既存デザインデータが多かったりするので、応急処置として実装とデザインの差分をまとめたページを作りました。
このページを開発メンバーに共有しコミュニケーションコストを以前よりも減らしていけました。
○デザイン作成し展開するも様々な仕様考慮漏れ
○そして仕様がふわっとしたままリファインメントに入り仕様議論時間が長引く
こちらに関してはデザイン展開前のチェックリストを作成し凡ミスや考慮漏れを防ぐようにしました。
またエンジニア視点でのデザインレビューもしていただくことになり(非常にありがたい)開発メンバーの皆さんにアイディアを出してもらいました。
リファインメント長引く問題に関しては、開始前にプロジェクトマネージャー、リードエンジニアとデザインレビューMTGをして仕様を固めていくフローを追加しました。
振り返りの時間はありがたい
こうやって改善していけたのもスプリント・レトロスペクティブという振り返りの場と開発メンバーのおかげです!
キズナコネクトの振り返りはペンギンがたくさんいて賑やかです(コネペンといいます)
なぜこんなにペンギンが多いのか?というと
会議が長引きやすいので、議論したいふせんに1人ペンギンを3匹まで動かせて、ペンギンが多い順に議論するというルールでやっています。
日々課題は出てきますが、楽しさと癒しが加わって1週間を振り返られる機会があってとてもありがたいです!
最後までお読みいただきありがとうございました!