【資料公開】マネジメント向けアジャイル開発概要
みなさんこんにちは。@ryuzeeです。 2020年1月20日にとある企業の経営レベルの方向けにアジャイル開発の概要について説明した際の資料を公開します。 自社で経営者の方やマネージャーの方にアジャイル開発がなぜ必要なのかを説明する際の参考になれば幸いです。 （スライドはこちらからもご覧いただけます：https://slide.meguro.ryuzee.com/slides/101） 本資料は、なぜ今アジャイルが必要なのかという点をまず理解していただけるようにコンテキストのすり合わせに主眼を置いています。 経営者やマネージャーの方にとってはスクラムの具体的なやり方といった手法部分はあまり関係なく、それによって組織がどういう影響を受けるのか、組織としてどんな取り組みをすべきなのかが分かることが重要なためです。 単一チームや小さなプロダクトでアジャイル開発をするのと、組織的にそれをスケールし
スクラムの理解を深める「スクラムショーワークショップ」のご紹介 - Qiita
スクラムショーワークショップとは yycr2019(アジャイルコーチとスクラムマスターの宴、通称：よなよなコーチングリトリート)で生まれた、スクラムを短い時間で理解するためのワークショップの紹介です。 発起人は森一樹(@viva_tweet_x)と吉羽龍太郎(@ryuzee)です。 スクラムショーワークショップは、スクラムの説明をショー（寸劇）形式で行うワークショップです。 内容はご自由に使っていただいて構いませんが、利用する場合はクレジットをどこかにご明記ください。また、SNS等で利用した旨を共有いただけますと、ワークショップの作成者皆が喜びます。 なお、この記事はイベント中にモブブロギングによって作成されました。 記事の内容は06/19AMに行ったワークショップのリハーサルによって、時間や細かな流れなどカイゼンが行われる予定です。 記事の内容は06/19AMに行ったワークショップのリハ
アジャイルとは？アジャイルを教わりに行ったら組織哲学を学んだ話。LINEアジャイルコーチ 横道さんにFLEXYの麻衣子お姉さんが聞く！ #アジャイル編 | FLEXY（フレキシー）
HOME>開発手法と体制>アジャイルとは？アジャイルを教わりに行ったら組織哲学を学んだ話。LINEアジャイルコーチ 横道さんにFLEXYの麻衣子お姉さんが聞く！ #アジャイル編 アジャイルとは？アジャイルを教わりに行ったら組織哲学を学んだ話。LINEアジャイルコーチ 横道さんにFLEXYの麻衣子お姉さんが聞く！ #アジャイル編 FLEXY編集部の麻衣子お姉さんが、現場の最前線で活躍するエンジニアへ会いに行くこの企画。 「聞いたことあるけど良く分からない」「ざっくりと教えて」という非エンジニアならではの問いに答えてもらいます。技術書やWebで調べてもいまいち難しくて理解できないあんな技術やこんな技術。プロに優しく教えてもらいましょう。 今回のテーマは「アジャイル」。麻衣子姉さんもアジャイルという単語は聞いたことがあるものの、なぜ巷で流行っているのか、そもそもスクラムとの違いが何なのかは知らな
SUUMOアプリチームがスプリントを廃止してカンバン方式に移行した話 | リクルートテクノロジーズ メンバーズブログ
このエントリは全9回を予定する18卒新人ブログリレーの第4回です！ 今回は、SUUMOのモバイルアプリ開発の現場から、企画と開発が一体となったチームでの開発プロセスについてご紹介します！ はじめに はじめまして。リクルートテクノロジーズ新人の三田涼介です。現在は不動産検索サービスSUUMOのAndroidエンジニアとして働いています。 今回はSUUMOアプリチームの開発プロセスについて紹介します。 SUUMOは巨大なサービスでありながら日々高速に改善を行っており、週1回以上の頻度でiOS、Androidの各OSでリリースを行っています。このスピード感を実現するために、開発プロセス自体も日々磨き込みが行われており、私が配属された3ヶ月前にも開発プロセスに大きな変化がありました。 この記事では、私が新人としてキャッチアップしていく中で学んだ、 なぜ開発プロセスを選ぶことが必要なのか どうやって
Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む（Spotifyモデル）
(注)ヘンリックの許可を得てざっくり意訳しました。原文は『Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds』です。訳に対するヘルプも歓迎します。Thanks Henrik, this article is great for me. プロダクト開発をしている組織において、多角的なチーム構成を実現するのはいつもチャレンジな作業だ！ 今まで見てきた中で印象に残っている例がひとつある。それはSpotifyだ。Spotifyは3つの都市にまたがって30以上のチームにスケールしているが、アジャイルなマインドセットをキープし続けている。 Spotifyは音楽産業を一変させている魅惑的な企業だ。創業してから6年しか経っていないのに、1500万ものアクティブユーザーを抱え、400万以上の決済が行われている。また、そのプロダクトは「
職能横断型チーム(Cross-FunctionalTeam)の限界
アジャイル開発をいろいろ試してみて、もしかして銀の弾丸なんじゃないかレベルで気がついたことは、「職能横断型チームを作ることができたら、あとは勝手にアジャイルな開発になっていくのではないか」いう仮説でした。でも、実際に職能横断型チームになっている現場を見ていると、それにも限界があるのだなぁと感じることがいくつかありました。 育成がしにくい 職能横断型チームの場合、いろんな職能の人がチームにいます。たとえば、ある特定の職能のエンジニアが1名しかいないとすれば、どうやってその人は成長していくのでしょうか？ 個人でがんばれる部分もあるでしょうが、先輩からまなぶことも多いはずです。 職能横断型チームが縦のつながりだとすれば、横のつながり（同じ職能など）が薄れるので、それをどう「つないでいくか」がポイントになりそうです。 Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩むの
「それ、アジャイルできてへんのちゃいますか？」チェックリストの公開 - メソッド屋のブログ
DevOps を導入して、リードタイムの短縮などの効果を出したい時に、前提条件となっている「アジャイル」がまだ導入できていないケースが多い。そういったケースでは、まずアジャイル導入のご支援をすることもよくある。 そういった支援に入ると、「アジャイル導入前提」で構成されたはずのプロジェクトであっても、全然「アジャイル」のポイントを外しているというケースは珍しくない。更に問題なことに、「アジャイルをできます！」と言っているベンダーさんを連れてきても、全然ポイントを外しているというケースすら珍しくない。今回のブログではそういったケースでも、簡単に確認できる、「アジャイルになっていないかもしれない簡単なチェックポイント」を対策付きでいくつかご紹介しよう。 スプリントの中で、ウォータフォールを実施するのではない。それはミニウォータフォールというバッドプラクティスだ。 1. 進化型設計ができていない
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
伊藤直也が語る「仕事の流儀」第3回──OSSプロジェクトのように組織をつくる｜CodeIQ MAGAZINE
伊藤直也氏が語る「仕事の流儀」の第3回は、暗黙知を作らない組織の作り方。オープンソースのスタイルで組織を作ればいいという直也氏は、KAIZEN platform Inc.において、どのような行動をとっていたのか。 ある取り組みによって、KAIZEN流の行動哲学が生まれたという事例をもとに語っていただいた。 by 馬場美由紀 （CodeIQ中の人） 暗黙知を作るな、すべてを形式知に変えよ 前回は、Sqwiggleを活用したリモートワークやGitHubを活用した開発について述べました。 開発プロセスは、まあアジャイル開発っぽいですね。アジャイル開発というか、スクラムで求められている他のプラクティスについて、KAIZENのリモートワークではどのようにやっているかをもう少し説明すると、まずデイリースタンドアップ、いわゆる朝会です。リモートでやってるので、スタンドアップといいつつ立ってはいないんです
スクラムはもうだめぽよ!新しい開発手法『パワープレイ』をお姉さんが教えてあげちゃう!
2013/3/9 NADECで講演した内容です。 都合上、やったみた結果の一部内容は省きました。 何かあればTwitterで @arimamoto までお願いします (^^)/
ダメなデイリースタンドアップについて。 - Sooey
ダメなデイリースタンドアップについて。 CarbonFiveのブログにWhy Your Daily Standup Sucks (and how to fix it)といういいエントリがあったので、ポイントを簡単に訳して紹介しておきます。 詳細を話しすぎる 誰かが詳細を聞きたがったら、それはスタンドアップの後で話し合え みんな準備不足 毎日同じ時間にやることがわかっているのだから、準備をしたうえで時間通りに参加しろ スタンドアップの前に記録した作業時間、コミット、作業中のストーリーを確認しておけ 問題解決しすぎ デイリースタンドアップでは状況のアップデートだけをせよ 議論や問題解決をするときではない 合言葉は"take it offline" 障害を取り除こうとせよ スタンドアップの「あと」で障害に取り組め 誰かから「それについては力になれるよ」と聞ければ充分 ホワイトボードをスタンドアッ
社内ユーザテスト勉強会のスライドを公開します - Hatena Developer Blog
こんにちは、id:uedayです。 5/22にはてな社内でユーザテストについての勉強会を実施しました。 良いユーザ体験には、ユーザが迷わず快適に操作できるインタフェースが不可欠です。 ユーザビリティを評価する方法としてユーザテストがありますが、はてなブログチームでは、「アジャイル・ユーザビリティ―ユーザエクスペリエンスのためのDIYテスティング―」という本を参考に、社内でユーザテストを行っています。 今回の勉強会は導入編として、ユーザテストのメリットや事例など基礎的なことを解説したスライドを発表しました。 ご興味のある方はご覧ください。 ユーザテスト社内勉強会 View more presentations from ueday_h アジャイル・ユーザビリティ ―ユーザエクスペリエンスのためのDIYテスティング― 作者: 樽本徹也出版社/メーカー: オーム社発売日: 2012/02/23メ
Rational Team Concertのある生活～チーム・リーダーの1日
前回の最後で紹介したように、「チーム開発のコミュニケーション・プラットフォーム」として「IBM Rational Team Concert」（以下、RTC）が出荷されています。この製品の特徴・機能を理解してもらうため、RTCを使う際に「どのような準備や操作が必要なのか」、「どのような効果が得られるのか」について、順を追って説明します（コラムC1参照）。 【コラムC1】RTCとは、どのようなツールなのか構成管理（SCM: Software Configuration Management)、障害・問題管理、ビルド管理、プロジェクト計画管理を統合した開発環境ツールです。特徴は大きく3つあります。 （1）新しい開発環境に対応しているクライアント・ソフトウエア、ユーザー・インタフェースとしては、 Eclipse Visual Studio Plugin Webブラウザ の3つのUI（User In
Rational Team Concertのある生活～チーム・メンバーの1日
前回は、新しく始まったプロジェクトで、チーム・リーダーが、どのようにして、IBM Rational Team Concert（以下、RTC）を利用する環境を構築していくかについて説明しました。 今回は、チーム・メンバーの視点で、開発メンバーが用意されたRTCの環境を、どのように使っていくかを紹介します。 具体的には、RTCの「ワークアイテム管理」「ソース管理」「ビルド管理」などの開発プロジェクト作業において、最も頻繁に使用する機能の、典型的な利用例について説明します。 また、今回も、EclipseのUI（ユーザー・インタフェース）操作画面を例に、説明します。 0. ～プロジェクトの背景・特徴～ 前回も説明しましたが、今回取り上げるプロジェクトの背景・特徴は、以下の通りです。 メンバーにアジャイル開発の知識があるので、顧客の理解を得て、「スクラム」プロセスが採用された。 リーダーは、別のプロ
5分で分かる、「スクラム」の基本まとめ
5分で分かる、「スクラム」の基本まとめ：開発チームを改善するためのスクラムTips（8）（1/2 ページ） 「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。 これまで、アジャイル時代のチーム・マネジメント手法として主流になっている「スクラム」の手法を紹介してきました。今回は総集編として「スクラムの基本」をコンパクトにまとめます。 そもそもスクラムとは スクラムは、一言でいえば「チームで仕事の進めるための枠組み（フレームワーク）」です。 もともとはソフトウェア開発プロジェクトを成功させる仕組みですが、技術的な要素は取り除かれ、多くのチーム作業に共通して適用できる要素だけが残りました。そのため、ソフトウェア開発以外のチームにも適用できるのが特徴です。 ●バッ
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
2012/12/22(土)の社内で開催した「プレゼン祭り」で発表した内容です。アジャイルに全く触れたことが無い人を対象にしたつもりが、「難しい」「内容が盛り沢山で覚え切れなかった」「寝ちゃった」などなどとあまり好評ではなかったのですが、自戒の念も込めて公開しておきます。 対象は「ウォーターフォール開発しか体験したことのない経験5〜6年程度の若者」です。 ※2022/04/11追記 Speaker Deckに移行しました。 https://speakerdeck.com/takigawa401/toriaesu30fen-tehitotoorifen-katutaqi-nihanareruasiyairuru-men
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイル開発の進め方
第4回 RTCを活用したアジャイル開発の実際 | Think IT
Google Code Archive - Long-term storage for Google Code Project Hosting.