Submit Search
Upload
ウォーターフォールとアジャイルのフェアな比較
•
18 likes
•
9,596 views
Yoshitaka Kawashima
Follow
おもにエンタープライズの開発において「アジャイルってどうなの?」という方への説明資料です。
Read less
Read more
Software
Report
Share
Report
Share
1 of 24
Download now
Download to read offline
Recommended
ブログでもいろいろ解説しています。 http://little-hands.hatenablog.com/entry/top ドメイン駆動設計屈指の難解な概念「境界付けられたコンテキスト」について解説します。 --- 公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています) bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. 境界付けられたコンテキスト 特定のモデルを定義・適用する境界を明示的に示したもの。 代表的な境界の例は、サブシステムやチームなど。 まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。 境界付けられたコンテキストは、2つの観点から解説が必要でしょう。 ・概念としての境界付けられたコンテキスト ・境界付けられたコンテキストをどう実装に落としこむか 今回のスライドでは、概念の方の説明をしたいと思います。
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
Koichiro Matsuoka
アプリ「ニュースパス」をマイクロサービスで開発してみた泥臭い体験談です。
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
2022-03-05 YAPC::Japan::Online 2022
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
ドメイン駆動設計 Domain-Driven Design ( DDD ) 準備 / スタートアップ / ブラッシュアップ / チャレンジ / 参考書籍 /
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨
第16回Creators MeetUp http://atnd.org/events/50388 技術的内容に対して「それは違うよ!」を激しく指摘することをマサカリを投げると例えてよく言われます。彼らの指摘は厳しく、とても厳しく、そんな言い方しなくても!ってくらい厳しい。そんなマサカリの受け方をレクチャーしちゃいますっ! ▼後日談ブログ記事 【祝ホットエントリー】「マサカリを受け止める心得」ってスライドを公開した後日談。やっぱ発信をやめたくはないなあと思えた。 http://www.rechiba3.net/entry/masakariafter/
エンジニアから飛んでくるマサカリを受け止める心得
エンジニアから飛んでくるマサカリを受け止める心得
Reimi Kuramochi Chiba
エヴァンス本を読んだことがない人、ネット上の情報を聞きかじったことがある程度の人、そんな人たちを対象に、ドメイン駆動設計について、わかりやすく説明してみました。
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
図解で学ぶ「Lean UX」
図解で学ぶ「Lean UX」
図解で学ぶ「Lean UX」
Katsuhito Okada
Recommended
ブログでもいろいろ解説しています。 http://little-hands.hatenablog.com/entry/top ドメイン駆動設計屈指の難解な概念「境界付けられたコンテキスト」について解説します。 --- 公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています) bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. 境界付けられたコンテキスト 特定のモデルを定義・適用する境界を明示的に示したもの。 代表的な境界の例は、サブシステムやチームなど。 まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。 境界付けられたコンテキストは、2つの観点から解説が必要でしょう。 ・概念としての境界付けられたコンテキスト ・境界付けられたコンテキストをどう実装に落としこむか 今回のスライドでは、概念の方の説明をしたいと思います。
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
Koichiro Matsuoka
アプリ「ニュースパス」をマイクロサービスで開発してみた泥臭い体験談です。
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
2022-03-05 YAPC::Japan::Online 2022
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
ドメイン駆動設計 Domain-Driven Design ( DDD ) 準備 / スタートアップ / ブラッシュアップ / チャレンジ / 参考書籍 /
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨
第16回Creators MeetUp http://atnd.org/events/50388 技術的内容に対して「それは違うよ!」を激しく指摘することをマサカリを投げると例えてよく言われます。彼らの指摘は厳しく、とても厳しく、そんな言い方しなくても!ってくらい厳しい。そんなマサカリの受け方をレクチャーしちゃいますっ! ▼後日談ブログ記事 【祝ホットエントリー】「マサカリを受け止める心得」ってスライドを公開した後日談。やっぱ発信をやめたくはないなあと思えた。 http://www.rechiba3.net/entry/masakariafter/
エンジニアから飛んでくるマサカリを受け止める心得
エンジニアから飛んでくるマサカリを受け止める心得
Reimi Kuramochi Chiba
エヴァンス本を読んだことがない人、ネット上の情報を聞きかじったことがある程度の人、そんな人たちを対象に、ドメイン駆動設計について、わかりやすく説明してみました。
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
図解で学ぶ「Lean UX」
図解で学ぶ「Lean UX」
図解で学ぶ「Lean UX」
Katsuhito Okada
ギルド勉強会で使ったスライド。
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
toshihiro ichitani
ドメイン駆動設計の考え方、ドメイン駆動設計を理解する三つのキーワード、エヴァンス本のススメ、レガシーに立ち向かう、マイクロサービスとドメイン駆動設計
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
増田 亨
BtoB SaaSの会社でDDDを活用して事業を成長させてきた中で、DDDのプラクティスの実践という面ではかなり大きな成果が得られました。 しかし、事業を成長させるという点において、DDDのプラクティスだけではうまくいかないこともあり、別のアプローチも同時に試行錯誤しています。 この発表では、うまく行ったプラクティスの内容と、カバーできなかった課題、そこに対する現在の取り組みについて紹介します。 ドメイン駆動設計 サンプルコード&FAQ https://little-hands.booth.pm/items/3363104 ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 ドキュメント内のブログ記事URL https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
Koichiro Matsuoka
更新日時を排除していくことでそこそこのモデルを書けるようになる手法です。
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
GraphQLを使ったアプリケーションで、サーバでのデータの変化をクライアントに通知するメカニズムであるsubscriptionsについて概要を述べる
GraphQLのsubscriptionで出来ること
GraphQLのsubscriptionで出来ること
Shingo Fukui
設計ナイト2022 「トランザクションスクリプト」でのディスカッション枠スライドです。
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
ドメイン駆動設計の要点は3つ。ビジネスルール・値オブジェクト・型
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料:http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ CQRSはDDDと切り分けて単独でも適用することができるので、DDDについてご存知ない方もご覧いただけます。日本語の文献は意外と少ないので、この辺りの分野に興味がある人の参考になれば幸いです。
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
質問への回答(35件)を、ブログにまとめているのでこちらご覧ください https://little-hands.hatenablog.com/entry/2019/08/31/genba_de_ddd 「Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD! コラボカンファレンス」登壇資料 ブログ:https://little-hands.hatenablog.com/ Twitter:https://twitter.com/little_hand_s 質問箱:https://peing.net/ja/little_hands
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
JaSST Review 2020の発表資料です。
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣
Yoshitaka Kawashima
2017-06-22 Rails Developers Meetup #2
ふつうのRailsアプリケーション開発
ふつうのRailsアプリケーション開発
Takafumi ONAKA
初心者向けにMongoDBの基本を解説しています。 この資料は2014/3/1のOSC 2014 Tokyo/Springで発表しました 。 2015/3/3最新の情報で一部アップデートしました。 2015/7/15MongoDB ver3.0ようにちょっと修正しました。
初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!
Tetsutaro Watanabe
技術書典8で発売予定だった「ドメイン駆動設計 モデリング/実装ガイド」 https://little-hands.booth.pm/items/1835632 発売記念に、本書内容の第3章の内容を解説するオンライン勉強会です。 特に前提知識は設定せず、本書をお持ちでなくても理解できる構成にする予定ですが、併せてお読みいただけるとより深く理解する助けになると思います。 3章より「DDD固有のモデリング手法」 集約とは 境界付けられたコンテキストとは sli.doを使って質疑応答 [前回イベント][https://ddd-community-jp.connpass.com/event/168674/) でお答えしきれなかったsli.doの質問にもお答えしようと思います。 ■協賛いただきました! Forkwell(株式会社grooves)様 https://forkwell.com/ ソニー株式会社 https://www.sony.co.jp/
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
Koichiro Matsuoka
ドメイン駆動設計 のための オブジェクト指向設計 の基本と実装技法。
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
増田 亨
SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
2020/03/03 に富士通本社で行われた、富士通TechLiveに発表資料です。 コロナウィルスの影響で、リモート発表になりましたが、当日は800人以上の方に同時視聴していただきました
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
商品リンクはこちら https://little-hands.booth.pm/items/1835632 DDDはドメインモデリングを通じてソフトウェアの価値を高めようとする設計・開発手法です。 新しく得られたモデルに関する知見を頻繁にコードに落とし込む必要があるのですが、 それはソフトウェアにとっては非常に高い要求をしていることになります。 そこでDDDでは、オブジェクト指向の手法を利用して、メンテナブルで、拡張性の高いコードを書くことを目指しています。 このセッションでは、DDDではモデリング結果をどのようにコードに落とし、どのような利益を得られるのかを、具体的なコードを交えながら解説します。
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
Koichiro Matsuoka
アーキ部#13で使ったスライドです。 サンプルコードはこちらです。 https://github.com/kawasima/revisiting-domain-model
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Yoshitaka Kawashima
Agile Japan 2019 での公演用の資料。 https://www.agilejapan.org/session.html#kb-06
Agile japan 2019 受託開発でのアジャイル奮闘記
Agile japan 2019 受託開発でのアジャイル奮闘記
ssuserec5505
アジャイル開発の基本と、エンジニアに求められる姿勢
プロエンジニアになるための「アジャイル開発」再入門
プロエンジニアになるための「アジャイル開発」再入門
Yoshihito Kuranuki
More Related Content
What's hot
ギルド勉強会で使ったスライド。
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
toshihiro ichitani
ドメイン駆動設計の考え方、ドメイン駆動設計を理解する三つのキーワード、エヴァンス本のススメ、レガシーに立ち向かう、マイクロサービスとドメイン駆動設計
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
増田 亨
BtoB SaaSの会社でDDDを活用して事業を成長させてきた中で、DDDのプラクティスの実践という面ではかなり大きな成果が得られました。 しかし、事業を成長させるという点において、DDDのプラクティスだけではうまくいかないこともあり、別のアプローチも同時に試行錯誤しています。 この発表では、うまく行ったプラクティスの内容と、カバーできなかった課題、そこに対する現在の取り組みについて紹介します。 ドメイン駆動設計 サンプルコード&FAQ https://little-hands.booth.pm/items/3363104 ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 ドキュメント内のブログ記事URL https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
Koichiro Matsuoka
更新日時を排除していくことでそこそこのモデルを書けるようになる手法です。
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
GraphQLを使ったアプリケーションで、サーバでのデータの変化をクライアントに通知するメカニズムであるsubscriptionsについて概要を述べる
GraphQLのsubscriptionで出来ること
GraphQLのsubscriptionで出来ること
Shingo Fukui
設計ナイト2022 「トランザクションスクリプト」でのディスカッション枠スライドです。
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
ドメイン駆動設計の要点は3つ。ビジネスルール・値オブジェクト・型
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料:http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ CQRSはDDDと切り分けて単独でも適用することができるので、DDDについてご存知ない方もご覧いただけます。日本語の文献は意外と少ないので、この辺りの分野に興味がある人の参考になれば幸いです。
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
質問への回答(35件)を、ブログにまとめているのでこちらご覧ください https://little-hands.hatenablog.com/entry/2019/08/31/genba_de_ddd 「Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD! コラボカンファレンス」登壇資料 ブログ:https://little-hands.hatenablog.com/ Twitter:https://twitter.com/little_hand_s 質問箱:https://peing.net/ja/little_hands
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
JaSST Review 2020の発表資料です。
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣
Yoshitaka Kawashima
2017-06-22 Rails Developers Meetup #2
ふつうのRailsアプリケーション開発
ふつうのRailsアプリケーション開発
Takafumi ONAKA
初心者向けにMongoDBの基本を解説しています。 この資料は2014/3/1のOSC 2014 Tokyo/Springで発表しました 。 2015/3/3最新の情報で一部アップデートしました。 2015/7/15MongoDB ver3.0ようにちょっと修正しました。
初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!
Tetsutaro Watanabe
技術書典8で発売予定だった「ドメイン駆動設計 モデリング/実装ガイド」 https://little-hands.booth.pm/items/1835632 発売記念に、本書内容の第3章の内容を解説するオンライン勉強会です。 特に前提知識は設定せず、本書をお持ちでなくても理解できる構成にする予定ですが、併せてお読みいただけるとより深く理解する助けになると思います。 3章より「DDD固有のモデリング手法」 集約とは 境界付けられたコンテキストとは sli.doを使って質疑応答 [前回イベント][https://ddd-community-jp.connpass.com/event/168674/) でお答えしきれなかったsli.doの質問にもお答えしようと思います。 ■協賛いただきました! Forkwell(株式会社grooves)様 https://forkwell.com/ ソニー株式会社 https://www.sony.co.jp/
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
Koichiro Matsuoka
ドメイン駆動設計 のための オブジェクト指向設計 の基本と実装技法。
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
増田 亨
SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
2020/03/03 に富士通本社で行われた、富士通TechLiveに発表資料です。 コロナウィルスの影響で、リモート発表になりましたが、当日は800人以上の方に同時視聴していただきました
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
商品リンクはこちら https://little-hands.booth.pm/items/1835632 DDDはドメインモデリングを通じてソフトウェアの価値を高めようとする設計・開発手法です。 新しく得られたモデルに関する知見を頻繁にコードに落とし込む必要があるのですが、 それはソフトウェアにとっては非常に高い要求をしていることになります。 そこでDDDでは、オブジェクト指向の手法を利用して、メンテナブルで、拡張性の高いコードを書くことを目指しています。 このセッションでは、DDDではモデリング結果をどのようにコードに落とし、どのような利益を得られるのかを、具体的なコードを交えながら解説します。
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
Koichiro Matsuoka
アーキ部#13で使ったスライドです。 サンプルコードはこちらです。 https://github.com/kawasima/revisiting-domain-model
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Yoshitaka Kawashima
What's hot
(20)
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
GraphQLのsubscriptionで出来ること
GraphQLのsubscriptionで出来ること
Tackling Complexity
Tackling Complexity
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣
ふつうのRailsアプリケーション開発
ふつうのRailsアプリケーション開発
初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Similar to ウォーターフォールとアジャイルのフェアな比較
Agile Japan 2019 での公演用の資料。 https://www.agilejapan.org/session.html#kb-06
Agile japan 2019 受託開発でのアジャイル奮闘記
Agile japan 2019 受託開発でのアジャイル奮闘記
ssuserec5505
アジャイル開発の基本と、エンジニアに求められる姿勢
プロエンジニアになるための「アジャイル開発」再入門
プロエンジニアになるための「アジャイル開発」再入門
Yoshihito Kuranuki
2015.04.19 Agile Japan Osaka の講演資料です。
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
智治 長沢
Cloud Run は、インフラ管理を一切する必要がなく、自動プロビジョニング、0 to N 高速スケールなアプリケーション基盤を GCP 上に構築出来ます。また Cloud Firestore という高速でサーバーレスの、フルマネージドな ドキュメント データベースと合わせて利用し、Firebase および Google Cloud Platform(GCP)と統合することで、フロントエンドからバックエンドまでのアジャイル開発を加速します。
[Cloud OnAir] Cloud Run & Firestore で、実践アジャイル開発 2020年6月25日 放送
[Cloud OnAir] Cloud Run & Firestore で、実践アジャイル開発 2020年6月25日 放送
Google Cloud Platform - Japan
請負型システム開発とプログラマの価値
請負型システム開発とプログラマの価値
sunnyone41
SIからServiceへの転換のために。
これからのプロダクトについて
これからのプロダクトについて
speedkingg
「E-AGILITY Conference 2011」第2回講演での講演資料。
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来
Yoshihito Kuranuki
つまらない仕事も劇的改善!カスタムアプリを使った業務改革事例
つまらない仕事も劇的改善!カスタムアプリを使った業務改革事例
つまらない仕事も劇的改善!カスタムアプリを使った業務改革事例
Cybozucommunity
社内へのスクラム研修用資料です。
Hello Scrum!
Hello Scrum!
Daisuke Sato
presentation on 2013-05-16 @PMI-Japan
アジャイルの障害
アジャイルの障害
Tadatoshi Sekiguchi
2012/7/27に開催されたDevelopers [Social Enterprise] Summit 2012の講演【 B-2】 「エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方」
夏サミ 2012 [B-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
夏サミ 2012 [B-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
Yusuke Suzuki
ニフティクラウドC4SA_ご紹介資料ver.1.1
ニフティクラウドC4SA_ご紹介資料ver.1.1
Satoshi Ueno
2019年9月18日開催のAWS Japan × Atlassianセミナー「DXを加速するDevOps − 理解と実践」のセッション2「AmazonカルチャーとDevOps」スライドです。
2019年9月18日開催AWS Japan × Atlassianセミナー_セッション2「AmazonカルチャーとDevOps」
2019年9月18日開催AWS Japan × Atlassianセミナー_セッション2「AmazonカルチャーとDevOps」
アトラシアン株式会社
JAWS re:Mote 2015 での発表に使用するスライドです。内容はJAWS DAYS 2015での発表+αです。 サービス (web API) を安全に運営するために、どんな風に AWS を使って設計したかが書かれています。同様のサービスの開発を検討されている方の参考になれば幸いです。 もうすぐ画像認識APIに追加される新機能の紹介も兼ねています。
JAWS re:Mote 2015 Nagoya
JAWS re:Mote 2015 Nagoya
陽平 山口
2012/9/14に開催されたDevelopers Summit 2012 Kansai (通称:デブサミ関西)の講演【A-2】 「エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方」
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
Yusuke Suzuki
デブサミ2010の講演資料
クラウドがもたらすパラダイムシフト
クラウドがもたらすパラダイムシフト
kurikiyo
#CloudOnAir 記念すべき第一回目の放送では、皆様に Google Cloud Platform の概要や Google Cloud のビジョンなどをお話します。 Google Cloud Platform の製品で何ができるのか?何がビジネスに役立つのかなど、分かりやすくポイントを交えながらご紹介していきます。 番組動画はこちら: https://youtu.be/VSV9AJWjMCI
[Cloud OnAir] #01 徹底解剖 GCP のここがすごい
[Cloud OnAir] #01 徹底解剖 GCP のここがすごい
Google Cloud Platform - Japan
2012年12月6日 Cloudforce Japan Developer Zone内のシアターで講演された資料です。
Force.com開発基礎
Force.com開発基礎
Salesforce Developers Japan
Red Hat Forum 2014 のIBMセッション資料です。 「ビッグデータの即時活用を実現するJava高速処理OpenStackプラットフォーム」 http://redhatforum2014.jp/ https://redhatmktg.smktg.jp/public/session/view/18
Red Hat Forum 2014 IBM session
Red Hat Forum 2014 IBM session
Shinichiro Arai
AWS FinTech Bootcamp! 2022/11/15
クラウドを積極活用したサービスの開発のために
クラウドを積極活用したサービスの開発のために
Yuichiro Saito
Similar to ウォーターフォールとアジャイルのフェアな比較
(20)
Agile japan 2019 受託開発でのアジャイル奮闘記
Agile japan 2019 受託開発でのアジャイル奮闘記
プロエンジニアになるための「アジャイル開発」再入門
プロエンジニアになるための「アジャイル開発」再入門
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
[Cloud OnAir] Cloud Run & Firestore で、実践アジャイル開発 2020年6月25日 放送
[Cloud OnAir] Cloud Run & Firestore で、実践アジャイル開発 2020年6月25日 放送
請負型システム開発とプログラマの価値
請負型システム開発とプログラマの価値
これからのプロダクトについて
これからのプロダクトについて
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来
つまらない仕事も劇的改善!カスタムアプリを使った業務改革事例
つまらない仕事も劇的改善!カスタムアプリを使った業務改革事例
Hello Scrum!
Hello Scrum!
アジャイルの障害
アジャイルの障害
夏サミ 2012 [B-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
夏サミ 2012 [B-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
ニフティクラウドC4SA_ご紹介資料ver.1.1
ニフティクラウドC4SA_ご紹介資料ver.1.1
2019年9月18日開催AWS Japan × Atlassianセミナー_セッション2「AmazonカルチャーとDevOps」
2019年9月18日開催AWS Japan × Atlassianセミナー_セッション2「AmazonカルチャーとDevOps」
JAWS re:Mote 2015 Nagoya
JAWS re:Mote 2015 Nagoya
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
クラウドがもたらすパラダイムシフト
クラウドがもたらすパラダイムシフト
[Cloud OnAir] #01 徹底解剖 GCP のここがすごい
[Cloud OnAir] #01 徹底解剖 GCP のここがすごい
Force.com開発基礎
Force.com開発基礎
Red Hat Forum 2014 IBM session
Red Hat Forum 2014 IBM session
クラウドを積極活用したサービスの開発のために
クラウドを積極活用したサービスの開発のために
More from Yoshitaka Kawashima
アーキ部#15の資料です。
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Yoshitaka Kawashima
吉祥寺.pm32で話したスライドです。 邦題: デザインパターンは死んだ(のか)?
Are Design Patterns Dead?
Are Design Patterns Dead?
Yoshitaka Kawashima
アーキ部 #12 「複雑さ」について語り合う会 の参考資料です
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
Yoshitaka Kawashima
吉祥寺.pm #26でお話したソフトウェア開発における『知の高速道路』の話です。 将棋や数学とのソレには程遠い。主にサッカーの戦術的ピリオダイゼーションを参考に考えてみました。が結論は、まだありません。
ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』
Yoshitaka Kawashima
吉祥寺.pm #24の発表資料です。
本番障害に至る病
本番障害に至る病
Yoshitaka Kawashima
吉祥寺.pm #23の発表資料です。 Test Harnessを使って、仕様外のふるまいをテストしましょうというお話です。 https://github.com/kawasima/rodriguez
システムダウンのひみつ
システムダウンのひみつ
Yoshitaka Kawashima
JJUG CCC 2019 fall g3のセッション資料です。 「ちょっと凝ったことをしようとすると大量のXMLを書かなきゃいけない」「プラグインを並べてもうまく動いてくれない」など、Mavenは誤解され敬遠され、Gradleなどの他のビルドツールにシェアを奪われてきました。 が、依然としてMavenはJavaのデファクトスタンダードなビルドツールに位置づけられており、マスターする価値は十分にあります。そして良く学んでみると、そもそもXMLで過度なカスタマイズしようというのが誤った使い方だったのに気づきます。そこへ至るにも、タスクランナーの延長線上にある他のビルドツールと異なり、Maven独特なライフサイクルとプラグインの関係性もきちんと理解しておかなければなりません。
Mavenの真実とウソ
Mavenの真実とウソ
Yoshitaka Kawashima
NoOps Meetup Tokyo #8での発表資料です。
アンチフラジャイルの世界
アンチフラジャイルの世界
Yoshitaka Kawashima
すえなみチャンス暑気払い 2019夏で話した、設計要素を分解して理解してみようという話です。 Simplicity makes easy to understand.
Atomic Architecture
Atomic Architecture
Yoshitaka Kawashima
JJUG CCC 2018 Fall #ccc_e3
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
Yoshitaka Kawashima
技術書の見つけ方です。
How to find tech books
How to find tech books
Yoshitaka Kawashima
How to building an antifragile system using Java.
Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1
Yoshitaka Kawashima
2017/2/17のアーキ部の資料です。 異文化理解力に関して思うところをまとめました。
たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力
Yoshitaka Kawashima
SIerの方が本質的にオープンにいけると思うのですよ。
SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199
Yoshitaka Kawashima
受託開発を生業とするものにとって、見積もり根拠を正しく示すことは死活問題だ、という話です。
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
Yoshitaka Kawashima
nishi-shinju-clojure #0のLTスライドです。
Antifragile Clojure
Antifragile Clojure
Yoshitaka Kawashima
BoilerplateとMagic論争をStruts1を交えて考えてみました。
Boilerplate vs Magic
Boilerplate vs Magic
Yoshitaka Kawashima
既婚プログラマの時間捻出術です
既婚プログラマの時間捻出術
既婚プログラマの時間捻出術
Yoshitaka Kawashima
Java Day Tokyo 2016 のセッション3-Eの資料です。 Java8, Java9の新機能がシステムの設計にどういう影響があるのかを考えてみました。
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
Yoshitaka Kawashima
JJUG CCC 2016 Spring CD-7 のセッションスライドです。
マイクロフレームワークEnkan(とKotowari)ではじめるREPL駆動開発
マイクロフレームワークEnkan(とKotowari)ではじめるREPL駆動開発
Yoshitaka Kawashima
More from Yoshitaka Kawashima
(20)
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Are Design Patterns Dead?
Are Design Patterns Dead?
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』
本番障害に至る病
本番障害に至る病
システムダウンのひみつ
システムダウンのひみつ
Mavenの真実とウソ
Mavenの真実とウソ
アンチフラジャイルの世界
アンチフラジャイルの世界
Atomic Architecture
Atomic Architecture
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
How to find tech books
How to find tech books
Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1
たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力
SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
Antifragile Clojure
Antifragile Clojure
Boilerplate vs Magic
Boilerplate vs Magic
既婚プログラマの時間捻出術
既婚プログラマの時間捻出術
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
マイクロフレームワークEnkan(とKotowari)ではじめるREPL駆動開発
マイクロフレームワークEnkan(とKotowari)ではじめるREPL駆動開発
ウォーターフォールとアジャイルのフェアな比較
1.
ウォーターフォールとアジャイルの フェアな比較 kawasima
2.
アジャイルとは何か?
3.
アジャイルマニフェスト プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 http://www.agilemanifesto.org/iso/ja/
4.
分かりやすい喩え ウォーターフォール アジャイル ホールケーキとして作る 必要に応じてカットケーキを作る
5.
アジャイル開発の 実際の進め方 (rascal-scheme) https://github.com/kawasima/rascal-scheme
6.
体制 プロダクトマネージャ ● 要求を実装可能なストーリーに変換する。 ● チームがスムーズに実装できるレベルまで、ストーリーを理解させる。 チーム ● スプリント(2〜4週間)で実装するストーリーをコミットし完遂する。 ● スプリント期間は、外部からの開発進捗の妨げを排除する。 (スクラムマスターの仕事) ● タスクの見積りはチームで行い、各タスクの完了責任はチームで持つ。 (クライアント) ● 要求をとりまとめ、開発サイドに伝達する。 ※ストーリーとは、実装可能な仕様の塊。通常、機能一覧の1行に該当する。
7.
権限の7つのレベル マネージャとして意思決定するTell 意思決定について説得するSell 意思決定する前にチームに相談するConsult チームと一緒に意思決定するAgree チームが意思決定する前にアドバイスするAdvice チームが意思決定した後にフィードバックを求めるInquire チームの意思決定に何も影響を与えないDelegate
8.
権限レベルを決める ストーリーの内容 Tell Sell Consult
Agree Advice Inquire Delegate ストーリーの中の 内部仕様 PM Team Client PM スプリントに含める ストーリー PM Team PM Client … ストーリー全体計画 Client PM
9.
全体スプリント計画 Sprint1(8/16〜8/29) Sprint2(8/30〜9/12) Sprint N(mm/dd〜mm/dd) ● 顧客の検索ができるようにする ● 顧客のデータを登録できるようにする ● … プロダクトバックログ スプリントバックログ システムに要求される機能を分解し、ストーリーとしてプロダクトバックログに積む。 ストーリーの優先順位をつけ、だいたいの見積りをし、スプリントバックログに割り振る。
10.
スプリント計画MTG プロダクトマネージャ チーム Sprint N(mm/dd〜mm/dd) ● スプリントでの総開発量の決定 ● ストーリーの見積り ● ストーリーのタスク分解 ● ストーリーの内容説明 ● ストーリーの詳細なスコープ決定
11.
スプリントレビュー チーム ● スプリントの成果をデモ プロダクトマネージャ (クライアント) ● 指摘をバックログに反映する
12.
QCDに沿ってアジャイル開発の メリデメを考える
13.
コスト ● 結果として無駄なものを作らなくて済む可能性があ り、当初の概算よりコストを抑えることができるかも しれない Pros Cons ● タイムボックス分割の分のオーバーヘッドがかかる。 ● 大量生産可能なものに適用してもオーバーヘッドが上 乗せされるだけである。
14.
品質 ● タイムボックスごとにテストがされるので、必然的に 品質は高くなる傾向にある。 Pros Cons ● デグレを防ぐために、回帰テストが必要になる。 (コストへのインパクト)
15.
納期 ● フィジビリティを確認しながら、開発を進められるの で、実現が難しい機能がクリティカルパスになって、 設計・プログラミング工程で遅延が発生するという 事態を防ぐことができる。 Pros Cons ● 基本的にはコスト・品質を固定して、納期とスコープト レードオフをコントロールしていくプロセスなので、ス コープの調整が前提になっていないと、納期は守れな い。
16.
マネジメントの違い ウォーターフォール アジャイ ル Quality Cost Delivery Scope 固定 コントローラブル 固定 コントローラブル 固定
コントローラブル (大量に積んだバッファでやりくり) (納期とスコープのトレードオフを やりくりする) 固定 固定
17.
体制 ウォーターフォール アジャイル 時間 人数 時間 人数
18.
体制 ● 最初から同じメンバーなので、立ち上げのコストが 少ない。 ● 同じプロジェクトに継続してたずさわるので、学習 効果が期待できる Pros Cons ● 特になし
19.
FAQ
20.
Q. スキルの高い人でチーム組まないとできないの? A. そういうことはない。 しかし、タイムボックス分割のオーバーヘッドを最小化する ためにはプロダクトマネージャには高いスキルが要求される。
21.
Q. ドキュメント書かないので、保守フェーズで苦労するって聞いた。 A. ドキュメント書く、書かないの話はアジャイルとは関係ない。 設計書などは、コードを書いた後で作ることができるので、 手戻りがなくドキュメンテーションの効率がよくなる効果はある。
22.
Q. ミッションクリティカルなシステムなので品質が心配だが… A. スタートアップ起業文化で成長してきたのメソッドなので、 品質に対する意識が低そうな印象があるのは事実だが、 品質保証プロセスに何の違いもない。 デグレのリスク増など、留意 すべき点を間違えなければ、 ミッションクリティカルで使え ないということはない。
23.
まとめ
24.
● 同じものを同じメンバーで作るのであれば、ウォー ターフォール、アジャイルに大きな違いはない。 最終的に出来上がるものが違うから、プロセスを選び分ける ● プロジェクトの特性による向き不向きがある。 – 向いているものは… ● ビジネスの成功に必要な機能を誰も明言できないもの ● 技術的に実現可能性が見えていないもの ● 納期の制約がないもの
Download now