10 ways to better lead your agile team
10 ways to better lead your agile team February 24, 2012 JR iOS agile, agile leadership, leadership, team lead 8 Comments Leadership is one of those personal things I find hard to give advice on. As if there were merely 10 things you needed to do to successfully lead your agile team. I feel no more qualified to tell you how to lead your software project than I do telling Wayne Gretzky how to play
Jonathan Rasmusson(アジャイルサムライ著者)によるアジャイルインセプションデッキ作成ワークショップに参加してきた #agilesamurai | Act as Professional
Jonathan Rasmusson(アジャイルサムライ著者)によるアジャイルインセプションデッキ作成ワークショップ 基本的にはJonathanが公開している The Agile inception deckの流れで、参加者が知りたいことに答えていく流れであった。 Agile tools for startups « The Agile Warriorで公開されているPDFの記事を一部使用しておこなわれたので、こちらの資料も参考になる。 個人的な忘却録メモを残す。 インセプションデッキとは？ アジャイルサムライで書かれている、アジャイルソフトウェア開発をおこなう上で、最初におこなうべき10の手強い質問に答えるワークショップや作成するものである。 通常、一般的にアジャイルといわれるプロセスはソフトウェア開発の開発中の事にフォーカスして述べられ、考えられている。インセプションデッキは、このソフ
「アジャイル開発 基本のキ リターンズ」- Agile Japan 2012 #aj12 - ヲトナ.backtrace
3/16 に大阪で開催された Agile Japan 2012 で上記のタイトルで講演させていただきました。 当日の資料は以下になります。 アジャイル開発 基本のキ リターンズ View more presentations from Nishimura Naoto 以前に同名タイトルの資料は公開していて普段の仕事でやっている研修でも利用してきました。 今回は研修で得たフィードバックもたまってきたので、えいやっと作り直してみました。 当日は部屋の都合もあり、ワークショップに全員参加できない方もいてすいませんでした。 その中でも大阪のスタッフの皆さんには、なるべく多くの方に参加できるように取り計らってもらい、とても助かりました。 僕自身も多くの人に参加していただいて、大阪のスタッフの皆さんに色々と助けてもらい、とても有意義な時間を過す事ができました。本当にありがとうございました。 そう言えば
【資料公開】アジャイルな開発からアジャイルな組織へ
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 2012年3月16日に実施されたAgile Japanの大阪メイン会場に登壇させていただきました。 発表の資料を以下に公開します。 会場の外まで立ち見が溢れるくらいの多くの方にお越しいただき感謝するとともに、ご不便をおかけした方にはお詫びしたいと思います。 僕が話した内容は、実は単に実際の現場で、現場を良くしたいと思っている皆さんの胸のうちを代弁しただけです。 アジャイルという単語、スクラムやXPといった手法の名前自体の認知度があがって、ともすればこれらを導入すれば全てうまくいくんだ、と誤解を生んでいるのではないかと感じています。 でも手法は手法でしかなく（したがってスクラムやXPを
Agile do IT ! - マスター・センセイとヤフー、スクエニ、DeNAが集うAgileイベント in Tokyo / 3.19開催
真の「マスター・センセイ」を東京にお迎えして開催する "Agile do IT ! " (it ≒ Information Technology)。Agile Japan (大阪) からスピンオフして、DeNA がお届けします。 Agile do IT のアウトラインは次の通りです。 アジャイルサムライ著者 Jonathan Rasmusson氏 による、Agile Japan (大阪) でのトークセッションを再現します（※一部） ヤフー、スクウェア・エニックス、DeNA。ネット業界・ゲーム業界の最前線で Agile/Scrum に熱心に取り組み始めている企業から、取り組みにおける成功・失敗からの学び、気づきをシェアします Jonathan Rasmusson氏を交えて、スクラムマスター達とのパネルディスカッションを実施。スペシャルモデレータとして、角谷信太郎氏にご登壇頂きます 本イベント
Agile Japan 2010 イベントレポート：後編（Day2）｜イベント｜アジャイルジャパン公式サイト
体験しよう！考えよう！行動しよう！ Agile Japan 2010 ― 日本のアジャイルはここにある ― EM ZERO編集部 野口隆史 第2日目（2010年4月10日） 前編（Day1）はこちら。 キーノートセッション 「アジャイルの現状と未来、次に来るもの―リーン開発への展望」 Alan Shalloway氏 アジャイルジャパン2010の2日目はAlan Shalloway氏のキーノートで幕を開けました。1日目のパネルディスカッションで、これまでのアジャイルにはコンセプトをビジネスにつなげる「価値流」が欠けていることを指摘した同氏は、その主張を詳しく説明しました。 ・アジャイルに欠けているもの アジャイルには大きく分けて、技術面にフォーカスしたXPと開発チームにフォーカスしたスクラムがあるものの、いずれも全体性に欠けており、これまでチームレベルでは成功を収めているものの企業レベルでは
アジャイル開発とはなにか - うさぎ組
ふと、気づいた。 「アジャイル開発は答えではない。答えを探す手法である。」 前に「○○な問題があるんだけど、それはアジャイルではどう答えているの？」とPMな人に聞かれた事があって「ありません」って答えたんだけど、そのときどうやって説明していいかわからなくって、具体的にXP, Scrumの話をしてしまった。 でも、間違っていたかもしれない。 アジャイル開発は何かに対する答えを持っているんじゃなくって、自分達の最適解を探すためのアジリティなメンタルモデルを掲げていて、その具体例としてXP, Scrum, Lean が定義されてきた。 だから、いつだって答えは僕たちが見つける必要がある。 Agileを難しいと感じたときに「Agileで答えを見つけようとする手法そのものに感じている」のか、「Agileによって明確になった問題に対して感じている」のかをちゃんと区別しなきゃいけない。 Agileの達人
Head First Inception Deck
1. Head First 頭とからだで覚えるデッキ作りの基本 n-nishimura@esm.co.jp 11 10 11 1
Jeff Patton's Presentation Slides and Handouts
Presentation Slides & Handouts Short Talks Embrace Uncertainty: Strategies for on-time delivery in an uncertain world In this talk I explore the common misconceptions about incremental and iterative development that lead Agile practitioners to focus more on building required scope on time, and less on the value they're delivering. I'll then offer strategies to help Agile projects both finish on ti
スクラムに対するよくある偏見と本当にチームを生産的にする方法
スクラムにおけるよくある偏見スクラムではドキュメントは何も書かないスクラムではアーキテクチャの設計はしない。またはアーキテクチャはないスクラムでは計画はしないプロジェクトの開始時点では、何を作りたいかは何も決まっていないスクラムと固定費用のプロジェクトは相容れない（※1）チームはチームが望むことは何でもできるスクラムマスターは上級管理職ではない（※2）スクラムはマネージャを必要としない（※2）プロダクトオーナーは全てのステークホルダーの代弁者であるスクラムはシンプルだ（※3） 以上がよくあるスクラムに対する偏見だそうです。 偏見をもったままでスクラム（やアジャイル）を導入したところで良い成果は出ません。 補足上記に関していくつか補足しておきます。 （※1）相容れないのは、「固定費用かつ固定スコープ」のプロジェクト（※2）チームではもちろん自己組織化が前提なのでコマンドコントロール型の管理職
第7回スクラムプロダクトオーナー勉強会に参加してきた #postudy - Diary of absj31
1月27日 第7回スクラムプロダクトオーナー勉強会(東京都) (写真：前回第6回のふりかえり風景。) 去年11月末以来、1ヶ月半振り位に開催された第7回プロダクトオーナーに参加してきました。 開催場所はTIS株式会社＠西新宿。年を跨いで従来の竹芝から移転をされたそうです。 そして実はこの日日中に参加してた下記のイベントも同じ西新宿、そして同じ建物でした！ 勉強会ハシゴ参戦となったこの日ですが、物理的にもハシゴ参戦(#cross2012：1F → #postudy：14F)となっておりました(笑) エンジニアサポート新年会2012 CROSSに参加してきた #cross2012 - Shinya’s Daily Report 今回のテーマ：ストーリーテリング スクラムプロダクトオーナー勉強会 第7回 View more presentations from full virtue 今回のテー
[Scrum]Scrumではコードレビューをどうやっているか？ | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 よく一緒に議論したり大学行ってワークショップをしたりしている原田さんが、スクラムでのコードレビューについて書かれましたので、僕も過去数年コーチとして色々な現場に行った際のことや、自分で受託開発をスクラムでやった際のことを踏まえてスクラムにおけるコードレビューのやり方を書いてみます。 レビューのやり方早期から頻繁に僕自身は小規模で頻度の高いインクリメンタルなレビューを好んでいます。 かつて大きなSIerにいてウォーターフォール型の開発をしていた際に、パートナーさんから出てきたソースコードを見ると、コピーペーストの嵐だったり、変数名がデタラメすぎたり、インデントがぐちゃぐちゃだったり（以下思いつく全ての「えーーー」を適当に想像してください）して、かつ工程の後半にレビューしていたので、直すに直せないというような悲惨なことも経験しました。 （注）ウォーター
![[Scrum]Scrumではコードレビューをどうやっているか？ | Ryuzee.com](https://cdn-ak-scissors.b.st-hatena.com/image/square/a31e0bf93e286adee40dad5e291b096b09a3fb0d/height=288;version=1;width=512/https%3A%2F%2Fwww.ryuzee.com%2Fcontents%2Fblog%2Fimages%2F4588%2Fthumbnail.webp)
DVCSもBTSも知らない人達とScrumをやってみた。 - うさぎ組
このエントリーはStartup Scrumなブログではありません。Scrumというものに興味をもった当時23歳うさみみ系エンジニアがScrumという言葉を借りて開発してみた。という話です。2011/3から2011/5あたりの話。 2011/3。僕はデスマ４年目を終えて、新しいプロジェクトに移りました。 あるプロジェクトの中の4人チームのうちの1人として。もちろん僕はいちばん下っ端として。 （元請け会社の2人、当時同じ会社だった先輩、僕の4人） そのプロジェクトはWFだったんですけど、タイムボックスやリスク管理について理解があることは雰囲気で伝わってきました。 僕はその頃勉強し始めていたあらゆることを現場で試してみたいって強く思いました。 僕はMercurial、Jenkins、Groovyを趣味的に使い始めていて(MercurialとJenkinsは2010/10から。Groovyは201
Scrum ではコードレビューをどうやっているか？ - haradakiro's blog
森崎先生のソフトウェアレビューの講演を聴いて、今やっているレビューの方法をまとめときたいと思ったので、まとめてみます。今回は、コードレビューの話です。Scrum ではといっていますが、レビューのやり方はチームによって違うので、あくまでも例ですよ。PBI とか、仕様、ドメインモデルのレビューの話はまたこんど。 レビューの目的は、もちろん作成するプロダクトの品質向上です。障害を検出するのも、もちろん目的ではあるのですが、それ以降のスプリントで作成されるコードで同じ障害を作り込まないのが目的としては大きいです。そのため、レビューはプロジェクトもしくはチーム立ち上げ後、数スプリントで重点的にやります。後はスプリントの振り返りでレビューをやりたいが出てきたら、チームで決めます。 レビューのやり方 基本はチーム全員で集まってやります。最大２時間。それ以上やっても集中力が続かないので。プロジェクタで対象
第11回すくすくスクラム――ユーザーストーリービギンズナイトで講演してきました。 - capsctrldays(2010-02-25)
■1 第11回すくすくスクラム――ユーザーストーリービギンズナイトで講演してきました。 講演といってもワークショップ形式なので、あまりしゃべってないですけれども。 2時間という長時間でしたが、原メソッドのおかげでピッタリ時間通りに終わりました。ご参加いただいたみなさん、ust参加者のみなさん、スタッフのみなさん、どうもありがとうございました。 今回は、ワークショップへの参加者として思ってたことを2つ実践してみました。 （参加者同士の）自己紹介なんて必要なくね？ 模造紙って非日常的だから使えなくね？ もちろん異論はあるでしょうけれど。 ustの録画は以下。 ちゃんとした録画は、このへんにアップされるんじゃないかなあ。 http://www.microsoft.com/japan/powerpro/developer/agile/community/suc3rum.mspx 資料も、いずれこの
Scrum Gathering Tokyo 2011で「ユーザーストーリー：ファーストジェネレーション」を開催しました。 - capsctrldays(2011-10-22)
Scrum Gathering Tokyo 2011で「ユーザーストーリー：ファーストジェネレーション」を開催しました。資料を置いておきます。 20111022 user-story-first-generation View more presentations from Masanori Kado ツッコミを入れる
スクラムマスター マニフェスト ver.1.2 の非公式翻訳 - kawaguti’s diary
Scrum Global Gathering London でまとめられた スクラムマスター マニフェスト なるものがあるということなので、翻訳しておきます。翻訳時点の原版のバージョンは1.2と表記されていました。この存在は InfoQの記事 ( InfoQ: Is the ScrumMaster a Full Time Role? Yes, According to the ScrumMaster Manifesto ) で知りました。 私たちは、スクラムマスターはフルタイムの役職であり、一つのスクラムチームにつき、一人のスクラムマスターが必要であると信じます。 12のスクラムマスター原則(ポケット版) 1. 専任デリバリー改善者 2. 継続的改善を促進する 3. 継続的改善を支援する 4. 権限委譲する、コーチする、デリバリーする (?) 5. チームを育てる 6. 透明なチームになる
ワンクリックデプロイ勉強会に参加してきた #ocdeploy - Diary of absj31
connpass-ワンクリックデプロイ勉強会 (資料公開)ワンクリックデプロイ勉強会 #ocdeploy | Ryuzee.com 2011/12/20 ワンクリックデプロイ勉強会 #ocdeploy - Togetter (写真：講演終盤、ワンクリックデプロイを実演中の@Ryuzee氏。) 開催までの経緯 まずはこちらのつぶやきやり取りを。 …という様な感じでつぶやきのやり取りがなされ、この日に晴れて『ワンクリックデプロイ勉強会』が開催されました。 開催場所は日本マイクロソフト品川本社。私自身この日が2回目のマイクロソフト本社での勉強会だったのですが、開始前のモニターには何とTV画面が。勉強会とは関係無いところでちょっとした驚きでした(笑) イベント発起人であるkatzchang(TwitterID:@katzchang)さんによる前説的トーク、会場をご提供頂いたTomoharu Nag
バックログで、動的に計画変更できる仕組みを作る
バックログで、動的に計画変更できる仕組みを作る：開発チームを改善するためのスクラムTips（3）（1/2 ページ） 「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。 今回の内容 ●課題： 予定外の仕事が入ってタスクをこなし切れず、残業ばかりである 年末は忙しくて余裕がないのに、期限の短い仕事が増えてしま ●スクラムのプラクティス 急な仕事に「スプリントバックログ」を使って上司と相談をする ポイントは「状況を共有し、“問題vs．私たち”の状態を作る」」 年末になると、なぜか期限が短い仕事が増える…… 年末になると、なぜか期限が短い仕事が増えます。なぜでしょうか？ 原因はいくつかあると思われます。 役所への申請や正月休みの影響で、年内に「完了が必須」の仕事が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Arxan Japan
