Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
アジャイルコーチング読書メモ
  • 👀まえがきに「技術書を読む」とあって、俄然読む気が高まってきた
  • 👀アジャイルコーチングに書いてあること、別にコーチじゃなくて、チームがチームでワークするためのヒントとして読めばいいのにと思うんだが、きっとそれが難しいんだろうなと思う。
  • p5
    • アジャイルの重要な原則は、持続可能なペースで(燃え尽きずに)働くこと
    • 他人に言っていることと自分がやることを一致させる
  • p7
    • チームの一員であることを示す
    • 役割で人を区別しない
  • p11
    • 👀properサイクルよさそう
    • 👀コーチングに限った話じゃないね
  • p18
    • 開発の初歩的なお作法を導入しないことには、アジャイルのプラクティスを始めることはできません
    • 👀基礎力大事
  • p22
    • あなたがきちんと話を聞かなければ、二度と話してくれないでしょう
  • p27
    • 👀合意の段階が紹介されてた
  • p29
    • ミーティングを継続すると決めたら、何事もなかったかのように装うのはやめましょう
  • p32
    • アジャイル信者にならないように気をつけて。みんなに引かれるわよ。
  • p33
    • 👀誘導的なコーチング嫌いだ
  • p34
    • 自分のアイデアであれば、最後までやり抜いてくれる
  • p40
    • あなたが意見を大切にすることを理解してもらうまでは、決して質問をしてはいけません
  • p48
    • すべてを開示する必要はない。だが、すべてを秘密にしてはいけない
  • p50
    • 人を判断する前に、その人の立場になってしばらく考えよ (ネイティブアメリカンのことわざ)
  • p52
    • 簡単すぎず、難しすぎず
  • p54
    • ゴールドカード
  • p55
    • 衛生要因
    • 高度なコンピューター、美味しいコーヒー、十分な報酬は、それがあるときには何も感じませんが、なければモチベーションが下がります
    • インセンティブの制度は個人の生産性を高めるものであり、それによってチームのコラボレーションが損なわれる可能性があります
  • p62
    • チームに期待する振る舞いの模範となることは、コーチングの重要な技術よ
  • p82
    • ビジネスパーソンは、すべてがうまくいったときに何をするかだけを考えています。つまり、うまくいかない可能性については考えていないのです。
  • p86
    • ユーザーが触れる機能がなくても、「誰が欲しいの?それはなぜ?」という質問は使える
  • p92
    • 計画ミーティングは何をするのかを理解する場です。
  • p94
    • 書記はやらないように
  • p100
    • ステークホルダーの興味は、ユーザーストーリーがすべて完成するかどうかであり、タスクのことには興味ありません。タスクはデリバリー可能ではないからです。
  • p101
    • チームの生産性は希望的観測や「一生懸命」によって改善されることはない、ということです。
  • p105
    • 電子的に保存されている計画は「情報冷蔵庫」です。
  • p110
    • 文房具は高品質なものを買いましょう。
  • 👀タスクの追跡を電子でやるのはコストが高過ぎるんだよな
  • p115
    • イテレーションが終了するたびにボードを綺麗にすると良いでしょう。そうすれば、次のイテレーションを真っ白なボードで開始できます。
  • p122
    • テストは個人の仕事ではありません。チーム全体の責任です。
  • p128
    • バグトラッキングシステムとは、隠れたバックログなのです
  • p130
    • 見るからに忙しそうな人に声をかけようと思う人はいません
  • p133
    • テスターの仕事は「欠陥を防ぐこと」であり、収集することではありません
  • p141
    • 継続的インテグレーションはツールではなく態度です。
  • p152
    • 読む側に伝わるようなコードを書くのに魔法があるわけじゃない。文章を書くときと、まったく同じである。読者を理解し、明確な全体像を頭に描き、ストーリー全体につながるように詳細を記述していく。
  • p167
    • デモは、チームとビジネス側が信頼関係と結果責任を構築する場です。
  • 👀デモが信頼関係と結果責任の構築場であることに異論はないけど、それを構造化した「顧客がチームの作ったものをデモする」というメンローのアイディアは本当にすごいと思う。
  • p180
    • 振り返りをしなければ、あなたのチームが同じ間違いを何度も繰り返す光景を見る羽目になるだろう
  • p181
    • チームができることについて話し合わなければ、改善は実現できないでしょう。
  • p187
    • 問題は解決する前に理解する必要があります。
  • ペアでアクションプラン作って統合していくやりかたよい
  • p188
    • 最優先指令
  • p190
    • ふりかえりの事前準備
  • p193
    • 月一冊の技術書
    • 月一回の勉強会
  • p200
    • いつの日にか思い返して笑える日が来るでしょう。それなら今も笑いましょうよ。
  • p201
    • 「同じ立場になるまでは、他人を批判してはいけない」
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.