#今日の30分 ログ

ツイート

Clean Agile

#今日の30分 -1分。「Clean Agile」KindleでNo.3037まで。コーチングについての別意見。著者的には「意見が一致しない」とのことだけど、アジャイルの導入時期に言及すれば必要だということで一致するようにも思える。アジャイルが導入できたあとに関してはわからないけども。

— ざっきー dev (@zakky_dev) 2020年11月16日

#今日の30分 「Clean Agile」KindleでNo.3235まで。大規模アジャイルでのチーム間調整のプラクティスの話と、ソフトウェアクラフトマンシップの話。アジャイルが指すものが、当初目指したものからただのソフトウェアの高速構築プロセスに成り下がった結果、クラフトマンシップが生まれた、と。

— ざっきー dev (@zakky_dev) 2020年11月17日

#今日の30分 -2分。「Clean Agile」読了。イデオロギーとメソドロジー、価値にフォーカスするということについて。目指している理想、理念と、そこに行き着くための手段、プラクティス。メソドロジーは補助輪であり、いずれは外し、より先を目指さなければならない。目的を見失わないように。

— ざっきー dev (@zakky_dev) 2020年11月18日

Clean Agile　基本に立ち戻れ (アスキードワンゴ)

INSPIRED

#今日の30分 「INSPIRED」流し読み92ページまで。プロダクトマネジメントのあたりが弱いので読むことに。結局のところ文化作りの話になる。小手先の手段や変化だけでは達成できず、根本的に違うものに変わらないと何も改善しない。他の本の主張とどこまで重なるか気になるところ。 pic.twitter.com/Jw8CvXbS6G

— ざっきー dev (@zakky_dev) 2020年11月19日

#今日の30分 -4分。「INSPIRED」流し読み終わり。製品開発の人的構造、理念やビジョンを基盤として成果を目標とする、製品開発のプロセス、そして文化について。成果を目標にする、と言ったとき、やっていると答える人は多そうだよな。実際どうかは別として。出した機能数は結果。

— ざっきー dev (@zakky_dev) 2020年11月20日

#今日の30分 +2分。「INSPIRED」30ページまで。スタートアップ企業、成長期企業、エンタープライズ企業、製品開発失敗の根本原因。スタートアップ企業は産みの苦しみ、成長期企業は文字通りの成長痛、エンタープライズ企業は持続性の問題。成長期の時点でエンタープライズの問題が出たりしそう。

— ざっきー dev (@zakky_dev) 2020年11月21日

#今日の30分 −10分。「INSPIRED」36ページまで。従来のウォーターフォールプロセスの問題点、全体論的な製品。眠気がひどすぎてまともに読めた気がしない。製品という単語にモノだけでも開発まで含めただけでもなく、エンドユーザーの体験まで含めている。製品を取り巻くすべて。

— ざっきー dev (@zakky_dev) 2020年11月22日

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

ふりかえり

前回の結果

• タイミングを決めて「今日の30分」とは別枠で本を読む。
  • -
• ケーススタディはその場では読まず、まとめを書いてから読む。
  • -
• ハードな振る舞いの練習方法を相談する。
  • -

今回の追加活動

前回の活動を継続。

「Clean Agile」KindleでNo. 2873までの読書ログ #今日の30分

ツイート

Clean Agile

#今日の30分 +1分。「Clean Agile」KindleでNo.1774まで。QAと受け入れテスト、デモ、ベロシティ、小さなリリース、受け入れテスト。「リリース」という単語には注意が必要だな。技術的にデプロイ可能な状態であって、ビジネス的な良し悪しはこの単語には含まれていない。勘違いしやすそう。

— ざっきー dev (@zakky_dev) 2020年11月9日

#今日の30分 -4分。「Clean Agile」KindleでNo.1951まで。受け入れテスト、チーム全体、チームプラクティスのメタファーについて。メタファー自体はXP関係調べているときに知ったけど、エヴァンスのDDDで言うユビキタス言語と目指したところは一緒だったのか。言われてみれば納得。

— ざっきー dev (@zakky_dev) 2020年11月10日

#今日の30分 +30秒。「Clean Agile」KindleでNo.2225まで。チームプラクティス、持続可能なペース、共同所有、継続的インテグレーション、スタンドアップミーティング。テクニカルプラクティス、TDD。ルールを徹底したとき、TDDのサイクルは5秒程度になる、というのはちょっと衝撃。

— ざっきー dev (@zakky_dev) 2020年11月11日

