2018/3/1

夜、朝方にまとめて開発したい

レビュー待ちの状態で止まる

このときにやることがなくなってしまうことが許容できない

空いた時間にほかの作業を進めた方が効率的という考え

レビュイー側はレビューばっかになってしまう

開発速度に差があるので

細かくタスクを分ければいい

分け方が工程別 = タスク単位

ストーリーにかけるか、タスクにかけるか

ストーリーの開発だけが進む

ミニウォータフォール

アンチパターン

ここがうまく説明できない

なぜか

本当のリリースはずっと先なので、特定のストーリーが速くリリースできる必要がない

最終的に間に合えばいつでてもいい

リリースまでやらなくて良いんじゃないか

レビューまででいいんじゃないか

今回は本番に早い段階で出せる

そうでもないかも

WIP制限の実効性

破ろうと思えば敗れる

それでも今まで自主的に守ってきた

なんで制限を超えてしまったか原因を考えるのが大切

問題(ボトルネック)を発見するためにやっている

レビューに時間がかかるとか

とりかかるタイミングが悪いとか

リリース後の確認に時間が取られるとか

ほかの方法で見つからないのか

振り返りとかで取り上げていけばいい

具体的な方法が上がらなかった

今までリリースの時間が長いことをふりかえりで指摘したことがあったか

ない

バリューストリームマップを書く

仕事の流れを書く

問題発見を特定の方法だけで見つけようとするのは良くない

WIP制限だけで問題を発見しようとはしてない

問題を発見するだけではだめではないか

問題を可視化するだけでこんなに苦しい思いをする必要があるのか

工程中のボトルネックを特定する

コンテキストスイッチを減らす

今減ってない

ABCと3つ作業があって

Bを開発している人がAをレビューにいくことでBの開発が止まってしまう

制限しないとDFG....と来てさらに

要求内容が途中で変わる可能性がある

仕掛り増やすと、作り直しが増える

開発だけ終わったタスク

要件がなくなると、無駄になる

助け合い

詰まっているタスクを助けにいく

分かるように説明できない