ツイート
#今日の30分 +8分。リーンソフトウェア開発3章。決定をできるだけ遅らせる上で、決定するときに考慮すべきことと、決定するときに使えるツールの話。最終責任時点、これ、そのタイミングを見極めるの難しそうだなー。慣れが必要になりそう。
— ざっきー dev (@zakky_dev) June 11, 2018
#今日の30分 +3分。リーンソフトウェア開発122ページまで。迅速に提供することのメリットと、そのために有用なツールとしてのプルシステムの話。これまで読んできた本の話にも繋がることが多いな。「何故」から始めよ、という言葉に置き換えできる。余計なものを作らず、必要なものを最低限作る。
— ざっきー dev (@zakky_dev) June 12, 2018
#今日の30分 +3分。リーンソフトウェア開発134ページまで。待ち行列理論と遅れのコストの話をちょっとだけ。待ち行列理論、ORの話だったんか。よく聞く頻繁なリリースもこのあたりから来てるのね。そっちのほうが効率がいい、とORで決着ついてるなら、それを理由に説得材料として使えそう。
— ざっきー dev (@zakky_dev) June 13, 2018
#今日の30分 +3分。リーンソフトウェア開発151ページまで。速度がビジネス価値に与える影響の計測のために、単純な損益モデルを作り、トレードオフを導く話。あとトップダウン方式の開発改善プログラムの例の説明。
— ざっきー dev (@zakky_dev) June 14, 2018
#今日の30分 +10分。リーンソフトウェア開発169ページまで。プロセス改善はボトムアップ的にやると効果的である話と、メンバーのモチベーションの話。
— ざっきー dev (@zakky_dev) June 15, 2018
プロセス改善の話、ボトムアップ的にやるのはいいのだけれど、これ局所最適とかになったりしないのかな。気になる。
#今日の30分 +4分。リーンソフトウェア開発178ページまで。チーム開発で必要、あるいは生じていくリーダー的なロールの話。アプリケーションドメインとソリューションドメインの両方に精通した人や、チームが円滑に開発できる状況を整える人。なんとなくPOとSMを思い出す間感じ。
— ざっきー dev (@zakky_dev) June 16, 2018
#今日の30分 -10分。5章読了。専門知識を共有したり、使う方法の話。文書では伝えきれないことがあるので、口頭で伝えなければならない。このあたりは感覚と一致する。自分の場合、ちょっと口頭に寄りすぎているけれど。
— ざっきー dev (@zakky_dev) June 17, 2018
レトロスペクティブ
前回の結果
- 特定日までにやるべきことをはっきりさせ、必要なタスクを洗い出す。
- 0回。これはひどい……。
今回の実験
- カンバンにないタスクはやらない
- 計測方法: カンバンのタスクに使った総時間を追記して、その総計を調べる