#今日の30分 −5分。「Clean Agile」KindleでNo.2406まで。テクニカルプラクティス、テスト駆動開発、リファクタリング、シンプルな設計。テストの成功 = デプロイ可能と信じられないのは、自分がテストスイートに穴を開けた結果、他の人も開けるだろうと疑っているから、か。耳が痛い。

— ざっきー dev (@zakky_dev) 2020年11月12日

#今日の30分 −2分。「Clean Agile」KindleでNo.2534まで。テクニカルプラクティス、ペアプログラミング。アジャイルの価値基準と動物のサーカスについて。ペアプログラミングのコストの話、興味深い。直接的なコストは15%の増加という研究があるらしい。思っていたより少ないな。

— ざっきー dev (@zakky_dev) 2020年11月13日

#今日の30分 +3分。「Clean Agile」KindleでNo.2728まで。アジャイルへの移行、アジャイルコーチ、大規模アジャイルへの見解。大規模アジャイルへの見解はどうにもよくわからなかった。多様なチームを協調させるいつもの問題に対処するだけ、って話として理解したけど、本当にそうなのか？

— ざっきー dev (@zakky_dev) 2020年11月14日

#今日の30分 -4分。「Clean Agile」KindleでNo.2873まで。アジャイルのツールについて。物理的なツールを使いつつ、チームのコンテキスト、ワークフロー、パターンを分析し、それらをサポートするための電子ツールを導入すると良い。問題を理解してから、解決策として電子化、自動化を選ぶ。

— ざっきー dev (@zakky_dev) 2020年11月15日

Clean Agile　基本に立ち戻れ (アスキードワンゴ)

ふりかえり

前回の結果

• タイミングを決めて「今日の30分」とは別枠で本を読む。
  • 「超顧客主義」1章まで。
• ケーススタディはその場では読まず、まとめを書いてから読む。
  • -

今回の追加活動

• 「今日の30分」とは別枠で本を読む。
• ケーススタディはその場では読まず、まとめを書いてから読む。
• ハードな振る舞いの練習方法を相談する。

「Clean Agile」KindleでNo.1268までの読書ログ #今日の30分

ツイート

Clean Agile

#今日の30分 -4分。「Clean Agile」流し読み終わり。間違いなく今読んでおくべき本だ。アジャイルの不正利用の話、もともと目指していたものの話、大切にしたい価値の話、今なお続いているビジネスとの分断を埋めることについて。コーチングについての著者の思いと、それとは別視点での言及。

— ざっきー dev (@zakky_dev) 2020年11月2日

#今日の30分 +1分。「Clean Agile」KindleでNo.501まで。アジャイルの歴史と概要。ウォーターフォールがロイスの意図したものと違う形で広まった、って話は聞いたことがあったけど、そもそも勘違いされて広まったのか。思っていた以上にひどくてちょっと衝撃なんだけど。

— ざっきー dev (@zakky_dev) 2020年11月3日

#今日の30分 +1分。「Clean Agile」KindleでNo.837まで。ソフトウェア開発の特徴、アジャイルの概要、鉄十字のマネジメント、サークルオブライフ。アジャイルは速く進むことではなく、どれだけ上手く行っていないのかを速く知るためのもの。厳しい現実を突きつけるもの。

— ざっきー dev (@zakky_dev) 2020年11月4日

#今日の30分 -4分。「Clean Agile」KindleでNo.1070まで。アジャイルにする理由。プロフェッショナリズムとまっとうな期待。そりゃこういう期待は持つよなー。ゴミをリリースされたくないし、どこまでできているか知りたいし、生産性安定してほしいし、変更が容易であってほしい。

— ざっきー dev (@zakky_dev) 2020年11月5日

#今日の30分 +4分。「Clean Agile」KindleでNo.1305まで。プログラマーへのまっとうな期待と権利章典について。権利章典が好き。権利であり、それを成立させるための義務もある。サポートするアプローチもある。自律性を求められる。こういう側面に惹かれているのかもなあ。

— ざっきー dev (@zakky_dev) 2020年11月6日

#今日の30分 -2分。「Clean Agile」KindleでNo.1443まで。ビジネスプラクティス、計画ゲームについて。ストーリーポイントは誰がやるかによって変わる、みたいな悩みをよく聞くけど、これを読んでようやく理解した。長期的視野で捉えたチームとしての処理速度の算出ツールだコレ。

