組織パターン メモ
組織パターン読了。ハイライト的なやつ。 もう少しまともなまとめを書きたい想いはあるものの、時間的にここまで。
p4 パターンとは何か？
p7 パターン言語とは何か？
p29 本書を使うべき人
p115 トラックナンバーとは、他の人が知らない重要なドメインの専門知識を有する人の数
p118 ソロ バイオリニスト システム全体の設計と実装を、最も生産性の高い開発者一人か二人で行おう
p146 人気者の興味深い一形態が、道化師、別名賢い愚者だ。 p147 人気者は本質的に非公式だ。
p149 婦長がいれば、チームはよいときも悪いときも結束できる。 婦長は調停者のもっと広いバージョンで、婦長は通常、人気者である。 追記しておくと、このロールを誰かに押し付けてはならない。生まれついての婦長もいれば、そうでない人もいるのだ。それゆえ、仕立てるのではなく、見つける必要がある。
p154 偉人ロール
p166 うまくいっているプロジェクトというものは、成功に導くようなふるまいに報酬を与えることでうまくいき続けている。
p195 よほどのことがない限り、ロールを演じている人はプロジェクトのリリースまではそのままにしよう。ロールを混乱させるような事態が起きたときに、それに対処するという一時的なタスクを持ち上げるのはやめよう。 混乱が生じたときに、それに対処する新しいロールを作らないことがコツだ。混乱への対処、特に危機への対処にはある種のステータスがつきまとう。もしロールを作ってしまうと、そのロールのふるまいが定義され、結果として、混乱が生じることを奨励することになってしまう。それよりも “生産者” を育てることに集中しよう。
p198,199 ビジネス構造は組織構造を構築するうえで重要な考慮点だ。ビジネス構造のほとんどは、アーキテクチャの中にはっきりと表現される。したがって、コンウェイの法則は、分割統治を支える重要なパターンなのだ。 もし、サブ組織を形成する際に中心となれる中核的なロールがなければ、その組織を区切ることはできないだろう。
p213 コミュニケーションが自然に発生することは期待できない。さらに言えば、任意の社会構造の中で、特定のコミュニケーションが自然と構成されることはまったく期待できないのだ。 それゆえ: 組織内や作業場の中に、コミュニケーションのつながりを推奨するような場所を作ろう。そうしたつながりが他のパターンを養うのだ。 “組織は拠点配置に従う”
p266, 267 最初は、ソロ バイオリニストから始まり、人が増えていくこともある。… チームのオープンクローズドの原則 … 開発者リーダーがあるプロジェクトでソロ バイオリニストのロールを演じていた場合、そのふるまいをやめるのは難しいこともある。
p308 6.2 漸進的成長 一度に一つずつパターンを適用し始めるのだ。 形式主義と再現性
p315 組織パターンは処方箋ではなくインスピレーション 組織のコンテキスト次第
p316 組織パターンは個人ではなくグループで使う
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: 逃げる
Macのカメラが認識されないとき
Macでruby buildがうまくいかないときのxcodeのアレ
毎回忘れてて調べ直すいつものやつ
sudo xcrun cc xcode-select --install rbenv install 2.4.0
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 をまっとうに使っている記事はもう色々あるので、 こういうの公開しておく意味はありそうかなと思ったのでした。
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 版に比べて速くなるでしょう。
