永瀬美穂のレビュー一覧
-
-
-
-
-
-
-
Posted by ブクログ
スクラム開発の基本を漫画形式で学べる
メモ
1. プロダクトバックログ: 実現したい要求をリストにして並び揃え、常にメンテナンスして最新に保つ。価値、リスク、必要性が具備。ユーザーストーリー形式で書くことが多い。
2. スプリント: 1〜4週で期間は固定、計画設計開発テストとリリースに必要なすべてのことを行う。
3. スプリント計画ミーティング: スプリントの目標を簡潔にまとめスプリントゴールを決める。タスク一覧(スプリントバックログ)を計画する。タスクは1日以下の単位とする。開発は合意内容を完了させることに全力は尽くすが約束してるわけではない。
4. リリース判断可能なプロダクトとは、完了の定義
* コードレビュー
* チェックイン
* ユニットテスト
* カバレージ
* ドキュメント
* セキュリティ
* 性能
* デプロイ
5. スプリントレビュー: 動作するプロダクトをオーナーがレビューする
見積もり
- バックログの工数はわかりやすいものを基準としておき、感覚で置いていく。フィボナッチ数列の値を使うとやりやすい。
- 実際にスプリントでいくつ分消費できたかがわかるとベロシティがわかる。そこから全体のバックログを消化するのに必要なスプリント数が割り出せる
-
Posted by ブクログ
# 多方面からプロダクトに立ち向かうための、戦略的組織論
## 面白かったところ
- 組織とソフトウェアアーキテクチャは密接に関わり合っており、人こそがソフトウェアであり組織を良くも悪くもすることがわかった
- 自分が管轄外のプロダクトには適切な境界線（interface）を切って、異なる概念を持ち込まない・持ち込ませない制約があるとイイことを改めて学べた点
## 微妙だったところ
- 引用がとても多く、著者自身の熱い思いがあまりなかった点。チームトポロジーのフレームワークはすごいしやってみる価値はあるんだけど、イマイチ引き込まれれる何かがなかった。
## 感想
現場での課題図書として上がっていた一冊。なにもないところから著者の真意を汲み取ることは難しいだろうなとは思いつつ、現場での組織構成を擬えて見るとかなりイメージが進んだ。
人間一人の認知負荷にも限界があり、チームのそれにも限界がある。この前提を踏まえたうえで、自チームで担当すること・しないことのドメイン境界を切ってinterfaceでハーネスをかける。
「〇〇チームは▲▲機能の担当」という境界を Package by Featureで区切る。多機能とやり取りするときは必ずInterfaceを切って、他チームとコミュニケーションを図る。
なるほど。今やっている僕らの軌跡はこの本からやってきたんだと腑に落ちた。 -
-
-
Posted by ブクログ
アジャイル開発に関してはアジャイルサムライを読んでざっくり理解して普段から行なっていたが、各役割の名前、各イベントの名前などは抜け落ちていたので改めて把握するいい機会になった。
また、開発メンバーへの教育に関しても考えさせられるいい書だった。
機能要望と実際のメンバーの力量や残工数のバランス取りが難しいなーと感じていたが、
本書で言われている、プロダクトオーナー兼スクラムマスターはあまり良くないという状況にまさに合致していることに気がつかされた。
メンバーの設計力や俯瞰力を考えるとなかなか任せにくい状況なのだが、なんとかスクラムマスターとして動ける人を育てられるようにしたい。
また、自分のチームを振り返ると、自己組織化されたチームにはできていない。
全員に心構えやどういうチームにしていきたいかを発信していけると良さそうだと感じた。 -
-
-
Posted by ブクログ
チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
エンジニア、コンサルタントのマシュー・スケルトン氏、マニュエル・パイス氏の著書です。ソフトウェアの開発、運用組織に関する書籍になります。
【本書で学べること・考えること】
- コンウェイの法則
- 一般的な組織構造がソフトウェアに与える影響
- 組織図とコミュニケーションギャップ
- 認知負荷
- 逆コンウェイ戦略
- チームファースト思考
- チームのアンチパターン
- 4つの基本的なチームタイプ
- 3つのチームインタラクションモード
- 組織構造のプラクティス
読んでみての感想です。
この本のベースは、「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」というコンウェイの法則をベースにしています。
組織構造をあるべきアーキテクチャに合わせて変化させることで、ソフトウェアのアーキテクチャを最適化するという思想です。
コンウェイの法則、言われてみればですが目から鱗です。
基本となるストリームアラインドチーム（DevOps）を中心に基盤を支えるプラットフォームチーム、補助するイネイブリングチーム、専門的なサブシステムを提供するコンプリケイテッド・サブシステムチームという4つの基本的なチームが、コラボレーション、X-as-a-Service、ファシリテーションの3つのインタラクションので関わり合う構造のプラクティスを紹介しています。
自社サービスの会社ではない場合、完全に適用することはできないですが、組織の構造、認知負荷、チームの定義、タックマンモデルなど、チームに関する知見は大いに参考になると思います。
マネージャーやマネージメントを目指す方には、是非、一読してほしい良書です。 -
-
-
-
Posted by ブクログ
スクラムlikeから、本格的にスクラムをやってみたいと思って読んだ本 (N氏オススメ)
ストーリ調で分かりやすく、頭に入ってきやすかった。
全体像を掴むには大変いい本だと思った。
# 面白tips
- リリースレゴ: リリースの度に、レゴ組み立ていく
- モブプログラミング: みんなでコーディング
# 細かい疑問点
- 運用フェーズでは、結構問合せタスクだったりなど飛び込み入ってくるがそれにはどのように対策するのか
- スプリントゴールに関係してないけど、これは3hで終わるしやっておいた方がよくない的なやつの扱い方
- ユーザストーリでプロダクトバックログ切っていくと、非機能要件的なものは優先度下がったり漏れちゃいそう -
Posted by ブクログ
アジャイルサムライを読んで市谷さんがカイゼンジャーニーを書いたように、西村さん達はこの本を書いたのかな。
アジャイルサムライではハードルが高すぎたり、つまずきやすい点のフォローが不足しているのをカバーするには
どうしたらよいかを考え、実際によく詰まりやすい事例を示し、 実践に適用しやすいシナリオで解説されている。
初心者にもわかりやすい順で言えば、この本、カイゼンジャーニー、アジャイルサムライの順なのかもしれないが、
人それぞれ経験やわかりやすさも違うだろうから読む順番とかどれがベストかは決めづらいかな。
アジャイルサムライで全て理解できていたとしても、それぞれの書籍に新たな発見はありそうだし。
プチョーはなにやってんのかなーと思いつつ、みんなで同意して残業してやりきるのってちょっとうらやましい。ブラックかなと思いつつも胸が熱くなる。 -