— ざっきー dev (@zakky_dev) 2020年11月7日

#今日の30分 -2分。「Clean Agile」KindleでNo.1584まで。計画ゲーム、ユーザーストーリー、ストーリーの見積もり、イテレーションのマネジメント。イテレーションの目標を、ストーリーを完成させてデータを生成すること、って言い切るのか。ものを作ることじゃないのな……。

— ざっきー dev (@zakky_dev) 2020年11月8日

Clean Agile　基本に立ち戻れ (アスキードワンゴ)

ふりかえり

前回の結果

• タイミングを決めて「今日の30分」とは別枠で本を読む。
  • -
• ケーススタディはその場では読まず、まとめを書いてから読む。
  • -

今回の追加活動

前回の活動を継続。

#今日の30分 ログ

ツイート

SCRUMMASTER THE BOOK

#今日の30分 +3分。「SCRUMMASTER THE BOOK」KindleでNo.1544まで。チームの5つの機能不全、チームを蝕む4つの毒、責任プロセスモデル、部族としての組織。約150人までで、それ以上は部族のネットワークで構築される、って話はどこかで似たようなことを聞いた気がする。なんだっけな。

— ざっきー dev (@zakky_dev) 2020年10月26日

#今日の30分 -3分。「SCRUMMASTER THE BOOK」KindleでNo.1753まで。正しいリーダーシップスタイル、分散化のテクニック、変化について。不確実性が高く、創造性が求められる場合において、旧来のリーダーシップスタイルは合わない。メンバーを支援するサーバントリーダーが望ましい。

— ざっきー dev (@zakky_dev) 2020年10月27日

#今日の30分 -2分。「SCRUMMASTER THE BOOK」KindleでNo.1915まで。スクラムマスターの道具箱について。守破離、システムルール、ポジティブさ、ファシリテーション。体得するまでプラクティスにとにかく従う、できたらその背景に気を配り調整する、そして最後に実践と経験から生み出す。

— ざっきー dev (@zakky_dev) 2020年10月28日

#今日の30分 -5分。「SCRUMMASTER THE BOOK」KindleでNo.2102まで。スクラムマスターの道具箱。ファシリテーション、コーチング、根本原因分析、インパクトマッピング。インパクトマッピングのこの使い方いいなー。闇雲に変化を促すのではなく、こうして計画的に考えて変化を促す。

— ざっきー dev (@zakky_dev) 2020年10月29日

#今日の30分 -11分。「SCRUMMASTER THE BOOK」読了。スクラムマスターの道具箱。大規模スクラムと、スクラムをより効果的にするためのチェックリスト。大規模の話、LeSSの話だけでちょっと残念。SAFeの話とか、もっと別の大規模アジャイルの話とかも触れられてたら嬉しかったかもなー。

— ざっきー dev (@zakky_dev) 2020年10月30日

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ

Clean Agile

#今日の30分 +1分。「Clean Agile」流し読みKindleでNo.1052まで。ボブおじさんによる、最初に提唱されたアジャイルは何を伝えたかったのかの解説書っぽい。もしくは本人が言っている通り、「うちの庭で遊ぶな！」という怒り。大本を知ってこそと思うので、こういう内容はありがたい。 pic.twitter.com/sHVQWcJYGd

— ざっきー dev (@zakky_dev) 2020年10月31日

#今日の30分 「Clean Agile」流し読みKindleでNo.2387まで。アジャイルはプロフェッショナリズムな規律のためのフレームワークである、という主張。ビジネス、テクニカル、プロダクト開発に関わる人々に、強い権利と規律を要求する。その要求に応えることで、速度や優位性の恩恵を得る。

— ざっきー dev (@zakky_dev) 2020年11月1日

Clean Agile　基本に立ち戻れ (アスキードワンゴ)

ふりかえり

前回の結果

• タイミングを決めて「今日の30分」とは別枠で本を読む。
  • -
• ケーススタディはその場では読まず、まとめを書いてから読む。
  • -

今回の追加活動

前回の活動を継続。

「SCRUMMASTER THE BOOK」KindleでNo.1268までの読書ログ #今日の30分

ツイート

SCRUMMASTER THE BOOK

#今日の30分 「SCRUMMASTER THE BOOK」流し読みKindleでNo.705まで。スクラムマスターはどういった役割と責務を担い、何を考えながら介入方法を選択しているのか。どういったスキルが必要で、何を見ながらその行動を選択するのか。求められる資質、行動は何か。みたいな話っぽい。 pic.twitter.com/UQdazb7t0U

