Scrumが難しいのは幻想-情熱の再定義- を講演してきました。 #RSGT2018 - うさぎ組
私が所属しているチームは2017年にいろんなプラクティスを実践してきました。その内容をRegional Scrum Gathering Tokyo 2018で発表しました。 2018.scrumgatheringtokyo.org confengine.com 発表内容の概要 私達のチームは2016年までメトリクスの活用、スプリント期間の短縮、くじ引きで決めるPOやSM、などのプラクティスを通して改善を繰り返してきました。スクラムガイドもどんどん破りました。 このチームはScrumが難しいなんて思っていませんし、誰でも出来ると信じています。 チームが開発する製品は大きく変わりましたがScrumが難しいなんてことはありませんでしたし、 なによりこのチームのエッセンスを大学生40名に導入したところなんと1週間で1日スプリントをモノにしました。Scrumが難しいのは幻想だったのかもしれません。
スクラムにおける技術的スパイクの進め方
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 スクラムでは、スプリントに投入するプロダクトバックログアイテムはReady（準備ができている）である必要があります （Readyとはどんな状態なのかについては以前に詳しく説明したので、そちらを参照してください）。 Readyにしておくことによって、成果の量が安定しプロダクトオーナーやステークホルダーにとっては予測精度が向上していきます。 Readyにする活動は単に受け入れ基準を用意したり、プロダクトバックログの内容を精緻化したり、並べ替えたりするだけではありません。 スプリント内でプロダクトバックログアイテムが完成する可能性を上げるために必要な活動すべてが含まれます。 そしてその中の
オープンソースのTrelloクローン Libreboard | Ryuzee.com
Trelloは、https://www.trello.com で提供されているオンラインのタスク管理サービスで、利用している人も多いと思います。僕自身も以前書いたSCRUM BOOT CAMP THE BOOKの執筆の進捗管理や、Regional Scrum Gathering Tokyoのタスク管理などで使っていました。 このTrelloのオープンソース版のクローンが登場したので紹介します。 LibreboardLibreboardは、こちらで開発が進められているオープンソースソフトウェアでMITライセンスで提供されています。2014年の頭に開発が始まり、最初の開発ペースは早くありませんでしたが、昨年末くらいから急激に開発速度が上がってきているようです。 技術的には、NodejsのフレームワークであるMeteor(メテオ)を利用しています。 Meteorの詳細については以下を参照すると良
5分で分かるアジャイルムーブメントの歴史
_ 5分で分かるアジャイルムーブメントの歴史 この記事は "Brief History of Agile Movement" の全文を日本語に翻訳したものです。 この記事の著者であり、日本語版の公開を快諾いただいた Udayan Banerjee 氏 に感謝します。 翻訳の間違いなどの責任は私 (@fkino) にあります。コメントなどで指摘していただけると嬉しいです。 2012年2月にアジャイルムーブメントは丸11年を迎えました*1。みなさんも何らかのアジャイル開発手法を既に取り入れているか、アジャイル開発に取り組もうと検討されていることではないでしょうか。さて、みなさんはアジャイルムーブメントがどのようにして起こったのかご存知ですか？それは、偶然だったのか？それとも、必然だったのか？アジャイルマニフェストに影響を与えたのは何だったのか？アジャイルマニフェストの執筆者の名前は言える？彼ら
エンタープライズの開発における、プロダクトオーナーとしての組織（前編）。Developers Summit 2014 Summer
エンタープライズの開発における、プロダクトオーナーとしての組織（前編）。Developers Summit 2014 Summer ソフトウェア開発において、プロダクトに責任を持って決断してくれる優秀なプロダクトオーナーがいることは望ましいことですが、一般に受託開発において、お客様側にしっかりとしたプロダクトオーナーとしての担当者がいることはめったにありません。 7月末に行われたDevelopers Summit 2014 Summerのセッション「創業122年の企業と顧客価値にコミットした 開発を実現する試みと成果について」では、東京商工リサーチのシステム開発を行ったグロースエクスパートナーズが、「プロダクトオーナーとしての組織」と題して受託開発における現実的なプロダクトオーナーの取り組みについて解説しています。 このセッションは開発側であるグロースエクスパートナーズだけでなく、発注側で
Agile2014に参加してみて分かった昨今の世界のアジャイル事情 - The HIRO Says
先日参加してきた Agile2014 の、社内向けレポートを公開しても良いことになったので、共有させていただきます。 Agile2014 Report: As a Speaker and a Reporter of the latest Agile in the world from Hiroyuki Ito 本当は帰国時（8/4）の飛行機の中で書き終えており、帰国次第即公開しようとしたのですが、社内手続きなどの都合で公開が遅れていました。 また、公開まで期間が空いたので、レポートを書いた当時は理解できなかった点についてもある程度理解が追いつくようになったのですが、帰国時の雰囲気をそのまま伝えたいと考えたため、あえて追加修正をしないでの公開とさせていただきました。 英語で書いたということもありますが、説明足らずの部分も多々ありますので、可能な範囲で追加説明をしてみようと思います。 ３つのト
アジャイル導入コンサルタントという名前でスクラムだけを導入しようとする人は死ねばいいのにと思った - 水まんじゅう2
この文章中で表現されるアジャイルとはアジャイルソフトウェア開発宣言に沿ったものとします。 なぜか定期的にアジャイル開発をしようとしている人を食い物にしようとしている人のお話を聞くので。 タイトルですべてです。それ以上のことはない。 スクラムはアジャイルな開発を実現するためのプラクティスではあるけれども、スクラムをしてもアジャイルになるわけではないという事実。 それだけなのですが。 今まで見たり聞いたりしてきたアジャイルの失敗例 突き詰めると以下の二つではないかと思っています。 設計ができない 失敗ができない 設計ができない アジャイルだから設計書を作らなくてもよいよね。という人たちはいまだにいるらしい。 設計書という体裁では不要の場合もありますが、設計は必要です。 思いつく限り書き上げると以下の通り。 プロダクトオーナー(お客さん)との合意形成のため 全体で何を作るのかを明確化するため 必
Developers Summit 2014 で「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」という内容で発表してきました - sifue's blog
あまりにタイトルが長すぎるだろうと各所から突っ込まれ、あまりにも詰め込んだ内容で発表してしまったとちょっと反省しています。 お話としては、現在ニコニコ生放送の内部をPHPからScalaへ書きなおしているよ、というお話でした。 発表内容はこちら。 Developers Summit 2014 「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」 from Yoshimura Soichiro これらの内容は、これからScalaを使ってWebサイトを構築、運営してみようとしているリーダーさん向けに書いたものとなっています。Play2/Scalaやドメイン駆動設計、またスクラム開発の導入への足がかりにの情報となっていれば幸いです。 こんな雪の中わざわざ聞きに来てくださった皆様、そしてこの書き直しを着想するにあたってお世話になった特にじゅんいちかと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
