© 2012-2019 BASE, Inc. #AgileTesting #CI #CD #DevOps #推しテクはgauge TDDからATDDへ歩みをすすめる 2021.01.24 July Tech Festa 2021 Winter @hgsgtk Kazuki Higashiguchi - Step to Acceptance test–driven development from TDD -

© 2012-2019 BASE, Inc. 当発表で紹介する取り組みのモチベーション １ ２ ３ イテレーションごとの（外部）品質 を高める開発の方法を模索したい E2Eなテストの仕組みを整え、より開発 者が安心できる開発へ テストピラミッドを登る、 ユニットテストから受け入れテストへ

© 2012-2019 BASE, Inc. 当発表で話すこと ● アジャイルテストの考え方 ● ATDD (Acceptance test–driven development) とはなにか ● ATDDを実践する開発文化とプロセス ● 受入テスト自動化フレームワークgaugeを用いたテスト作成環境 ● エンドツーエンドテストの自動実行基盤 ● CircleCIを用いたCI/CDパイプラインへの組み込み ● TDDからATDDへ歩みをすすめた現場の実例

© 2012-2019 BASE, Inc. @hgsgtk Kazuki Higashiguchi 東京に住まう Full Cycle Developer BASE BANK, Inc. Tech Lead / Manager 自己紹介 July Tech Festa 2020 少人数でのアジャイル開発への取り 組み実例（一歩目の踏み出し方） https://speakerdeck.com/hgsgtk/a-first-step-to-agile-m ovement Dockerアプリケーション開 発実践ガイド コンテナアプリケーションの設計セ オリー https://gihyo.jp/magazine/SD/archive/2020/202012

© 2012-2019 BASE, Inc. 目次 １ 2 3 4 5 TDDからATDDへ歩みをすすめる アジャイルテストとは ATDDとは Test Automation Framework 「gauge」 gauge を用いてATDDへ歩みをすすめた実例

TDDからATDDへ 歩みをすすめる

© 2012-2019 BASE, Inc. TDDからATDDへ歩みをすすめる ※ 4象限内の要素は『Agile Testing Condensed: A Brief Introduction』 (2019年)の定義に準拠 『Agile Testing Condensed: A Brief Introduction』 https://www.amazon.co.jp/dp/B002TIOYWQ 四象限における Q2 を強化する １ 2 テストピラミッドを登る ATDD TDD 『初めての自動テスト――Webシステムのための自動テスト基礎』 https://www.oreilly.co.jp/books/9784873118161/ The Way of the Web Tester by Jonathan Rasmusson / Chapter 8 Climbing the Pyramid https://www.oreilly.com/library/view/the-way-of/9781680502251/f_ 0065.xhtml

© 2012-2019 BASE, Inc. アジャイルテストの四象限 テスト活動を2つの軸で分類した - 技術面 or ビジネス面 - 開発チーム支援 or 製品批評 Q1: 技術面 && チーム支援 - コードレベルのテスト - 自動化 Q2: ビジネス面 && チーム支援 - 顧客視点の高レベルのテスト - 自動化・手動を組み合わせる Q3: ビジネス面 && 製品批評 - ユーザー受け入れテストや探索的テスト...etc - 手動で行われるものが多い Q4: 技術面 && 製品批評 - パフォーマンステスト・セキュリティテスト....etc - ツールによる実施 ※ 4象限内の要素は『Agile Testing Condensed: A Brief Introduction』(2019年)の定義に準拠

© 2012-2019 BASE, Inc. 四象限における Q2 を強化する 開発チームを支援するテストは、コーディング前・進行中に作成され、欠陥の防止に役立つ 製品を批評するテストは、コーディング完了後に行われ、欠陥の発見・欠落したフィーチャ の特定に役立つ TDDの領域 - Unit tests - (Component tests) ATDDの領域 - Story acceptance tests - Examples TDD: Q1、技術面のUnit Tests等で駆動する ATDD: Q2、ビジネス面のStory Acceptance Tests で駆動する TDDからATDDへ歩みをすすめることで、ビジネス 視点の機能に対するテストの取り組みが強化される