— ざっきー dev (@zakky_dev) 2020年10月19日

#今日の30分 +1分。「SCRUMMASTER THE BOOK」流し読みKindleでNo.2067まで。観察、スクラムマスター道、チェンジマネジメント、守破離。知識的にはあることも多いけれど、実戦経験の薄さが個人的な問題だな、と反省。ここから数年取り組むことになる自分の課題。どうしたものか。

— ざっきー dev (@zakky_dev) 2020年10月20日

#今日の30分 -4分。「SCRUMMASTER THE BOOK」KindleでNo.465まで。スクラムマスターの概要、目標、責務と自己組織化したチームについて。流し読みが終わったので本読みへそのまま突入。スクラムマスターの目標を、チームと組織の自己組織化の促進だ、と明言するのは珍しい印象。

— ざっきー dev (@zakky_dev) 2020年10月21日

#今日の30分 -1分。「SCRUMMASTER THE BOOK」KindleでNo.654まで。役割兼務の落とし穴、サーバントリーダー、一歩だけ先を行く。そして心理状態モデルについて。役割兼務の話はスクラム現場ガイドにもあったっけな。マネージャとの兼務が目新しい感じ。決定権を持ってる影響かー。

— ざっきー dev (@zakky_dev) 2020年10月22日

#今日の30分 昨日分。「SCRUMMASTER THE BOOK」KindleでNo.878まで。心理状態モデル、ファシリテーションとコーチング、観察結果から考えるアプローチの段階別使い分けと、スクラムマスター道の話。スクラムマスターのレベルは3つで、それぞれチーム、チーム周辺、会社全体に焦点を当てる。

— ざっきー dev (@zakky_dev) 2020年10月24日

#今日の30分 +2分。今日分。「SCRUMMASTER THE BOOK」KindleでNo.1067まで。スクラムマスターのグループ、システムとしての組織、スクラムマスターチームの役割、クネビンフレームワークについて。自分たち自身が言っていることを実践できない、というのはありがちなことなのか。

— ざっきー dev (@zakky_dev) 2020年10月24日

#今日の30分 -5分。「SCRUMMASTER THE BOOK」KindleでNo.1268まで。メタスキルとコンピタンス、タックマンモデルの話。特定状況下での振る舞いの方針、具体的な振る舞い、状況をどう分類するか、かな。言われてみれば状況に応じて意図的に考え方切り替えたりしてるなー。あれの話か。

— ざっきー dev (@zakky_dev) 2020年10月25日

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ

ふりかえり

前回の結果

• タイミングを決めて「今日の30分」とは別枠で本を読む。
  • -
• ケーススタディはその場では読まず、まとめを書いてから読む。
  • -

今回の追加活動

前回の活動を継続。

「LeSS」読了までの読書ログ #今日の30分

ツイート

LeSS

#今日の30分 -3分。「LeSS」256ページまで。スプリントプランニング1と2について。前者は「何を」、後者は「どうやって」を決める。具体的には、どのチームもしくはグループがどのアイテムを実施するか、アイテムをどう実現するか。そのため、アイテムの分割はSP1に含まれる。

— ざっきー dev (@zakky_dev) 2020年10月12日

#今日の30分 -2分。「LeSS」263ページまで。スプリントバックログと調整・統合について。自然発生的な調整を支持する、って話は以前どこかで見た記憶がある。LeSSとは別の文脈だったはずだけど。メンバー自身が「誰」に対して「何を」調整するのか考えられるように場を作るのが必要か。

— ざっきー dev (@zakky_dev) 2020年10月13日

#今日の30分 「LeSS」269ページまで。調整しやすい環境、コードでのコミュニケーション、継続的にインテグレーションする。CIツールの使い方を、ずっと勘違いしていたのかもしれないな。壊れるのは前提で、壊さないようにするのではなく、フィードバックとして受け取って直すように動く。

— ざっきー dev (@zakky_dev) 2020年10月14日

#今日の30分 -1分。「LeSS」276ページまで。コミュニティ、設計ワークショップ、クロスチームミーティングの話。フィーチャーチームをベースとした場合、チーム間の関心事はどうしても問題になる。その解決策として、ボランティアで結成されたコミュニティを作り、議論や意見提案を推奨する。

— ざっきー dev (@zakky_dev) 2020年10月15日

