高木正弘のレビュー一覧
-
Posted by ブクログ
> ソフトウェアは、業務側が「こうしたい」と考えていたことを、ソフトウェア開発者が翻訳したようなものになってしまうことが多い。できあがったソフトウェアがドメインエキスパートのメンタルモデルをきちんと反映できているわけではなく、仮にできていたとしても部分的なものに過ぎない。時がたつにつれて、この断絶のコストは高くつくようになる。開発にかかわったメンバーが他のプロジェクトに移ったり転職したりした時点で、ドメインに関する知識のソフトウェアへの翻訳は消え去ってしまう。（事業価値をもたらすのは難しい）
> ここで言う「チーム」とは、ドメインエキスパートとソフトウェア開発者がどちらも参加しているものだ。「私たちとあの人たち」ではない。常に「私たち」だけになる。（DDD がどのように役立つか）
良書。
決して読みやすい本ではないが、それは説明の悪さにあるのではなくて、DDD を現実のサービスに適用する際の難しさ（自由度の高さ）にあるのではないかと感じる。
概念的すぎず、ドメイン、バリューオブジェクト、エンティティなど DDD の基本的な概念が定義から記述されている。慣例はそれとして、「本来それらの概念はどのようなものであるべきか」を DDD の立場から考えるための視点を与えてくれる。
> ソフトウェア開発の世界では、...豊かな振る舞いを備えたドメインの概念を設計するのではなく、まずはデータの属性（カラム）と関連（外部キー）を考えてしまう。（エンティティ）
> Java の世界では、インターフェイス名の後ろに Impl を続けたものを、実装クラスの名前とするのが一般的だ。...実装クラスをこんな名前にできるということは、そもそもセパレートインターフェイスなど必要なかったという証ではないだろうか。（セパレートインターフェイスは必須なのか） -
-
-
-
-
-
-
Posted by ブクログ
スクラムを始めたときから、何回も開いている。
ここに答えはないが、考えるための要素がある。
これまで一気通貫で読んだことがなかったので、通しで読んでみた。
結果、あらためてスクラムは難しいと思った。
予想として良しとするのか、コミットメントしてやり切るのか。
どっちが正解なのかわからない。
本気なのか適当なのか。
本気でやってても、他人からみたら適当レベルに見えるかもしれない。
ただ開発はチームで行っていて、人と一緒にチームを形成している。
一人ひとりが異なるのだから、どのチームでも正解なんてないのと同じように、
そういうことを受け取られる可能性の一つがスクラムなのだと思う。
スクラムを用いることで、チームに最低限のルールを示し、
一人ひとりが異なることを前提に、チームで前進していくしかないのだろう。
（以下抜粋。○：完全抜粋、●：簡略抜粋）
○私自身は、開発チームはすべからく、各スプリントで何を届けられるかを予想（見積もり）しなければならないということに賛同する。しかし、予想を基にコミットメントを導きだすことで、利益を得られる開発チームも多い。コミットメントによって、プロダクトオーナーと開発チームの間にも、開発チームの内部にも、相互の信頼関係が築かれる。（P.18）
○プロダクト開発の初日には、自分たちが何をしているかについての情報は最も少ない。開発が続くにつれて、少しずつ学習していく。それではなぜ、最も重要で、おそらくやり直しの利かない判断を初日、もしくは初期に行おうとするのだろうか？（P.38）
○ただ実際のところは、ほとんどの技術的ストーリーはプロダクトバックログに入れるべきではない。代わりに、これらのストーリーはビジネスストーリーの関連タスクとするべきだ。（P.88）
●プロダクトバックログアイテムの例：PBIの形式は、フィーチャー、変更、不具合対応、技術的な改善、知識の獲得
○みんなでグルーミングすることでさまざまな意見がを引き出せることを知っている。みんなの意見や、それぞれの立場から視点を活かせば、重要な情報をもれなく引き出せる。また、いろいろな立場のチームのメンバーをグルーミングに参加させると、プロダクトバックログについての明確な理解を共有できる。（P.102）
○見積もりはコミットメントではない（P.120）
○技術的負債があまりにも増えすぎてしまうと、そのプロダクトに関して何らかの予測をするのはほぼ不可能になる。（P.139）
○負債を返済する手段として一括払いを選ぶことが多い。それよりは、何回にも分けて、適切なタイミングでインクリメンタルに既知の技術的負債を返済していくほうがよい。（P.154）
○チームを小さく保つ理由を以下のように述べている。
・誰かがやってくれるから自分はやらあくてもよいという「社会的手抜き」が少ない。
・小さなチームは建設的なやり取りが頻繁に発生する。
・調整に必要な時間が少ない。
・誰も陰に埋もれることがない。
・小さなチームのほうがメンバーを満足させることができる。
・有害な過度の専門家が発生しにくい。（P.197）
●Appelo による7段階の権限レベル、通知、説得、相談、合意、助言、確認、委譲（P.218）
●伝統的なプロジェクトマネージャーの責務は一貫性の管理、スコープ、時間、コスト、品質、チーム、コミュニケーション、リスク、調達。PO、SM、開発チームはこれらの責務を分割、あるいは共有する。（P.226）
○事前にきちんと計画を作れると思うな（P.235）
●プランニングのレベル（P.244）
・ポートフォリオ：おそらく年単位
・プロダクト：数か月単位、あるいはもっと長期
・リリース：3か月から9か月
・スプリント：1週間から1か月
・デイリー：毎日
○MRFは最低限の「必須」フィーチャーを表すものだ。つまり、顧客が期待する価値や品質をもたらすために、今回のリリースに必ず含める必要があるフィーチャーである。リリースプランニングの中でも重要なのが、今回のリリースにおける真のMRFが何なのかを再評価して見直すことだ。（P.300） -
-
-