A mindmap is a diagram used to visually organize information. It can be called as a visual thinking tool. A Mindmap allows complex information to be presented in a simplified visual form. A mind map is created around a single concept. The concept is represented as an image in the center to which the associated ideas are added. Major ideas are connected directly to the central concept, and other ideas branch out from those. Mindmap is a great tool for note taking, planning, studying, brainstorming etc. The term 'mind map' was first used by Tony Buzan in 1974. I drew my first mindmap when I was in school. I preferred mind-mapping over text notes and it proved to be a great aid to revise and recall the concepts quickly. This is because the information in mindmap is structured in a way that mirrors exactly how the brain functions - in a radiant rather than linear manner. A Mind Map literally ‘maps’ out your thoughts, using associations, connections and triggers to stimulate further ideas.

Tester's are expected to come up with a lot of artifacts during the process of testing. The traditional test artifacts are time intensive, bulky and their structure do not support the agile approach of software development. When working in an agile environment testers work in a highly compressed test execution cycles. The stakeholders always complain about testing as a bottleneck and ask to cut down a number of testing activities or time allocated for testing. If we spend too much time on documentation, we might end up having very less time to do actual testing. Documentation != testing Testers can use smart techniques like Mindmaps to create lean test artifacts - from test plan to a test report. Lean test artifacts convey the same information using fewer details and less verbose. Lean test artifacts save a tremendous amount of time involved in test documentation. When I say I am applying lean approach it means I am reducing waste and at the same time, I am amplifying my learning.

Mind mapping is a cognitive activity that triggers creative ideas and reduces waste by avoiding extensive formats for test documentation. Mind maps can be used in all the test stages from test planning to test case execution. Mindmaps can be used for:

- Test Planning
- Requirement analysis
- Impact analysis
- Task allocation
- Test case design
- Traceability
- Test reporting
- Quick test reports

Test planning
While test planning, you can draw an initial Mindmap keeping in mind the list of tasks, schedules, tools, roles, responsibilities, milestones etc. Present the Mindmap and discuss it with your stakeholders. Modify the Mindmap if any changes are required. One thing you will love about mind maps is its flexibility to adapt to changes. All you might have to do is to add or remove a node/branch. This flexibility might not happen when you draw on a paper, but a mind mapping software assists any changes easily. The final mind map shows you the scope of testing in one glance. This mind map can be used as a blueprint and later converted into a plan. This ensures that no test activity is missed.


Test case design
Mindmaps are an efficient way of creating lean test cases. It reduces the time required for creating test cases yielding better results. Mindmaps are very easy to maintain and are flexible to changing requirements. Draw branches from every user story/epic and associate all its functionalities as sub-nodes. Start adding test ideas/test case for each functionality. I created a mindmap covering test ideas for the major functionality. My team started to expand the mindmap by branching out more and more test ideas. We kept adding new nodes when we found unique scenarios that uncovered the bugs during our test sessions. This drastically increased our test coverage. The final mindmap can be as the basis for test case document or it's cool if it's used as it is. The best part of mind mapping is that you generate more ideas when drawing them. Collaborative mind mapping with the team gives you the best results.

Traceability mindmap

A traceability matrix is an essential tool for every tester to analyze and improvise the test coverage. You can use a mind map instead of a tabular traceability matrix.

To create a traceability mindmap - add nodes of all the Epics. Draw branches from every module and associate all its user stories as subsequent nodes. Now link the test cases for all functionality. You can link the required number of the test management tool.

This ensures that you have not missed out writing test cases for any user story. This mindmap gives you the birds-eye view of your test coverage. You can identify the areas where you need to strengthen your coverage.

 
3 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/Structure of the Thought & Practice

  • Introduction to mindmaps
  • Problems that we face in our day to day lives - and how mind maps can help to overcome them.
  • How to draw a mind map from scratch using best practices.
  • Challenges that testers face with test documentation
  • How mindmaps can act as lean test artifacts
  • Designing Lean test plan using 2 different techniques.
  • Designing Lean test cases using 4 different techniques.
  • Designing a traceability mindmap instead of a traceability matrix
  • Using Mindmaps for Enhanced learning
  • Mindmaps for recording meetings.

Learning Outcome

  • What is a mindmap and why mindmaps work?
  • To draw effective mindmaps using best practices.
  • Overcome challenges with traditional artifacts using mindmaps.
  • To design a lean test plan.
  • To design lean test cases and boost your test coverage.
  • Enhanced learning using mindmaps.
  • Recording your meetings effectively using mindmaps.