#今日の30分 +3分。「LeSS」283ページまで。現在のアーキテクチャワークショップ、コンポーネントメンター、トラベラー、その他いくつかのガイド。LeSS導入直後の話が多い。旧来の組織構造で発生していた属人化と、それに対する対応策について。勉強会、チームの教師、コミュニティなど。

— ざっきー dev (@zakky_dev) 2020年10月16日

#今日の30分 -7分。「LeSS」290ページまで。レビューとレトロスペクティブについて。どちらも経験的プロセス制御の核であり、プロダクトや、プロダクトをどう作ったかを対象として改善する。レビューは市場とユーザーに対する適応、レトロスペクティブは経験し、わかったことへの適応。

— ざっきー dev (@zakky_dev) 2020年10月17日

#今日の30分 +6分。「LeSS」読了。オーバーオールレトロスペクティブ、システム思考、LeSS Hugeでのレビューとレトロスペクティブ。システムに着目するために、ボトムアップ的に考えない。システムは部分の総和ではない。部分よりも関係性、全体のダイナミクスに着目して改善点を見つける。

— ざっきー dev (@zakky_dev) 2020年10月18日

大規模スクラム Large-Scale Scrum(LeSS)

ふりかえり

前回の結果

• タイミングを決めて「今日の30分」とは別枠で本を読む。
  • -

今回の追加活動

• タイミングを決めて「今日の30分」とは別枠で本を読む。
• ケーススタディはその場では読まず、まとめを書いてから読む。

「LeSS」204ページまでの読書ログ #今日の30分

ツイート

LeSS

#今日の30分 +2分。「LeSS」219ページまで。LeSS Hugeのプロダクトバックログ、LeSSのDoneの定義について。LeSS Hugeでも、アイテムの祖先は3レベルに抑える。深くしすぎると、アイテムが顧客中心から外れ、技術中心のものになってしまいがち。OPBLとAPBLの両方に祖先列を追加する。

— ざっきー dev (@zakky_dev) 2020年10月5日

#今日の30分 -3分。「LeSS」226ページまで。LeSSのDoneの定義を拡張する話。あとリファインメントをちょっとだけ。まずはUndoneワークをすべてDoneの定義に含み、フィーチャーチームが解決できる状態にする。スプリント期間の短縮などはその後のさらなる改善の話。

— ざっきー dev (@zakky_dev) 2020年10月6日

#今日の30分 -2分。「LeSS」230ページまで。LeSSのプロダクトバックログリファインメントについて。オーバーオールPBRでどのチーム、どのチームグループがアイテムの詳細化を担当するか決め、複数チームPBRや単一チームPBRで担当したアイテムを明確化、分割、見積もりを行う。

— ざっきー dev (@zakky_dev) 2020年10月7日

#今日の30分 -5分。「LeSS」232ページまで。複数チームPBR、複数拠点でのPBRについて。眠くてダメ、集中できん。複数チームPBRでは、2チーム以上の全メンバー、顧客/ユーザー、ステークホルダーが参加し、OPBRで割り当てられたアイテムについてリファインメントを実施する。

— ざっきー dev (@zakky_dev) 2020年10月8日

#今日の30分 +1分30秒。「LeSS」238ページまで。最初のPBRについて。LeSSを始めた直後は多くのものが変化する。チーム構造はその筆頭。その影響もあり、それまで使っていたバックログやアイテムが使えなくなる。これをLeSS用に整理し直し、最初のLeSSのバックログを作る。

— ざっきー dev (@zakky_dev) 2020年10月9日

#今日の30分 -3分。「LeSS」245ページまで。アイテムの分割について。LeSSは扱っているプロダクトが大きいことから、要求も大きなものになりやすい。そうなると、1スプリントで終わらせるサイズにまで分割する必要がある。分割のときでも顧客中心、E2Eに薄くスライスすること。

— ざっきー dev (@zakky_dev) 2020年10月10日

#今日の30分 -4分。「LeSS」252ページまで。1スプリントあたり4アイテム、見積もり、スプリントプランニングについて。Doneの定義ならぬReadyの定義って話がどこかの本で読んだ覚えがあるけどどの本だったか。多分、スプリントプランニングで話すことは思っていたより少ない気がする。

— ざっきー dev (@zakky_dev) 2020年10月11日

大規模スクラム Large-Scale Scrum(LeSS)

ふりかえり

前回の結果

• タイミングを決めて「今日の30分」とは別枠で本を読む。
  • -

今回の追加活動

前回の活動を継続。