筋トレが最強のソリューションであるを読んだ
2018年18冊目
筋トレを通して、栄養学、睡眠の重要さ、計画性、不要な飲みなど、自律するための方法、計画に向けての行動、自信がいかに重要か、アウトプットに影響を与えるか?ということが1分で読めるコラムのように面白おかしく書いてあって、とてもサクサク読めるし、元気になる内容。
食べ物に関しては同時に読んでた本と同内容で、白い炭水化物を避けるような記述があった。
以下は面白いと感じたポイントの引用。
人生が必ず楽しくなる8つの行動
暗い顔したそこの君 !
①愚痴を言う暇があったら改善策を探せ
②言い訳するぐらいなら潔く謝れ
③妬むぐらいなら教えを請え
④僻まず素直に負けは認めろ
⑤陰口叩くぐらいなら人を褒めろ
⑥溜息つきたくなったら歌っとけ
⑦節約するなら家でしろ 、ケチは好かれん
⑧迷ったら筋トレしとけ人生楽しくなる 。
人生の選択を他人に委ねない。たとえ親でもだ。
に 「好きでもない事を嫌々やって成功をつかめると思うな 」の方がシックリくる 。熱意を持って打ち込める事に出会ったら簡単に離すな 。
これは本当にその通り。
なぜあんなにものめり込んでできるのだろう?と他人に思うことはある。自分にとってみたら、それは人の心と行動の関係を知ること、伝えること。
モチベーションは気持ち一つで変わるし、気持ち一つで仕事の成果が変わる。
これはチームプレイをした時に如実に結果として出てくる。
ジム以外での行動が勝負を分ける
ハ ードに筋トレしてもデカくならんと嘆いてるそこの君 !筋肉はジムで作られるんじゃない 。週 4回の筋トレで全力を出し切るのは当然だがちゃんと週 3 5回以上食べてるか ?週 8時間の筋トレをこなすのはいいが週 5 6時間以上寝てるか ?筋トレというゲ ームは面白いモノでジムの外での行動が勝敗を分ける 。
カイゼンジャーニーを読んだ
2018年17冊目
今年読んだ中でもトップ3くらいに入る楽しさ。
どうしたらチームのメンバーが輝けるか?
最近はそう考えることが多い。コードを書く時間が減り、チームのメンバーと話す時間を重視している。一つの課題を片付けたら次、そしてその次と一つ一つ対応して行く。この繰り返しを進めている。
考える時間を作らねば。
一冊を通して最高に決まった言葉はこれだった。
「あなたは何をしている人なんですか ? 」
「あなたの旅は何ですか ?次に目指す先はどこですか ? 」
チームのアイディア意見を集約して現在最高と思う解を出す。そしてそれを皆で進められるように準備する。これがいまの役割だと思っている。そしてその方法を会社のすべてのプロジェクトに広めたい。これが叶えば次の旅に出ようと思う。今はまず目の前の役割に全力を出す。これが自分が組織にいる最大の理由だと思う。
1on1
会議やタスクによって1ヶ月に一度の1on1を出来ないのだとしたら上司やリーダーを降りた方が良いというのは辛辣だが真理
スクラムとは、振り返りながら改善していく経験主義を根本思想としている。
経験主義とは経験したことからの学びを重要視し不確実な状況においても漸進的に物事を進めていく考え方。
漸進的とは?
物事を順を追って目的を実現していく様。
例 漸進的な改革
ソフトウェア開発とは、泥臭くて感情に左右されやすい人間の営み
プロセスやプロダクトを継続的にふりかえり早く失敗する Fail Fast の精神が漸進的な開発を後押しする。
スプリントゴールとは?
スプリントプランニングの要求からスプリントゴールを明文化する。
課金決済機能開発スプリント のような書き方
それをホワイトボードや模造紙に貼って全体の共有事項とする。
完成の定義と受け入れ条件
カンバンの方法を変えている点に注意
Product Backlog
Sprint Backlog
Doing
Done
完了や完成の定義を貼っておく
完成の定義と受け入れ条件とは?
完成とは?の定義をプロダクトオーナーと開発メンバーで同じ認識を持つ
例えば、ステージングで動作する
ユニットテストをパスしている
受け入れ条件を満たしている
レビューが済んでいる
というような内容
受け入れ条件とは機能非機能を含めて、このリストを満たしていれば要求を確かに実現していると明文化されているリストのこと。
完成の定義と受け入れ条件をクリアして初めて完了となる。
インセプションデッキの10の問い
これはミーダーが作るのではなく、チームで作る
われわれはなぜここにいるのか?
ダニエル・キム
成功の循環モデル
行動の質は思考の質によって決まる。
思考の質に影響を及ぼすのは関係の質、つまりチームワークの質。
チームワークを高めるには共通認識が必要になる。
WORKING agreement
チームの生産性をより高めるための取り組み
期待もプロジェクトマネジメント
内側の期待 チームにおける期待
外側の期待 プロジェクト関係者における期待
ドラッガー風エクササイズ
①自分は何が得意なのか ? ②自分はどうやって貢献するつもりか ? ③自分が大切に思う価値は何か ? ④チ ームメンバ ーは自分にどんな成果を期待していると思うか ?
第五の質問
チームメンバーが、本人に対してその期待はあっているか?を問う
危険なシグナルをデイリースタンドアップで見つける質問
3つ目の質問テンプレードが良いので早速使う。あと、スプリントゴールを達成するためにという頭の言葉は良い。気がつくと自分のタスクの中に入ってしまうので、それを防ぐ事ができる。
□開発チ ームがスプリントゴ ールを達成するために 、私が昨日やったことは何か ? □開発チ ームがスプリントゴ ールを達成するために 、私が今日やることは何か ? □私や開発チ ームがスプリントゴ ールを達成するときの障害物を目撃したか ?
意見を聞く時は考えた後にファイブフィンガーを使う
本数の少ない人から聞いて、意見に対して批判はしない。二度とネガティブな事が言えなくなるから。
5本 :とってもうまくやれている 4本 :うまくやれている感触あり 3本 :可もなく不可もなく 2本 :不安は少しある 1本 :全然ダメで絶望的
モダンアジャイルの基本原則
人々を最高に輝かせる
安全を必須条件にする
高速に実験&学習する
継続的に価値を届ける
そうなれば 、マルチタスクになり 、スイッチングコストが増加し 、遅延が徐々に膨らみ 、体力が消耗され 、失敗が増え 、手戻りが発生するという悪循環が生まれます 。
本当にそうだよ。改善はやらないことを決めることに他ならない。
プロジェクトにおいて度々起きる各チームの優先度と情報共有、衝突
むきなおりとYWT
スクラムオブスクラムは他のチームとの橋渡しメンバーで集まって話をする時間
スクラムオブスクラムを考えると自分がスクラムを導入しようと考えたきっかけに行き着く
組織が横断的につながる
組織が上下にあるのではなく各プロジェクトやメンバーが自己組織化を図る
その意識を持つことが重要
自立分散型組織という高いレベルの組織で素早く価値を提供し、顧客価値最大化を望むのであれば、スクラムの本質や概念や文化が組織に浸透するのか近道ではないか?
インタビュー
このラポール空間とはつまり心理理的安全な状態を作ることに繋がりそうだ。
ペ ーシング (話すスピ ードや声のト ーン 、まばたき 、呼吸などのペ ースを合わせる方法 )を用いたり 、ミラ ーリング (表情や飲み物を飲むタイミングなどを鏡のように振る舞う方法 )などのテクニックを使うことで 、相手との間にラポ ール空間という安心感や信頼関係を構築していくことができます 。
メンバーの状況に合わせてスタイル、リーダーシップを変えるSL理論。これは変えられるようにスタイルを考えておきたい
① S 1 (教示的リ ーダ ーシップ ) :具体的に指示し 、事細かに監督する
② S 2 (説得的リ ーダ ーシップ ) :こちらの考えを説明して 、疑問に応える
③ S 3 (参加的リ ーダ ーシップ ) :考えを合わせて決められるよう仕向ける
④ S 4 (委任的リ ーダ ーシップ ) :仕事の遂行の責任を委ねる
定期的に出てくる、あなたは何をする人なんですか?
この問いは厳しいけど、答えは一つ。
チームの課題を解決してチームメンバー全員を輝かせられる人。
そのためのアクションは?
あとがきの印象的な言葉
これは自発的に取り組むときに大事なこと。
集中するべきなのは 、自分から踏み出し 、表し 、巻き込むサイクルを繰り返し 、学びを蓄積しようとすることです 。この渦の中から 、予測しえない変化が起きることを楽しみに待ち構えながら 。
これだ。
「あなたは何をしている人なんですか ? 」 「あなたの旅は何ですか ?次に目指す先はどこですか ? 」
スクラム現場ガイドを読んだ
2018年16冊目
なんか最近ペース落ちてた。
以前読んでたユースケース駆動開発を夏期休暇の間に読み直したりしてた。
ユースケースからロバストネスへのモデリングは慣れたら強力なモデリングの方法だと再認識。
スクラム現場ガイド、文字が多く結構読むのがタフだった。
2章
p60 情報を提供しよう
現在の状況が辛い状況であっても、ほとんどの人はそこから動こうとしない。もっといい方法があると本当に確信するまでは穴から出ようとしないもの。
あなたの役割は新しい提案をわかりやすく伝え、人々が考えを変えるまで辛抱強く待つだけだ。
結局のところ、あなたが自由自在に操れるのは自分自身だけだ。
変化に人々を巻き込むという苦労の多い仕事だが、元気を出していこう。
拒絶されるこたも多いだろう。ブレないでいこう。
ポジディブでいよう。強くあろう。こいつは大変なんだ。
3章 モデル
チームコンサルタントとコアチームメンバー
この役割分担は面白いし、マトリクスは必見
スクラムマスター、プロジェクトオーナー、開発コアチームの向いている人、利点欠点が記載されている。
p71
人数は重要
コンサルタントを含めても9人を超えると納期が伸びる研究あり
トラッキング、ドキュメント、デザインがしっかりしていれば人数の追加の影響を受けにくいと1999に出ている。スツィーブマコネルの論文
人月の神話では語られていない部分。
p182
ストーリーの粒度
ユーザーがやりたいと思うアクションの最小のもの、あるいはビジネス価値がある最小の機能
エポック、テーマ、ストーリー、タスクの粒度がわからなくなったら再度読もうと思う。
この本を読んだ一番の収穫は、コアチームとコンサルタントチームを別けるアイディア。
コアチームとは別に外部から支援してもらうコンサルタントチームを機能横断として持っておき、必要な際は支援してもらうと言う体制図は、現実として応用ができそう。
仕事が4倍速くなる世界標準のチーム戦術を読んだ
2018年15冊目スクラム
スクラムとは
リズムを大切にして、チーム全員が報告する責任を持つ進め方
スクラムはラグビーボールでチームが協力してボールを運んで行く事
サザーランドの本ということで全体的にエモさはある。幸せという言葉が出てきたときはびっくりしたが、幸福度はベロシティに時間差で現れるというのは納得した。仕事とプライベートと分けるよりも同じとして考える方が自分には合う。
p24
意味のない仕事に人生を費やす人がいてはいけない
ビジネスとしてダメなだけでなく、その人の心をダメにしてしまう
人の心を扱うのは他の本ではなかった。
p26
アジャイル開発宣言
つぎの4点に価値を置く
プロセスやツールよりも個人との対話
包括的なドキュメントよりも動くソフトウェア
契約交渉よりも顧客との協調
そして計画に従うことよりも変化への対応
p37
この本の目的
人がもっとも効果的にベストな仕事をするための本質的な方法を探り、なぜ仕事の計画や見積もりがうまくいかないのか、残業が増えるとなぜプラジェクトはさらに遅れるのかといった事を明らかにして行く。
どの本にも出てくる原著論文
新たな新製品開発競争
The New New Product Development Game
p54
紙飛行機のワーク
サイクルを3回繰り返すとスピードは2倍から3倍 実は少なくとも2倍向上する
p58
仕事は喜びの表現であり、より高い目標に向かって進むべき。不可能ではない。ただそれには練習がいる。こういう考えはサザーランドだからなのか。とても人間的な側面から物事を進める印象を持つ。
p67
戦略としての最終目標を決めるのは経営陣の責任だが、どうやってその目標を達成するかを決めるのはチームの仕事
p83
スクラムマスターの発生理由
そして役割
各スプリントの最後に、
メンバー間のやりとり、業務、プラセスについてチームで見直す
プロジェクトの進め方で変えられるところはないか
仕事を進める上でどこが一番の難関だろう
この2点に答えが出せれば、チームのスピードは上がる
p116
マルチタスクのスピード変化は面白い
ワインバーグの著書
システム思考法 ソフトウェア文化を創るが参考に上がっているので読んでみたい
p135
自我消耗
何かを選択し決断する行為は消耗する
p156
絶望的に見積もるのが苦手
相対サイズを使う
ドッグポイント
p175
ストーリー
エピック
クイックのスクラムマスターとして、スクラムの意義やり方を伝える必要がある。なぜならプロジェクトを動かすチーム自ら可視化し、課題を解決するチームを作るためだ。
INVESTの法則
ストーリーはこの基準に沿って進める
p197
振り返りで幸福度を測る
4つの質問は目から鱗
幸福度とベロシティは数週間遅れで同じ動きをする
p199
優れたチームを作る要素
これは必ず念頭に置きたい
主体性
目的意識
具体的な表現として、
自分の運命を自分でコントロールできること
何かについて自分が上達しているという実感
そして自分よりも大きな何かに力を尽くしているという感覚
p291
スクラムはゴールを設定し、系統立てて、一歩一歩達成に近づいていく。さらに大事なのは何がゴールの達成を阻んでいるのかを見つけ出す点。
アジャイルな見積もりと計画作りを読んだ
2018年13冊目
スクラムを調べる中で多くの方々に参考にあげていたので読んでみた。
良書すぎて驚いた。
内容としては、いかにタスクベースでなくフィーチャベースで見積もりと現実を継続して進めていくかという話。
ついつい普段からタスクベースの見積もりをしているので目から鱗。
リリースプラン、イテレーションプラン、デイリープランを元にチームのベロシティ(速度)を計測しながらリリース日を決めていく流れはチームに取り入れていきたい。
そもそも見積もりの不確実性をもっと意識しようと思った。理想予想工数とリリース日を一致させるのは不確実性を無視した勘でのリリースにしかすぎず、そりゃ遅れも出るわという印象。
経験と勘と度胸ベースの見積もりをやめ、チームの開発速度を可視化できる術を試していこうと思う。
そのためにはイテレーションベースの開発文化を作っていかないといけない。結局は文化チーム組織作りにつながる。
DevOpsにもつながる部分だ。
以下はきになる点のメモ
毎度出てくる不確実性のコーン
プロジェクト初期では60-160の誤差がある
20週の見積もりは12週から32週のズレがあるという事。モニタリングの重要性。
1章 計画の目的
良い計画とは?
リスクを軽減する
不確実性を減らす
意思決定を支援する
信頼を確立する
情報を伝達する
プロジェクトの成功とは?
予定通りの期間で予定通りの予算で、最初に定義した全てのフィーチャを満たしていること
ほんとに?
最初に定義したフィーチャが、価値に見合わない場合は失敗では?
では失敗とは?
作者は、最初に定義したアイディアより良いアイディアを最後まで誰も思いつかなかったプロジェクト。としている。
ただ最初の定義に入っていないからと却下されるのは、ユーザーにとって満足のいくプロダクトにはならないだろう。
積極的に変更したいと思える状況
これは、学習や過ちに気付いた時にしか起きない気持ち。
プロジェクト初期で全体を予測することを不可能とする立ち位置
その中でアジャイルな計画作りとは?
計画よりも計画作りを重視する
変化を促進する
計画そのものは容易に変更できる
プロジェクト全体に渡って繰り返される
作業の完了ではなく、フィーチャの提供をゴールとする
顧客には作業の完了はどうでも良い。
フィーチャを単位とすべき。
作業ベースだと、作業の抜けがないかを探す。実際は作業の抜けではなく、フィーチャの抜けに気を使わなければいけない。
仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する。
問題とゴール
見積もりがコミットメントになっている
アジャイルとしての考え方
変化への適応を優先する
ここがウォーターフォールとの大きな違いか。
より身軽に身動きの取れる手法を選択するならば、アジャイル、かっちりと変化が起きにくいとすればウォータフォールとする。
のようなチームの分け方は良いと思う。
ユーザーストーリーは要求を表現する手段。
ユーザー目線で機能の概要となる。
ユーザの種類として、機能や性能が欲しい。それはビジネス価値のためだ。というテンプレート。
例 本の購入者としてISBNで本を検索したい。それは
探している本を素早く探すためだ。
ストーリーカードはスタート地点に過ぎないので、それをベースにオーナーと要求仕様を話したりドキュメントにまとめたりする
10km競争と60分競争
この例えは面白い。60分競争では、ゴールが決まっていない。その期間でどこまで遠くまで走れるかを競う。
ストーリーボードのポイントと、スプリント期間によって、見積もりが出来るというのはとても腑に落ちた。これは皆に共有せねば。
4章
ストーリーポイントと理想日の話
どちらもベロシティで割れば結果が出る
第8章見積もりの技法
プロダクトオーナーはプランニングポーカーに参加する
プランニングポーカーには全エンジニアが参加する フロント、デザイナもそう
見積もりでは絶対的な制度は必要ない
8章
ストーリーポイントは純粋に大きさを表す
理想日ベースよりも見積もりが早い
理想日が違う問題。
誰がやるかわからないから理想日が違うならば技術の標準化、平均化が必要
14章
1ポイントのストーリーでも平均時間が異なる。錯覚しないように。
2ポイントよりも1ポイントのストーリーが大きいことはある。
イテレーション報告書
ペロシデイ平均値
ペロシデイの達成ストーリポイント内訳
次回イテレーションへのアクションプラン
そんなところか。
SCRUM BOOT CAMP THE BOOK を読んだ
2018年12冊目
スクラム開発をチームで進めるにあたり起こりそうなストーリーが説明とイラスト漫画で解説するのでスラスラ読めた。今は2周目。
スポーツで言う戦術、フォーメーションとしてチームでプロジェクトを進めるノウハウを求めて読み始めた。短いスパンの振り返りを繰り返しながら、細かな修正をかけて行くスタイルは自分のチームとあっているように感じる。結局見積もっても実績との乖離を可視化するすべがなく、1日1日遅れが積み重なって行くのであれば、一つのスプリント毎に遅れや進みが見えるのであれば都度リカバーできる。
理解は容易で習得が難しいと言われるのはこのあたりだろう。なんとなく出来そうに感じてしまうが継続してやり続けるにはスクラムマスターのような人が慣れるまでは声を出していかないといけない。
慣れてきたらスクラムマスターが自身をクビにして自立、自律したチームが残る。これを繰り返していくと社内にスクラム文化が残る。こういう役割を担っていかなくてはと思った一冊。
読んでいて疑問に思った点。
解決したら追記していく予定。
1点目
要件をまとめたバックログの項目と、バックログからブレークダウンした、バックログタスクの予定工数がポイントや作業量での相対見積もりとなる。この時のポイント粒度をどうやって揃えるか。
同じポイントを使うのであれば、2時間単位の小さなポイントと、5人日のポイントの粒度を合わせる必要がある。
要件から作成したバックログタスクは1週間が望ましいようだが、ブレークダウンしたタスクは2時間1ポイントくらいの粒度で運用したい。
2点目
バックログタスクで大きく工数やプロジェクトの予定納期をガントチャートで線引きして、毎回のスプリントレビューでリリース日をプロダクトオーナーが変更調整し続けるということで良いのか?
毎回見える化しているから、逆に楽なのか?作業量は大きくふえそうなきがするが。
3点目
マークアップやフロント、バックエンドのメンバーが同時にタスクを着手する場合細かく刻んだタスクを各職種毎に対応すると思うが、大元のタスクをどうやって切っておくのか?
切り方が重要な気がする。実際の運用レベルでのタスク切り分けを知りたい。他本を漁る。
鬼速PDCAを読んでる
2018年11冊目
最近の効率化の一つとして参考にしている。
PDCAの検証て行われるのは、うまくいかなかった原因に着目しがち。
うまくいった原因も分析し、次も再現性があるかを明確にすることが重要。
WIP