アジャイル、とりわけスクラム開発をやるときに立ち向かわなければならない壁の話 - freee Developers Hub
この記事は freee Developers Advent Calendar 2022 の3日目です。 このドキュメントはなにかの答えをあたえるというより、アジャイルやスクラムを有効化させる上での障害はこれであるということを検討するためのドキュメントです。壁はすべての環境で発生するわけではないですが、そういう壁があるということを認識することで、転ばぬ先の杖となるような文章になることを目指しています。そして、その解決方法は示さず「意図的に不完全」にしています。これを読んで「なぜ意図的に不完全にしているのか」を味わっていただければと思います。（あるいは、私自身のエクスキューズかは読んでる皆様にその判断を委ねます） 前提: アジャイル開発とは アジャイルソフトウェア開発（以後、アジャイル開発）はアジャイルソフトウェア開発宣言で示されている価値の実現を目的とした開発手法です。宣言では4つの項目でそ
この記事は datatech-jp Advent Calendar 2023 3日目の記事です。 背景・趣旨 筆者（@yuzutas0）は風音屋（@Kazaneya_PR）という会社を経営しており、データ職種の採用・育成に関心を持っています。 複数企業で少ない専門家を奪い合って疲弊するような採用活動ではなく、マーケット全体がより豊かになるような動き方はできないだろうかと模索しています。 1つの実験として、MENTAで「第2新卒が3ヶ月でデータ職種への転職を目指す講座」というトレーニングを提供し、ありがたいことに30名以上の方々に受講いただきました。 ちなみにこの講座は今では風音屋の社内研修になっています。 MENTAの受講者が30名を突破しました🎉 卒業生が風音屋に入社したり、スキルアップして「社内で提案が通るようになった」「現職で活躍できるようになった」という感想もいただいています。
Pull Requestを小さくする戦略 - 開発チームのパフォーマンス向上のための第一歩 - Agile Journey
Agile Journeyをご覧の皆さん、こんにちは。ZOZOの御立田です。 私が所属する株式会社ZOZOは、「世界中をカッコよく、世界中に笑顔を。」を企業理念として掲げ、ファッションEC「ZOZOTOWN」、ファッションコーディネートアプリ「WEAR」などの各種サービスの企画・開発・運営や、「ZOZOSUIT」「ZOZOMAT」「ZOZOGLASS」などの計測テクノロジーの開発・活用をおこなっています。また、カスタマーサポート、物流拠点「ZOZOBASE」を運営しています。 ファッションコーディネートアプリ「WEAR」やショップスタッフの販売サポートツール「FAANS」を手がける、私が所属するブランドソリューション開発本部では、「開発生産性を3倍に」を目標に掲げ、多くの改善を進めています。 「開発生産性」をどのように定義するかには議論がありますが、まず私たちが向き合ったのは「仕事量の生産
制御不能な時代のプロジェクトマネジメント / Project Management in Agile Era
2020年10月11日（日）「【オンライン】JBUG広島#6 制御不能な時代に立ち向かえ」にて。
ryuzee技術顧問と1on1公開 〜 どうやって学び、どうやって活用しているのか？ - NTT Communications Engineers' Blog
こんにちは、イノベーションセンター Agile CoE PJリーダーの岩瀬（以下、iwashi）です。 NTT Comで技術顧問をされており、アジャイルコーチでもある吉羽さん（以下、ryuzee）に「普段からどうやって学んで、どうやって活用しているのか？」という問いを1on1で投げかけてみました。本記事では、1on1模様の一部を公開します。 情報収集やナレッジマネジメントのテクニックが載っていますので、興味ある方はぜひご覧ください。というわけで、早速いってみましょう！ RSSリーダーを使って購読 iwashi: ryuzeeさんは海外記事の翻訳など、かなり幅広く情報収集をされている印象があります。普段はどうやって情報をみつけているんですか？ ryuzee: RSSリーダーにたくさん登録しています。最近はRSSリーダーが下火で悲しいんですが、feedlyを使って色々なRSSを購読しています。
「アジャイルソフトウェア開発という概念」の源流は日本なのか 〜『日本企業はなぜ「強み」を捨てるのか 』を読んで〜 - bonotakeの日記
夜中におもむろに書評を書き出す第2段。 日本企業はなぜ「強み」を捨てるのか～増補改訂版『日本“式”経営の逆襲』～ (光文社新書) 作者:岩尾 俊兵光文社Amazon この本自体はとても面白いし首肯できる部分も多いが、1箇所だけイチャモンをつけたい。 そもそもアジャイルソフトウェア開発という概念自体、マニフェスト（注：アジャイルソフトウェア開発宣言のこと）の発表よりも3年早く、1998年に日本の研究者から提案されている。 南山大学の青山幹雄教授による一連の研究である。 （同書より引用） ここで紹介されている「1998年」の「提案」とは、おそらくICSE1998で青山先生が発表した論文 "Agile Software Process and Its Experience" のことだろうと思う。Agile Software Process（ASP）という、実際に富士通の社内で実践されたソフトウェ
コンウェイの法則とかで、マイクロサービス=組織 という話になることが多いなと感じる。 正解の場合もあるし、不正解の場合もあると思っていて、個人的には小さいチームでもマイクロサービスをやるメリットは技術的にも組織的にもあると思う。 そのメリットを無視してすぐ組織の話に持っていきたくないので、基本分離したくないマンとしての主張を書いておく 技術観点でのメリット いまさら語るまでもないけど、 ドメイン境界の分離 デプロイ独立性 リソースの最適配分 障害の局所化(サーキットブレーカー等) このうち、ドメイン境界の分離だけはモジュラモノリスで対応可能だが、あとの3つにはマイクロサービスが必須。(もっとあるかも) この3つが必要なのにモノリス or モジュラモノリス で進める判断をするということはシステムの表現力を落とすことに直結する。 もちろん、複雑度は増すし難易度も増す。熟練のサーバーサイドエンジ
受託開発におけるアジャイルに限界を感じた私が、「納品のない受託開発」を始めるまで - 倉貫義人の「はじめてのアジャイル」 - Agile Journey
Agile Journeyをご覧のみなさん、はじめまして。株式会社ソニックガーデンの代表をしている倉貫義人と申します。 私はもともと大手システム会社でプログラマとして働いていました。そのとき出会ったアジャイル開発に魅了され、これこそ自分にとって理想の姿であると確信し、それ以来アジャイル開発を広めるための様々な活動を社内外で行ってきました。 最終的に、本当に自分の理想とするソフトウェア開発と、それを実現する組織をつくるためには、自ら会社を経営する立場になるしかないと考え、起業することになりました。そうしてできたのが株式会社ソニックガーデンです。 ソニックガーデンでは「納品のない受託開発」というサービスを提供しています。従来的な受託開発から、そもそものビジネスモデルを見直したことで、今では「アジャイル開発」を意識せずとも、自然とそれに取り組める組織として機能しています。 思い返すと、私のアジャ
AWS Dev Day 2023 Tokyoの登壇資料です。
モブプログラミングで「一緒に働く」を戦略的に仕事に取り入れよう - Agile Journey
みなさん、こんにちは。「制御不能なアジャイルモンスター」こと及部敬雄（@TAKAKING22）です。私は現在、 Silver Bullet Club というソフトウェア開発チームに所属していますが、チームでは2017年5月にモブプログラミングを採り入れ、現在も継続しています。こうした経験のなかで得られたモブプログラミングに関する知見を、書籍、記事、コミュニティ活動などを通して発信してきました。また、アジャイルコーチとしてチームや組織へのモブプログラミングの導入支援もしています。 本稿では、モブプログラミングを実際の現場で活用する際に直面しがちな悩みポイントを抑えつつ、個人やチーム、そして組織がモブプログラミングとどう向き合っていけばよいのかについて、ご紹介します。 モブプログラミングとは モブプログラミングの流れ なぜモブプログラミングが必要なのか 分担作業とモブプログラミングの比較 2つ
実践ATDD 〜TDDから更に歩みを進めたソフトウェア開発へ〜 / ATDD by genba example
ソフトウェア開発において、不確実性にどのように立ち向かっていくかは大きな課題です。 PHPerとしては、開発中にいかにコード品質を上げるかといったことは大きな関心で、その一つの規律のとり方としてTDDを実践されてきた方は多いのではないでしょうか。 トークの表題であるATDDは、Acceptance Test Driven Developmentの略です。TDD Cycleよりももう一つ大きなスコープでのフィードバックループをテストによって駆動します。特にアジャイル開発の文脈で「Agile Testing」という一つのテーマ内で紹介されることが多い手法です。 ユニットテスト・コンポーネントテストをカバーするテストによって開発を駆動するTDDに対して、ATDDはよりビジネスフォーカスの強いテストによって開発を駆動します。ATDDの開発プロセスの実践によって、技術レイヤ横断的な製品全体の回帰テス
スクワッド体制における留意点として、「Spotifyは "Spotifyモデル "を使っていない [3]」で以下のように述べられているように、単に方法論を真似るのではく、自分の組織と向き合い、学習して、進化し続けることが大切であると思います。READYFORにおいても日々、組織体制について議論し、改善を進めています。 ビジネスユニット、部門、チーム、マネージャーは、Spotifyの失敗した方法論に固執してはいけません。彼らはSptifyのモノマネよりも効果的に組織構造の役割と責任を伝えることができるのです。 あなたがSpotify Modelを見つけたのは、自分のチームをどのように構成するかをいつも考えていたからでしょう。でもここで止まってはいけません。学習を続けてください。 1-2. READYFORのスクワッド体制 READYFORの場合、どのようなスクワッド体制を敷いているか？ ひと
ヤフーのユーザー5,400万人から"同意"を得るための技術（HTML/CSS/JavaScript）
こんにちは。SWATチームの今谷と、LY会員サービス統括本部の木所です。 LINEとヤフーの会社合併に伴って、LINEヤフー株式会社が提供するサービスを利用するユーザーに「新プライバシーポリシーへの同意」をいただくためのモジュールを開発しました。本記事では、ヤフーのユーザー5,400万人から”同意”を得るための工夫について、実装上の不具合も交えてご紹介します。 なお、ご紹介する内容は、UIT × Bonfire Front-end Meetup #1 での発表が起点となっています。詳細についてより深く知りたい方は、発表資料 や Podcast をあわせてご参照ください。 会社合併と、新プライバシーポリシーのご案内 LINEとヤフー、それぞれで同意モジュールがあります。Web向けのほか、iOS・Androidアプリ向けにも提供しました。 Webの同意モジュールでは「Modal版」と「Ful
コードを書き始める前からテストをずっと考える ─ 継続的テストモデルとシフトレフトなテスト活動をアジャイルにどう取り入れるか - Agile Journey
読者の皆さんは、テストについてどのようなイメージをお持ちでしょうか。「開発の後に行う確認作業」といったイメージを持たれている方もいるかと思います。 しかし、開発しようとしているソフトウェアに不具合の混入を防ぐには、もっと早い段階でテストについて考えることが必要です。こういったテスト活動は、プログラムを1文字も書いていないときから始めることができるのです。 本記事では、2016年に提唱された継続的テストモデルを紹介しつつ、アジャイルとも親和性のあるシフトレフトなテスト活動について解説していきます。 DevOpsにおけるテストの考え方 DevOpsのループ図とは何か？ 継続的テストモデルとは何か 継続的テストモデルにおいてテストは「活動」である シフトレフトなテスト活動とシフトライトなテスト活動 シフトレフトなテスト活動としてのテスト駆動開発 コード実装を始める前から行うテスト活動 シフトレフ
プロジェクトのスコープ調整を考える - 開発チームが信頼を獲得し変化に対応するためのアプローチ - Agile Journey
日々、懸命に開発にあたっていても、スコープ調整は否応なく発生します。Agile Journeyの読者の方も、「予定していた機能開発を削らないといけない」と判断せねばならない経験をお持ちかもしれません。こうした判断をネガティブなものではなく、「変化への対応」と捉えて前向きにプロジェクトを進めるためには、なによりも信頼が必要、と語るのは、10年以上、アジャイルコーチとしてさまざまなチームに関わってきた安井 力さんです。安井さんが信頼を積み重ね、「変化に対応できる」チームになるために必要なことを解説してくれました。 プロダクト開発の中で「あれがほしい」「いつまでにほしい」「もっと早くほしい」とリクエストされることは珍しくないでしょう。また一方で、開発側から「これは難しい」「それまでにはできない」「思ったよりも時間がかかる」と伝えないといけない状況も、これまた珍しくはありません。さまざまなツールや
会社でScrapboxを使っている。チームごとやプロジェクトごと、話題や趣味ごとにプロジェクトを作っていて、うちのチームは1年3ヶ月くらい使って3000ページほどに達している。 どんどん書いていたのだけど、最近、どこに何があるかわからなくなってきていた。同僚に、ここの仕様はどうでしたっけ、って何度も聞いてしまうことがあったので、これはまずいと思ってちょっと整理していた。 表記揺れを直す One Fact in One Placeということで、どんどんページをマージしていった。ページを同名にリネームするとマージボタンが出現して押すだけなので楽。 よくみるとスペースの有無によって同じ話題のページが2ページに分かれていたり、略称と正式名称と、「(正式名称)まとめ」の3つにわかれたりしていた。情報を探しているときにはどんどんマージしたりしないので、今回マージするぞと見返せてよかった。 サポート担当
スクラムガイドに載っていないスクラムのはじめかた - チームでスクラムをはじめるときに知っておきたい5個のコツ - / How to start Scrum that is not written in the Scrum Guide
Scrum Fest Fukuoka 2024にて。 https://confengine.com/conferences/scrum-fest-fukuoka-2024/proposal/19555/5 プロフィールやお問い合わせはこちらからどうぞ！ https://agile-monste…
チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」 - BASEプロダクトチームブログ
こんにちは。BASE BANK株式会社 Dev Division にて、 Software Developer をしている東口（@hgsgtk）です。私のいる開発チームでは、アジャイル開発の考え方・取り組みを取り入れています。アジャイル開発の導入については、「小さなチームが始めたアジャイル開発」という資料を公開しています。 今回は、アジャイル開発において、重要な振り返りについて、Mad Glad Sad(喜、怒、哀) というレトロスペクティブ（振り返り）のワークを紹介したいと思います。 TL;DR Mad Glad Sad(喜、怒、哀)は、感情データを集めるためのワーク イテレーションで起きた、喜んだり、怒ったり、哀しかったりした時間やイベント、を書き出していくイベント 素直な感情ベースでイベントを振り返ることで、 "理性のフィルター"で見つからない潜在的課題をチームが見つける きっかけに
Zero Touch Productionとは何か
GoogleのSREとSecurityによるBuilding Secure Reliable Systems という本の中で「Zero Touch Production (ZTP) 」という考え方が紹介されていた．これはインフラの権限管理やインフラの構築そのものの指針となる概念であり，自分がそうあるべきだとずっと思ってきた考え方でもある．これはどのような考え方なのか?をこれまでの歴史を踏まえて具体的なツールや事例とともにまとめておく． Zero Touch Production Building Secure Reliable Systems においてZero Touch Production (ZTP) は以下のように定義されている． The SRE organization at Google is working to build upon the concept of least
Agile Testingを夢見たテスト自動化 〜ATDDへの挑戦から始まる 1年間の試行錯誤〜 / dreaming agile testing at basebank
「CIのためのテスト自動化」というテーマで第17回QUESに招待いただいた際の資料です。 - Agileチームにおけるテスト自動化の試行錯誤から得られたしくじり - Agile Testingの概要とその一つの取組みとしてのATDDの実践をテスト自動化目線で - システムレベルの自動E2Eテス…
Design Skill Map - メルカリUXデザインチームの専門スキル｜Mercari Design Blog
UX Designチームのasakomです。今回はデザイナーの役割定義の活動の一つとして作成した、”Design Skill Map”についてお話しします。 このSkill Mapは、メルカリUX Designチームで求めるデザイナーの専門スキルを整理したものです。以前紹介したDesign Ladderは、メルカリの行動指針に基づいて作成した、デザイナーに求める態度やマインドセット。今回は専門職としてのデザイナーに必要な技術や知識をSkill Mapとしてまとめました。 UXデザイナーの役割定義や、個人の目標設定、採用の基準作りなど、チームの運用に関わる人や、メルカリのUXデザインチームが求める人材に興味のある方に、ぜひ読んでいただきたいです なぜSkill Mapを作ったかUXデザインチームの役割定義は、チームのミッション達成のために存在します。私たちのチームのミッションは、”メルカリの
はじめにまずこの話をするのにあたって「正しい見積り」という伝承を語らねばならない。 次の章は、筆者が観測してきた100社ほどの開発関連会社におけるトレンドを雑に集約したものなので、当然ながら観測者バイアスがかかっている。 したがって、ITエンジニアのみなさんご自身の体験とはだいぶ違う事もあるかもしれない。その点はご了承願いたい。 ところで、カンブリア爆発のように、ある事柄がきっかけて急激に世界が変わっていくことは産業界にもよくある。 たとえば蒸気機関の登場が産業革命を引き起こしたように。 また、システム開発にも古代と現代を区切るほどのエポックメイキングな出来事が一つあると思っている。 それは「GitHubの台頭」。 本論では、この古代のことを「前GitHub時代」と呼ぶことにする。 ※厳密に言えばGitHub以外にも様々なソースコード共有サイトやリポジトリシステムは存在した。が、それらをコ
10/5 の「ふりかえりの手法をたくさん学ぼう」でいいふりかえり手法をたくさん紹介いただいたので、改めてまとめます。 記事の元になったお話、資料 ここに記載しているのは、以下で紹介された手法です。 ふりかえりの手法をたくさん学ぼう(ふりかえりam #27-28公開収録) - connpass podcast ep.27【#ふりかえりam】ふりかえり手法をたくさん学ぼう（前編）～ 紹介した手法：いっぱい ep.28【#ふりかえりam】ふりかえり手法をたくさん学ぼう（後編）～ 紹介した手法：いっぱい YouTube ふりかえりの手法をたくさん学ぼう ふりかえり手法の確認には、以下が紹介されていました。 ふりかえりチートシート 各手法、簡単に実践方法と効果を書いています。 実践例の記事が見つかったものはリンクを貼っているので、詳細はそちらをご参照ください。 各手法の参考リンクは、適当にググって出
テスターのくせに Janet Gregory さんと Lisa Crispin さんの書籍『Agile Testing』『More Agile Testing』を読まずに今日まできてしまったのですが、この二冊を凝縮（Condensed）した『Agile Testing Condensed』（日本語訳）くらいは目を通しておかないとね！ということで読みはじめました。 leanpub.com この記事は本書に書かれていたある問題を取り出し、それに対してわたしたちのチームが普段やっていることをわたしの目線で紹介したものです。ツイートするには長いのでこちらに書きました。 チームが「サイロ化」する問題 複数のチームがすべて同じプロダクトで作業している大規模な組織でよく見られる問題の1つは、チームが「サイロ化」する傾向があることです。依存関係を解決するために他のチームと話すことを忘れています。（第3章：
Spotify’s Failed #SquadGoalsを和訳してみました。 Spotifyは "Spotifyモデル "を使っていない。そして、あなたもそうすべきです。 スタートアップカルチャーの魅力の中でも、小規模なチームのスピードとアジリティに勝るものはありません。が、企業が成長していく中でこの感覚を維持することは困難です。2012年、Spotifyは新しい働き方を発表し、スピードとアジリティを理解したことを示唆しました。私が2017年にストックホルム本社のプロダクトマネジメント職の面接を受けたとき、Spotify Modelを実際に目の当たりにして興奮しました。しかし、最初の...
アジャイルの「理論」や「理想」だけではない、 実際に実践したからこそ見えてきた「現実」に役立ったヒントを紹介したのは、マネジメントソリューションズ社の渡会氏。「Rebuild our Agile!」をテーマに掲げた「Agile Japan 2023」で、アジャイルのRebuildについて発表しました。全2回。前半は、「選択肢のRebuild」と「ロールのRebuild」について。 開発の考え方をウォーターフォール→アジャイルにRebuild 渡会健氏：みなさん、こんにちは。マネジメントソリューションズの渡会と申します。これから、「アジャイルで実際に困ったからこそアジャイルをRebuildした話」ということで講演させていただきたいと思います。よろしくお願いいたします。 （会場拍手） 最初に、私の自己紹介。この自己紹介の中にも、けっこうRebuildしたことが入っています。 最初の20年は、プ
DXの流れも相まって、アジャイル開発に取り組む会社が増えてきています。自社にも取り入れてみたいけれども不安がいっぱい、取り入れてはみたもののうまく行かない、そんなことありませんか？正しいアジャイルって...
達人出版会
探検! Python Flask Robert Picard, 濱野 司(訳) BareMetalで遊ぶ Raspberry Pi 西永俊文 なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 Jesse Storimer, 島田浩二(翻訳), 角谷信太郎(翻訳) 知る、読む、使う！ オープンソースライセンス 可知豊 きつねさんでもわかるLLVM 柏木餅子, 風薬 徹底攻略 AWS認定 クラウドプラクティショナー教科書 第2版［CLF-C02］対応 トレノケート株式会社 高山裕司 超楕円関数への招待 楕円関数の一般化とその応用 松谷 茂樹 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 Tom Hombergs(著), 須田智之(訳) 詳解 AWS CloudFormation 潮村 哲 その決定に根拠はありますか？ 確率思
アジャイルを支えるテストアーキテクチャ設計/Test Architecting for Agile
高品質と高スピードを両立させるテストアプローチ/Test Approach that Improves Quality and Agility Together
受託開発でもアジャイル開発できました / Agile in Contract Development
AWS Developer Live Showにて。 https://aws-dev-live-show.connpass.com/event/331735/ プロフィールやお問い合わせはこちらからどうぞ！ https://agile-monster.com/profile/ https:/…
すべてがXPになる ─ エクストリームプログラミングで見える開発風景（セミナーレポート） - Agile Journey
アジャイルソフトウェア開発を企業が導入する際に、スクラムと並んで名前が挙がる開発手法にエクストリームプログラミング（XP）があります。ガイドブックや研修が存在するスクラムに対して、ペアプログラミング（ペアプロ）やテスト駆動開発といったプラクティスをエクストリーム（極限的）に実践しようというXPの導入には、どこから始めればよいのかと戸惑う開発組織もあるようです。 2022年6月に開催されたユーザベース主催の勉強会「エクストリームプログラミングで見える開発風景」では、XPの提唱者であるケント・ベックの著作などの翻訳者として知られる角征典さんと、XPを導入しているユーザベースのソフトウェアエンジニアである野口光太郎さんが講演したのち、XPの始め方やエンジニア以外との体制づくりなどについて、視聴者の質問をもとにパネルトークが行われました。 本記事では、組織にXPをどのように導入するか、またスクラム
そろそろ全体を見た話が聞きたい２ - ニューロサイエンスとマーケティングの間 - Between Neuroscience and Marketing
2010年の年末に『イシューからはじめよ』を出版した。何ヶ月か後、歴史的な大地震（いわゆる311）が来た。大津波の死者・行方不明者は無数、フクシマは爆発する、東京は計画停電が始まるしで、何がなんだか訳のわからない不安と混乱が世の中を覆い尽くしていた。随分目先のしかも全体観のない議論ばかりが行われていて不毛だと感じ、10日あまり経ったところで課題の全体観を俯瞰したブログエントリを書いた。 kaz-ataka.hatenablog.com 今見てもそれほど大きな違和感がない。初動、その後の対応の残念さ、せっかくの刷新にもうまく繋げられたとは言い難かったことも明らかになっているのだが、それは一旦おいておこう。 ＿ いま僕らを襲っているのは歴史的には人類最大の死因の一つ、疫病だ。 拙著『シン・ニホン』が2月20日に世に出たときはまだ中国と日本のダイヤモンド・プリンセス号にほぼ閉じた話だったが、現在
リモートワークでも生産性を上げる！スクラム創始者直伝の実践ノウハウを日本語化して入門者向けにまとめました。 - Qiita
リモートワークでも生産性を上げる！スクラム創始者直伝の実践ノウハウを日本語化して入門者向けにまとめました。プロジェクト管理スクラムリモートワークコミュニケーションコロナウイルス はじめに 認定スクラムマスター(LSM)取得者向けに「Distributed Teams: Mitigating Business Risk in Uncertain Times」と題したウェビナーがスクラム創始者の Jeff Sutherland 氏を交えて3月に行われました。 この投稿はウェビナーの内容を噛み砕き、リモートワーク環境でもスクラムの実践がスタートできる内容を目指しました。チームリーダーやマネージャーとしてスクラムを推進している方や、これから導入を検討している方のご参考になれば幸いです。 まずは結論から リモートワークでより成果を上げる働き方は可能なの？ 可能。→ リモートチームを成功させた企業のユ
このブログエントリは日本信頼性学会論文誌 Vol.42, No.2, 2020年3月号に寄稿した「アジャイル/DevOps開発における品質保証と信頼性」という解説論文の転載です。 （品質管理研究会でこの解説論文の内容をもとにした特別講義を来年実施します。ご興味ある方はぜひご参加ください。） --- 概要 近年日本のソフトウェア開発チームでも取り入れられるようになったアジャイル/DevOps などのソフ トウェア開発手法は,今まで主流であったウォーターフォール開発と異なる特徴を持つため,その品質保 証や信頼性の考え方をそのまま適用できない場合も多い.アジャイル/DevOps 開発では短い開発サイクル の中で小刻みなフィードバックループと改善活動を繰り返しながら開発する.そのため,QA テストとして の品質保証の役割はアジャイル/DevOps においても依然重要であるが,それに加え開発サイクル
【翻訳記事】テストに対する考え方「Testing Manifesto」 - ブロッコリーのブログ
はじめに（Testing Manifestoを紹介するに至った背景） 既にこのブログでお伝えしたように、先日『Agile Testing Condensed』の日本語翻訳本を出版しました。 この書籍の中で、テストマニフェスト（Testing Manifesto）が紹介されています。 アジャイルソフトウェア開発宣言（Agile Manifesto）を元ネタにして作ったものだと思います。 この考え方は書籍を購入していない人にもぜひ知ってほしいと感じているので、この記事でも紹介することにしました。なお、記事に載せることについては、この画像の作者であるKarenとSamにメールを送り許諾を得た上で掲載しています。*1 テストマニフェスト 翻訳した画像はこちらです。*2 オリジナルの画像等はこちらにあります。 www.growingagile.co.za また、画像だけでなく文章も残しておきます。
はじめに こんにちは。ソーシャル経済メディア「NewsPicks」の QA/SET チームの海老澤です。 先日 弊社で E2E テスト実行するために Playwright を導入したため紹介させてください。 E2Eテストとは E2Eテスト（エンドツーエンドテスト）とは、ソフトウェア開発におけるテスト手法の一つで、アプリケーションが実際の運用環境と同様の条件下で正しく動作することを確認するためのテストです。 システムの開始点から終了点までを通じて、ユーザーの視点でアプリケーションのフローを追い、機能全体が連携して期待通りに動くかを検証します。具体的には、ユーザーが行うであろう一連の操作をシミュレートして、データがシステムを通じて適切に流れるかや、最終的なアウトプットが正しいかどうかを確認します。E2Eテストにより、部分的な単体テストや統合テストでは見逃されがちな問題を発見することができます。
「システム構築はどこから始めるべきだろうか。システム構築が終わったらこうなる、というストーリーを語るところからだ。」 - Qiita
「システム構築はどこから始めるべきだろうか。システム構築が終わったらこうなる、というストーリーを語るところからだ。」アジャイル要求ユーザーストーリー はじめに ◆この記事は何？ アジャイル開発における「要求」や「ユーザーストーリー」を細分化する記事です。 ◆対象は？ 要求やユーザーストーリーを整理する方 アジャイル開発に関わる方 ◆ねらいは？ アジャイル開発に関わる方が、何気なく使っている「要求」や「ユーザーストーリー」の解像度を上げること エンジニア人生に影響を与えたフレーズ 「システム構築はどこから始めるべきだろうか。システム構築が終わったらこうなる、というストーリーを語るところからだ。」は、書籍『テスト駆動開発』に出てくるフレーズです。 そして書籍『テスト駆動開発』の中で、私が最も印象に残っている文章です。 この文章に出会ってから、私は「言われた通りにシステムを作る」から脱却して、「
2022のアジャイル本紹介です。『継続的デリバリーのソフトウェア工学』は、久しぶりにソフトウェア工学を題した「アジャイル開発」の本です。もう一度、ソフトウェア工学の観点からアジャイルを説明していて、ま...
カンバンボードで業務を可視化・整理しよう - 組織に合ったカンバンの設計・運用をヴァル研究所の実践に学ぶ - Agile Journey
Agile Journeyをご覧の皆さん、こんにちは。ヴァル研究所の熊野壮真 / 小泉翔太です。 私たちの勤務する株式会社ヴァル研究所は、日本で最初に発売された経路検索サービス「駅すぱあと」を中心に、公共交通に関連するさまざまなプロダクトを展開しています。最近では MaaS （Mobility as a Service)）といった、未来の移動のあり方を変えていくような取り組みにもチャレンジしています。 これらプロダクト開発の現場にはアジャイルの考え方が浸透しており、各チームでは現場ごとに合わせたさまざまな形のアジャイルの実践が見られます。その実践手法は多様ですが、各チーム、共通して力を入れているのが「カンバン」による仕事の可視化の取り組みです。こと「カンバン」に関しては開発部門のみならず、バックオフィス部門でも積極的に活用しており、その活用場面の多さ、バリエーションの豊かさは当社の特色と言
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データ職種の課題図書リストを作りたい - 下町柚子黄昏記 by @yuzutas0
マイクロサービスでチームを分離したくないマン - まっちゅーのチラ裏
アジャイル開発は本当に必要なのか、何を解決するのか
エンジニアリングマネージャーとしての開発力向上の取り組みついて - Qiita
チームのScrapbox3000ページくらいを見返して整理した - hitode909の日記
「人類がソフトウェアの工数を正確に見積もるのは、もはや不可能である」｜はまあ
「ふりかえりの手法をたくさん学ぼう」で紹介された手法まとめ - Qiita
チームが「サイロ化」しないための仕掛け - CAT GETTING OUT OF A BAG
Spotifyは "Spotifyモデル "を使っていない
アジャイルを導入したものの続けられなかったあなたへ 誤解や理解不足で起こる“もったいない”を解消するヒント
アジャイル勘違い集 (2024) | Agile Studio
アジャイルとDevOpsの品質保証と信頼性 - Test Automation
Playwrightを使ったE2Eテストを導入した話 - Uzabase for Engineers
継続的デリバリーのソフトウェア工学 | Agile Studio
エラー監視とテスト体制への改善作戦 / PHPerKaigi2022