2022.07.06 Scrum Developers Night #10 1st Discussion ~21:10
テーブル1
設計の認識合わせをどこまでするか/設計スプリントをどうするか?
課題
設計と呼んでいるものの粒度による部分
設計に関する議論が後から出てきてしまう
スキル差があるチームの中で、どこまでスキルのある人の知見をコードに活かせるか
プロセスや仕組みで担保できないか?
チームとコードベースの対応関係
チームごとのコードベース
チーム内で議論が閉じる
チームごとの色がコードベースに出てしまう
チーム間でのコードの共有
チームごとの色がコードに出過ぎない、全体で共通理解を作って進められる
チーム間で議論が生じるので、手戻りが発生することも
テーブル3
デザイナーとの協業
デザイナーに作り込みを要求せずにタイムボックス内でできる範囲で作ってもらう
フィードバックが増える事でデザイナが作り込んだもの一発で見るより意見交換が活発になる
デザイナーの稼働を計測したいというチーム事情などもある
2nd Discussion ~22:00
テーブル1
ある現場
8人のメンバーとPO
単なる進捗報告会、発言しない人もいる
別の現場
複数チーム
違うチームの人を呼ぶとか
そもそも正しくスクラムできてない?
効果的なスプリントレビューや役割分担をできるように
チームが大きくなってきているので分割した方がいい?
発言しない人問題への対応
その後、スクラムとかアジャイルの話を諸々
テーブル2
大規模な開発案件の設計をひたすらやるスプリントの是非
課題感:事前に決めすぎて、フィードバックを受けての改善が捗らない
「設計や仕様は決めきれない」というのが重要なポイント
決め切らずに進めること
分割して、シンプルなところを最低限で作って、フィードバックを得る
データベース設計なども、最小限の設計でとどめる
とはいえ、色々な問題がおきそうではある
とりあえずやってみたい
その他の課題
QAチームが外にいてスクラムチームの中にいないので、中に混ざってもう
週の初めはテストケースを作る、そこで仕様の漏れなども出てくる
テーブル4
複数チームでのスクラムで、複数のPO/PdMの役割分担をどうするか?
役割に対する期待が人によってずれていそう?
プロダクトマネージャーのキャリアラダーを参考にしてみたり
EMやスクラムマスターのキャリア
フィードバック