Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

“あれから14年が経ち、私たちは行き先を見失っています。 ”アジャイル”という言葉はスローガン化し てしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまっ たとすら言えます。 といった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重 ねるといった、口先だけのアジャイルの狂信者がたくさんいるのです。 ” https://postd.cc/the-failure-of-agile/ アジャイルの破綻―原因、そして新たな提案 (”The Failure of Agile” の翻訳)

Slide 3

Slide 3 text

“初心者がこれに対応する唯一の方法は、コンテキストのない簡単なルールに従うことです。例えば、「これが起こったら、あれ をする」といったようなルールです。ご丁寧なことに、アジャイル開発手法には初心者用にいくつかの具体的なプラクティスが提 供されているため、 彼らは、アジャイルの原則やアジャイル宣言の概要を尊重することなく、鉄則となっているプラクティスを入手するだけで、それ 以上何もしないのです。 ” https://postd.cc/the-failure-of-agile/ アジャイルの破綻―原因、そして新たな提案 (”The Failure of Agile” の翻訳)

Slide 4

Slide 4 text

● チーム開発について考える際に、「アジャイル開発」のエッセンスを取り入れ ることは、思いつきがちだろう ● しかし、 なことは、The Failure of Agile でも示されている ● 様々な現場で実践されている分、 だろう ● そんな今、アジャイル開発を始めるために役に立つのは、正誤あるにしろ、 の事例ではないか

Slide 5

Slide 5 text

● ● ● ● ○

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

※ 2020年6月4日時点

Slide 8

Slide 8 text

● 資金調達サービス「YELL BANK」など金融サービス (機能)を開発・運用 ● から、稼働中サービスの など ● 半 (backend/infra/frontend ...etc) ※ 適宜他チームと協同しながら ※ サービス実現のためのカバー範囲を広げていく方向へ お急ぎ振込 お急ぎ振込

Slide 9

Slide 9 text

https://www.oreilly.co.jp/books/9784873119090/ Matt LeMay 著、吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士 訳、及川 卓也 まえがき みんなでアジャイル ―― 変化に対応できる顧客中心組織のつくりかた “成功するアジャイルの適用は、常に厳しく正直に現状を見ることから 始まる。何がうまくいっていて、何がうまくいっていないのか。アジャイ ルを今の仕事のやり方をちょっと変えるだけのことと思っているなら、 アジャイルから得られるメリットもちょっとだけになるだろう。” (2章 自分たちの北極星を見つける)

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

fukabori.fm 32. みんなでアジャイル w/ ryuzee https://podplayer.net/?id=104223290 季節が移り変わっても北極星の位置が変わらないように、状況 が変わり時間が経っても変わらない、自分たちが大事にしたい ・目指したい目標。

Slide 12

Slide 12 text

社内Docに怪文書を投げかけ チームで議論したり

Slide 13

Slide 13 text

そのために次のことを取り組む ● 個々人の納得感と達成感のあるマイルストーン ● 重要マイルストーンに対するブレークダウンと見積もりの 継続的評価 ※ 2020/6/4時点 (成果を出せている感覚) (関係各所に宣言し、PJの現在地点を適宜振り返り、その状況を適切に共有する) ※ まだ文章としては正確な表現になっていない気もしています

Slide 14

Slide 14 text

● COVID-19 の感染拡大防止による WFH の開始 ● WFHでのプロジェクト遂行については、 ● になりがちな潜在課題

Slide 15

Slide 15 text

「組織の構成要素は人ではない! 」 渡邉 信光 / https://b-p-i-a.com/?p=709 “経営学者チェスター・バーナードが述べた3要素 1. 共通の「ゴール」(共通目的) 2. 協働意欲 3. コミュニケーション” 改めて、これらの要素にしっかり向き合う必要性が高まっていた

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

“プロセスやツールよりも を、 包括的なドキュメントよりも を、 契約交渉よりも を、 計画に従うことよりも を” Manifesto for Agile Software Development / https://agilemanifesto.org/

Slide 18

Slide 18 text

“アジャイルチームの基本的な仕事の進め方 ” https://book.mynavi.jp/ec/products/detail/id=22141 Mike Cohn 著 安井 力、角谷信太郎 訳 / アジャイルな見積りと計画づくり 価値あるソフト ウェアを育てる概念と技法

Slide 19

Slide 19 text

● 仕事の進め方は、 に大きく寄与する ● は、関係各所との に寄与する ● 方針は、 にマッチしそう

Slide 20

Slide 20 text

● 「アジャイル開発をしましょう」 ● アジャイル開発がやりたいわけではなくて、チーム課題を解決 したい ●

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

自分たちの優先度に沿って、「まずこれを始めよう」とピックアップして始めた ● イテレーション(スプリント) ● スプリントレビュー ● ストーリーポイント ※ 既に実施していたこと ● デイリースタンディング ● プランニングポーカー

Slide 23

Slide 23 text

