Developers Summit 2021 Summer[A-1]アジリティを支える品質特性 講演日時: 2021年07月30日(金) 10:00 ~ 10:45 概要: ビジネスにとってITは、「あると便利」から「有効」、「不可欠」を経て「中核そのもの」になりつつあり、柔軟かつ俊敏に…
![アジリティを支える品質特性 / Agility and Quality Characteristics Developers Summit 2021 Summer](https://cdn-ak-scissors.b.st-hatena.com/image/square/f948487ef46dac6d8f54e79ff2942169e7ae3012/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F39ec0243b5684e1db9d61a856b244252%2Fslide_0.jpg%3F18690188)
・・・ ・不確実性パフォーマンス・ドメインについて加筆しました ・テーラリングについて加筆しました ・適応課題について補足を追加しました。 はじめにPMBOKといえば、PMIが世界中のプロマネの実務家から意見を集めてプロジェクトマネジメントについて知識体系化している分厚い本、というイメージです。 いや、でした。。。以前の第6版までは(7版からはすごく薄い)。 2021年8月に第7版が発表されると(ただし、日本語版はもっと先)公式からアナウンスがありましたが、本家サイトに行ってみると英語版は既に購入できる状態でしたので早速電子版を購入し読みましたので解説したいと思います。 一応前置きしておきますと、僕はPMPホルダーではありません。外資系にいるときにPMBOKをベースとしたプロジェクトマネジメントを実施したり、国内企業ではCMMI レベル5(最高レベル)を運用したりバージョンアップ対応を経験
こんにちは、佐藤@読書好きプログラマーです! 無駄な知識など存在しないをモットーに雑多に本を読んでここで吐き出しています。 今回は「簡単に改善できないなら、それはアジャイルじゃないよね」という話をします。 あなたはソフトウェアの開発に関係する仕事をされていますか? もしされていないのであれば、ここから先を読む必要はありません。アジャイルは小さなソフトウェアを小さなチームで作るためのノウハウであり、それ以上でもそれ以下でもありません。これを念頭に置くべきです。 もしかしたら別の場所でも使うことができるかもしれませんが、使う前にそれは簡単に変更することができるものか考えてください。もし、簡単に変更することが出来ないなら、アジャイルを使うことは出来ません。 なぜなら、アジャイルは小さな改善のループを素早く回すことで、見積もりを正確にしながら安定度の高いものを作成する開発手法だからです。 大きなも
みなさんこんにちは。@ryuzeeです。 とある同人誌に寄稿した原稿を知り合いに共有していたのですが、ブログでオープンにしてほしいという依頼を受けたので公開します(同人誌の発行者には許可を取っています)。 怪文書みたいなものですが、感想お待ちしております。 本稿で何を書こうか考えていたところ、Twitterで「これがNASA流の仕事術、「プロジェクトマネージャーが守るべきルール100」が公開される」 という2014年の記事を見かけました。書かれている内容はとても妥当なもので、プロジェクトマネージャーだけでなく、組織のリーダーでもプロダクトマネージャーでもプロダクトオーナーでもあてはまるものでした。 ただ問題は100個という数です。チェックリストに100個の項目があっても覚えられません。プロダクトバックログに100個の項目があった場合、覚えているのは先頭の方と、気になる項目だけになるでしょう
コンビニに行けば常に商品がずらりと並び、ECで買った商品は翌日届きます。消費者の利便性を優先して設計されてきたサプライチェーンは、過剰生産による資源ロスや、仕入れにかかる不均衡など、その綻びがいま深刻化しています。企業や消費者の共感を得ながら、サプライチェーンを再設計する方法を模索して、顧客体験設計の最前線を知るビービットの藤井保文氏と富士通 SVP 神 俊一が対談します。
連載を続けていると、「それはアジャイルではない」「あなたの書いていることは間違っている」といった意見が届くことがある。様々な観点のフィードバックをもらえるのはうれしいのだが、失礼ながら細かい点にこだわりすぎではないかと感じる意見もある。 「スクラム以外でスプリントという言葉は使ってはいけない。これはルールだ」「アジャイルではユースケースなんて使わない。何か勘違いしているのではないか」といった反応で、「それは我々のアジャイルではない」と言われると、正直なところアジャイルの将来を懸念してしまう。 ウォーターフォールで工程の呼び方が違う(例えば基本設計と外部設計)から、「それは正しいウォーターフォールではない」という声が上がるだろうか。もちろん誰もそんなことは言わない。ウォーターフォールは道具であり、それを現場に合わせて使っていると誰もが認識しているからだ。 アジャイルもウォーターフォールと同様
9/24土に早稲田大学で行われた「XP祭り」の私的まとめです。XP祭りは完全に有志駆動で、好きな人が、好きな風にあつまって、好きに発表する、年に一度のお祭りです。今年はぼくは発表しませんが、牛尾さんの基調講演と、永和システムマネジメントの新人教育のセッションを中心に感想とともにお伝えします。 仙人たちの漫才 恒例の小井土さんと福井さんによるアジャイル漫才です。XPの概要といいながら、動くコードを書くことの大切さやフロー(流れ化)について語っていました。 牛尾さんの「XPが日本のソフトウェア開発」 MSのVSTSの開発チームを見に行った話から。DevOps の形として L-team(Live=ライブサイトのメンテ) と F-team(Feature=新機能開発)の2チームに分けて、それぞれ長く滞在している人を交換している。というのが新しかったけれど、ほとんど他のプラクティスは「知っているもの
今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。 私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、本人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って本物を見てみたかったのだ。 だから、今回Samにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。 気になっていたSamの一言 VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日本で行っ
働く組織の概念は毎年進化してきました。自己組織化されたチームが高い成果を生み出すことを見つけたのはアジャイルの実践家だけではありません。強いマネージャは高い成果を生み出すチームの必須要件ではありません。しかし、それは自己組織化されたチームにはリーダーシップがないということではありません。そのようなチームはたくさんのリーダーシップがあります。ひとりに集まるのではなく、チームのメンバ全員に分散されているのです。 分散されたリーダーシップはBlake氏とMoulton氏の論文を無効にするものではありません。人と成果に焦点を当てバランスを取ることはチームにとって大事です。そのようなバランスを存続させるためAlexis Phillips氏とPhillip Sandahl氏はBlake氏のリーダーシップ格子をベースにしたチーム診断モデルを提案しました。ふたりはマネジメント側の“人に対する関心”を、チー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く