並び順

ブックマーク数

期間指定

  • から
  • まで

121 - 160 件 / 166件

新着順 人気順

scrumの検索結果121 - 160 件 / 166件

  • Santiago on X: "Scrum is a cancer. I've been writing software for 25 years, and nothing renders a software team useless like Scrum does. Some anecdotes: 1. They tried to convince me that Poker is a planning tool, not a game. 2. If you want to be more effi

    • えぇ!?はじめてのスクラムマスターでも新卒研修で最高のスクラムチームを作れるようになれるって本当ですか? | BLOG - DeNA Engineering

      スクラムチームの構成 私たちのスクラムチームは以下のような構成で開発を行いました。 開発者 4人 プロダクトオーナー 2人 スクラムマスター 1人(私) プロダクトオーナーが2人というのは通常のスクラムで考えるとあまりないのですが、今回ビジネスサイドから参加したメンバーが通常業務との兼任だったため、なかなか時間を割きにくいという特殊な事情もあり、このような体制をとっていました。 スクラム開発で起こった問題 「スクラムわからん」 これが僕たちのチームに最初に立ちはだかった、最大にして最難関の壁でした。 スクラムの講義やスクラムガイドに目を通しただけではスクラムを理解することは難しく、何を取り組むにしても「これはスクラムのやり方に則っているのだろうか?」という疑問にぶつかってしまい、みんながモヤモヤしているし、物事も前に進まないということがスプリント1では起きていました。 スプリント1のスプリ

        えぇ!?はじめてのスクラムマスターでも新卒研修で最高のスクラムチームを作れるようになれるって本当ですか? | BLOG - DeNA Engineering
      • リーダーのための「スクラムガイド」手引き | サーバントワークス株式会社

        Warning: Undefined array key "footer-widget-center-2" in /home/nagasawa/servantworks.co.jp/public_html/wp-content/themes/emanon-premium/inc/template-cache.php on line 190 Warning: Undefined array key "footer_widget_copyright" in /home/nagasawa/servantworks.co.jp/public_html/wp-content/themes/emanon-premium/inc/template-cache.php on line 213

          リーダーのための「スクラムガイド」手引き | サーバントワークス株式会社
        • V字モデルを使って開発プロセスを組み立てよう〜システム開発で迷子にならないために - TRACERY Lab.(トレラボ)

          TRACERYプロダクトマネージャーの haru です。 システム開発におけるシステムとは何か - TRACERY Lab.(トレラボ)では、システムの定義について説明しました。 この記事では、V字モデルを使ってシステム開発の進め方を組み立てる考え方について説明します。 システム開発は迷路のようなもの まずは質問です。迷路をうまく抜けるコツはなんでしょうか。 迷路をうまく抜けるコツは? 答えは迷路を上からみることです。迷路を上から俯瞰することで、複雑な迷路もゴールが見えて、進むべき方向が見えてきます。 迷路を上から俯瞰する システム開発プロジェクトも迷路のようなものです。 できそうなことから手当たり次第に進んでも、ゴールにたどり着くことはできません。全体像が見えないまま進めると、無駄な作業や手戻り工数が発生しやすくなり、プロジェクトが混乱状態となるリスクが高まります。 システム開発でやるべ

            V字モデルを使って開発プロセスを組み立てよう〜システム開発で迷子にならないために - TRACERY Lab.(トレラボ)
          • From many to one: Moving our JavaScript code into a monorepo | Aha! software

            Aha! Develop is for healthy enterprise development teams — that use scrum, kanban, and SAFe frameworks Learn more Do we need a monorepo? When I first joined Aha!, I was surprised by how well-structured the engineering onboarding program was. I spent several weeks getting to know all the teams and learning the pieces of our system. What I didn't realize at the time was these onboarding conversation

            • Linearでタスク管理したら最高だった話

              はじめに 株式会社mikan のBackendチームの @hoshitocat です。 Notion から Linear にタスク管理を変更して、めちゃくちゃ良かったのでそのご紹介ができたらと思います。 TL;DR Notionも良かったけど、Linearにしたらさらにタスク管理がやりやすくなった タスクのポイントに基づいたベロシティやProject機能がすごい GithubやSlack、Notionとの連携機能が便利すぎる ショートカットが便利すぎる これまでの運用 mikanでは2019年くらいから社内ドキュメントツールとして、Notionを使ってきました。そのこともあって、タスク管理もNotionのDatabaseの機能を使って管理していました。 Product Backlogの運用フロー 事業成長に向け以下のような流れでProduct Backlogを運用しています。 PMや事業企

                Linearでタスク管理したら最高だった話
              • 人事のマネージャーになってのふりかえり|tweeeety@メルカリ

                こんにちは! メルカリのHR部門でマネージャーをしている@_tweeeety_です。 ぼくはソフトウェアエンジニア/エンジニアリングマネージャーがキャリアの大半だったのですが、HR領域に興味を持ちすこし前に人事へジョブチェンジをしました。 興味をもったきっかけは、社会課題を解決するためのテックカンパニーもエンジニア組織も「起こる問題のほとんどは組織と人の問題」ということをエンジニア時代から感じていたことに起因します。そういった問題にぶちあたり、採用 / 育成 / People Managemnet / 目標設定 / etc…と学んでいると「これって人事だよね?」と考えることが多くなっていました。そこからも紆余曲折はあったものの、エンジニアと人事をそれぞれ中途半端に学ぶのではなく、思い切って興味関心が湧いていた人事へ舵をきってみた、という流れです。 そんなこんなで2023年は人事部門にてマネ

                  人事のマネージャーになってのふりかえり|tweeeety@メルカリ
                • スクラムガイドを読んでスクラム開発の理解を深める

                  はじめに スクラム開発は11の異なるソフトウェア会社でCTO/CEOを務めた経験のあるJeff Sutherlandと、30年以上のソフトウェア開発業界での経験があるKen Schwaberによって1990年代前半に共同開発されました。 スクラム開発は公式から"スクラムガイド"という詳細なガイドラインが出ており、30ヶ国語以上に翻訳されていて日本語のバージョンも公開されています。 本記事ではスクラムガイドを要約をしました。スクラムガイドを読んだことがある人の復習になったり、読んだことのない人の全体的な理解の助けになればと思います。 日本語版ではなく英語版をもとにこの要約を作成したので、日本語版とは一部言葉遣いが違っている可能性がありますがご了承ください。要約したスクラムガイドはこちら Scrum Guide | Scrum Guides Scrum Guideについて スクラムガイドはスク

                    スクラムガイドを読んでスクラム開発の理解を深める
                  • サービス案内 |婚活Debutで受けられるサポートについて - 20代 30代のための結婚相談所 婚活Debut

                    ご希望の条件を入力してお相手を検索いただけます。 当相談所では全国6.4万人以上の会員が登録するデータベースSCRUMを使用しており、多くの会員様の中からご希望の方にお見合いのお申込みが可能です。 またカウンセラーよりおすすめのお相手をご紹介いたします。 どんなお相手にお見合いを申し込めばよいかわからなければ、まずカウンセラー紹介の方にお見合いを申し込んでみましょう。 婚活を始めると悩みは尽きません。 また時には不安になるときもあるでしょう。 お一人おひとり、しっかり時間をとって活動の進捗や今後の方針について毎月カウンセリングするので、悩みや不安を一人で抱える必要はありません。 また活動期間中は常時相談を受け付けています。 LINEの返信に悩んでいる、お見合いの服を見てほしい…などどんな些細な内容でも相談は大歓迎。 LINE、Zoom、電話、面談などでいつでもご連絡ください。 プロフィール

                      サービス案内 |婚活Debutで受けられるサポートについて - 20代 30代のための結婚相談所 婚活Debut
                    • In Agile, Where Change is Valued, Why Is a Stable Team So Important?

                      A stable team is one in which team membership doesn’t change often and, instead, is consistent over time. Why should we care? Isn’t Scrum like basketball where you can change the players on the court anytime there is an interruption? Let’s find out… High-performing teams —or teams that gets stuff done with insanely high quality— is the goal of many who arrive in Scrum expecting to get amazing perf

                      • 【リスト】アジャイル開発で使えるプラクティスを集めてみた - Qiita

                        アジャイルプラクティス一覧 アジャイル開発で使えそうなプラクティスを一覧化してみました。(カッコ内)は別名です。ググる際など参考にして下さい。なお、ここで言う「プラクティス」は広い意味で使っています。詳細は末尾の「注意点」を参照願います。このリストが誰かのお役に立てば幸いです。 開発方針/コンセプトの定義 インセプションデッキ エレベーターピッチ (エレベータースピーチ、Lift speeche、Elevator Statement) プロダクトビジョン プロダクトゴール プロジェクト憲章 ゴールデンサークル (Start With Why) チームビルディング ナイスなチーム名 (Team Branding、Team Naming、Group Identity) 星取表 (スキルマップ、スキルマトリックス) トラックナンバー (トラック係数、バス係数、ハネムーンナンバー) ドラッカー風エ

                          【リスト】アジャイル開発で使えるプラクティスを集めてみた - Qiita
                        • Why is Common Lisp not the most popular programming language? | Hacker News

                          It's the lists.No, not the prefix notation, parenthesis, what have you, although that doesn't help. The lists themselves. In Lisp, code is data, and data is lists. Yes, of course, there are hashmaps, arrays, strings. But idiomatic Lisp code really does use linked lists extensively, it's an entire style of programming. Even if you'd prefer to use different data structures (and again, Common Lisp do

                          • 組織全体の改善サイクルが回っておらず、スピード感もない LeSSにおける“複数チームが関わる部分がうまくいかない”問題への対応

                            「【SmartHR/カケハシ/リクルート】複雑化する開発体制におけるエンジニアの社内巻き込み術 ‐プロダクト成長をリードするエンジニアたちの試行錯誤‐」は、成長プロダクトの開発をリードするエンジニアたちの試行錯誤に触れ、社内巻き込み術や改善のステップなどのノウハウを紹介するイベントです。ここで株式会社SmartHRの迫氏が登壇。大規模スクラムにおけるコミュニケーション課題への対応について話します。 迫氏の自己紹介 迫康晃氏:それでは「大規模スクラムにおけるコミュニケーション課題への対応」というタイトルで発表します。まず今日の話のまとめですが、「やりたいこととイベントの目的を整理しよう」ということと「意思決定と共有フローを決めよう」というのがテーマです。 ということで自己紹介です。SmartHRで基本機能のシニアマネージャーをしている迫と申します。3年ほど前にバックエンドのエンジニアとして入

                              組織全体の改善サイクルが回っておらず、スピード感もない LeSSにおける“複数チームが関わる部分がうまくいかない”問題への対応
                            • 登録プロダクトオーナーを取得しました | フューチャー技術ブログ

                              2年前にスクラムマスターを取得しましたが、今後スクラムでプロジェクト運営をしていきたい、DXチームを社内で組織化して手綱を握っていきたいのでプロダクトオーナーを自分たちでやっていきたいというお客さんが増えてくるだろうな、ということでそういうお客さんの支援をしっかりしていけるように知識をアップデートしようということで参加してきました。前回、Scrum Inc.版のスクラムマスターをとったので、同じScrum Inc.版のプロダクトオーナー研修を受けました。 認定スクラムマスターの資格を取得しましたスクラムマスター研修との違い前回受けたスクラムマスターの講習の構成とだいたい同じで、4H程度のスプリントが4回で、2日間の研修があり、最後にオンラインの試験を受けて認定を取得という感じです。内容も、無料で公開されているスクラムガイドで説明されているプロセスをベースにプロダクトオーナーに特化したトピッ

                                登録プロダクトオーナーを取得しました | フューチャー技術ブログ
                              • スクラム知識0のチームが3ヶ月スクラムを回してみたらめちゃくちゃ良かった話 - freee Developers Hub

                                こんにちは Enabling SRE team(通称hayabusa)に所属しているSREのchoreです! この記事はfreee Developers Advent Calendar 2023 - Adventar 2日目です。 内容としてはスクラムが右も左も分からないチームがスクラムを回していってどうなったかを書いています 対象読者 チーム運営が上手くいっておらずスクラムってどうなん?って思ってる人 話さないこと スクラムについての基本的な知識の説明 話の結論 まずはスクラムガイドに従ってセオリー通りにスクラムをしてみて、上手く行かないと感じた部分はスプリント終わりの振り返りで改善していこう! 定期的にスクラムチームの成熟度がどうなっているかを検証するフローを組んでいこう! スクラムはいいぞ〜〜〜 背景 Enabling SRE team*1が発足したのは今年の7月からで、4~5人のS

                                  スクラム知識0のチームが3ヶ月スクラムを回してみたらめちゃくちゃ良かった話 - freee Developers Hub
                                • ユーザーに価値をしっかり届けるために実例マッピングを実施しました - コドモン Product Team Blog

                                  プロダクト開発部の千田です。 チームで「実例マッピング」を実施してみたので、今回はそのことについて記事を書いていこうと思います。 ユーザーストーリーが曖昧なまま開発が進んでいる、ビジネスサイドと開発者の一体感がないなどの課題感があるチームの参考になったら嬉しいです! 前提 チームが抱える課題 実例マッピングとは 実施方法について 良かった点 まとめ 前提 基本的にコドモンでは開発を進める際に、ユーザーストーリーを作成します。私が所属するチームでは、機能を開発する際にPdMがカスタマーサポートなどのビジネスサイドのメンバーから要件をヒアリングした後に機能の仕様を整理し、ユーザーストーリーの一覧を作成します。 その後、PdMと開発メンバーでユーザーストーリーの読み合わせをし、ストーリーポイントを付けていました。しかし、この方法には課題がありました。 チームが抱える課題 PdMが事前に作成したユ

                                    ユーザーに価値をしっかり届けるために実例マッピングを実施しました - コドモン Product Team Blog
                                  • The end of UX design: the birth of product leadership?

                                    Non-UI UX is dead: noone wants “wireframers” anymore. It has far-flinging implications, but I guess the problem lies elsewhere. Please note: I’m personally affected by this. I don’t have a visual talent — I have considerable knowledge attainable about graphics design, but just like someone with a body type of a walrus won’t became a gymnast no matter how hard they train, I will not be able to clea

                                    • 初心者スクラムマスターはどうやってスクラムをチームに定着させたのか? - Cybozu Inside Out | サイボウズエンジニアのブログ

                                      はじめに こんにちは。開発者とスクラムマスター(以下、SM)をしている金丸です。 サイボウズのGaroonという製品の開発チームに所属しています。 サイボウズではSMのことを社内外問わず、より多くの人に知ってもらう啓蒙活動の一環として、サイボウズのSM達によるリレーブログ企画を開催しています。 blog.cybozu.io チームでスクラムを始めて約1年経ち、良い機会と感じましたので、このリレーブログに参戦させていただきます。 今回は、いち開発者がどうやってSMを始めたのか、そして自身の所属するチームにどうやってスクラムを定着させていったのか、自らの経験をベースにお話させていただこうと思います。 駆け出しではありますが、SMが何を行っているかのご理解に役立ちましたら幸いです。 スクラムがチームに定着するまでの流れ スクラムチームの始まり まずはじめに、私のチームの紹介をします。 私のチーム

                                        初心者スクラムマスターはどうやってスクラムをチームに定着させたのか? - Cybozu Inside Out | サイボウズエンジニアのブログ
                                      • 「スクラム」と「カンバン」の“いいとこ取り”アジャイル型開発は可能か?

                                        関連キーワード 開発プロセス | プロジェクトマネジメント 「アジャイル」型開発は、小規模な変更を短期間のうちに繰り返すシステム開発手法だ。実際の開発においては「スクラム」や「カンバン」といった開発手法に沿って進めることになる。スクラムとカンバンはそれぞれ異なる点を持つが、利用シーンによって使い分けるよりも、併用に意義があるという意見がある。どういうことなのか。 スクラムとカンバンは併用できる? 併せて読みたいお薦め記事 連載:スクラムとカンバンの違い 第1回:いまさら聞けない「スクラム」と「カンバン」の違い アジャイル開発の2大手法 第2回:アジャイル型開発の「カンバン」には“あれ”がない? スクラムとの主な違い 第3回:「カンバン」でのアジャイル実践 「スクラム」よりも好まれる利用シーンは? さまざまな開発手法 「アジャイルならドキュメントを残さなくてOK」が根本的に間違っている理由

                                          「スクラム」と「カンバン」の“いいとこ取り”アジャイル型開発は可能か?
                                        • AI-Powered Development with GitHub Copilot 20240202

                                          Bringing Open-Source Brilliance to Scrum Teams: �A Guide to Enhanced Collaboration

                                            AI-Powered Development with GitHub Copilot 20240202
                                          • 読まないと後悔する技術書30選 - Qiita

                                            はじめに 現代の人に名著以外の本を読むような時間はない こんにちは、Watanabe Jin (@Sicut_study)です みなさんは何か新しい技術を学ぶときにどんなコンテンツを利用するでしょうか? 最近ではUdemyなどの動画講座を利用する人が多いと思いますが、本を読んで学ぶという人もまだまだ多いのではないかと思います 今回は私がこれまで5年間読んできた150冊以上の中から厳選した30冊の本を紹介します。広く多くの人に役立つものから、特定の技術の書籍までどれを読んでもあなたの大切な一冊になるのでぜひ読んでみてください 現代人には時間がない なぜ働いていると本が読めなくなるのかという本が話題になりました 現代人は本を読む時間がなくなっています。 仕事に追われてしまい、プライベートで本を読む暇などなくなっているのです。 しかし、エンジニアは「技術職」なのでプライベートの時間でも学習をして

                                              読まないと後悔する技術書30選 - Qiita
                                            • Kanban: A Project Management Approach to Software Development

                                              Kanban is a popular agile project management framework. Kanban methodology shares a few similarities with Scrum, primarily in terms of its focus on early release through collaborative and self-management teams. The origin of the Kanban concept goes back to the production line of Toyota factories during the 1940s. Kanban methodology is highly visual. This visualization helps develop optimal results

                                                Kanban: A Project Management Approach to Software Development
                                              • アジャイルな組織を作るために開発チーム作成ガイドを書いた話 / Scrum Fest Mikawa 2023

                                                みなさんご存知の通り、スクラムの基本単位はスクラムチームという小さなチームです。 サイボウズという組織の内外でスクラムマスターとして約8年の試行錯誤を重ね、組織全体をアジャイルにするためには、組織の基本単位をスクラムチームのような自律的な小さなチームにすることが何よりも重要だと考えることになりました。 チームが重要であることはその通りですが、組織を見渡してみると、必ずしもすべてのチームがスクラムを実践しているわけではありません。スクラムを指導したいわけではなく、自律的に活動する小さなチームを作りたいのです。チームやチームワークに関する情報は巷に多く存在しますが、我々のようにすでにある程度の規模で活動しているプロダクト開発組織で、チーム環境を整えるために実践的に使える情報は存在しませんでした。 そこで、これまでのチームに関する学びと実践を踏まえ、サイボウズの開発組織の文脈において、スクラムを

                                                  アジャイルな組織を作るために開発チーム作成ガイドを書いた話 / Scrum Fest Mikawa 2023
                                                • アジャイルと反復開発 ~忍者式テスト20年の実践から~ 再演とパネルディスカッション - 関将俊、深谷美和、米澤慎

                                                  Scrum Fest Mikawa 2023 #scrummikawa スクラムフェス三河2023 栃木の基調講演に誘われました! 今回はSQiP2023の再演を軸にしたパネルディスカッションをやります!30分の再演パートと60分のパネルパートで構成します。 SQiP2023の概要: 反復開発やテスト駆動開発を基礎としたアジャイル開発は世界中で広く普及している。その一方で、アジャイル開発の個々のプラクティスはうまくできているのに、製品開発がうまくいかないといったケースも見受けられる。うまくいかないチームの様子を聞いてみると、基礎となる反復開発の実践に問題があるように感じた。 私たちのチームは製造業でミッションクリティカルな領域のソフトウェアをエクストリームプログラミングで開発している。私たちの20年以上にわたるアジャイル開発の豊富な経験から、反復開発をうまくやる方法を伝え

                                                    アジャイルと反復開発 ~忍者式テスト20年の実践から~ 再演とパネルディスカッション - 関将俊、深谷美和、米澤慎
                                                  • スクラムマスター不在でスクラムをやるのは(とても辛いので)やめておけ! #scrumfukuoka

                                                    2024年3月8〜9日に行われたScrum Fest Fukuoka 2024の登壇資料です。 Speakers Kazushi NAKAMICHI haruhito aso Talk Details https://confengine.com/conferences/scrum-fest-fukuoka-2024/proposal/19495

                                                      スクラムマスター不在でスクラムをやるのは(とても辛いので)やめておけ! #scrumfukuoka
                                                    • Technology Trends for 2024

                                                      What O’Reilly Learning Platform Usage Tells Us About Where the Industry Is Headed This has been a strange year. While we like to talk about how fast technology moves, internet time, and all that, in reality the last major new idea in software architecture was microservices, which dates to roughly 2015. Before that, cloud computing itself took off in roughly 2010 (AWS was founded in 2006); and Agil

                                                        Technology Trends for 2024
                                                      • スクラムフェスニセコ2023に参加してきました #scrumniseko | DevelopersIO

                                                        11/2-3にヒルトンニセコビレッジで宿泊込みで行われたスクラムフェスニセコ2023のイベントレポートです。 こんにちはCX事業本部Delivery部のさかじです。 11/2-3にヒルトンニセコビレジで宿泊込みで行われたスクラムフェスニセコ2023に参加してきました。一部ですが様子をお伝えしたいと思います。 Day1 オープニング アジャイル札幌のいづさんから、今回のスクラムフェスニセコについて説明がありました。 なぜニセコなのか やらないこと、新しくやること 2日間の過ごし方 行動規範 ビンゴ 1列でもビンゴになるとニセコのお土産がもらえます。内容はスクラムフェスニセコに関連する内容がありました。 Keynote 内容がありすぎて(スライドのすべて話せなかった+オーバーランでした)すべてを書きと止めることもできず、自分の良いなとおもったところだけ上げておきます。 自己紹介 さっぽろに来て

                                                          スクラムフェスニセコ2023に参加してきました #scrumniseko | DevelopersIO
                                                        • スクラムチームのメンバーとしてQAが入ってみる - freee Developers Hub

                                                          こんにちは。freee会計のQAをしているakariです。 freee Developers Advent Calendar2023 8日目です。 私が所属する開発チームでは、QA含むスクラムチームで開発をしています。スクラムチームの中で QAがどのような動きをしているかについて先日インボイス制度に対応した際の例を挙げて書きたいと思います。 まだまだ改善点はありますが参考程度に読んでいただけると嬉しいです。 過去にはfreeeカードUnlimitedのテストでの事例をymtyさんが紹介していますのでご覧ください。 developers.freee.co.jp 開発エンジニアとQAエンジニアについて freeeでは多くの開発チームが各プロダクトや各機能別に分かれています。QAチームの場合は、プロダクト横断で存在していますが普段は各開発チームごとに分かれ1開発チーム5~6人に対してQAエンジニ

                                                            スクラムチームのメンバーとしてQAが入ってみる - freee Developers Hub
                                                          • 開発生産性と探索型組織の作り方 / developer-productivity-20240126

                                                            SmartHR におけるスクラム開発の歴史と変遷@スクラムフェス大阪2022 / smarthr-scrum-history-20220618

                                                              開発生産性と探索型組織の作り方 / developer-productivity-20240126
                                                            • [Mac] スクラム開発のプランニングポーカーで”2″と見積もった人のカメラ画面に風船が飛ぶ | DevelopersIO

                                                              プランニングポーカーとは スクラム開発やアジャイル開発では、PBI(Product Backlog Item)の完了に必要な工数を見積もるために、プランニングポーカー という手法がよく使われます。 プランニングポーカーでは、各メンバーが PBI ごとに予測されるストーリーポイント数を「いっせーの」で示します。ポイント数を示す方法は、主に以下の 2 つがあります。 数字が書かれたカードを使う ポイント数分の指を立てる 今回の事象は、後者の「ポイント数分の指を立てる」方法で、"2" を見積もるために V サインをした際に発生しました。 発生理由 macOS Sonoma 以降では、ビデオ会議でジェスチャーによるリアクション機能が追加されたためです。この機能は FaceTime の他に Google Meet や Microsoft Teams などでも有効となっています。 リアクションを起こせ

                                                                [Mac] スクラム開発のプランニングポーカーで”2″と見積もった人のカメラ画面に風船が飛ぶ | DevelopersIO
                                                              • Agile in the Age of AI

                                                                Scrum is over 30 years old, the Agile principles are over 20 years old, and we are now entering the Age of AI, a strange new world where intelligence is available as a service. How does AI impact Agile, and popular methods and frameworks like Scrum? Most Agile practices and principles are based on assumptions about human behavior and team productivity. Some of these assumptions still hold true, bu

                                                                • Regional Scrum Gathering Tokyo 2024 で「アジャイルの価値を活かせる受託開発案件の取り方・始め方」という登壇をしてきた | DevelopersIO

                                                                  Regional Scrum Gathering Tokyo 2024 で「アジャイルの価値を活かせる受託開発案件の取り方・始め方」という登壇をしてきた はじめに こんにちは、モダンオフショア事業推進担当兼Classmethod Vietnam(Danang)の藤村です。2024年1月10日〜1月12日に東京の御茶ノ水ソラシティカンファレンスセンターで開催されたRegional Scrum Gathering Tokyo 2024で「アジャイルの価値を活かせる受託開発案件の取り方・始め方」という登壇をしてきました。 RSGTでの登壇は、RSGT2015「開発モデルの作り方 ~守破離の破!~」、RSGT2016「フィリピンのスタートアップにスクラムを導入しようとしてみたお話」、RSGT2020「最高のScrumキメた後にスケールさせようとして混乱した話」、RSGT2021「モダンオフシ

                                                                    Regional Scrum Gathering Tokyo 2024 で「アジャイルの価値を活かせる受託開発案件の取り方・始め方」という登壇をしてきた | DevelopersIO
                                                                  • 見積もりじゃなくてプロダクトを見ながら開発 #RSGT2024 - Mitsuyuki.Shiiba

                                                                    Regional Scrum Gathering Tokyo 2024 (RSGT2024) で、ゆのんさんと一緒に登壇してきました。 資料 https://speakerdeck.com/kakehashi/develop-a-new-product-with-bad-practices 話したこと ゆのんさんがエンジニアリングマネージャ兼スクラムマスター、僕がフルスタックエンジニアとして4人のチームを作って、新規プロダクトの立ち上げにスクラムで取り組んだ。 その中で、Badプラクティスと呼ばれる「あまりやらないほうがいいと言われていること」も選んで開発に取り組んだのだけど、どうしてそんなことをしたのかってお話。 新規開発と見積もり 今回はReadyになるのを待たずに、見積もりをせずに開発に取り組んだ。 新規開発って、分かっていないことがたくさんあるし、開発を進める中でも新しい情報がどん

                                                                      見積もりじゃなくてプロダクトを見ながら開発 #RSGT2024 - Mitsuyuki.Shiiba
                                                                    • Agile Methodology for Project Management

                                                                      Agile methodology is one of the most popular and recognizable project management methodologies. This article will discuss what Agile Methodology is and what the benefits are in implementing projects with its iterative and incremental project execution concepts. What is Agile Project Management? Agile methodology is an iterative approach to project management and software development that prioritiz

                                                                        Agile Methodology for Project Management
                                                                      • SWAT×Agile Coach: 異なるスキルが共創するまで

                                                                        こんにちは!Agile SWATチームの谷村、日下、荒瀬です。普段私たちはLINEヤフー株式会社およびグループ会社のアジャイル開発のサポートをしています。 もともとSWATチーム(谷村、日下が所属)とAgile Coachチーム(荒瀬が所属)は別々のチームでしたが、1つのチームとして協働でAgile開発支援をすることになりました。なぜタッグを組んだのか、どのようなシナジーが生まれたかをお話しします。 SWATチームとAgile Coachチーム、それぞれの強みと課題 SWAT チームは、社内のさまざまなサービスの技術サポートを行っています。この名前は、警察の特殊部隊を連想させるような仕事内容から来ています。具体的には、各部門の開発チームだけでは対応できない技術的課題に対応し、依頼内容に応じて適切なメンバーをアサインし、開発チームとともに数カ月間で課題の解決にあたります。 SWAT メンバー

                                                                          SWAT×Agile Coach: 異なるスキルが共創するまで
                                                                        • スクラムの価値基準を育む: 新スクラムチームのためのコーチングテクニック10選 | サーバントワークス株式会社

                                                                          Warning: Undefined array key "footer-widget-center-2" in /home/nagasawa/servantworks.co.jp/public_html/wp-content/themes/emanon-premium/inc/template-cache.php on line 190 Warning: Undefined array key "footer_widget_copyright" in /home/nagasawa/servantworks.co.jp/public_html/wp-content/themes/emanon-premium/inc/template-cache.php on line 213 Professional Scrum Product Owner™ 認定研修(試験付き) (2024年3月28日

                                                                            スクラムの価値基準を育む: 新スクラムチームのためのコーチングテクニック10選 | サーバントワークス株式会社
                                                                          • チーム開発はじめました - エムスリーテックブログ

                                                                            コンシューマーチームのブログリレー3日目です。 コンシューマーチームで行ったアスクドクターズ開発の開発体制変更についてご紹介したいと思います。 はじめまして。エムスリーエンジニアリングG コンシューマーチームで主にアスクドクターズ開発のスクラムマスターの甲村と申します。 すっかり寒くなり紅葉の季節ですね。 六義園の紅葉です アスクドクターズ開発の守備範囲 元々の開発体制 体制変更と工夫した点 変更したら何が起きたか 体制変更後の失敗談 まとめ We are hiring!! アスクドクターズ開発の守備範囲 オンライン医師相談サービスのアスクドクターズは15年以上続いているサービスです。 このサービスの技術基盤はStripe、AmazonPay、 携帯キャリア決済関連にiOS決済、ネイティブアプリ(iOS/Android)やメール決済など。機能としてもコアとなる医師相談の他、企業従業員向けに

                                                                              チーム開発はじめました - エムスリーテックブログ
                                                                            • スクラム | 用語解説 | 野村総合研究所(NRI)

                                                                              スクラムを支える考え方 スクラムを支える考え方は、経験主義と、リーン思考に基づいています。経験主義とは、知識は経験から生まれるものであり、観察に基づき意思決定するという考え方です。リーン思考とは、無駄を省いて本質に集中するという考え方です。 この2つの考え方を踏まえて、透明性、検査、適応という「スクラムの3本柱」と、確約、勇気、尊敬、公開、集中という「スクラムの5つの価値基準」が定義されています。 スクラムの3本柱 「透明性」「検査」「適応」という3本柱を実現できるようにスクラムは設計されています。 透明性の柱では、プロセスや作業を作業をする人と受け取る人の双方に見えるようにすることが言及されています。透明性の低い作成物はプロダクトの価値を低下させ、リスクを高める意思決定につながる可能性あります。透明性があることで検査が意味を帯びてきます。 検査の柱では、望ましくない変化や問題に気づくため

                                                                                スクラム | 用語解説 | 野村総合研究所(NRI)
                                                                              • デザイナーだけど、認定スクラムマスター取得して良かったなぁ。|イシジマミキ

                                                                                エンジニア組織内でデザインするのが大好きですので、スクラム開発を見たり聞いたり、開発内スクラムイベントの場にいる事はよくありました。しかし、スクラムへの理解があった訳ではないのでいつもチンプンカンプン。 先達であるエイマエダカツタロウさんから具体的にオススメの研修を教えてもらったので自腹で参加しました! 「スクラムマスター」という名前がカッコ良かったし、スクラムを知っておく事はムダにはならんやろ。という気楽さです。 この記事は赤ちゃんスクラムマスターである私がスクラム研修や認定を受けてか良かったな〜という点を挙げたものです。 デザイナーなのにスクラム勉強して意味あんの 現在の体制や役割について理解が深まって良かったよ チームとして望ましい動きってのが少し見えたかな 要約すると上記のような主旨です。主に感想記事ですのでここから下は興味があれば読んでやってください。 またスクラムガチ勢の皆様に

                                                                                  デザイナーだけど、認定スクラムマスター取得して良かったなぁ。|イシジマミキ
                                                                                • Scrum Inc. Japan #TeamworkMakesTheDreamWorkアジャイル マニフェストはいかにして生まれたか - Scrum Inc. Japan #TeamworkMakesTheDreamWork

                                                                                  by Jeff Sutherland | February 11, 2021 | Blog(翻訳:荒本 実) 20年前、私はユタ州スノーバードに行き、同じ目標を持つ16人の仲間と合流しました。 それは、私たちの業界、つまりソフトウェア開発のやり方をより良い方向に変えることでした。顧客を第一に考え、よりスマートに働き、より速く、より頻繁に、より良い成果を出すことでした。 その会議で、私たちはアジャイル マニフェストとしてよく知られている4つの価値と12の原則を作成しました。 私は、多くの変革に貢献したこの文書の 17 人の署名者の 1 人であることを誇りに思っています。 アジャイル 20 周年を記念して、アジャイル マニフェストがどのようにして生まれたのかをお話ししたいと思います (こちらのビデオもご覧ください YouTube channel)。まずは、その場にいたすべての方々に感謝の意を表

                                                                                    Scrum Inc. Japan #TeamworkMakesTheDreamWorkアジャイル マニフェストはいかにして生まれたか - Scrum Inc. Japan #TeamworkMakesTheDreamWork