● ○ エンドユーザーに実際に届ける粒度 ● ○ このくらいの期間に「ここまでいければ」というまとまり ○ プロジェクトごとに適応した形で設定しようと試みている ○ ex. 画面リニューアルPJ => n回のイテレーションで実現したい ユーザーストーリー を設定 ● ○ 現在は 1 week で設定している ○ 最初はフィードバックを回すために 2 days を小さくやってみ た

Slide 24

Slide 24 text

Sprint Review

Slide 25

Slide 25 text

● カンバンには、 を利用 ● 課題解決スコープをあくまで (ビジネス的なIssueについては 対象外へ) ○ 「 」精神 ○ そのため、Developerの使い勝手などを重視 ● ストーリーポイントの可視化は、 というブラウ ザ拡張を利用 ○ https://github.com/banyan/github-story-points

Slide 26

Slide 26 text

● banyan/github-story-points では、[1pt] とissue/pr/cardのタイトルに設定 することで、ストーリーポイントとして可視化する ● 毎イテレーションごとにレーンを残して消化ポイントを記録、のちのベロシ ティ計測へ活かす

Slide 27

Slide 27 text

● アジャイルでは、フェーズは基本的には設けないが、モデリングなど薄い フェーズを設けることはある ● プロジェクトによっては、既存コードの確認・大まかなプロト的実装による 「どのような要素があるか」・「それぞれのIssueになるうるものの大きさはな にか」について ● ちょうど新しいメンバーの方に来ていただいたタイミングもあり、 としても設定

Slide 28

Slide 28 text

https://www.oreilly.co.jp/books/9784873119090/ Matt LeMay 著、吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士 訳、及川 卓也 まえがき みんなでアジャイル ―― 変化に対応できる顧客中心組織のつくりかた 2. 組織の個人は、自分のチームやサイロの居心地のよさのなかでいちばん簡単に 完了できる仕事を優先する。 3. 進行中のプロジェクトは、プロジェクトを承認した最上位者の決定がない限り 続く。

Slide 29

Slide 29 text

● イテレーション中に発生した、問い合わせ対応やバグフィックスは、 ● 「チームの速度の阻害要因」と捉えてしまわないように ● 当初の計画に大きな支障がでたら、そのスプリントレビューで対策を考える方 向にしている(今のところは顕在化していない)

Slide 30

Slide 30 text

● スプリント期間終了時に、振り返りを行う ● 複数PJ横断するチームにおけるスプリントレビューの主目的を定義 ○ はとにかく大事にする ○ 自分たちにとってのなぜ: プロジェクト終了毎じゃなくて して、チームと して強くなっていこうぜ”

Slide 31

Slide 31 text

● 毎回KPTをする ○ ツールに や を使用、オンラインでのホワイトボードとしてうまく ワークしてる ● その中でマイルストーンの見直しや解像度の高まりを計画に反映 ● (これから)プロダクトの成果に対するフィードバックループを構築する必要性もPJに よっては感じている ○ → 必要なPJに対して取り組んでいく

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

期間・規模が大きいPJ中盤で中だるみ PdMが開発Directionまでやっているが、 そろそろ厳しい(特定ロールの負荷) PJメンバー間の仕様や状況の認識ブレ 良くも悪くも、個人の馬力でリリースス ケジュールを実現している ロールと個人が疎結合になり、個人がボトルネックにな りにくくなった

Slide 34

Slide 34 text

まだ、よちよち歩きだが、概ね打ち手として機能しようとしてい る (後日談: この資料のレビューを通して、改めて「うまくいけてるか?」という議論に なった。 )

Slide 35

Slide 35 text

● 、目指す方向を定め、それとアジャイル宣言・ 原則は同じ方向を向いていることを確認した ● ことで、いま自分たちがやっていることはうま くできているか、について ● 必要なことを最小限に行う発想、手法の実施アプローチとして は といえるのでは

Slide 36

Slide 36 text

● WFHの状況において、 に は、コミュニケーションを武器にするアジャイル開発は上手くハマった ● オンラインでのKPTでの共同ワークは、ドメインモデリングなど

Slide 37

Slide 37 text

● チーム開発にてアジャイルを取り入れるにあたり、現場で「どう考え たか」という思考プロセス、をお伝えした ● 現場でチーム開発を考えている人に役立てば幸い

Slide 38

Slide 38 text

● アジャイルの破綻―原因、そして新たな提案 (”The Failure of Agile” の翻訳) ○ https://postd.cc/the-failure-of-agile/ ● Matt LeMay 著、吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士 訳、及川 卓也 まえがき / みんなでアジャイル ―― 変化に対応できる顧客中心組織のつくりかた ○ https://www.oreilly.co.jp/books/9784873119090/ ● Manifesto for Agile Software Development ○ https://agilemanifesto.org/ ● fukabori.fm 32. みんなでアジャイル w/ ryuzee ○ https://podplayer.net/?id=104223290 ● Mike Cohn 著 安井 力、角谷信太郎 訳 / アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技 法 ○ https://book.mynavi.jp/ec/products/detail/id=22141 ● 「組織の構成要素は人ではない! 」 渡邉 信光 ○ https://b-p-i-a.com/?p=709