Slide 1

Slide 1 text

終わってる風終わってないタスク が自分の首を締めた話 コミューン株式会社 浅見達也 / @astatsuya1

Slide 2

Slide 2 text

自己紹介 フロントエンドエンジニア 浅見達也 twitter: astatsuya/@astatsuya1 2022年7月 コミューン株式会社入社 スクラムチームでcommmune(プロダクト名です)のフロントエンド・バックエンド開発 を行っています

Slide 3

Slide 3 text

2022年に所属した2つのスクラムチームの話をし ます

Slide 4

Slide 4 text

終わってる風終わってないタスクとは?🤔

Slide 5

Slide 5 text

まだやることが残っているのに終わったものとみなさ れているタスク

Slide 6

Slide 6 text

まだやることが残っているのに終わったものとみなされているタスク 一応動く状態になってるのでスプリントレビューで発表したけど・・・ ● 実はアプリが動くかわからない ○ まだテストしていない ○ 特定のユーザー操作によって動作しないケースがあるのを知っている ○ 本番環境で動かすためにやることがある ● アプリ自体は動作している ○ 良くないコードで作ってそのまま ○ 自動テストを書いていない ○ 資料作成が終わっていない

Slide 7

Slide 7 text

どんな問題が起こるのか?

Slide 8

Slide 8 text

実はアプリが動くかわからない 1. 出来た部分をスプリントレビューで発表 2. ほぼ終わってると思われてるのでリリース予定日の調整が進む 3. ではリリースしましょう! 4. まだやることがあって焦る

Slide 9

Slide 9 text

実はアプリが動くかわからない ● 焦っているので妥協したり、普段とは違うプロセスで開発をしたりする結果、問 題が起きがち ● 焦っても間に合わないので、スケジュールを再調整する場合は、プロダクトオー ナー、ステークホルダーを含む多くの人を巻き込むことになりがち

Slide 10

Slide 10 text

アプリ自体は動作している 1. 終わってる風終わってないタスクを抱えた状態でスプリントが始まる 2. スプリントプランニングで決めたスプリントバックログ+終わってる風終わってな いタスクをやらないといけない

Slide 11

Slide 11 text

アプリ自体は動作している 問題が起きなくてもスクラム3本柱の1つ、「透明性」にかける スクラムガイドの「透明性」によると 創発的なプロセスや作業は、作業を実 ⽰する⽰とその作業を受け取る ⽰に⽰える必要がある。 スクラムにお ける重要な意思決定は、 3 つの正式な作成物を認知する状態に基づいている。 透明性の低い作成物は、 価値を低下させ、リスクを ⽰める意思決定につながる可能性がある。 透明性によって検査が可能になる。透 明性のない検査は、誤解を招き、ムダなものである。 引用: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

Slide 12

Slide 12 text

アプリ自体は動作している ● バグ修正等、急いで変更を入れたいときに素早い動きができない ○ 自動テストがない場合はまず自動テストを書くところから始めないといけない ○ 自動テストを書かないで変更する場合はそのたびに手動テストが必要 ○ 最後に直したバグ修正が別のバグを引き起こしているかもしれないと気にしながら実装しない といけない

Slide 13

Slide 13 text

失敗はなぜ起こってしまったのか

Slide 14

Slide 14 text

失敗はなぜ起こってしまったのか とにかく出来た部分を見せてフィードバックをもらうべきだと思っていた ● そうした方が良いってどこかで読んだ気がしていた ○ 「まだ終っていない部分もありますが、動きはするので見ていただきたいです」と言われて動い ているものをみたらほぼ終わっていると思ってしまうのも当然

Slide 15

Slide 15 text

失敗はなぜ起こってしまったのか 自動テスト、リファクタリング、資料作成等が一番最後に残りがち ● プロセス的にこれらだけがスプリント内に終わらないというのがよくある ○ 各プロダクトバックログアイテムの最後にやるタスクがこれらになりがち ○ 機能だけは出来ているのでリリースしがち ○ 自動テストをなるべく早い段階で書きたいと思っていても最後になりがち

Slide 16

Slide 16 text

教訓 1. 終わってないことをスプリントレビューで提示しない 2. 急ぎでやらないといけないことは結構な頻度で突然やっ てくる 3. 優先順位は変わるもの。薄めて完了にしない

Slide 17

Slide 17 text

1. 終わってないことをスプリントレビューで提示しない スクラムガイドの「確約(コミットメント):完成の定義」によると プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。 ましてやスプリントレビューで提⽰することもできない。そうした場合、あとで検討できるようにプロ ダクトバックログに戻しておく。 引用: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf と書いてあるのでそれに従うのみ 途中でもフィード・バックが欲しいのであれば、スプリントレビューとは明確に区別して扱う

Slide 18

Slide 18 text

2. 急ぎでやらないといけないことは結構な頻度で突然やってくる スプリント中に差し込みタスクが発生することはある ● 普段から緊急事態に動けるようにしておく ○ 残業前提でスケジュールを組まない ○ 丁寧な開発を心がける。自動テストも書く ○ 忘れるまでにやればいいとなりがちな資料作成や、スクラムの仕事以外でやらないといけない こと(日報や経費精算とか)もやれるときにやっておく

Slide 19

Slide 19 text

1つの機能を作るためのプロダクトバックログが複数になることはあるが、やり残した ことがあるものを次のプロダクトバックログに回して完了にしない ● 新規登録、削除、更新が全て出来上がってリリースの予定でも、「1度登録した ら変更することはほとんどないから、更新は開発不要」となることはありえる ● 自動テストは次に回そう、バグはあるけどまだ誰も使わないから次で修正しよ う、をしない。同じプロダクトバックログで終わらせる 3. 優先順位は変わるもの。薄めて完了にしない

Slide 20

Slide 20 text

まとめ

Slide 21

Slide 21 text

日頃から最後まできっちりと丁寧にタスクを終わ らせて、終ってる風終ってないタスクを増やさない ようにしましょう

Slide 22

Slide 22 text

© commmune Inc. All rights reserved コミューン株式会社 / We are hiring!! 
 22 顧客コミュニティ作りに 特化したプロダクト
 commmune(コミューン) 顧客コミュニティプラットフォームを提供することによって、 企業とユーザー間にある”コミュニケーションの壁”を取り払い、 “対話による深い相互理解”と”共創の場作り”を提供するプロダクトです。 募集中ポジション
 ● エンジニアリングマネージャー
 ● フロントエンドエンジニア
 ● サーバサイドエンジニア
 ● QAエンジニア
 ● APPエンジニア(Flutter)
 ● データサイエンティスト
 commmuneは全レイヤー TypeScript実装 開発組織 開発組織は順調に成長してきておりますが、今後更に良いプロダクトを 作りをしていくためにもエンジニアメンバーを募集しています! まずはカジュアル面談でぜひお話しさせてください! >> 会社説明資料・job description
 (https://commmune-careers.studio.site/)
 >> テックブログ
 (https://tech.commmune.jp/)