アジャイルアライアンスがPMBOKなどを策定するプロジェクトマネジメント協会に加盟。「PMIアジャイルアライアンス」に アジャイル開発手法を推進する非営利団体の「Agile Alliance」（アジャイルアライアンス）は、PMBOKなどのプロジェクトマネジメントの標準の策定などを行っている「Project Management Institute」（PMI：プロジェクトマネジメント協会）への加盟を発表しました。 これによりアジャイルアライアンスはPMI傘下の「PMIアジャイルアライアンス」として今後活動を行っていくことになります。 アジャイルアライアンスとプロジェクトマネジメント協会 アジャイルアライアンスは、アジャイル開発手法の原点であるアジャイルソフトウェア開発宣言の著者らによって2001年に設立された世界的な非営利会員組織です。 会員は世界中に9万人以上とされており、アジャイル開発関
いちど立ち止まって 背景 インフラチームの小川です。 自分たちのチームでは例に漏れずスプリントの終わりにふりかえりを行っていますが、ここ最近はゆるやかな形骸化を感じていました。具体的には、以下のようなことがたびたび起きていました。 アイデアや問題が出てこない ただアジェンダをこなすだけの雰囲気が漂っている ふりかえりの効果が感じられない 一定成熟したスクラムチームにおいては、いずれも身近なケースだったりしないでしょうか。 対策 「ふりかえりのふりかえり」を実施しました。文字通り、普段のふりかえりを見つめ直すものです。海外では Retrospective of Retrospectives (RoR) と呼ばれているようで、Rails みがあります。 流れ 課題管理には GitHub Projects のボードを利用しました。 課題の洗い出し 通常のふりかえり後に、考える時間を何回かとる 出
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに あなたのふりかえりを更に拡張するふりかえりカタログ（コミュニティ版）を公開いたします！ ふりかえりカタログ（コミュニティ版）は、ふりかえりの手法（現在）84個とその特徴を網羅したカタログです。下記画像はイメージです。 Miroにて作成したものをどなたでも利用可能です！ 利用はこちら => ふりかえりカタログ（コミュニティ版） 2021年1月にpdf版/speakerdeck版でリリースして以降、なんと約8万viewと、長く多くの現場にご利用いただいています。そちらを、より使いやすく、みんなで編集できる形にしたものが今回のコミュ
# プラクティス一覧について# プラクティスとは日本語ではあまり馴染みのない「プラクティス」という言葉ですが、 「習慣」ととらえていただくのが一番わかりやすいかと思います。 課題を解決するために最適化された組織に必要な様々な「習慣」を「プラクティス」としています。 # プラクティス一覧とはプラクティス一覧は「The Open Practice Libraryopen in new window」を参考にして作成しました。 このサイトは日々の新しいアイディアや経験から作られたプラクティスを共有しているサイトです。 ここにあるすべてのプラクティスは「Outcome Deliveryopen in new windowフレームワーク」と呼ばれる考え方を基にして、分類分けをしています。 # Outcome Deliveryフレームワークとは 参照元：The Open Practice Librar
こんにちは！ いきいきいくお（小田中育生、@dora_e_m）です。現在、株式会社カケハシにエンジニアリングマネージャーとして所属しています。カケハシにジョインしたのは2023年10月で、それまでは長い間、株式会社ナビタイムジャパンに所属していました。 ここ数年はアジャイルコミュニティで発信する機会が多いため、「アジャイルの人」という印象があるかもしれません。2011年に書籍『アジャイルサムライ』と出会い、2017年頃から本格的にアジャイル開発に取り組み始め、アジャイルコミュニティにも参加するようになりました。2020年には『カイゼン・ジャーニー』の著者である市谷聡啓さんや新井剛さんとともにアジャイルの入門書『いちばんやさしいアジャイル開発の教本』を執筆する機会にも恵まれました。 私がアジャイル開発に取り組み、その活動を広げてきた原点は「目の前にある課題を解決したい」「よりよい状態へとカイ
Agile Journeyをご覧のみなさん、はじめまして。川口恭伸（@kawaguti）と申します。 私はアジャイル開発やスクラムに関する知識を提供し、モダンなソフトウェア開発の要素の研究、プロダクト開発の進め方やチームの目標設定など、さまざまな領域でのコンサルティングを手掛けています。 また、アギレルゴコンサルティング株式会社においてシニアアジャイルコーチとして活動しており、一般社団法人スクラムギャザリング東京実行委員会と一般社団法人DevOpsDays Tokyoの代表理事も務めています。さらに、コミュニティ活動としては、毎週水曜日に品川アジャイルに参加しており、RSGT、スクラムフェス、DevOpsDaysといったカンファレンスでのスタッフワークも担当しています。 このように、ほぼ公私の境なくアジャイルやスクラムを基にした活動を長く行っていますが、本稿では、私がスクラムを始めるまでの
アジャイルプラクティスマップはアジャイル開発においてよく使われるプラクティスを鉄道の路線図の形式でまとめたものです。単なる用語集とは違い、二次元で視覚的にプラクティスの位置づけを理解することができます。またアジャイル開発で用いられる各種手法の関連性をつかむことができます。 過去にも、Agile Alliance からアジャイルプラクティスの地下鉄地図（Subway Map to Agile Practices）が公開されるなど、多くの路線図形式のマップが存在しますので、このサイトはさながら Yet Another Agile Practices Map ということになります。 Agile Studio の識者たちにより、過去の歴史を踏まえたアジャイルのトリビアとも呼ぶべき豆知識も充実させました。 マップでは、「手法」を路線で、「プラクティス」を駅で示しています。プラクティスによっては、いく
「のどが渇いた」というユーザーに何を出す？ ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ 2022年9月13日 株式会社メンバーズ ポップインサイトカンパニーでのウェビナーのスライドです。「ユーザーが欲しいと言った機能をつけたのに使われない！」という経験はありませんか。プロダクトをつくるとき「ユーザーの心理を理解しよう」とよく言われます。しかし、ユーザーに言われたままやることと、ユーザーが本当に望んでいることは異なります。「UXデザイン・UXリサーチ」は、ユーザーを理解するための専門技術です。ユーザーインタビューやユーザビリティテストを用いてファクトを集めることで、ユーザーの表面的な言葉に惑わされない、本当のインサイトにたどりつくことができます。かんたんなワークも交えながら、体系的に解説いたします。
こんにちは。Mackerel開発チームディレクターの id:daiksy です。 Mackerelチームでは、開発プロセスにおけるプラクティスや、チームをうまく機能させるための様々な取り組みに対して、普段から定期的なカイゼンを行っています。 世の中は新年度を迎え、いろいろと新しい取り組みにチャレンジしやすい時期でもありますし、Mackerelチームで行った最近のカイゼンの様子を簡単にまとめてみようと思います。 振り返りでKPTをやめた Mackerelチームではスクラムをベースとした開発サイクルを採用しており、1スプリント2週間というペースで開発イベントが計画されています。スプリント最終日に振り返りを実施し、2週間の間に起きた出来事や課題などを議論して、次のスプリントでカイゼンをする、というルーチンです。 チームではこれまで長い間、KPTという振り返りのフレームワークを採用していました。K
我々も「スクラム」やるぞ！と言われても、イマイチどうしてスクラムでやりたいかが伝わっていないことがあると思います。あまり乗り気でない開発者は以下のようなことを感じているかもしれない。 スクラムを導入したところで嬉しさがわからない スクラム独自の用語が沢山あり、覚えるべき概念が多そうに感じる・学ぶための労力が割にあわないと思っている そもそもチーム改善とかに興味がない 改善に興味がなかったら厳しそうですが、スクラムを導入する嬉しさは簡単にでも紹介できたほうが良いと思うのであらためてちょっと整理してみます。 そもそもどういうことができているチームが優秀なチームかというのを考えると 以下のようなことができていると、優秀なチームなのかなと私は考えています。 改善サイクルが回っている（一定の周期で開発と振り返りと改善を繰り返すことができている） タスクが急遽差し込まれたり、方針が変わったときにスムー
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 職業柄スクラムを始めたばかりのチームを支援することがよくあります。 そのような状況で、ロールの明確化や初期のプロダクトバックログの準備とあわせて話題にのぼることが多いのが、スプリントの期間をどうするかです。 そして、多くの場合、1週間スプリントを提案しています。 今回はなぜ1週間スプリントが良いのか見ていきましょう。 1週間スプリントがよい理由1週間スプリントがよい理由を列挙すると以下のようなものがあります。 レトロスペクティブ（ふりかえり）が頻繁にあるので改善が進む計画の精度が高くなる例え失敗しても一週間で済むので実験しやすいベロシティの数字がすぐ出るのでやる気になる中だ
本ポストは特に私が所属する組織の見解ではなく、私が今までの経験＆自分がチームを作るときにチームの目標を考えたり、組織内にアジャイルを導入したり、組織内での開発チームの位置づけをどうするかなどなどを考えるときに意識していることですのであしからず。 内製化や、アジャイル化のビジネス上の効果を得やすい部分をビジネスモデルから考える 昨日、プロダクトオーナー祭り2016で「DevOpsとリーンスタートアップ時代のプロダクトオーナーシップ」というセッションでパネルディスカッションに登壇させていただきました。 postudy.doorkeeper.jp そこで内製化や、アジャイル化はどの部分からやるのがよいかみたいな話の流れかなにかで、「System of Engagementでなおかつ成果課金のようなエンジニアの書いたコード上で売上が立つモデルだとエンジニアリングが直接売上に寄与しやすいためビジネス
登壇内容ダイジェスト 継続的に学習する組織とは 今回の発表のタイトルにもなっている、「継続的に学習する組織」について、私のイメージはこのスライドに書かれいている、"Culture Of Continual Experimentation And Learning"、つまり"継続的な実験と学習の文化を持つ組織"だと考えています。 そのような組織に変わるためのステップとは、書籍『The DevOps 逆転だ!』や『The DevOps ハンドブック』で説明されている、"3つの道(DevOpsを支える原則)"だと考えています。 それぞれの道について、簡単に説明します。 3つの道とは まずは第1の道。図ではDev（開発）からOps（運用）までのワークフローになっていますが、私としては、組織がエンドユーザーに対してこういった機能を提供したい！って考える企画の段階から、実際にリリースしてエンドユーザー
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 スクラムチームのなかで分業と平行作業が多くなっているのを見かけることがあります。 この理由の1つは、スプリントバックログの一環として作られたタスクの分解の仕方にあります。今日はこれについて見ていきたいと思います。 スプリントバックログとは？まずは復習です。 ご存じのとおり、スプリントプランニングでは、そのスプリントで達成したいスプリントゴールを検討し、スプリントゴールの達成に必要なプロダクトバックログアイテムを選択し、インクリメントを届けるための実行計画を作成します。これら3つを合わせたものをスプリントバックログと呼びます。 スプリントバックログは、開発者による開発者のため
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く