ツイート
#今日の30分 -1分。スクラム現場ガイド1章まで。スクラムの導入に失敗しないためのガイド。まずは教科書通りのスクラムを導入することから始めること。通常、スクラムの導入時にはマインドセットを大きく変える必要がある。従来のプロセスに従ったままではうまくいかない、という話。
— ざっきー dev (@zakky_dev) October 8, 2018
#今日の30分 -6分。スクラム現場ガイド2章。スクラムを導入するときに発生する抵抗との付き合い方。Fearless Changeを思い出す内容。新しいアイデアに熱狂しても、押し付けられた相手は引くだけで受け入れることは難しい。なので、受け入れてもらうために色々やる必要がある、という話。
— ざっきー dev (@zakky_dev) October 9, 2018
#今日の30分 -1分。スクラム現場ガイド3章。専任チームが作れない場合に、コアチームとチームコンサルタントを用意する方法。専任チームを作れれば最高だが、現実はそう上手くいかないことが多い。なので、社内にいる傭兵として、チームコンサルタントという立場を作り、プールする。
— ざっきー dev (@zakky_dev) October 10, 2018
#今日の30分 スクラム現場ガイド4章。最初のベロシティについて。プロジェクト開始前にベロシティを出すにはどうすべきか。方法としては3つ。過去データ、憶測、様子見。どのアプローチを取るべきかはチームが既存か新規かと、採用する技術が既知か未知かで優先順位が提示されている。
— ざっきー dev (@zakky_dev) October 11, 2018
#今日の30分 -7分。スクラム現場ガイド5章。役割の兼任について。基本方針としては「やるべきでない」。それでもやるならコアチームメンバーとSMの兼任にしておくように、という話。中でもやめるべきなのはPOとSMの組み合わせ。エッセンシャルスクラムでも同じこと言ってたな。
— ざっきー dev (@zakky_dev) October 12, 2018
#今日の30分 +6分。7章まで。スプリント期間と完成の定義について。スプリント期間はフィードバックサイクルを早く回したいものの、ステークホルダーを巻き込む場合は短くしすぎることは難しいので調整する。また、短くしすぎてチームが混乱するならそれもまた良くないので注意。
— ざっきー dev (@zakky_dev) October 13, 2018
#今日の30分 +10分。スクラム現場ガイド9章まで。専任スクラムマスターの利点、技術プラクティス導入の必要性について。んー、読みが浅いのか、集中できていないのか、どうにも専任SMであるべき理由がよくわからなかった。やること多すぎて他のことやってる時間ないよ、って話でいいのかな。
— ざっきー dev (@zakky_dev) October 14, 2018
ふりかえり
前回の結果
- 1日ごとにTryの達成状況を確認する。
- 結果: 100%。
- 「今日の30分」とは別枠で「テスト駆動開発」を読み、写経する
- 結果: -、-、-、19章まで、2部読了、-、27章まで
- 19時と20時にアラートを設定し、20時時点に本を読み始められるように生活を調整する。
- 結果
- 22:30くらい、3
- 19:30くらい、3
- 21:15くらい、3
- 17:30くらい、5
- 22:00くらい、4
- 22:00くらい、3
- 21:00くらい、3
- 結果
- 朝に前日に「今日の30分」で読んだ箇所を流し読みする。
- 結果: -、実施、実施、実施、実施、実施、-
- 入眠時刻、起床時刻を記録する。
- 結果
- 23:54 - 06:08
- 00:14 - 03:32
- 22:00くらい - 05:03
- 22:43 - 04:37
- 22:32 - 05:43
- 01:15 - 06:38
- 00:46 - 06:46
- 結果
雑感
開始時刻と眠気の間にはさほど関係がない気がしてきた。 むしろ睡眠時間と関係が強そう。 開始時刻を完全に固定して、睡眠時間とセットで記録してみる。
今回の実験
- 1日ごとにTryの達成状況を確認する。
- 「今日の30分」とは別枠で「テスト駆動開発」を読み、写経する
- 朝に前日に「今日の30分」で読んだ箇所を流し読みする。
- 開始時刻を19時に固定し、睡眠時間と眠気をセットで記録する。
個人的メモ
週末にAWSを触り始めた。 これまで全く触ってこなかった領域について、少しでも知見を得るため。 無料枠内で色々遊んでみたいところ。