日常

ケ・セラ・セラ

SCRUM BOOT CAMP THE BOOK メモ

Scrum はフレームワーク

Scrum はアジャイル開発手法のひとつ

プロダクトバックログ

p24 プロダクトオーナー

スプリント期間は固定する

Scrum ではロールの兼任は禁止されていない p53 でも兼任すべきじゃないこともある。

スプリント毎に終わらせられるポイント数はベロシティと呼ばれる。 ベロシティは決めるものではなくて測るもの。

タイムボックスを守る。制限時間内に終わらなかったものは次のタイムボックスに回すだけ。期限が来ればその作業は中断し、次のスプリントで再びやるかどうかから考え直す。

プロダクトバックログの項目の並び順はすぐに入れ替え出来るようにしておこう。たとえばこの項目は大きくて今回は終わらせられないのでその下の小さい項目をやってもいいですか?で入れ替えができるぐらいの順序でよい。

実はプロダクトバックログは空っぽにはならない。プロジェクトが終わるか続くかは別として、少しでも良くしていこうとするのが Scram の原動力。もし誰も追記しなくなったらそれは良くない兆候。

p163 デイリースクラム

安定していないベロシティは予測には使えない。

p244 鶏と豚の例え話

本来はリリーススプリントがなくてもいいようにしていく

p276 理解を深めるために読んでほしい文献

p277 ボクくんが気づいた大切なこと

Team Geek メモ

Team Geek

以下は印象に残ったあたりのメモ。

  • p8 隠したらダメになる

  • p15 三本柱 (HRT, heart, not hurt)

    • 謙虚 (Humility)
    • 尊敬 (Respect)
    • 信頼 (Trust)
  • p18 人間関係は確実にプロジェクトよりプロジェクトより長続きするものである。

  • p19 組織を自分の仕事に使うことを学べば、組織を自分の要求に合わせられるようになる。そうしなければ、宣戦布告なしの小さな戦争を人生をかけて日々戦うことになるだろう。

  • p23 過ちから学ぶには、失敗を文書化することである。我々の業界では、「ポストモーテム」を書くという。適切なポストモーテムには、学習した結果として何を学んだかと何を変更するかを記述する。書き終わったら見つけやすい場所に置いて、変更を継続できるようにする。

  • p24 優れたポストモーテムには以下のことが含まれる。

    • 概要
    • イベントのタイムライン (調査開始から解決に至るまで)
    • イベントの根本原因
    • 影響と損害の評価
    • すぐに問題を解決するための行動一式
    • 再発を防止するための行動一式
    • 学習した教訓
  • p35 自己選択的な文化

  • p71 アンチパターン: パフォーマンスの低い人を無視する

  • p73 アンチパターン: 人間の問題を無視する

  • p74 アンチパターン: みんなの友達になる

  • p74 アンチパターン: 採用を妥協する

  • p87 幸せを追い求める 「何か必要なものはある?」 ここで重要なのは、暗黙的な目標を明確化することである。

  • p99 チームの文化に含めないことについても議論すべきである。効率的で動きの早いチームを目指しているのであれば、やりたくないことも明確にしておいたほうがいい。

  • p145 プランB: 逃げる

rails new skip-いろいろ して react_on_rails を使おうとた場合に遭遇したあれこれ

これは整理して書いておこうと思ってもう2ヶ月経ってしまったものなので、この際ちらかったままに公開だけしておこうというメモです。

意気込んで、

rails new app --skip-action-cable --skip-action-mailer --skip-bundle --skip-javascript --skip-listen --skip-puma --skip-spring --skip-test --skip-turbolinks

などどして react_on_rails を使い始めようとした際に得た知見です。 react_on_rails をまっとうに使っている記事はもう色々あるので、 こういうの公開しておく意味はありそうかなと思ったのでした。

gist.github.com

RailsでRuby2.4のHash#compactを使うp-rがある

読みました。短くまとめます。

これがマージされると、Ruby 2.4 で加わる Hash#compact / Hash#compact! を Rails でも使うようになる。

Hash#compact が無い環境では、従来どおり activesupport 版を使うような変更ですね。

# activesupport/lib/active_support/core_ext/hash/compact.rb

+  unless Hash.instance_methods(false).include?(:compact)
+    # Returns a hash with non +nil+ values.
+    #
+    #   hash = { a: true, b: false, c: nil }
+    #   hash.compact        # => { a: true, b: false }
+    #   hash                # => { a: true, b: false, c: nil }
+    #   { c: nil }.compact  # => {}
+    #   { c: true }.compact # => { c: true }
+    def compact
+      select { |_, value| !value.nil? }
+    end

Ruby 2.4 の Hash#compact #compact! は C 実装です。ActiveSupport 版に比べて速くなるでしょう。

yaml_checker という Gem を作りました

github.com

https://rubygems.org/gems/yaml_checker

ファイル名かディレクトリを指定すると、.yml / .yaml 拡張子のファイルのみ YAML.load_file して回って、例外を起こしたものをまとめて標準出力する。というやつです。

$ yaml_checker path/to/directory
$ yaml_checker path/to/directory/foo.yml
$ yaml_checker path/to/directory/bar.yaml

invalid なファイルを含む時の様子です。

$ yaml_checker examples/
(/path/to/examples/dir1/dir2/invalid.yml): did not find expected key while parsing a block mapping at line 1 column 3
(/path/to/examples/dir1/invalid.yml): did not find expected key while parsing a block mapping at line 1 column 3
(/path/to/examples/invalid.yml): did not find expected key while parsing a block mapping at line 1 column 3
(/path/to/examples/dir1/dir2/invalid.yaml): did not find expected key while parsing a block mapping at line 1 column 3
(/path/to/examples/dir1/invalid.yaml): did not find expected key while parsing a block mapping at line 1 column 3
(/path/to/examples/invalid.yaml): did not find expected key while parsing a block mapping at line 1 column 3

もう少し機能的に色々考えていて書き始めたのですが、とりあえずこれだけあればいいかという気持ちになってきて公開しました。必要が生じたらまたという気持ちです。