Target Audience

Testers, QA, Scrum master, Product owners, Developers

Prerequisites for Attendees

N/A

schedule Submitted 5 months ago

Public Feedback

comment Suggest improvements to the Speaker

  • Liked Yoh  Nakamura
    keyboard_arrow_down

    Yoh Nakamura - ファシリテーションの難しさと楽しさ

    20 Mins
    Thought & Practice
    Beginner

    ScrumでもXPでもアジャイルなやり方でプロダクト開発をしていく上で”会話”は大事になってきます。

    そのような会話は1対1に限らず、チーム全員、チームとステークホルダーのような複数人である会話することもあります。
    そのような場には様々なコンテキスト、利害関係を持った人々が集まることもあり、何もしないで良い結果を得るのが難しい場合もあります。

    その場の質を高めるスキルの1つがこのセッションのテーマである”ファシリテーション”です。


    ファシリテーションとは、会議、ミーティング等の場で、発言や参加を促したり、話の流れを整理したり、参加者の認識の一致を確認したりする行為で介入し、合意形成や相互理解をサポートすることにより、組織や参加者の活性化、協働を促進させるリーダーの持つ能力の1つ。日常での組織コミュニケーション全般において、ファシリテーション技術は活用される。 (Wikipediaより抜粋)


    このセッションでは、スクラムマスターにとって必要なスキルの1つでもあるファシリテーションの難しさや楽しさを、現場コーチとして20以上の現場を支援してきた知見を交えてお話します。

  • Liked Shigeki Morizane
    keyboard_arrow_down

    Shigeki Morizane - 全部SCRUM!~SIerで大切だったもの、サービサーで大切だったもの~

    Shigeki Morizane
    Shigeki Morizane
    CTO
    Levtech Co., Ltd.
    schedule 5 months ago
    Sold Out!
    20 Mins
    1st Step Case Study
    Beginner

    2018年、15年勤めた富士通、NRIというSIerを辞め、Leveragesというベンチャーのサービサーに移籍しました。

    これまで、SIerやそのお客様先でSCRUMの導入を支援してきましたが、実際のWeb系のサービサーでのSCRUMはまったく毛色の違ったものでした。

    でも、どちらもSCRUM!全部SCRUM!

    規模や価値観やビジネスモデルによるSCRUMの取り入れ方の差を身体で感じ取った話しをします。

  • Liked Yusuke Amano
    keyboard_arrow_down

    Yusuke Amano / Toshiyuki Ohtomo - チームワークの会社で最高のプロダクトを目指すチームができるまで -強くてスケールするチームの作り方-

    45 Mins
    Thought & Practice
    Intermediate

    私(@ama_ch)が所属するサイボウズでは、「チームワークあふれる社会を創る」というビジョンを掲げてグループウェアを開発しています。

    自分たち自身のチームワークを高めるために、2016年にスクラムを導入しました。私の所属するkintone開発チームでは、スクラム導入から1年以上が経過し、新たに下記のような問題に直面していました。

    「スクラムを導入したは良いけど、まだ加速しきれていない気がする」
    「チームが壊れないようスケールさせるにはどうすれば?」

    これらの問題を解消し、最高のプロダクトを目指すチームを作るために社外のスクラムマスター(@toshiotm)を巻き込んで、より良いスクラムの実践を探求してきました。

    1年間の実践を通じて、私たちのチームには以下のような特徴が現れました。
    - 複数拠点をまたぐリモートモブ中心の開発
    - 新卒エンジニアが1週間で活躍し始める
    - スプリントごとにチーム構成が変わる
    - 仮説検証マインドにもとづく高速な改善
    - スクラムマスターが不要になる

    この1年の活動をふりかえり、スクラムが本当の意味で機能し始めたチームに起きた質的な変化、スケーリングの取り組み、私自身に起きたスクラムマスターの役割の変化などについて、一緒に推進してきた社外スクラムマスターと一緒に考察したいと思います。

  • Liked kyon_mm
    keyboard_arrow_down

    kyon_mm - 超Scrum入門〜未完成フラクタルと15minSprint〜

    kyon_mm
    kyon_mm
    Test Architect
    オンザロード
    schedule 6 months ago
    Sold Out!
    45 Mins
    Thought & Practice
    Advanced

    https://www.youtube.com/watch?v=7xhxIYYMmTc

    チームがうまくいっていることはスクラムチームの大きな目標です。

    いくつかのスクラムチームに関わってきた立場から、良いチームになるための1つの大きなアプローチを見つけました。私が関わってきたチームでは、最初から1DaySprintをやりつづけています。また、1 Hourのタイムボックスを持つチームもあります。またそれらはたった数日で成されます。

    良いチーム、美しいチームとはスクラムという視点だけにはとどまりません。あるチームでは、15minSprint、1hourSprint、1DaySprint、1WeekSprint、1MonthSprintを構成したフラクタルなスクラムを実践しています。

    数万年に渡る生物の美しさ、クリストファー・アレグザンダーが発見してきた美しさ、といった視点からスクラムやチーム、そして理想像を整理します。

  • Liked Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori - Effective Retrospective / とにかく楽しいふりかえり

    45 Mins
    Thought & Practice
    Beginner

    みなさんは楽しくふりかえりをできていますか?

    スクラムでは「レトロスペクティブ」というイベントとして、チームの活動の一環として定義されている「ふりかえり」。色々なチームの話を聞いていくなかで、ふりかえりがなかなかうまくいかない、というチームが多いという現状が見えてきました。

    マンネリ化してしまったり、ふりかえりがスキップされてしまったり、アイデアがなかなか出てこなかったり。そんな状態から脱却するためには、まずは「場」を作ることが大事だと考えています。

    場とは、心理的・物理的なさまざまな側面からなる流動的に変わっていく生き物のようなものです。この場を参加者全員の力でよい方向に形成することで、チームがより高く成長するためのアイデアが出やすくなります。

    場とは何か。そして、場を作るためにどんなことをすればよいのか。また、ふりかえりを楽しくするためのやり方にもフォーカスを当てて、「ふりかえり」全般についてお話できたらいいな、と考えています。

    以下のことを中心にお話いたします。

    • ふりかえりの3つの目的と3ステップ
    • ふりかえりにおける「場」とは
    • 物理的・心理的に場を作るための方法
    • ふりかえりをより楽しくするための方法
    • ふりかえりのさまざまな手法
  • Liked Takahiro Futagawa
    keyboard_arrow_down

    Takahiro Futagawa - スクラムチームを辞めて20人でカンバン運用してきた半年間の軌跡

    Takahiro Futagawa
    Takahiro Futagawa
    Software Engineer
    eureka, Inc.
    schedule 6 months ago
    Sold Out!
    20 Mins
    Advanced Case Study
    Intermediate

    Pairsを運用する株式会社エウレカでは2018年4月から、それまでの目的別スクラムチーム組織を変更し事業部全体でリアルカンバンを用いたプロダクトバックログの優先順位を忠実に消化できるチーム体制へ変更しました。

    このセッションでは4月から今までのリアルカンバン運用の軌跡についてお話しながら、つらみやうまく行ったこと、今後の展望などをご紹介したいと思います。

  • Liked Yosuke Ota
    keyboard_arrow_down

    Yosuke Ota - スクラム1年生のチームが全員でRSGT2018に参加してわかったチーム開発、はじめの一歩

    20 Mins
    1st Step Case Study
    Beginner

    どのようにするとより良いチーム開発ができるのでしょうか。

    いま、私たちのチームは自信を持ってチーム開発をしています。1週間スプリント中の1日スプリント、当たり前に行われるペア・モブプログラミング、チームの活動に合わせた工夫のあるタスクかんばん、多くのプラクティスを実践することで安定してチームの成果を出しています。

    しかし、スクラム導入からしばらく、自信を持ってチーム開発をしているとは言えない状態でした。

    メンバーの状態に左右されるベロシティ、レビューで発覚する未完了、再計画されないデイリースクラム、さまざまな課題がそこには存在していました。スクラムのことを良く分かっておらず、言われたことをやっているだけの状態だったため、改善のサイクルをうまく回せないことが続きました。チーム開発に対する不安が大きい時期です。

    このような状態から大きく変わる転換点となってくれたのが、チーム全員で参加したRSGT2018でした。

    本セッションでは私たちのチームがわかったRSGTの素晴らしさと、チーム開発のはじめの一歩を紹介します。

  • Liked Tsutomu Yasui
    keyboard_arrow_down

    Tsutomu Yasui - 心理的安全性ゲーム

    Tsutomu Yasui
    Tsutomu Yasui
    Consultant
    self-employed
    schedule 6 months ago
    Sold Out!
    45 Mins
    Thought & Practice
    Beginner

    チームの中で、なにか事件が起きたとき、誰がどういう反応をするかでチームの底力が垣間見えます。「心理的安全性ゲーム」では、マズい状況に対する様々な反応を体験して、チームにおける心理的安全性の意味と作り方の理解を深めます。

    「心理的安全性ゲーム」はカードゲームですが、勝敗はありません。マズい状況を発見して報告してくれた「平和を破壊する役」に対して、各メンバーは手札から「発言」を選んで反応します。10分ていどで遊べる簡単なゲームになります。

    このゲームは文字通り、心理的な効果を体験できます。たとえゲームと分かっていても、「教えてほしい」と頼んでいるのに「舌打ちをして」「自分でやれ」と言われるとちょっと傷つきます。言ったほうも、あとで心苦しくなったりします(あるいは、スカッとするかもしれません)。そうしたやりとりを目の当たりにしたチームと一緒に、よいコミュニケーションについて話をするきっかけを作るゲームです。

    4-5人のグループでゲームをやり、そこでの気づきやよりよいコミュニケーションの在り方について議論をしたり、共有したりします。さらにどんな改善が見られるか、再度ゲームをやって試してみましょう。

  • Liked Yoshihiro Yunomae
    keyboard_arrow_down

    Yoshihiro Yunomae - 運用中のモバイルゲーム開発チームに、並行バージョン開発を導入してみた

    20 Mins
    Advanced Case Study
    Intermediate
    モバイルゲームの運用では、プレイヤーを飽きさせないために、週2~3回のコンテンツのアップデートと、月1回の機能アップデートを実施します。このため、開発チームは継続的に価値を出し続ける工夫が必要となります。

    アカツキのある大規模開発チームにおいて、人数の割に開発の進みが思わしくなく、作業が属人化されていました。結果的にプレイヤーに継続的に価値を届けるのが困難となっていました。これは、以下の2つが根本的な原因でした。

    ・チームの開発スタイルが確立する前にチームが肥大化したことにより、コミュニケーションフローが整備されていなかった
    ・開発業務中に運用業務の差し込みが入り、度々開発が中断していた

    これらの根本課題に対処するため、以下を実施しました。

    1. 開発チームを分割し、コミュニケーションパスを設計
    2. Scrumをベースに、複数のチームが並行バージョン開発出来るように開発フローを設計
    3. 次々バージョン開発チームが運用業務を行うようにし、次バージョン開発チームの業務中断を抑止

    本セッションでは、並行バージョン開発を取り入れた経緯と、取り入れた並行バージョン開発の手法を詳細に紹介します。
  • Liked Masato Ishigaki
    keyboard_arrow_down

    Masato Ishigaki - プロダクトオーナーとして『開発プロセス』を思考せよ〜EBM(Evidence-Based Management)を軸とした『プロセスの見える化』と『ムダからの解放』を実践したインパクトについて〜

    Masato Ishigaki
    Masato Ishigaki
    Product Owner
    DMM.com
    schedule 6 months ago
    Sold Out!
    20 Mins
    1st Step Case Study
    Beginner

    チームとして、良い『開発プロセス』を設計することは重要です。
    ROIを高めながら、どうやってプロダクトを『最速』でリリースし、仮説検証を『高速』で繰り返せるかを常に考える必要があります。
    そこで、重要なポイントとして気づいたのは、EBM(Evidence-Based Management) の概念におけるT2Mの部分『プロセスの見える化』と『ムダからの解放』です。
    今回は、理想の開発プロセス(EBM(Evidence-Based Management) to 『Lean x Scrum』)から、VSM x SIPOC分析による『プロセスの見える化』の実現から分析プロセス。
    そして、見える化することでわかる『ムダ』の解放をどのような工夫で行ってきたかをお話できればとおもいます。

  • Liked Ken Takayanagi
    keyboard_arrow_down

    Ken Takayanagi / Manabu Shibahashi / Yumiko Yoshida - 喧嘩できるチームを作るワークショップ

    100 Mins
    Workshop
    Advanced

    「チームのメンバーで喧嘩できてますか?」

    自分が言いたいことが相手の意見と対立しそうで、伝えなかった…。
    言ってもわかってもらえないと思ったので言わなかった…。
    このチームでは余計なことをすると指摘されそうで面倒臭いのでやらなかった…。
    そんな体験はないでしょうか?

    自分の伝えたい考えをきちんと伝える。相手が伝えたい考えときちんと向き合う。
    これはチーム内での会話の仕方でもありますが、チームの空気感というか文化からも影響を受けると考えます。

    「喧嘩できる」というのは対立構造ということではなく「喧嘩ができる」チームの空気感があるというある意味「健全なコミュニケーション」が行える状態についてお伝えしたいと思います。

    その改善として、このワークでは組織や文化の理論もお話ししながら、学びと体験をお届けします。

    2018/10/19
    同ワークショップを企業で実施した時の記事が公開されました。

    http://bit.ly/2OCzYA9

    ワークショップを作る時に描いた図

  • Liked Atsuko Tsujioka
    keyboard_arrow_down

    Atsuko Tsujioka - リーダーシップを一度捨ててチームの輪の中に置いた話

    Atsuko Tsujioka
    Atsuko Tsujioka
    Engineer
    SMS Career,inc.
    schedule 5 months ago
    Sold Out!
    20 Mins
    1st Step Case Study
    Beginner

    株式会社エス・エム・エスキャリアの辻岡です。

    弊社は人材紹介事業を主に、医療介護通じて働く人と日本を元気にする会社です。

    私は社内の人材紹介エージェント(キャリアパートナー)が利用する業務システムの開発を主に担当しています。2年半前に弊社に転職しました。

    入社当初配属された部署には以下の課題がありました。

    • 現状の課題をあきらめがち
    • 全員目の前の火消しや依頼に対応するのが精一杯
    • 正社員が誰も実装してない。一切ソースコード見てない
    • 開発計画の正否の考え方が短期目線なものばかり
    • 社員数 << 他の会社から来てくれる人数。→人の管理者状態。
    • リリースしてもトラブルがあっても殆どキャリアパートナーに連絡しない

    etc…

    YAMAZUMI(山積み)

    ある日1つのチームを持つことになりました。

    彼らにアジャイル手法を伝え続けてチームの輪が出来始めた頃。

    私は一人で抱えたチームのリーダーシップを一度捨てました。

    そしてそれをチームの輪の中に置きました。

    リーダーシップを一度捨てることで全員がオーナーシップを持って課題を乗り越えていくチームができた事例を紹介したいと思います。

    発表スライドはこちら

    https://www.slideshare.net/AtsukoTsujioka/rsgt2019-127663850

  • Liked Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe / Haruna Iizuka / Masahiko Morita / Megumi Tsuchihashi / Ryota Nagatomo / Saki Ota / Saki Tanaka / Takuya Uchida / Tsubasa Kanemura / Yuki Misumi - 学習する/Unlearnするチームへ ー 新卒研修とスクラムとモブプログラミング ー

    45 Mins
    Thought & Practice
    Intermediate

    チームがうまくなるために、「学習」と向き合うことはとても大切です。
    私がこれまで関わってきたチームでも、アジャイル開発を通してチームがうまくなることに取り組み続けてきました。

    ところが、最近新卒向けの研修に携わった際に衝撃を受けました。

    ビジネス採用として入社したためプログラミング未経験だった新卒の彼らは、当初は黒い画面(ターミナル)すら怖がっていましたが、数カ月後にはメンター陣からのインプットを頼りに、

    • 1 day timebox
    • 1 hour timebox
    • モブプログラミング
    • プロトタイピング
    • ユーザーインタビュー

    などをまわしながら、3週間でプロダクトを作れるようになっていました。
    その道のプロフェッショナル達がエクストリームだと思うこと/どうはじめたらいいのか悩んでいることを平気で突破してしまったのです。

    もちろん彼らはプロダクトを本番リリースしたわけではありません。
    もちろん彼らは運用しながらお金を稼いでいるわけではありません。
    でも彼らはプロダクトづくりの経験をもっていませんでした。
    でも彼らはプログラミング経験ももっていませんでした。

    私達は、

    • 学習し続けていく中で固定観念に囚われてしまうことがあること
    • 学習をしていないことが圧倒的成長スピードを生むことがあること

    という事実に向き合う必要があります。

    学習を積み重ねていくことで成長スピードが落ちてしまうのではなく、学習を積み重ねていっても成長スピードを落とさないチームをどうつくるか。そのためにはUnlearn(学びをリセット)がキーになります。

    このセッションでは、そろそろ言い訳するのはやめてもっとうまくなるためにはどうすればいいのかを真剣に考えます。もっとうまくなるための学習する/Unlearnするチームについて一緒に考える時間にしましょう。

  • Liked Kenta  Sasa
    keyboard_arrow_down

    Kenta Sasa / Iwao Harada - 明日現場で使える!とにかく明るいScrum Patterns 活用ワークショップ

    100 Mins
    Workshop
    Beginner

    皆さん、開発をエンジョイしてますか?
    開発を行っていると楽しいこともありますが、様々な問題が発生してツラいこともあると思います…

    そんな問題に直面したとき、皆さんはどう対応していますか?
    Try & Errorを繰り返しながら、困難な問題と闘い続けているのではないでしょうか?

    そんな皆様、お喜びください!

    このセッションは、Scrum Patternsを使った問題解決の紹介するだけでなく、実際にそれを体感できるワークショップを開催させてもらおうと思います!
    多くの現場で有効なパターンを学ぶことで、明日の現場に役立つ方法を持ち帰ることができます。

    パターンとは既に実証済みの解決策

    パターンは建築家アレグザンダーの提唱した『パタン・ランゲージ』で挙げられており、パターンの構造は以下のようになっています。

    ❝ある「文脈」で繰り返し起こる「問題」「解決」する方法。その方法にはいくつかの「制約」が課せられているかもしれない -- 結城浩

    私たちはそのパターンを通して、先人たちの知恵を学ぶことができます。
    パターンは時に知っていると思い込んでいる事に関しても新しい視点を与えてくれたり、改めて解決方法の目的の真意を思い起こさせたりします。

    そんなパターンを中心にみんなで問題を議論し、よりよい解決方法を見出したいと思っています。

    皆さんがお持ちの悩み、既にパターンに書いてあるかも?

    ワークショップに関して

    ワークショップを開催するのは、アジャイルコーチやスクラムマスターを中心とした、パターン大好きメンバーが集まったグループ "Scrum Patterns Tokyo (通称SPaT)" です。
    パターンを知らない人や、アジャイル開発初心者でも楽しめる場を提供したいと思います。

    1組4、5人で4組を想定しており、各チームに1人SPaTメンバーがフォローに入ります。

    みんなでパターンランゲージを楽しみましょう!

    ワークショップ登壇者

    • 天野 祐介
    • 原田 厳
    • 稲野 和秀
    • 木村 卓央
    • 川口 恭伸
    • 小坂 淳貴
    • 笹 健太

    参考サイト

    Scrum Patternsに関してはScrum PLoPのサイトがあります(英語)
    http://www.scrumplop.org

    ※本セッションではSPaTが日本語訳したパターンカード(仮)を使用します。

    英語が苦手な方でも問題ありませんのでご安心下さい。

  • Liked Tatsuya Kinugawa
    keyboard_arrow_down

    Tatsuya Kinugawa / Rochelle Kopp - そのときサーバントリーダーはどう振る舞うか

    45 Mins
    1st Step Case Study
    Beginner

    サーバントリーダーシップを実践するにあたって様々な場面で振る舞いを考えさせられることがあります。

    上司への向き合い方、配下リーダー陣への向き合い方、はたまた彼らのメンバーに向けてもこれまでとは違う振る舞いをすることが多いです。

    本セッションではRochelle Koppさんと一緒に具体的なシチュエーションを題材にしながら旧来のマネジメントとサーバントリーダーシップの振る舞いの違いについて実例を挙げながらお話したいと思います。

    これによりこのマネジメント手法がより身近なものに感じて頂ければ嬉しいです。

  • Liked Harada Kiro
    keyboard_arrow_down

    Harada Kiro - Scrum@Scale Guide を読んでみよう

    Harada Kiro
    Harada Kiro
    CEO and Agile Coach
    Attractor Inc.
    schedule 6 months ago
    Sold Out!
    20 Mins
    Thought & Practice
    Beginner

    Scrum@Scale Guide を読んでみましょう(RSGT2019までには日本語版が出ているはず)。

  • Liked Fumitaka Inayama
    keyboard_arrow_down

    Fumitaka Inayama / Kazuki Mori / Ken Takayanagi / Shigeki Morizane / Toshiaki Nomura - フルバージョン登場!「プロばこ」で学ぶ作業プロセス・デザイン・ワークショップ

    100 Mins
    Workshop
    Beginner

    「考えていた作業計画と実際の作業が全然違っていてチームの作業が進捗しない」
     「改善をしているはずだけどトラブルが起きてからの事後対処になっている」
    などの経験をしたことはありませんか。

    チームメンバを招集して、チームビルディングも儘ならないでプロジェクトを始めてしまって、後手後手にチームの仕事のルールを決めたり、メンバ同士の関係作りに時間を使うくらいなら、最初に『プロばこ』でワークショップをご体験ください!!

     フルバージョンで登場する「プロばこ」は、チームの作業プロセスのデザインと合意形成のフローを体験できるパワーアップしたワークショップです。

    rsgt 2018では、QualityとDeliveryの2つを制約条件にチームの作業プロセスをデザインしました。フルバージョンでは、さらに2つの制約事項がチームの制約として追加されます。

     あなたのチームは、さらに複雑になる制約条件をくぐり抜けられる作業プロセスをデザインできるでしょうか…

  • Liked Yoh  Nakamura
    keyboard_arrow_down

    Yoh Nakamura - プロダクトバックログアイテムの価値をどう扱うか?

    20 Mins
    Advanced Case Study
    Intermediate

    Scrumで「プロダクトバックログアイテム(PBI)の価値をどう考えて、どのように扱うか?」というのは時々聞く質問の1つです。

    1つずつのPBIの情報に"売上の増える額"や"ユーザー数の増加”を加えているチームもあります。
    また別の現場ではストーリーポイントと同じようなやり方で、仮想の単位を決めて相対的な値をチームで話し合って、どれからやるか?の参考にしています。


    プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性がある。(ScrumGuide2017より)



    このセッションでは、"プロダクトバックログにおける価値の取り扱いのやり方”のいくつかの事例や現場コーチとしての知見や考えをお伝えします。
    みなさんのプロダクトバックログがより良くなるヒントになればと思います。

  • Liked Ryutaro YOSHIBA (Ryuzee)
    keyboard_arrow_down

    Ryutaro YOSHIBA (Ryuzee) - アジャイル開発でコールド負けしないための5つのポイント

    45 Mins
    Thought & Practice
    Beginner

    多くの組織では、うまく進めるためのショートカットやツールを求める傾向にありますが、足元が固まっていない状態でさまざまなプラクティスやツールを導入しても無意味で、混乱したまま成果も出せずに終わってしまうこともあります。また、そのような状態で大規模な開発を進めるのは自殺行為です。

    本セッションでは、アジャイル開発をうまく進めるために最低限考えなければいけないポイントをスクラムの文脈で紹介いたします。これらのポイントは多くのアジャイルコーチングの場において強く伝えていることです。

  • Liked KazuhideInano
    keyboard_arrow_down

    KazuhideInano / Yoh Nakamura - 受託開発だったりロケーション離れてたりなど課題たくさんの中で支援している現場の話

    20 Mins
    1st Step Case Study
    Beginner

    「もっとビジネスのスピードを上げたい」という課題意識があり、それの解決方法として「今までのやり方のままでは難しい。だからアジャイル開発手法を導入したい」と考える企業は多いです。

    とはいえ「さあ始めよう」とするにしても、関わる人のマインドや協力会社との関係性、とりまく環境などなど変えて行かなければならないことがたくさんある場合が多く、実際のところそれがなかなか大変だったりします。人も組織もなかなか急には変われないものですよねぇ。

    よく直面しがちな課題の例を挙げてみると...

    • 受託開発でPOが発注側、DevチームとSMが受注側という関係性
    • 復数Devチームだがコンポーネントチーム
    • Devチームが個の集団
    • 複数POが織りなす複雑なビジョン
    • 得られた成果やアジリティが見えない
    • POとDevチーム、SMのロケーションが別
    • コミュニケーションしづらい座席レイアウト

    などなど。

    さて、このセッションではこのような課題を抱えつつもスクラムの実践に取り組み奮闘している現場のひとつをケーススタディとして、実際にどんな課題があり、スクラムチームやコーチがどのように取り組み解決を試みたのかの成功談や失敗談をみなさんの参考になるべく紹介したいと思います。