SCRUM BOOT CAMP THE BOOK を読んだ

2018年12冊目

 

スクラム開発をチームで進めるにあたり起こりそうなストーリーが説明とイラスト漫画で解説するのでスラスラ読めた。今は2周目。

 

スポーツで言う戦術、フォーメーションとしてチームでプロジェクトを進めるノウハウを求めて読み始めた。短いスパンの振り返りを繰り返しながら、細かな修正をかけて行くスタイルは自分のチームとあっているように感じる。結局見積もっても実績との乖離を可視化するすべがなく、1日1日遅れが積み重なって行くのであれば、一つのスプリント毎に遅れや進みが見えるのであれば都度リカバーできる。

 

理解は容易で習得が難しいと言われるのはこのあたりだろう。なんとなく出来そうに感じてしまうが継続してやり続けるにはスクラムマスターのような人が慣れるまでは声を出していかないといけない。

慣れてきたらスクラムマスターが自身をクビにして自立、自律したチームが残る。これを繰り返していくと社内にスクラム文化が残る。こういう役割を担っていかなくてはと思った一冊。

 

読んでいて疑問に思った点。

解決したら追記していく予定。

1点目

要件をまとめたバックログの項目と、バックログからブレークダウンした、バックログタスクの予定工数がポイントや作業量での相対見積もりとなる。この時のポイント粒度をどうやって揃えるか。

同じポイントを使うのであれば、2時間単位の小さなポイントと、5人日のポイントの粒度を合わせる必要がある。

要件から作成したバックログタスクは1週間が望ましいようだが、ブレークダウンしたタスクは2時間1ポイントくらいの粒度で運用したい。

2点目

バックログタスクで大きく工数やプロジェクトの予定納期をガントチャートで線引きして、毎回のスプリントレビューでリリース日をプロダクトオーナーが変更調整し続けるということで良いのか?

毎回見える化しているから、逆に楽なのか?作業量は大きくふえそうなきがするが。

 

3点目

マークアップやフロント、バックエンドのメンバーが同時にタスクを着手する場合細かく刻んだタスクを各職種毎に対応すると思うが、大元のタスクをどうやって切っておくのか?

切り方が重要な気がする。実際の運用レベルでのタスク切り分けを知りたい。他本を漁る。

 

鬼速PDCAを読んでる

2018年11冊目

 

最近の効率化の一つとして参考にしている。

PDCAの検証て行われるのは、うまくいかなかった原因に着目しがち。

うまくいった原因も分析し、次も再現性があるかを明確にすることが重要。

 

WIP

完全残業ゼロの I T企業になったら何が起きたかを読んだ

2018年10冊目

 

時間を決め、物事を進める。

今一番自分の中になく、そして自信のない部分。

そうしたいと願っているのではなく、実践してPDCAを回そうと思えた。

 

ステップとして以下を行う

仕事の見える化

仕事をなくす

仕事の自動化

仕事の標準化

 

業務効率を考えるのが自身のプロジェクトゴールなのに、自分自身が効率化できていない。

まずは自分から効率化をはかっていく。

 

引用

みんなが公私共に同じ方向を向くことで組織が上手く機能した時代もあったかもしれません 。しかし 、今は昔に比べて生活が多種多様です 。共働きすら珍しかった時代から 、時代は大きく変化しているのです 。もはや 、ひとつのやり方に絞ろうという方が無理があるのではないでしょうか。

そんな時代に 、会社という組織がどんな形になっていくべきか 、経営者として常に考え続けています 。そして 、いろいろな価値観に対応しやすい 、ライフプランが選びやすい 、そんな形があるべき姿だと思うようになり 、実践に移しています 。

 

広く弱くつながって生きるを読んだ

2018年9冊目

 

違う業界、世代とゆるくつながっていく生き方は参考にしたい。

多拠点生活の本も書いてるので次に読みたい一冊。

価値観として、お金よりつながりや生き方を考えるキッカケになった一冊。

佐々木さんの他の本も読みたい。

 

印象的だったのは、笑顔で手を振りながら離れていくという考え方。一つ一つ衝突しない生き方というのは参考になる。

職場ではPHP+OOPのようなブログ記事が多めです。

職場のブログで書いた内容をリンク。

aimstogeek.hatenablog.com

aimstogeek.hatenablog.com

aimstogeek.hatenablog.com

最近読んだ本のログ取れていない。 職場で書くような内容を手元でも試しながら書きたいところ。

TeamGeekを読んだ

2018年8冊目

タイトルが独特なので敬遠してた。
読んでみると、Teamを作っていくリーダーの為の本という感じ。

一番印象に残ったのはHRTだが、その流れで一緒に語られていた
「技術的に貢献出来る人は確実に交換可能だ。」という部分。

技術が尖っていても、メンバーに対するHRTを感じない振る舞いがあれば、 振る舞いを指摘し、改善してもらう。改善がない場合は、チームを去ってもらう。という風に受け止めた。 (もちろんベースとなる技術は必要で、どちらも持っている人を待つというのが良いと思う)

技術だけでなくチームに貢献出来る人になるよう、全員で文化を作っていく事がいかに重要か。

自身もチームを作っていくリーダーの一人として、HRTを常に念頭に置いて、
サーヴァント型の人としてチームに貢献していきたい。
疲れてくるとどうしても傾聴出来ずに割って話をしてしまう事が最近多いので、自己コントロールをし、
メンバーを信頼しながら進める。

環境によるSQL Modeの違いではまった

Laravelで開発中にAリポジトリでは行出来るバッチをBリポジトリに移植

しかし、以下エラーが発生する。

SQLSTATE[42000]: Syntax error or access violation: 1055 'AAAAA' isn't in GROUP BY

stackoverflow.com

原因は、config/database.php で定義している strict=true|false の違いだった。

片側のリポジトリではstrict=false となっていた。。。

こういう部分をfalseに変える時はSQLを変えて、SQLを直してtrueのままにして欲しい。