© 2012-2019 BASE, Inc. テストピラミッド Mike Cohn氏が提唱した概念 (『Succeeding with Agile: Software Development Using Scrum』2009年） 『martinfowler.com: The Practical Test Pyramid』では、 テストピラミッドから学ぶべき点は次の2つだと言っている 1. 異なる粒度のテストを書く 2. 高レベルになるほど、持つべきテストは少なくなる 『Succeeding with Agile: Software Development Using Scrum』 https://www.amazon.co.jp/dp/B002TIOYWQ martinfowler.com: The Practical Test Pyramid https://martinfowler.com/articles/practical-test-pyramid.html ※ ”UI Tests”などのテストレイヤーは現在のテスト状況に対してシンプルすぎるた め、それらに固執する必要はなく、自分たちのプロダクト・開発チームに沿ったレ イヤー名で良いと指摘している

© 2012-2019 BASE, Inc. テストピラミッドを登る ほとんどの開発チームはユニットテストから始める そして「アイスクリームコーン」にならないように、 必要に応じて上の階層に登っていく （『初めての自動化テスト』著者 Jonathan Rasmusson ） アイスクリームコーン 実行時間がかかり壊れやすい高レベルテストのほうが多く なってしまうアンチパターン ※ すべてのアイスクリームコーンが悪いわけではない （ex. そもそもテストが存在しないレガシーシステムでUIテストから始める） Testing is Good. Pyramids are Bad. Ice Cream Cones are the Worst / Stephen H Fishman https://medium.com/@fistsOfReason/testing-is-good-pyramids-are-ba d-ice-cream-cones-are-the-worst-ad94b9b2f05f

© 2012-2019 BASE, Inc. 現場の話 “BASE BANK” で歩みをすすめる [現状] ● 不確実性をコントロールするためアジャイルな開 発文化・プロセスを実践している ● イテレーションごとにUserStoryベースの開発計画 を行うことが増えてきた [歩みをすすめることで...] ● イテレーションごとの完成条件をより明確にし、 作ったものの外部品質を保証したい ● デグレを防止するための回帰テストを用意するこ とで、次の価値創出に集中したい 四象限における Q2 を強化する １ 2 テストピラミッドを登る [現状] ● ユニットテストを書き、CIでの自動実行を行って いる [歩みをすすめることで...] ● 複数サービスを横断するエンドツーエンドなテス トによって、より安心感のあるデプロイへ ● 単一エンドポイントにとどまらないシナリオを自 動テストでしっかり押さえたい

アジャイルテストとは

© 2012-2019 BASE, Inc. アジャイルテストの定義 “始まりからデリバリーまで、そしてそれ以降も継続的に実施される協調的なテストの実践 により、お客様への価値の頻繁な提供をサポートします。テスト活動は、高速なフィード バックループを用いて理解を検証しながら、プロダクトの品質を築くことに重点を置いてい ます。このプラクティスは、品質に対するチーム全体の責任という考え方を強化し、サポー トします。” by Lisa Crispin and Janet Gregory (Our ever-evolving, never set-in-stone definition of ‘agile testing’) https://agiletester.ca/ever-evolving-never-set-stone-definition-agile-testing/ 『Agile Testing Condensed Japanese Edition』 https://leanpub.com/agiletesting-condensed-japa nese-edition

© 2012-2019 BASE, Inc. Continuous Testing in DevOps https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ DevOpsにおけるあらゆるフェーズ においてTestingは存在している 「Continuous Testing（継続的テス ト）」という考え方 継続的かつ全体的なテストアプロー チを重要とする

© 2012-2019 BASE, Inc. Test Manfesto http://www.growingagile.co.za/2015/04/the-testing-manifesto/ by Karen Greaves and Samantha Laing 成功するアジャイルテストアプロー チに必要なマインドセット ● 開発プロセス全体をテスト ● バグの防止 ● 理解している価値をテスト ● 最高のシステムを構築 ● 品質に対するチーム全体の責任

© 2012-2019 BASE, Inc. アジャイルテストのPractices Our ever-evolving, never set-in-stone definition of ‘agile testing’ https://agiletester.ca/ever-evolving-never-set-stone-definition-agile-testing/

© 2012-2019 BASE, Inc. ATDD in アジャイルテスト Our ever-evolving, never set-in-stone definition of ‘agile testing’ https://agiletester.ca/ever-evolving-never-set-stone-definition-agile-testing/ 「具体的な例」によって 開発をガイドするプラクティス

ATDDとは

© 2012-2019 BASE, Inc. ATDDとは ● ATDD: Acceptance test–driven development（受け入れテスト駆動開発） ● ユーザーストーリーの受け入れテストである「ストーリー受け入れテスト」に着目する ● 例によって駆動するExample-driven developmentの ひとつのバリエーション ● 厳密な言語やルールのない例を使用して開発を導く、 より一般的な形式 ● BDD（Behavior-driven development: 振る舞い駆動開発）がGherkin記 法（Given/When/Then）という特定の記法を用いる のに対して、ATDDには厳密な記法の指定はない 『More Agile Testing: Learning Journeys for the Whole Team』 https://www.amazon.co.jp/-/en/Janet-Gregory-ebook/dp/B00O27 V8DA

© 2012-2019 BASE, Inc. ユーザーストーリーとは ● ユーザー・顧客視点での「フィーチャ」記述を指すもの ● 「フィーチャ」とはソフトウェアを使う側の視点で記述される使い手にとっての価値 ○ ex. 「注文画面」という機能ではなく、「欲しい商品が注文できること」 ● よくあるTemplate: ＜ユーザー＞が、＜機能・性能＞にする。なぜなら＜ビジネス価値＞のためだ。 ex. 「ショップオーナーが、入出金履歴で売上を見れるようにする。なぜなら売上を確認するためだ。」 ● ユーザーストーリーを実現するために、バーティカルスライスでのデリバリーが必要にな る

© 2012-2019 BASE, Inc. バーティカルスライスのデリバリー “短いスプリントがうまくいくには、動く機能を少しずつ頻繁にデリバリーする能力をチーム が養わなければならない。こうした活動をサポートするために用いられる設計アプローチは バーティカルスライスと呼ばれる。バーティカルスライスは、増分的に機能または価値をデ リバリーするために各アーキテクチャ層で変更を行う、というものである。” 『More Effective Agile “ソフトウェアリーダー ”になるための28の道標』 9.4 基本原則：バーティカルスライスでのデリバリー https://www.amazon.co.jp/dp/B089KFKB5H by Steve McConnell (『More Effective Agile “ソフトウェアリーダー”になるための28 の道標』著者)

© 2012-2019 BASE, Inc. ユーザーストーリーのスキルレベルを高める ● Agile Allianceではユーザーストーリーのスキルレベルに3段階あることを示している ○ https://www.agilealliance.org/glossary/user-stories ● ATDDのプラクティスはスキルレベル Intermediate への挑戦課題 ● ユーザーストーリーを表現するための標準的なフォーマットを1つ以上知っている ● ユーザーストーリーを例示して説明できる ● ...etc ● 機能を目標をユーザーストーリーに分割・ギャップを残さないように ● ユーザーストーリーを表現するための標準的なフォーマットを複数知り、最適な選択ができる ● ユーザーストーリーの受入基準を、自動化された受入テストとして直接使える言 葉で表現できる ● ...etc ● 非機能要件をユーザーストーリーの観点から解釈できる ● プロジェクト目標のより高いレベルの説明にリンクさせ、ユーザーストーリーのビジネス価値の根拠を提供できる

© 2012-2019 BASE, Inc. ATDDの開発ステップ 1. イテレーションの計画等で、抽象的な受け入れテス トをチームで会話し特定する - 「ストーリー受入条件」としてユーザーストー リーに記述 2. 自動化可能なテストであれば、失敗する受け入れテ ストコードを記述 3. 機能実現に向けて実装する（n回のTDD Cycle） 4. 機能完成後、自動テストを実行。その他探索的テス トなどのテストも行う 5. 受入条件（完成条件）を満たしていることが確認さ れれば、ストーリーを受け入れる ※ イテレーションの計画等に該当するキーワード スプリントプランニング・バックログリファインメント・「スリーアミーゴス」ディ スカッション...etc

© 2012-2019 BASE, Inc. ATDDの実装作業ステップ 1. 失敗するストーリー受け入れテストを最初に書く 2. ストーリー受け入れテストを通す過程でユニットレベルのサイクルを回す 3. n回のチェックイン後、ストーリー受け入れテストを通す

© 2012-2019 BASE, Inc. ストーリー受け入れテストに何を書くか ● 事業領域の用語で記述する ○ 関係者が理解でき、会話できることが期待できる ● 機能テストのみではなく、他の品質特性の要件（セキュリティやアクセシビリティ、 パフォーマンスなど）も含める ● 『実践テスト駆動開発』による薦め ○ そのアプリケーションのドメインに由来する用語しか使わない ○ 技術（データベース・Webサーバーなど）に由来する用語を使わない ○ [技術由来の用語を用いないMerit] ■ 実装に関する最初の想定に縛られない ■ 技術的詳細に引きずられてテストが複雑にならない ■ SUT(System Under Test)に対して疎結合 『xUnit Test Patterns: Refactoring Test Code』 https://www.amazon.co.jp/dp/B004X1D36K

© 2012-2019 BASE, Inc. 品質に対して得られるフィードバック 『実践テスト駆動開発 (Object Oriented SELECTION)』 第一章 テスト 駆動開発のポイントとは？ https://www.amazon.co.jp/dp/4798124583 外部品質のフィードバック (by ATDD) - エンドツーエンドテストの実行によってシステムの外 側の質がわかる - ストーリー受け入れテストを書くことでドメインにつ いてチームがどれほど理解できているかについての知 見が得られる 内部品質のフィードバック (by TDD) - ユニットテストを書くことで、コードの質についての フィードバックを数多く得ることができる 外部品質: システムが顧客やユーザーのニーズにどれだけ応えられているか （機能を備えているか、信頼できるか、利用できるか、素早く反応するか...etc） 内部品質: 開発者や管理者のニーズにどれだけ応えられているか （理解しやすいか、変更は容易か...etc）

Test Automation Framework

© 2012-2019 BASE, Inc. Tools for ATDD 有名なBDDツール Gherkin Syntax https://cucumber.io/ ThoughtWorks社がメンテしている Go製の受け入れテスト自動化フレー ムワーク https://gauge.org/ Uncle Bob氏が作った 本体のメンテは続いているがPlugin のメンテが一部止まっている http://fitnesse.org/FrontPage テスト自動化・RPA (Robot Process Automation) ツール https://robotframework.org/ 当発表で取り上げる「推しテク」 ● Markdownベースのシンプルな仕様記述Syntax ● ステップ実装のための言語は Java/JS/TS/Python/Ruby/C# をサポートしている ● メンテナンスが活発（Issueをあげたら数分後に返事が来た） ● Goがメインの開発チーム、Go 言語で開発されている内部実装であれば読みやすい ● cucumberと迷ったが Gherkin syntax を必須としなかったため gauge をまず試した

© 2012-2019 BASE, Inc. ● 受け入れテスト作成・実行のためのOSSフレームワーク ○ Markdownベースのシンプルな仕様記述Syntax ○ ステップ実装のための言語は Java/JS/TS/Python/Ruby/C# をサポート ● Visual Studio Codeの拡張 (https://marketplace.visualstudio.com/items?itemName=getgauge.gauge) が用意されている ○ 新規PJ作成・テスト実行・コード補完・定義ジャンプ・フォーマット...etc ● taiko（ブラウザ経由のテストを行うためのNode.jsライブラリ）との組み合わせ ○ 同じくThoughtWorks社がメンテしている taiko と組み合わせてUI経由のテストが行え る ○ コマンドでSUT(System Under Test)を操作した記録を元にコードを生成する ■ ex. openBrowser(), goto("example.com"), click("agree"), write("test") ○ ※ Seleniumを普通に使うのも可能 Test Automation Framework 「gauge」

© 2012-2019 BASE, Inc. gauge実行・結果レポート 2. 実行結果 1. VSCode上で実行 3. 結果レポート表示 example.spec

© 2012-2019 BASE, Inc. gaugeのSpecificationのSyntax Markdown-likeなSpecification Syntax # Specification 仕様、ユニットテストにおけるテストクラスのようなもの * Contexts step xUnit系でいうところのSetUp ## Scenario 個別のテストシナリオ * Step テストシナリオ内で実行するステップ ___ TearDown、定義後のStepは後片付けで実行される

© 2012-2019 BASE, Inc. gaugeのSpecificationファイル example.spec *.spec で定義したステップを選択したプログラミング言語で実装する Pythonの場合は @step() でマッピングする API Client実装 webdriver selenium

gauge を用いて ATDDへ歩みをすすめた 現場の実例

© 2012-2019 BASE, Inc. 今回の実例で取り上げるSUT ● 今回の実例で取り上げるテスト対象システム（SUT）は Web API Service ● 背後に内部APIやDB・Redis Server等が控える Public API ● 新規構築ではなく、すでに本番稼働しているサービスに対して導入した

© 2012-2019 BASE, Inc. 受け入れテスト記述リポジトリを準備する 既存のアプリケーションリポジトリとは別にgauge専用のレポジトリ（gauge-tests） を用意した [Merit] ● 特定リポジトリに依存しない、アーキテクチャ変更に対応しやすい ● 実装コードを参照しにくいためSUTに対して疎結合になる ● 他サービスへの展開も含めて、受け入れテストの運用方針・知見を 一つのリポジトリ内に集約できる [Demerit] ● 別レポになると開発者の実装リズムの中で頻繁に書きづらい ○ ex. 1minごとにCycleを回す ATDDはTDDよりも大きなフィードバックループを回すプラクティス その前提に立つと、別レポのDemeritは許容できると判断した $ tree -L 1 gauge-tests ├── README.md ├── serviceA └── serviceB ...

© 2012-2019 BASE, Inc. gaugeとともにあるATDD開発ステップ 1. スプリントプランニング等で、ユーザーストーリーの受入条 件をチームで会話し特定する - 「ストーリー受入条件」としてユーザーストーリーに記述 2. 自動化可能なテストであれば、失敗する受け入れテストコー ドを記述（「仕掛中」マーキング） 3. 機能実現に向けて実装する（n回のCycle） 4. 機能完成後、「仕掛中」を外してテストが通ることを確認 １ 2 3 4

© 2012-2019 BASE, Inc. 「仕掛中」と「完成」を区別する ATDDにおけるストーリー受け入れテストはフェーズによって２つに区分される 1. 仕掛中 - 「まず最初に失敗する受け入れテストを書く」 - 進捗を測るテストであり失敗することがわかっている、ビルドフローには含めない 2. 完成 - リグレッションを検出するテスト - 完成したストーリーのテストは常に成功することが期待するためビルドに含める リグレッションを検出するテストがATDDの入れ子のフィードバックループを加速させる 『実践テスト駆動開発』 第 4 章 テスト駆動のサ イクルに火を入れる https://www.amazon.co.jp/dp/4798124583

© 2012-2019 BASE, Inc. 「仕掛中」と「完成」を区別する ● gaugeにはTagsというテストをフィルタリングする 機能がある ● “draft” Tagsを活用して「仕掛中」を明示する ● CIフローでのテストスイート実行時は、 --tags=”!draft”オプションを設定し、draft以外を 実行する gauge run --tags "!draft" --env=ci specs 「仕掛中のテストシナリオ」は実 行スキップされている

© 2012-2019 BASE, Inc. CI/CD Pipelineに入れ込む ● 稼働中サービスは CircleCI を用いてCI/CD Pipelineを組んでいた ● 検証環境デプロイ後に「ストーリー受け入れテスト」の実行を入れ込む

© 2012-2019 BASE, Inc. CircleCIでのjob実行例 .circleci/config.yml https://github.com/hgsgtk/gauge-python-circleci-sample/blob/v0.0.2/.circleci/config.yml

© 2012-2019 BASE, Inc. 設定情報・秘匿情報の扱い [環境ごとに可変な設定] ● ローカル・CIや複数環境への対応で環境ごとの設定 が必要になる ● gaugeでは起動時に環境変数に設定する properties ファイルを活用した [秘匿情報] ● 受け入れテストをエンドツーエンドで用意しようと すると、テスト環境のAPI Keyやパスワードといった 情報が含まれる ● CircleCIのcontextに保管し、ジョブから参照 ○ context: 環境変数を保護し、プロジェクト間で共 有するためのメカニズム env ├── ci │ └── ci.properties └── default ├── ...etc ├── local.properties ├── local.properties.sample └── default.properties

© 2012-2019 BASE, Inc. SUTのCI/CD Pipelineに組み込む 検証用環境にデプロイ後、 自動受け入れテストを実行する ● SUTのCI/CD Pipeline内でgauge-testsをgit cloneして、デプロイ直後の検証環境に対し て実行する ● contextによって実行に必要な設定情報が共有されているため、gauge-testsリポジトリで 回しているJobの実行内容をほぼそのまま持っていける

© 2012-2019 BASE, Inc. 自動テスト基盤の構築プロセスでの検証プロセス シンプルなパターンから少しずつ実用まで解像度を上げていく 1. 実行自体の検証 a. 単純なPing程度のシンプルなテストケース 2. 複数環境での実行を想定したソリューション検討 a. OAuth2（client_credentials）の認証フローを通す 3. 実際のビジネス要件を試す a. 実際のチームのユースケースを満たしているか

© 2012-2019 BASE, Inc. 自動受け入れテストを拡充していく ● 新機能の作成では、新たに生まれたユーザーストーリーに対して、ATDDの開発ステップを 実施 ● 既存システムのバグ発生時等で、該当シナリオを「正常系」として追加 ○ エッジケースの場合は「テストピラミッドを意識」してユニットテストにする判断もあ る ● エンドツーエンドの整備自体が難しい場合もあるため、すべての受け入れテストを自動化 するという話ではない（ex. 送信されるメール・外部APIの検証環境との兼ね合い） ○ 受入条件として認識が明確になる事が重要 ○ 自動と手動は組み合わせつつ、手動でカバーしていた範囲を減らしていく

Summary

© 2012-2019 BASE, Inc. Summary ● ATDDの開発ステップを取り入れることで、フィーチャに対す る誤解を防止 ● リグレッションテストによって外部品質を保ち、フィードバッ クループを加速させる ● ユニットテストを揃えた足場を糧にテストピラミッドを登る ● gauge を用いてテストシナリオをE2Eに流せる仕組みを整備、 ATDDプラクティス・開発者の安心ためのテスト基盤に

References

© 2012-2019 BASE, Inc. 参考文献・資料 『Agile Testing Condensed: A Brief Introduction』 https://www.amazon.co.jp/dp/B002TIOYWQ 『Agile Testing Condensed Japanese Edition』 https://leanpub.com/agiletesting-condensed-japanese-edition 『実践テスト駆動開発 (Object Oriented SELECTION)』 https://www.amazon.co.jp/dp/4798124583 『xUnit Test Patterns: Refactoring Test Code』 https://www.amazon.co.jp/dp/0131495054 『Succeeding with Agile: Software Development Using Scrum』 https://www.amazon.co.jp/dp/B002TIOYWQ 『初めての自動テスト――Webシステムのための自動テスト基礎』 https://www.oreilly.co.jp/books/9784873118161/

© 2012-2019 BASE, Inc. 参考文献・資料 『More Agile Testing: Learning Journeys for the Whole Team』 https://www.amazon.co.jp/-/en/Janet-Gregory-ebook/dp/B00O27V8DA Our ever-evolving, never set-in-stone definition of ‘agile testing’ https://agiletester.ca/ever-evolving-never-set-stone-definition-agile-testing/ martinfowler.com: The Practical Test Pyramid https://martinfowler.com/articles/practical-test-pyramid.html Agile Alliance: User Stories https://www.agilealliance.org/glossary/user-stories Testing is Good. Pyramids are Bad. Ice Cream Cones are the Worst / Stephen H Fishman https://medium.com/@fistsOfReason/testing-is-good-pyramids-are-bad-ice-cream-cones-are-the- worst-ad94b9b2f05f

© 2012-2019 BASE, Inc. 参考文献・資料 The Testing Manifesto http://www.growingagile.co.za/2015/04/the-testing-manifesto/ Continuous Testing in DevOps… https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ Comparing Executable Specification tools https://jp-lambert.me/comparing-executable-specification-tools-b7081cc26315 アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点- / Satoshi Masuda https://www.slideshare.net/satoshimasuda/ss-3241717 Open Source Test Automation Framework | Gauge https://gauge.org/

© 2012-2019 BASE, Inc. 参考文献・資料 『More Effective Agile “ソフトウェアリーダー”になるための28の道標』 9.4 基本原則：バーティカルスライスでのデリバリー https://www.amazon.co.jp/dp/B089KFKB5H

© 2012-2019 BASE, Inc. 関連公開資料 振り返りで積み上げた開発プラクティス（2020年総まとめ） https://devblog.thebase.in/entry/bank-practices-2020 アジャイル開発におけるユーザーストーリー分割実践 〜画面リニューアルの裏側〜 https://devblog.thebase.in/entry/2020/08/13/110000 少人数でのアジャイル開発への取り組み実例 （一歩目の踏みだし方） | 詳説 | July Tech Festa 2020 登壇 レポート https://devblog.thebase.in/entry/2020/07/27/104144 チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」 https://devblog.thebase.in/entry/2020/07/08/162359 CircleCIとecspressoによるECSへのデプロイメントパイプライン by @fumikony https://devblog.thebase.in/entry/2019/04/10/110000

#JTF2021w