界隈がざわつくほど超進化したPMBOK第7版の解説【プロジェクトマネジメント】｜Miz Kushida
・・・ ・不確実性パフォーマンス・ドメインについて加筆しました ・テーラリングについて加筆しました ・適応課題について補足を追加しました。 はじめにPMBOKといえば、PMIが世界中のプロマネの実務家から意見を集めてプロジェクトマネジメントについて知識体系化している分厚い本、というイメージです。 いや、でした。。。以前の第6版までは（7版からはすごく薄い）。 2021年8月に第7版が発表されると（ただし、日本語版はもっと先）公式からアナウンスがありましたが、本家サイトに行ってみると英語版は既に購入できる状態でしたので早速電子版を購入し読みましたので解説したいと思います。 一応前置きしておきますと、僕はPMPホルダーではありません。外資系にいるときにPMBOKをベースとしたプロジェクトマネジメントを実施したり、国内企業ではCMMI レベル5（最高レベル）を運用したりバージョンアップ対応を経験
ウォーターフォールを世に広めたとされる米軍がアジャイルに移行中という話 - Qiita
また、この図の説明においては理想的なケースにおいても1つ前の工程に戻る事が述べられています。 " Hopefully, the iterative interaction between the various phases is confined to successive steps. " (投稿者訳) 理想的には、各段階において工程が前後する範囲は直近の工程に限られる。 理想的でない場合はどうかというと、テストから設計まで工程が戻りうると示唆しています。 "The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as dist
アジャイル開発の代表的なスケーリング方法まとめ - Qiita
（ラージソリューションは、あまり使わないと実践者の方に聞いたことがあるので上記の階層の説明からは一旦抜きました。） ここでいう、「プログラム」とは複数チームで構成される大規模な開発体制のことを意味します。各階層ごとに管理するバックログがあるため、ひとつの手法の中で粒度の異なる複数のバックログを管理することになります。これらの階層を一枚に図示したものを、SAFeの全体像 (big picture) と呼びます。 SAFeが実現しようとしているの価値は以下の4つになります。 ベクトル合わせ 3 つのレベルのメンバーが戦略的な目標を共有し、その方向に向かって力を合わせる コード品質 技術プラクティスを実践することで大規模で品質のよいプロダクトを実現する プログラムの実行 開発メンバーの自律性に基づく自己組織化や自己管理、及び反復のサイクルを自然な形でプログラムレベルにスケールアップすることで、大
Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む（Spotifyモデル）
(注)ヘンリックの許可を得てざっくり意訳しました。原文は『Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds』です。訳に対するヘルプも歓迎します。Thanks Henrik, this article is great for me. プロダクト開発をしている組織において、多角的なチーム構成を実現するのはいつもチャレンジな作業だ！ 今まで見てきた中で印象に残っている例がひとつある。それはSpotifyだ。Spotifyは3つの都市にまたがって30以上のチームにスケールしているが、アジャイルなマインドセットをキープし続けている。 Spotifyは音楽産業を一変させている魅惑的な企業だ。創業してから6年しか経っていないのに、1500万ものアクティブユーザーを抱え、400万以上の決済が行われている。また、そのプロダクトは「
Web系企業/事業会社への最高の反面教師: "Spotify's Failed #SquadGoals"を読んで - アジャイルコーチの備忘録
はじめに 以前Scrum@Scaleについて@tyantya41717651さん、@zakky_devさんとディスカッションしましたが、先日お二人と、大規模アジャイルフレームワークであるSpotifyモデルと先日公開された失敗記事(「Spotifyは "Spotifyモデル "を使っていない(Spotify's Failed #SquadGoals)」)についてディスカッションしたのでブログにまとめました。*1 はじめに Spotifyモデルと取り上げた理由 モデルの失敗ではなく、ヒトの失敗 扱える以上の自由や権限を与えた悲劇 1. チームへの過剰な権限付与による、サイロ化の加速 2. 分隊のプロセスの自由さや能力不足による、分隊間協力の困難化 3. 全員での意思決定を追求したことによる、意思決定コストの増大 まとめ Spotifyモデルと取り上げた理由 今回Spotifyモデルの詳しい解
IPA の アジャイル開発版「情報システム・モデル取引・契約書」｜木下史彦
IPA から アジャイル開発版「情報システム・モデル取引・契約書」が公開された。 【プレス発表】 DX推進に向け、アジャイル開発版の「情報システム・モデル取引・契約書」を公開 https://www.ipa.go.jp/about/press/20200331.html 【成果物公開ページ】 https://www.ipa.go.jp/ikc/reports/20200331_1.html 私はこの1年間、IPA の「社会実装推進委員会 モデル取引・契約書見直し検討部会 DX対応モデル契約見直し検討WG」の委員としてこのモデル契約書の策定に関わってきた。 モデル契約策定にあたって、私が特に実現できてよかったと思うことを書いていきたい。 準委任契約を前提とすることができた2012年にIPAから出された「非ウォーターフォール型開発に適したモデル契約書」（当時、IPAではアジャイルと言わずに非ウ
マネジメント向けアジャイル開発概要
2. 自己紹介 ✤ 吉羽龍太郎 (@ryuzee) ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ ✤ ✤ 野村総合研究所、Amazon Web Servicesなどを経てアトラクタを創業 開発プロセス/アジャイル開発/DevOps/クラウドコンピューティングが専門 ✤ Scrum Alliance Certified Team Coach (CTC) ✤ Microsoft MVP for Azure 青山学院大学非常勤講師 2 4. 時価総額ランキング 2019 (6末) 2007 1. マイクロソフト (10265億ドル) 1. エクソンモービル (4685億ドル) 2. Amazon (9322億ドル) 2. GE (3866億ドル) 3. アップル (9106億ドル) 3. マイクロソフト (2936億ドル) 4. アルファベット (7510億ドル) 4. CITIグルー
Data Science & Agile: What does work? | Towards Data Science
A deeper look into the strengths and weaknesses of Agile in Data Science projects (Part 1 of 2) In the last post, we discussed about the aspects of Agile that work, and don’t work, in the data science process. You can find the previous post here. After I posted on moderating a panel on Data Science and Agile, some have reached out for my views on this. This topic is also often discussed among the
アジャイルで目指した坂の上の雲 #devlove #devlovex #devlovexE / Clouds above the hill
アジャイルで目指した坂の上の雲 #devlove #devlovex #devlovexE / Clouds above the hill
チームの自己組織化を妨げる13のパラダイム | Social Change!
大量生産のために一斉に同じことをするような仕事は減り、個々人の創造性やアイデアが求められる仕事が増えてくる中で、チームのマネジメントも変えざるを得ない。 計画した通りに手を動かしているかどうか管理するようなマネジメントから、個性や強みを活かしながら成果を出すマネジメントへの変化が求められる。その先にあるのが「チームの自己組織化」だろう。 ティール組織が注目されたのも自己組織化すれば、自律的に働きながらもチームとして成果を出せるかもしれないという期待からではなかったか。 しかし、チームの自己組織化を実現しようとしても、そう簡単にはいかない。自主性を重んじて、マイクロマネジメントをやめるだけではダメだ。なにより気をつけなければいけないのは、従来のパラダイムに引っ張られてしまうことだろう。 本稿では、自己組織化を妨げてしまう13個の古い常識や価値観について書いた。 1.計画通りであることを良しと
アジャイル開発とアーキテクチャ
アーキテクチャの基本的な考え方は、機能要求に先行して構築されてることです。 この原則は、EA（Enterprise Architecture）、DOA（データ中心アプローチ）、プロダクトライン開発のアーキテクチャでもほぼ同じ思想を持っています。 一方、アジャイル開発ではTDDなどを使い、要求を定義しその実現を検証しながら開発を進めます。その結果、開発される成果物は必然的に要求との依存性が高くなります。要求との追跡性の重視や、ビジネス価値の追求を重視すれば、その傾向はさらに強くなります。それ自体は悪いことではなく、顧客の満足を考えればいい結果をもたらすでしょう。 リファクタリングを行うことで得られる結果は、インターフェイス定義の明確化（変化する部分と変化しにくい部分の分離）、コンポーネントやクラスやサービスの粒度の適正な決定を行えること、拡張性のためのより良い解を得られることなどです。 アー
柔軟なウォーターフォールはアジャイルと見分けがつかない - arclamp
2015年10月21日に行われたエンタープライズアジャイル勉強会2015年10月セミナーでの講演『エンタープライズアジャイルと全体最適について ～アーキテクチャ設計とウォーターフォールの必要性～』のレポートです。資料は以下。 講演の後の懇親会で「計画的なアジャイルと、柔軟なウォーターフォールは見分けがつかない。ていうか、名前だけの問題だ」という話になりました。 資料でも書いているとおりエンタープライズ案件はリリース日について厳密なコントロールを求められます。一方で、多くのプロジェクトではリスク管理が重要であることは間違いなく、だからこそ、アジャイルでもウォーターフォールでも（まともなプロジェクトであれば）実質的なオペレーションは似通ったものになるというのです。 確かに、僕の経験から言っても、一度アジャイルを経験してしまうと「ウォーターフォールかどうか」というのは希薄になって「計画すべきはど
怠惰PMのアジャイルOPS - Yamotty Blog
前置き 1年半くらい前、PMをしていたチームの開発オペレーションのなかで、「進め方」を議論する時間をゼロにしたかった。 その時間があるなら「価値」について考えたかった。 穴の掘り方より掘るべき穴の探索に時間を使いたいじゃないですか。 そのため初めに「ガッ」とOPSを組んで、進め方は完全なルーティンに落とし込んだ。いわゆるアジャイル。 その際に創ったドキュメントを、なぜか今更色んな人から見せてほしいと最近言われたから発掘して公開する。 ちなみに個人的にOPSの最適化は割と得意っぽい。参考になれば。 このドキュメントは何か アジャイルを実施するための方針・運用フロー 導入するツール（Zenhub）と使い方 導入にあたりQ&A を記したもの。 アジャイル導入の目的 ユーザーのストーリー = 問題解決に集中するチームを作ること。 生産性を高めること テンポを作る 迷う時間をなくす 振り返りの習慣
フロー効率性とリソース効率性について（QCDのトレードオフなんて本当は無かったんだ） - @i2key のBlog
最新版 本ポストをXP祭り2017で発表したので、補足を含め要点のみを抽出してリライトしております。 i2key.hateblo.jp 本ポストはプロダクト開発における特定の文脈によるものなのですべてがそうだとは言っていませんのであしからず。バイモーダル戦略でいうところのSoE領域*1であり、学びによる改善サイクルをガンガン回していくようなモデル・フェーズを対象としております。TPSやLEANを現場で実践してる方々には今更なお話かと思いますが、DevOpsやアジャイル、リーンスタートアップを実践していく上で何周かしてまた原点の理解すると深みがますというかようやく、「ちょっとだけリーンわかる」ようになったので自分用のメモになります。 共通の価値観としての「リードタイム」 SoEライクな開発をしていると、仮説を立案し、そのための仮説を実証するための機能を実装し、リリースして計測、そして学びを得
「それ、アジャイルできてへんのちゃいますか？」チェックリストの公開 - メソッド屋のブログ
DevOps を導入して、リードタイムの短縮などの効果を出したい時に、前提条件となっている「アジャイル」がまだ導入できていないケースが多い。そういったケースでは、まずアジャイル導入のご支援をすることもよくある。 そういった支援に入ると、「アジャイル導入前提」で構成されたはずのプロジェクトであっても、全然「アジャイル」のポイントを外しているというケースは珍しくない。更に問題なことに、「アジャイルをできます！」と言っているベンダーさんを連れてきても、全然ポイントを外しているというケースすら珍しくない。今回のブログではそういったケースでも、簡単に確認できる、「アジャイルになっていないかもしれない簡単なチェックポイント」を対策付きでいくつかご紹介しよう。 スプリントの中で、ウォータフォールを実施するのではない。それはミニウォータフォールというバッドプラクティスだ。 1. 進化型設計ができていない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Scrum@Scale 入門