スクラムガイド(LeSS版)
スクラムガイドの目的 スクラムは複雑なプロダクトを開発、提供、保守する為のフレームワークである。このガイドではスクラムを定義している。定義には役割、イベント、作成物とそれらをまとめるルールが含まれている。フレームワークの各要素は特定の目的を有し、スクラムによって実現される価値と成果にとって不可欠な要素となる。スクラムの考え方や構造を変えたり、要素を省いたり、ルールを無視する事は問題を隠し、スクラムから得られる価値を限定したり、無意味な物にしてしまうのである。 Ken Schwaber と Jeff Sutherlandはスクラムのフレームワークを作る事に重要な役割を担った。 LeSS（大規模スクラム）は複数のチームでプロダクト開発をする際にスクラムを適応し、組織のシステムが変化した結果として形作られ、LeSSはLeSSルールにて定義をされている。LeSSルールは、各チームのレベルではスクラ
タスク・プロジェクト管理ツール「Jooto」、AIでタスク管理ボードを自動生成する「AIタスク生成β版」の提供を開始
今回、提供が開始されたAIタスク生成β版では、Jootoの専用フォームに会社の業種、プロジェクトの概要、管理したい案件の規模といった簡単な項目を入力するだけで、入力した情報をChatGPTへ連携してJooto上に自動でタスクとリストを考案する。 製造業で新しい商品を開発する人には、商品開発に必要なリサーチ段階から発売後のPR活動まで、一貫して必要なタスクを含むプロジェクトボードが自動で作成されるなど、人力で1つひとつタスクを洗い出したり、順序を検討したりすることなく、自動で作成されたプロジェクトボードを使って直ちに仕事にとりかかれる。 AIタスク生成β版は、JootoのビジネスプランにおけるAPI機能の活用が前提となる。Jootoでは、新規登録後31日間はビジネスプランを無料で試用可能となっているが、今回はβ版での提供のため1組織あたり1か月に生成できるプロジェクト数に制限を設けており、正
「DDDもスクラムも当たり前」な開発者組織に入って気付かされたDDDの価値を出すための条件｜南部豪
この記事は 株式会社ログラス Productチーム Advent Calendar 2023 の17日目の記事です https://qiita.com/advent-calendar/2023/loglassこんにちは。ログラスでエンジニアをしております、南部です。 ログラスでは、当アドベントカレンダーの5日目の記事で紹介されていますように、「DDDもスクラムも当たり前」な開発組織が形成されています。 私は、今年の9月からログラスに入社していますので、上記の記事で紹介されているログラスのDNAを受け継ぐ側に当たるかと思います。 そしてちょうど直近で、DDDの文脈においてこのDNAの価値を感じる機会がありました。 実は、前職でもDDDっぽいコードを取り入れたりはしていたのですが、それによって特にメリットは得られておらず悩んでいました。 結論、原因は私の不勉強でDDDの価値を出せる条件となって
アジャイル開発はなぜ失敗するのか？ ガートナーが絶対押さえるべき6つのポイント解説
そもそも、アジャイル開発とは何か。片山氏は「正解がわからない状態で、正解に近づくためのアプローチであり、手法としてはインクリメンタル（徐々に増加する）とイテレーティブ（反復）、つまり、少しずつ繰り返しながらビジネス価値を上げて提供するアプリケーションを開発する点が特徴です。その考え方は複雑だったり、難しかったりするわけではありません」と説明する。 また、ウォーターフォール型開発との違いについて、片山氏は「ウォーターフォール型開発では決められたゴールを目指して直線的に進んでいくのに対して、アジャイル開発では試行錯誤を繰り返しながらゴールに近づくことを目指します」と解説する。 「ある程度の規模を持つシステムを開発する場合、アジャイル開発のほうが工数もかかることがあります。アジャイル開発の特徴が決して『早い』『安い』ではないと理解しておくことが非常に重要です」（片山氏） 片山氏によると、実際のア
『スクラムの拡張による組織づくり』を読んで、そもそも”組織をつくる”ってなんだろうなって考えた - Magnolia Tech
スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する WEB+DB PRESS plus 作者:粕谷 大輔技術評論社Amazon だいくしーさんこと、粕谷大輔さんの『スクラムの拡張による組織づくり』を読みました。 複数のスクラムチームを協業させていく手法として「Scrum@Scale」を軸に、スクラムという概念自体のおさらいから始まり、コミュニケーションを軸とした組織の作り方、運用の仕方を解説していく構成になっています。 第3章で出てくる「毎日45分で問題が解決する」というのはなかなかキャッチーな表現で、Daily Scrum -> Scaled Daily Scrum -> Executive Action Teamのそれぞれに15分という目安を作ることで、議論ではなく問題の確認と決定の場としてショートに実行するものである、という定義が明確で分かりやす
プロダクトマネージャーこそプロジェクトマネジメントという“武器”を身につけよう 業務ですぐに使える“共通スキル”と“専用スキル”
複数事業に携わるPM組織のスキル成長と評価について、コングロマリットな経済圏を持つDMMのPMから聞く「複数事業を跨ぐPM！なんでもやるDMMに聞く、PM組織の成長と評価の話【開発PM勉強会vol.21】」。ここで合同会社DMM.comの齋藤氏が登壇。プロダクトマネージャーとプロジェクトマネージャーの違いについて話します。 齊藤氏の自己紹介 齊藤亮氏：では「プロダクトマネージャーこそプロジェクトマネジメントを学ぼう」というテーマでお話をさせてもらえればと思います。 まず自己紹介になりますが、名前は齊藤亮と申します。キャリアですが、大学在学中からエンジニアとしてアプリ開発をやっていて、その後、toC向けのアプリ開発会社を創業しています。会社自体は畳んでしまいましたが、その後ヘルスケアテクノロジーのベンチャーでプロダクトマネージャーを経て、2022年の8月にDMMに入社しています。 今は横串部
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
東京都庁が「アジャイル型開発プレイブック」を公開 初学者向けに開発事例やスケジュールを集約