並び順

ブックマーク数

期間指定

  • から
  • まで

521 - 560 件 / 1351件

新着順 人気順

アジャイル開発の検索結果521 - 560 件 / 1351件

  • 工数超過の要因、過剰なテストを避けよう 効率的に要件を作成する「V&V」という考え方とは

    工数超過の要因、過剰なテストを避けよう 効率的に要件を作成する「V&V」という考え方とは:アジャイル開発における品質管理(3) 少人数、短期間の開発を繰り返すアジャイル開発では、どのようにすれば品質を保つことができるのだろうか。本連載では、アジャイル開発における品質管理の手法を解説する。今回は、スプリント内でのテストと品質保証について、2回に分けて解説する。前編となる今回は要件設定とV&Vについて。 アジャイル開発において、テストをどのように実施するかは難しい問題です。短い開発周期で、設計、実装にしっかり時間をかけようとすると、それに伴ってテストを実施する時間は少なくなります。結果として、テストがスプリント(※)内で収まらず、テストのタスクを次のスプリントに持ち越してしまいます。結果として本来のタスクに着手できず、プロジェクトが停滞してしまうことも考えられます。 (※)アジャイル開発におけ

      工数超過の要因、過剰なテストを避けよう 効率的に要件を作成する「V&V」という考え方とは
    • スクラムでの見積もり - Qiita

      はじめに スクラムでの見積もりは意外とさらっと書かれている事が多く、作業見積もりと規模見積もりがごちゃごちゃの状態でスクラムを進めていた結果、チームの中で見積もりに対する不信感が強くなり「このままではいけない」と感じたため、まとめました。 また、似たような記事があまりネット上で見かけなかったため、ここにざっくりと分かるように集約しました。ぜひ、自分のようにごちゃごちゃになってしまっている方に届けば嬉しいです。 まず何のために見積もるか アジャイルのチームにとって、作業を見積もることは、良い予測を追求しようとするだけではありません。チームが要求を深く理解し、開始する前に何を構築しようとしているのかをより深く考え、一定時間内にチームで協調して取り組むことで、構築しているものに対して大きな価値を生み出すことを促します。 (アジャイルメトリクス p40より) 見積もりによってプロジェクトの状態が見

        スクラムでの見積もり - Qiita
      • Clean Agileを読みました|食べログ フロントエンドエンジニアブログ

        こんにちは。食べログのフロントエンドチーム の荒川です。 先日、「Clean Agile 基本に立ち戻れ」を読みました。 本日はこの本の要約を、私たちのチームの活動を交えてご紹介しようと思います。 著者の Robert C. Martin氏は、アジャイルマニュフェストの創案者の一人で、 国際的なソフトウェアコンサルティング、スキル開発を行っています。 https://agilemanifesto.org/iso/ja/manifesto.html 1章 アジャイル入門 アジャイルの歴史 アジャイルの歴史は5万年以上前、人間同士が協力して、共通の目標を達成しようとしたことが始まりと述べています。ソフトウェア開発においては、アラン・チューリングがチューリングマシンの論文を執筆した1936年の当時や、1946年にACE(Automatic Computing Engine)のために書いた最初のコ

          Clean Agileを読みました|食べログ フロントエンドエンジニアブログ
        • DX白書2021を読むべし。|市谷 聡啓 (papanda)

          実に350ページを越える大部となっている。相当な厚みだが、くじけずに目を通せば何かしらの示唆が得られる内容になっているので、一読をおすすめしたい。というか、DXに関わる者にとっては必読もいいところ。これを無償で配布するのだから、IPA恐るべし。 まず目次に目を通そう。4部構成になっている。 第1部 総論 第2部 DX戦略の策定と推進 第3部 デジタル時代の人材 第4部 DXを支える手法と技術 総論の第1部と、具体としての第2部をあわせると100ページほどで、ここは必ず読んでおきたいところ。第3部は人材育成、第4部はDXのコアとなる技術に関する記述なので、関係が深い人はやはり読んでおきたい。 この白書の白眉なところは、徹底した「日米比較」を行っているところである。数多くの観点について、徹頭徹尾日本と米国での比較を示している。これが非常に分かりやすく、いかに日本のDXが水をあけられているか、こ

            DX白書2021を読むべし。|市谷 聡啓 (papanda)
          • 『データマネジメントが30分でわかる本』を出版しました - 下町柚子黄昏記 by @yuzutas0

            『データマネジメントが30分でわかる本』をKindleで販売開始しました!データ活用に関わる方々はぜひお買い求めいただければと思います!https://t.co/aRRYIsJeqR— ゆずたそ (@yuzutas0) March 13, 2020 (自称)企画屋・コンセプトデザイナーの @yuzutas0 です。 共著者・寄稿者を初めとして、スポンサーやレビュアーの皆様、各所で書籍を紹介してくださった皆様、 その他何らかの形でご協力いただいた皆様、本当にありがとうございました。 発売から間が空きましたが、スポンサー報告が完了したので、このブログに制作秘話をまとめます。 自費出版に関心がある人のヒントになれば幸いです。 もくじ もくじ 1. 書籍について 1-1. 書籍概要 1-2. 購入方法 1-3. 本書への反響 1-4. 関係者の皆様 2. 裏話 2-1. きっかけ 2-2. 企画

              『データマネジメントが30分でわかる本』を出版しました - 下町柚子黄昏記 by @yuzutas0
            • アジャイルとリーン・スタートアップを組み合わせた開発プロセス ~第1回 概要~ - selmertsxの素振り日記

              2019年8月にAzitに入社して4ヶ月。 私はSREとしての役割を期待されてAzitに入社したけれども、気がつけばバックエンドエンジニア兼スクラムマスターをやっていました。 バックエンドエンジニアとしては、AWSインフラ環境の完全な作り直しとTerraformによるコード化、Railsの負債解消、監視設定のコード化などを行っていました。 スクラムマスターとしては、初期の3ヶ月はアジャイル開発(スクラム、XPを組み合わせたもの)、そして12月からの1ヶ月はリーン・スタートアップ開発の導入等を行いました。 ここでは、スクラムマスターとして考えた開発プロセスについて資料にまとめます。 なおこの文章は、0-1 の開発フェーズではなく、すでにリリースされたサービスに途中で加わったスクラムマスターの目線で書かれており、対象とする読者も私と同じような境遇にあるスクラムマスターとなっています。 この開発

                アジャイルとリーン・スタートアップを組み合わせた開発プロセス ~第1回 概要~ - selmertsxの素振り日記
              • 事業をスケールさせるエンジニアリング〜技術のコモディティ化にエンジニアは敗北する〜 - DMM inside

                |DMM inside

                  事業をスケールさせるエンジニアリング〜技術のコモディティ化にエンジニアは敗北する〜 - DMM inside
                • 【アジャイル】書籍「Clean Agile」より「小規模開発のアジャイルプラクティス」

                  プロジェクトを機能・ストーリー・タスクに分割する方法と、それぞれの見積もり、優先順位付け、スケジューリングのガイダンスを提供します。 見積もりは細かく細分化するほど精度を上げることができるのは明らかです。しかしその代償として時間がかかります。不正確にすべきではありませんが、見積もりのコストは抑えたいと考えます。 有効な技法として「三点見積り」があります。この見積りは、「最良ケース」「最有力ケース」「最悪ケース」の3つの数値で構成されます。これらの数値は信頼性のより見積もられます。これはPERT法として調べると詳しい情報が得られるでしょう。 しかしながら三点見積りは長期のプロジェクトには有力ですが、プロジェクト内部のマネジメントで使うには精度が悪すぎるため、「ストーリーポイント」を用いるとよいということです。 ユーザー視点での機能であるユーザーストーリーに対し、具体的な時間の工数ではなく、相

                    【アジャイル】書籍「Clean Agile」より「小規模開発のアジャイルプラクティス」
                  • ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話(後編)

                    ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話(後編) アジャイル開発の代表的な方法論であるスクラムをテーマに、都内で1月に開催されたイベント「Regional Scrum Gathering Tokyo 2024」で、経験豊富なアジャイル開発のエキスパートとしてウクライナを拠点にアジャイルコンサルタントをしていたドミトロ・ヤーマク(Dmytro Yarmak)氏が、ロシア軍の侵攻後にウクライナ軍に入隊し、中隊長としてリーダーシップを発揮するためにさまざまなメソッドを駆使して軍隊の組織を変革していった経験を語ったセッション「A True Story of Agile Coaching in Ukrainian Armed Forces」が行われました。 軍隊という、企業とは異なる構造や目的を備えた組織で、しかも多くの民間人が入

                      ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話(後編)
                    • なぜSpotifyはOKRをやめた?アジャイル組織に最適な目標管理「Spotify Rhythm」とは|加藤 章太朗

                      なぜSpotifyはOKRをやめた?アジャイル組織に最適な目標管理「Spotify Rhythm」とは こんにちは、加藤章太朗(@katoshow)です。 前回のnoteでは、自律分散型の組織の1形態である「アジャイル組織」について説明しました。 今回は、アジャイル組織の代表Spotifyが採用する目標管理のフレームワーク(戦略フレームワーク)についてお伝えします。 Spotifyでは、2014年まではOKRを採用していました。Googleなどで大きな成果を上げたOKRは、日本でも昨今導入が進んでいます。しかし、SpotifyはOKRをやめ、Spotify Rhythm(スポティファイリズム)という独自の目標管理フレームワーク(戦略フレームワーク)に移行しました。 SpotifyがなぜOKRをやめたのか?そしてSpotify Rhythmとはどのようなものか?について説明していきます。 ※

                        なぜSpotifyはOKRをやめた?アジャイル組織に最適な目標管理「Spotify Rhythm」とは|加藤 章太朗
                      • スクラムは「気付いてもらう」とうまくいく、と気付いた話 - Commune Engineer Blog

                        こんにちは、コミューン株式会社でスクラムマスターを担っているヤマシタ(@yama_sitter)です。 前回「スプリントの属人性を減らしたらベロシティが安定した話」という記事を書きました。 この記事で紹介した取り組みに至るまでの過程に興味がある、という声を頂いたので、その過程、及び過程を振り返って得られた気付きを紹介させて頂きます。 ちなみに少し長いです。 ご了承下さい。 まずは結論から 取り組みの出会いから定着に至るまで 「WIP制限の導入」に至るまで 出会い 導入 定着 「タスクサイズの制限の導入」に至るまで 出会い 導入 定着 「死亡前死因分析(プレモーテム)の導入」に至るまで 出会い 提案 定着 改めて振り返ってみて まとめ 取り組みに出会えたのも上手くハマったのも正直偶然 「気付いてもらう」ことが大事。最後に決めるのはメンバー 「とりあえずやってみよう」くらいの気持ちで改善に取り

                          スクラムは「気付いてもらう」とうまくいく、と気付いた話 - Commune Engineer Blog
                        • アジャイルもDevOpsも費用対効果より機会損失で考える DASAアンバサダーが贈るこれからの開発現場へのアドバイス

                          「みんなのPython勉強会」では、Pythonを中心としてプログラミングを様々なシーンに生かす方法を一緒に学んでいます。今回は初級、中級のサーバーサイドエンジニア向けに、開発現場のアドバイザーでもある長沢氏がアジャイルとDevOpsについて話しました。後半はアジャイルとDevOpsをどう取り入れればいいかについてです。 従来の開発計画とアジャイルの計画の違い やっと本題のうちの1つ、アジャイルの話に入ります。アジャイル開発自体の成り立ちの話は今日はしません。今日話しておきたいのは従来型、わかりやすく言うとウォーターフォールに近いものの開発のやり方とアジャイルのやり方はだいぶ考え方が違うというところをお伝えしたいです。 従来の開発の計画の仕方というのは基本的にはすべてのスコープをはっきりさせます。ウォーターフォールは要件定義を最初にやりますよね。要件定義で全部決め、すべての要件が固まって見

                            アジャイルもDevOpsも費用対効果より機会損失で考える DASAアンバサダーが贈るこれからの開発現場へのアドバイス
                          • アジャイルプラクティスマップを公開しました | Agile Studio

                            Agile Studio プロデューサーの木下です。アジャイル開発をはじめるには、基本的な語彙やプラクティスをチームにいる全員が知ることが大切です。また、アジャイル開発を実践していく上ではスクラムのみ...

                              アジャイルプラクティスマップを公開しました | Agile Studio
                            • 無計画に見える計画・チーム感の欠如・とりあえずがんばる文化  “ふりかえりエバンジェリスト”が異動先で直面した組織の課題

                              「スクラムフェス仙台」は初心者からエキスパートまでさまざまな参加者が集い、学び、楽しむことができるアジャイルコミュニティの祭典です。ここで登壇したのは、森一樹氏。ふりかえりを日常とするチームができるまでを「プロダクトオーナー」という観点でふりかえり、それを再現するために必要だった要素について話しました。全4回。1回目は、異動から見えた、内情と課題について。 ふりかえりのエバンジェリスト・森一樹氏 森一樹氏:よろしくお願いします。みなさんこんにちは。 (会場拍手) 現地の方もオンラインの方も、よろしくお願いします。オンラインの方はすみません、私はだいぶ久々に現地登壇をするので、Discordのコメントを拾う余裕がなさそうです。とはいえ、コメントをもらえるとあとから見返した時にすごくうれしいので、ぜひよろしくお願いします。 今日は「プロダクトオーナーのための、ふりかえりが日常に溶けるチームの作

                                無計画に見える計画・チーム感の欠如・とりあえずがんばる文化  “ふりかえりエバンジェリスト”が異動先で直面した組織の課題
                              • QA≒テストからQA⊃テストに進化するためのQA入門 (JaSST ‘23 Tokyo 版)

                                Building Better People: How to give real-time feedback that sticks.

                                  QA≒テストからQA⊃テストに進化するためのQA入門 (JaSST ‘23 Tokyo 版)
                                • うおおおおおおおおおおおおお - ESM アジャイル事業部 開発者ブログ

                                  うおおおおおおおおおおおおおおおおおおおおおおおおおお。 子育て奮闘中の @wat-aro です。 この記事は ESM Advent Calendar 2022 - Adventar 19日目の記事です。 ある日 Slack のチャンネル一覧を眺めていると #うおおおおおおおおおおおおお というチャンネルがありました。 みんなで うおおおおおおおおおおおおお しています。 うおおおおしている様子 このチャンネル見つけてから毎日 うおおおおおおおおおおおおお しているわけですが、もっと うおおおおおおおおおおおおお したいわけです。 そんなわけで うおおおおおおおおおおおおお するプログラミング言語をつくりましょう。 繰り返し同じ言葉を使えるような言語であればたくさん うおおおおおおおおおおおおお できます。 そうですね。 Brainf**k*1 ですね。 Brainf**k での Hell

                                    うおおおおおおおおおおおおお - ESM アジャイル事業部 開発者ブログ
                                  • MVP(必要最小限のプロダクト) | UX TIMES

                                    ユーザーの欲しいものを時間をかけて作っても、使ってみるといらないと言われることがある。ユーザーは使ってみるまでプロダクトの価値が分からない。ユーザーへプロダクトの価値を確かめるための必要最小限のプロダクトをMVPという。 経営コンサルティング会社SyncDevのCEOであるFrank Robinson(フランク・ロビンソン)氏が、2001年にMVPを提唱した。2005年に、起業家であり学者のSteve Blank(スティーブ・ブランク)氏が、そのコンセプトを説明し、2010年に書籍「Lean Startup(リーンスタートアップ)」でEric Ries(エリック・リース)氏によって紹介された。 ユーザーの言う通りに作ってもダメな理由 ユーザーは、欲しい機能を実際にどう操作するか想像していないのに、あれば良さそうな機能も欲しいと言うことがある。 タスク管理アプリであれば、タスクの登録以外にも

                                      MVP(必要最小限のプロダクト) | UX TIMES
                                    • 『ユースケース実践ガイド』をもとにした品質向上への取り組み 全体像を見るテスターの視点はチームへの大きな貢献になる

                                      ソフトウェア開発、ITインフラ運用、そしてその境界線上にあるトピックをカバーし、特にDevOpsを実現するための自動化、テスト、セキュリティ、組織文化にフォーカスした「DevOpsDays」。ここでウイングアーク1st株式会社の伊藤氏が登壇。つづいて、ビックピクチャーを理解する重要性と、品質向上のために取り組んだ流れを紹介します。前回の記事はこちらから。 ビッグピクチャーとユースケース 伊藤潤平氏(以下、伊藤):ビッグピクチャーとユースケースです。ジャネット先生と話していると、「ビッグピクチャーを理解しましょう」という話がよくあります。ビッグピクチャーは全体像という意味で、Agile Testing Daysのキーノートでもジグソーパズルの例を出して説明していました。 ジグソーパズルの1ピース1ピースがユーザーストーリーで、これを組み立てると全体像になる、というキーノートでした。あとRSG

                                        『ユースケース実践ガイド』をもとにした品質向上への取り組み 全体像を見るテスターの視点はチームへの大きな貢献になる
                                      • アジャイルで生活習慣をカイゼンする - 虎の穴開発室ブログ

                                        アジャイルで生活習慣をカイゼンするOGP こんにちは、虎の穴ラボの磯江です。 この記事は「虎の穴ラボ 夏のアドベントカレンダー」の10日目の記事です。 9日目はH.Yさんによる「PlanetScaleでシャーディングに触れてみよう」でした。 toranoana-lab.hatenablog.com 10日目は大場さんによる「babylon.jsで夏のビーチを再現したい」が投稿されます。 はじめに 今回は、夏のアドベントカレンダー「仕事には役立たないかもしれない技術」編のラストではプログラミングからは離れて、書籍『「アジャイル式」健康カイゼンガイド』から学ぶ 生活習慣をカイゼンするための技術について、筆を取らせていただきます。 同書籍については、磯江もパーソナリティをしているPodcast「Toralab.fm」でも話しています youtu.be 書籍情報 今回は、翔泳社さんから2022年5

                                          アジャイルで生活習慣をカイゼンする - 虎の穴開発室ブログ
                                        • 「なんとなくスクラム」を見直して改善に取り組んだらチームの意識が変わった - ANDPAD Tech Blog

                                          はじめに はじめまして、アンドパッドSWEの小川です。 アンドパッドの開発組織では、アジャイル開発の手法を取り入れたチームづくりや開発プロセス改善に関する取り組みが盛んに行われています。 今回は、私が所属する施工案件管理チームで最近行った取り組みについて紹介したいと思います。 背景 これまでも、チームの開発プロセスにはアジャイル開発のフレームワークであるスクラムの手法を取り入れていました。たとえば、開発タスクはカンバン上で管理し、会議体としては毎日の朝会、週ごとのスプリントプランニングとレトロスペクティブを行っていました。 しかしながら、実際にはスクラムガイド記載の内容に従っておらず、「なんとなくスクラム」をやっているだけという面がありました。 たとえば、スクラムガイドが定義するスプリントプランニングはスプリントに実施するタスクを決定するための会ですが、我々の実施していた会では仕様や機能に

                                            「なんとなくスクラム」を見直して改善に取り組んだらチームの意識が変わった - ANDPAD Tech Blog
                                          • 意思決定と業務執行をシームレスにした話(概要編) - LayerX エンジニアブログ

                                            ご挨拶 毎々お世話になっております、LayerXから三井物産デジタル・アセットマネジメント(以下、MDM)に出向中の片桐(@akinama3)と申します。 普段は象のアイコンで活動しつつ、ねぎしを世の中に広める仕事をしています。 MDMの概要については、昨日@peroyuki_ がご紹介しているので、ぜひご覧ください。 tech.layerx.co.jp さて、世の中には「銀の弾丸」と思しきデジタル化のバズワードが溢れかえっておりますが、 実際には「業務とはなにか」をひたすら考えぬき、徹底的にSaaSを活用したり泥臭く自分でシステムを作ったりして改善するしか幸せになる道はありません。 というわけで、MDMで徹底的に拘って取り組んだ社内業務効率化の事例として、「意思決定機関である稟議」と「稟議に基づく業務の自動執行」について、ご紹介したいと思います。 実はこのときの実装経験がMDMで進めてい

                                              意思決定と業務執行をシームレスにした話(概要編) - LayerX エンジニアブログ
                                            • リモートワーク時のアジャイルソフトウェア開発チームに役立つ6つのベストプラクティス

                                              ガートナーの米国本社発のオフィシャルサイト「Smarter with Gartner」と、ガートナー アナリストらのブログサイト「Gartner Blog Network」から、@IT編集部が独自の視点で“読むべき記事”をピックアップして翻訳。グローバルのITトレンドを先取りし「今、何が起きているのか、起きようとしているのか」を展望する。 2020年、リモートワークへの移行が一気に進み、ソフトウェアエンジニアリングやアプリケーションのリーダーからは「開発スピードが低下するのではないか」と懸念する声が上がった。 もともと、アジャイル開発チームは自律性や変化への適応性が高い。だが、アプリケーション技術者の集団として力を発揮し続けるには、緊密なコラボレーションやフィードバックループ、ダイナミックな交流といった強力なチーム文化を維持しなければならない。 Gartnerのアナリストでシニアディレクタ

                                                リモートワーク時のアジャイルソフトウェア開発チームに役立つ6つのベストプラクティス
                                              • めちゃめちゃ使いこなす観察、理解、知識、解像度! そしてコンテキスト!!/observation-understand-knowledge-resolution-context

                                                https://confengine.com/conferences/scrum-fest-mikawa-2021/proposal/15981 私たちは観察、理解、知識を用いて仕事をこなしています。 これらは「心の働き」といえるものです。 仕事の成果の質を左右する重要な活動で、 子供の…

                                                  めちゃめちゃ使いこなす観察、理解、知識、解像度! そしてコンテキスト!!/observation-understand-knowledge-resolution-context
                                                • 【資料公開】プロダクトマネジメントの”罠”を回避しよう

                                                  みなさんこんにちは。@ryuzeeです。 3月23日に新刊『スクラム実践者が知るべき97のこと』が発売になりました。 スクラムを作ったケン・シュエイバー氏、日本で認定スクラムマスター研修を何度も開催しているジェームズ・コプリエン氏を始めとした海外のスクラム界隈の著名人68人による97本のコラム集です。 日本語版の発売に際して、及部敬雄さん、小林恭平(kyon_mm)さん、高橋一貴さん、長沢智治さん、平鍋健児さん、安井力(やっとむ)さん、和田卓人さん、訳者3人のコラムもあわせて収録しています。 チームのみんなで議論したり、ふりかえりのネタにしたり、自分たちの環境でヒントになることを探したりと、さまざまな使い方ができると思いますので、ぜひお手にとってご覧ください。 なお、僕が所属する株式会社アトラクタでは、発売を記念して抽選で20名の方にプレゼントする企画を行っていますので、興味のある方はお申

                                                    【資料公開】プロダクトマネジメントの”罠”を回避しよう
                                                  • 大学のアジャイル教育に奮闘した10年からの学び─短期の集中授業でアジャイルをどう実践するか? - Agile Journey

                                                    ソフトウェア開発において、アジャイルという考え方はかなり浸透しています。多く出版物やWebコンテンツ、さまざまなコミュニティやセミナーが存在し、アジャイルの情報には触れやすい状況になってきました。一方で企業においてアジャイルを導入しようとする際に開発チームのどこを変えるべきか、組織固有のルールとどう折り合いを付けるかなどに頭を悩ませる方も多いでしょう。 『SCRUM BOOT CAMP THE BOOK』などの著作で知られ、アジャイルコーチとして企業の組織づくりを支援する永瀬美穂(@miholovesq)さんは、これまで複数の大学で授業におけるアジャイル導入も支援し、その成果を発表する「Agile PBL祭り」を主催してきました。永瀬さんによると、学生は前提知識もないところからソフトウェア開発を学ぶため、社会人エンジニアより自然とアジャイルに取り組める面もあるそうです。 大学はなぜ教育にア

                                                      大学のアジャイル教育に奮闘した10年からの学び─短期の集中授業でアジャイルをどう実践するか? - Agile Journey
                                                    • スタートアップにおける組織設計とスクラムの長期戦略 / Scrum Fest Kanazawa 2024

                                                      ログラスの選考プロセスにおけるアトラクト戦略 / Attraction strategy in Loglass interview process

                                                        スタートアップにおける組織設計とスクラムの長期戦略 / Scrum Fest Kanazawa 2024
                                                      • アジャイルテストの世界 - Agile Testing Condensed と実例マッピング - kawaguti’s diary

                                                        リサとジャネットの Agile Testing Condensed という短い書籍があるんですけど、これの翻訳をお手伝いしました。権利周りの調整のお手伝いと、翻訳レビューです。 leanpub.com アジャイルテスティングという、日本ではそんなに盛り上がっていない分野がありまして。アジャイル時代にどのように品質を担保するのか、QAやテスターはどのように関わっていくのか、非常に大事なんですけど、なぜか日本ではTDD(テスト駆動開発)やテスト自動化についての注目に比べても、今ひとつ盛り上がっていない感じがします。惜しいことです。 Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all me

                                                          アジャイルテストの世界 - Agile Testing Condensed と実例マッピング - kawaguti’s diary
                                                        • 「Not for me」からの卒業――開発畑のプロダクトマネージャーの失敗から学べ

                                                          はじめに こんにちは、ゆずたそ(@yuzutas0)です。この連載では、ソフトウェア開発者からプロダクトマネージャーに転向した筆者が、多くの失敗を経て重要性を痛感した「プロダクトマネージャーのマインドセット」を解説します。 主な対象読者としては、同じようにソフトウェア開発を出自とした方で、「同じような失敗経験のある方」「これから失敗を経験するであろう方」を想定しています。連載の前提条件の詳細、免責事項などについては、第1回の冒頭を併せて参照ください。 「Not for me」からの卒業 前回は「品質から逃げてしまう」という問題を取り上げました。焦りに負けると、品質を担保しないまま、顧客にデバッグさせることになります。対処法として、企画とテストに投資せよと話しました。 今回は「責任から逃げてしまう」という問題を取り上げます。プロダクト開発はソースコードを書くだけではありません。法律や集客など

                                                            「Not for me」からの卒業――開発畑のプロダクトマネージャーの失敗から学べ
                                                          • SmartHRにおけるクロスファンクショナル実践例 - SmartHR Tech Blog

                                                            こんにちは! SmartHRで開発したり、アジャイル推進したり、筋トレしたりしてるkouryouです。 SmartHRでは顧客の価値の最大化を目指し、日々開発プロセスの改善を行っています。 特に私の所属する基本機能のDチーム*1では、以前からクロスファンクショナルを強く推進しています。 本日はクロスファンクショナルとは何なのか?やってみてどんなメリットがあったのかをまとめました。 クロスファンクショナルとは スクラムガイドでは機能横断型と翻訳されています。 機能横断型というのは、エンジニアリング、デザイン、QAなど複数の職能(スキル)を持つことを表しています。 そして機能横断型という言葉は、チームに対して使われることが多いですが、個人に対しても使われます。(例: プロダクトエンジニアがデザインもできる、QAエンジニアがコードも書けるなど) SmartHRにおいてチームが機能横断型であること

                                                              SmartHRにおけるクロスファンクショナル実践例 - SmartHR Tech Blog
                                                            • 開発チーム運営では問題発見・改善だけでなく、良かったことの共有も大事にする - $shibayu36->blog;

                                                              開発チームをスクラムなどを使って運営している時、改善がどんどん行われることは良いことである。しかし、その時によく起こりがちなのが、問題発見と改善にフォーカスしすぎた結果、チームの悪いところばかり見すぎてしまうことだ。過剰に悪いところばかり見てしまうと、徐々にチームが疲弊してしまうといったことが起こる。改善が捗ることは良いことだが、それでチームが疲弊してしまわないように注意しなければならない。 ちなみにスクラムガイドを参照してみると、スプリントレトロスペクティブの目的には「うまくいった項目や今後の改善が必要な項目を特定・整理する」と書かれている。つまり、デイリースクラムやふりかえり会などでは、問題発見と解決だけでなく、良かったことを言語化し再生産可能にすることも重視されているのである。 以上から、開発チーム運営では問題発見・改善だけでなく、良かったことの言語化・共有を大事にし、その2つをうま

                                                                開発チーム運営では問題発見・改善だけでなく、良かったことの共有も大事にする - $shibayu36->blog;
                                                              • なぜ、スクラムが上手くいかない・しっくりこないと感じるのか考えてみよう | IIJ Engineers Blog

                                                                なぜ、スクラムが上手くいかない・しっくりこないと感じるのか考えてみよう 2023年06月20日 火曜日 どうも名古屋支社の北河です。 今回はスクラムの “ちょっと” した感じ方について取り上げていきたいと思います。 スクラムを実践している方はスクラムガイドを一度は読んだことがあるかと思います。読んでみると、軽量級やシンプルといったキーワードが目に入ってきます。 そしていざスクラムを実践し始めるとこんな声を聴きます。 「う~ん、難しい。上手くいかない」「なんかしっくりこない」「これで良いのかな?」と。 ということで、なぜ上手くいかないと感じるのか、しっくりこないと感じるのか、を自分の解釈を交えて考えてみたいと思います。 スクラムとは アジャイルの価値や原則を満たすプラクティスを組み合わせたフレームワークの一つです。 アジャイルとスクラムを混同していたり、違いって何?というケースを見かけますが

                                                                  なぜ、スクラムが上手くいかない・しっくりこないと感じるのか考えてみよう | IIJ Engineers Blog
                                                                • スクラムチームを3年リードして得た学びと目線 - yigarashiのブログ

                                                                  この記事ははてなエンジニア Advent Calendar 20227日目の記事です。 昨日は id:utgwkk さんでした。 さて、今日はスクラムの話です。スクラムの導入とリードは自分のキャリアにおける重要な仕事のひとつで、気づけば3年ほどスクラムと取っ組み合ってきました。ここ1年くらいで、ようやく安定してテンポ良く開発が回るようになって、大仕事に一区切りついたような気持ちでいます。そうして少し肩の力が抜けた結果、最近はスクラムというフレームワークから一歩引いた位置に自分の目線が移動しつつある気がしています。自分の考えのスナップショットを取るには絶好のタイミングと思われるので、スクラムについての学びや、自分のスクラムに対する目線をまとめてみようと思います。 スクラム導入のキモ まずは、自分が経験したり見聞きした様子から、スクラム導入のキモだと思う点を2つほど書いてみます。どちらも越えが

                                                                    スクラムチームを3年リードして得た学びと目線 - yigarashiのブログ
                                                                  • スクラムのふりかえりに超便利なアプリ「anycommu」を使ってみた - Qiita

                                                                    スプリント レトロスペクティブにおいて、チームで「anycommu」という振り返りアプリを使っているので、その有用性を共有したいと思います。 前提として、私は現在(2023/7/8)、2つのチームに所属しています。1つは、エンジニアとして開発チームに所属しており、2つには、POとして新入社員向けのアジャイル開発研修のとあるチームに所属しております。 どちらのチームでも週に1度、1時間程度の時間をとってスプリントを振り返る機会があります。 目次 振り返りってなんのためにするの? 振り返りアプリanycommuと振り返り手法KPT/FunDoneLearnについて anycommuは、振り返りにどのような影響をもたらしたか(実体験) おわりに ※anycommuを使ってみた体験談のみに興味がある方は、2章に記載しているURLおよび、3章をお読み頂ければと思います! 1.振り返りってなんのために

                                                                      スクラムのふりかえりに超便利なアプリ「anycommu」を使ってみた - Qiita
                                                                    • 「国民性にはアジャイル要素があるのに、ビジネス文化になると合わない日本」 多くの人に忘れられがちなトヨタ生産方式のポイント

                                                                      登壇者の自己紹介 司会者:ここからは、クロージングに入ります。クロージングは、Scrum Inc.、アヴィ・シュナイアーさま、JJ・サザーランドさま、Scrum Inc. Japan、クロエ・オニールさまによるご講演とディスカッションです。それでは、モデレーターのクロエさま、お願いいたします。みなさま、拍手でお迎えください。 (会場拍手) アヴィ・シュナイアー氏(以下、シュナイアー):おはようございます。Agile日本! クロエ・オニール氏(以下、オニール):今日、アヴィが英語で登壇してくれるので、私が日本語に訳します。よろしくお願いします。 (会場拍手) 始める前に、Agile Japanのみなさんに感謝したいと思います。ここに呼んでくれてどうもありがとうございます。 コロナが明けてからみなさんが集まるのは初めてだと思います。以前、私も日本でトレーニングをしていたので、今回は見覚えのある

                                                                        「国民性にはアジャイル要素があるのに、ビジネス文化になると合わない日本」 多くの人に忘れられがちなトヨタ生産方式のポイント
                                                                      • 生産性が上がり続けるチームを作るための第一歩

                                                                        Blynk と Raspberry Pi Pico W で IoT 〜 MQTT・HTTPリクエストの組み合わせも 〜 / IoTLT vol.114

                                                                          生産性が上がり続けるチームを作るための第一歩
                                                                        • プロダクト開発チームで大切にしたい「学び」のサイクル - asken テックブログ

                                                                          こんにちは。VPoEの 安西 です。 4月になりましたね。askenの年度は4月から始まりますので、4月1日にキックオフが行われました。私も含めて、全部門の方針を全社で発表したのですが、せっかくなので、この場で公開してみようと思います。 現状のエンジニア組織の状況 2022年度方針 不確実性が高いプロダクト開発に対峙し価値貢献する co-learning(ともに、学ぶ)に込められた私の想い 「co-learning(ともに、学ぶ)」に向かうための2つの行動 1. チームが学ぶ 2. チームで学ぶ ①設計 : 増田亨さん ②インフラ・アーキテクチャ : 野村友規さん ③アジャイル ④asken Engineer All Hands (エンジニア全体会議) 学ぶために必要な在り方 人事制度も変えました co-learning(ともに、学ぶ)をカルチャーに 気軽にお話してみませんか? 現状のエン

                                                                            プロダクト開発チームで大切にしたい「学び」のサイクル - asken テックブログ
                                                                          • 日本の漫画やアニメやゲームはガラパゴスなのか? - 狐の王国

                                                                            なにやら最近、日本のアニメやゲームや漫画をガラパゴスだとか言ったり、ガラパゴスでいいんだとか言ったりしてる人たちを散見する。結論から言おう。日本のアニメもゲームも漫画もまったくガラパゴスではない。 ガラパゴス化批判というのは主に日本の携帯電話に対して行われてきたものだ。 NEC docomo N-01G ブラック メディア: 俺がさんざん日本のケータイはガラパゴスだと言い続けてきたのは、日本におけるOSSの幻想――OSS界のガラパゴス諸島、ニッポンという2004年の記事が元である。 OSS振興の流れは出てきたが、こと日本はOSSに関して独自の進化(退化?)を遂げている部分があると同氏は指摘する。その原因としては、英語という大海で遮断された状況からくる甘えの精神構造、貧弱な開発力とコミュニケーション下手であることなどが挙げられるようだ。 (中略) 問題なのは、本流とかい離し、日本独自の動きを

                                                                              日本の漫画やアニメやゲームはガラパゴスなのか? - 狐の王国
                                                                            • 結合テストの自動化にQAはどうかかわっていったか - Cybozu Inside Out | サイボウズエンジニアのブログ

                                                                              こんにちは、サイボウズの永田です。 私は、サイボウズの開発本部、アジャイル・クオリティで、アジャイルの品質を探求する活動をしています。 この記事では、2023年3月9日、JaSST Tokyo 2023のテクノロジーセッションで発表させていただいた内容を、より解説を入れながら紹介します。 結合テストの自動化にQAはどうかかわっていったか 今回取り上げる事例では、kintoneのフロントエンド刷新プロジェクト(フロリア)で結合テストの自動化を決定した際に、QAメンバーがどのように関与し、困難に直面しながらも、信頼性の高いテストコードを作成するに至るまでの過程をご紹介します。 フロリアについては次のブログをご覧ください。 blog.cybozu.io テストのポリシー ~このミッションにおけるQAのチャレンジ~ フロリア内で新しく3つのチームが立ち上がった際、各チームのテスト戦略の中心を、自動

                                                                                結合テストの自動化にQAはどうかかわっていったか - Cybozu Inside Out | サイボウズエンジニアのブログ
                                                                              • 「笑顔の合意」のテクニック - 噛み合わない会話と対立を克服するための、エモさを排した実践的なスキルと技法 -

                                                                                2023年1月12日(木)のRegional Scrum Gathering Tokyo 2023の登壇資料になります。 このセッションでは、他者との噛み合わない会話と対立を…

                                                                                  「笑顔の合意」のテクニック - 噛み合わない会話と対立を克服するための、エモさを排した実践的なスキルと技法 -
                                                                                • アジャイル開発向けソフトウェア開発委託契約書(準委任型) 情報処理学会