並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 14 件 / 14件

新着順 人気順

retrospectiveの検索結果1 - 14 件 / 14件

  • 「次から気をつけます」に対抗する、反省文よりは効果が上がる再発防止、学びの機会 - Qiita

    再発防止策を書くのは難しい。 良い再発防止策 良い再発防止策について、順位付けするとしたら、 その種類の問題について二度と意識することがなくなる解決策 その種類の問題を開発時に自動的に検知することができる解決策 その種類の問題が発生しても自動的に復旧することができる解決策 その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策 と言うのは意識したいと思いつつ、やはり難しい。 再発防止はむずかしい 障害の再発防止策は、 メカニズム ツール ルール チェックリスト の順番に検討せよ。と言われても、急いで書けなんて言われると「次回からは複数人でチェックします。」とか「チェック項目を追加します。」とかいう徹底できなそうな「反省文」になってしまう。 まさにこの有名な猫...。 **「なぜミスを繰り返すのか」「どうすればミスを防げるのか」を真剣に考えていないことがミス

      「次から気をつけます」に対抗する、反省文よりは効果が上がる再発防止、学びの機会 - Qiita
    • 一年半同じチームで色んなふりかえりをやったので手法と学び紹介していく

      Scrum Fest Mikawa 2021の登壇資料です。 以下は資料内で引用している参考リンクです DPA https://qiita.com/viva_tweet_x/items/97e819c626979b78947a KPT http://objectclub.jp/downlo…

        一年半同じチームで色んなふりかえりをやったので手法と学び紹介していく
      • ふりかえりを拡張する「ふりかえりチートシート」 - Qiita

        はじめに あなたのふりかえりを拡張するふりかえりチートシートを公開いたします! この記事では、技術書典7以降配布している「ふりかえりチートシート」の説明を行います。 ふりかえりチートシートは、ふりかえりの手法84個とその特徴を網羅した一覧表です。下記画像はイメージです。 pdfはBoothで無料DLできます。 DLはコチラ => (DL版)ふりかえりチートシート ふりかえりチートシートとは ふりかえりの様々なシチュエーション(ひとり、チーム、プロジェクト、組織)で利用可能なふりかえりの手法をまとめたチートシートです。 ふりかえりの各手法を「ふりかえりの5つの流れ」と「ふりかえりの8つの型」に沿って分類しています。 B5の2ページ分のpdfファイルで、両面印刷したものをイベント等で配っています。 DLしていただいたものは、ご自由に印刷&ご利用ください。 ふりかえりチートシートの想定利用対象者

          ふりかえりを拡張する「ふりかえりチートシート」 - Qiita
        • メルカリWebのマイクロサービス化、その4年 | メルカリエンジニアリング

          Author: @urahiroshi, Engineering manager of Web Platform team 2022年8月4日、メルカリで “web-2” と呼ばれるサーバがシャットダウンされました。これはメルカリWeb版の開発に携わっているチームにとって、一つの区切りとなる出来事でした。 web-2はPHPで記述されたwebサーバで、2015年から https://www.mercari.com/jp/ 配下のコンテンツを配信していましたが、現在では複数のWebマイクロサービスがその機能を担っており、 https://www.mercari.com/jp/ 配下のページは後継となるWebマイクロサービスが配信するページへリダイレクトされています。 メルカリWebのマイクロサービス化に向けた開発が始まり、最終的にweb-2がシャットダウンされるまで、実に4年以上の期間がかか

            メルカリWebのマイクロサービス化、その4年 | メルカリエンジニアリング
          • SCRUM MASTER'S LANGUAGE 言葉遣いこそ最強の武器

            2022.11.05 Scrum Fest Sapporo 2022

              SCRUM MASTER'S LANGUAGE 言葉遣いこそ最強の武器
            • スプリントの振り返り大全 〜 チームに最適な手法を見つける15のレトロスペクティブを振り返る - Agile Journey

              はじめまして。株式会社イノベーター・ジャパンでフロントエンドエンジニアをしている、うじた(@besburg)です。弊社ではスクラムによる開発を取り入れており、スプリントの最後には毎回スプリントレトロスペクティブという振り返りを行っています。そこで試した振り返りの手法をこの記事ではまとめてみました。 私たちのプロジェクトではタスクの優先度に入れ替わりが多く、今やっていることを可視化するため、2021年8月からスクラムを開始しました。参加メンバーは各プロジェクトのエンジニア全員で、スプリント期間に合わせて1週間ごとに振り返りを行っています。スクラムによる開発が初めてだったこともあり、当初は自分たちに合った手法を見つけることを目標に振り返りを進めました。 週ごとにメンバーが交代でファシリテーターを担当し、試したい振り返り手法を持ち寄ってレトロスペクティブを行いました。そのため基本的には振り返り手

                スプリントの振り返り大全 〜 チームに最適な手法を見つける15のレトロスペクティブを振り返る - Agile Journey
              • 「象・死んだ魚・嘔吐」をやってみた振り返り - JX通信社エンジニアブログ

                こんにちは。スクラムマスターの@sakebookです。 今回は「象・死んだ魚・嘔吐」をチームでやってみたのでその振り返りをします。 「象・死んだ魚・嘔吐」とは 振り返り手法の一つです。Airbnb Story 大胆なアイデアを生み、困難を乗り越え、超人気サービスをつくる方法(原題: The Airbnb Story)の中で紹介されていたようです。 翻訳されてなかなかキャッチーなネーミングになっています。 それぞれ次のようなことを意味します。 象 凄く大きい、見えているけど、みんな見ないふりをしている課題・問題。表層化しているけど大きすぎてみようとしていない。これが何かをみんなで話していく。 死んだ魚 放っておくと腐っていく。そういう問題。放置しておくとまずいことになる問題ってなんだろう?ということを話し合う。 嘔吐 自分の胸の中に隠していて、吐き出せなかったこと。これをこの場で嘔吐する。

                  「象・死んだ魚・嘔吐」をやってみた振り返り - JX通信社エンジニアブログ
                • こうしてふりかえりは終わってしまった / A Demise of a retrospective

                  2023.04.08 ふりかえりカンファレンス2023 https://retrospective.connpass.com/event/266892/

                    こうしてふりかえりは終わってしまった / A Demise of a retrospective
                  • 「Retrospectives Antipatterns」を読んだ - 勘と経験と読経

                    先日「Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)」を読んだばかりだけれど、別の調べ物をしていたら「Retrospectives Antipatterns」という本が最近発売されたことを知ってしまったので勢いで読んでみた。アンチパターン好きなもので。すごい有用な本だった。 Retrospectives Antipatterns 作者:Corry, Aino,Corry, Aino発売日: 2020/11/02メディア: ペーパーバック 著者サイトはこちらのようだ。https://metadeveloper.com/ 全体的な感想 えてして「ふりかえり」のファシリテーターは孤独だと思う。特にファシリテーションすること自体を主な仕事にしている場合、「より良い

                      「Retrospectives Antipatterns」を読んだ - 勘と経験と読経
                    • 出来事ベースでお気持ちを話しやすい振り返りワーク「YOT」 - BASEプロダクトチームブログ

                      こんにちは。BASE BANK 株式会社 Dev Division にて、 Engineering Manager をしている東口(@hgsgtk)です。 弊チームではプロダクト開発のリズムの中で振り返りを継続的に行っていますが、YOT という振り返りワークを作成、使用しています。BASE 社内の他チームでも「YOT っていう振り返り方法があるらしい!」と興味を持ってもらい活用されていたり、社外でもスクラムやアジャイル関連のカンファレンスでの登壇でちらっと紹介した際に「それ良さそう!」と一定の反響がありました。しかし、その一次情報はインターネット上のどこにもない状態でしたので、作成の背景も含めて参考にできる YOT の一次情報をここに記します。 TL;DR 振り返りの場のファシリテーターには、発言量が少なくてうまく場が盛り上がらない、というあるあるな悩みがありますよね 起こったことや思った

                        出来事ベースでお気持ちを話しやすい振り返りワーク「YOT」 - BASEプロダクトチームブログ
                      • KPT (Keep/Problem/Try) 等のふりかえりで、K (Keep) ネタを増やすみんなの工夫

                        KPT縛りではなく、他の代替手法、他の手法との組み合わせも含めた知見が集まっていました。 - 1 振り返りの前に - チームで共有したふりかえりの文脈をつくる - 前回のProblem/Tryを今回のKeepにつなげる 続きを読む

                          KPT (Keep/Problem/Try) 等のふりかえりで、K (Keep) ネタを増やすみんなの工夫
                        • チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」 - BASEプロダクトチームブログ

                          こんにちは。BASE BANK株式会社 Dev Division にて、 Software Developer をしている東口(@hgsgtk)です。私のいる開発チームでは、アジャイル開発の考え方・取り組みを取り入れています。アジャイル開発の導入については、「小さなチームが始めたアジャイル開発」という資料を公開しています。 今回は、アジャイル開発において、重要な振り返りについて、Mad Glad Sad(喜、怒、哀) というレトロスペクティブ(振り返り)のワークを紹介したいと思います。 TL;DR Mad Glad Sad(喜、怒、哀)は、感情データを集めるためのワーク イテレーションで起きた、喜んだり、怒ったり、哀しかったりした時間やイベント、を書き出していくイベント 素直な感情ベースでイベントを振り返ることで、 "理性のフィルター"で見つからない潜在的課題をチームが見つける きっかけに

                            チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」 - BASEプロダクトチームブログ
                          • 「ふりかえりの手法をたくさん学ぼう」で紹介された手法まとめ - Qiita

                            10/5 の「ふりかえりの手法をたくさん学ぼう」でいいふりかえり手法をたくさん紹介いただいたので、改めてまとめます。 記事の元になったお話、資料 ここに記載しているのは、以下で紹介された手法です。 ふりかえりの手法をたくさん学ぼう(ふりかえりam #27-28公開収録) - connpass podcast ep.27【#ふりかえりam】ふりかえり手法をたくさん学ぼう(前編)~ 紹介した手法:いっぱい ep.28【#ふりかえりam】ふりかえり手法をたくさん学ぼう(後編)~ 紹介した手法:いっぱい YouTube ふりかえりの手法をたくさん学ぼう ふりかえり手法の確認には、以下が紹介されていました。 ふりかえりチートシート 各手法、簡単に実践方法と効果を書いています。 実践例の記事が見つかったものはリンクを貼っているので、詳細はそちらをご参照ください。 各手法の参考リンクは、適当にググって出

                              「ふりかえりの手法をたくさん学ぼう」で紹介された手法まとめ - Qiita
                            • 職能横断型スクラム体制になってからのチーム改善活動 - STORES Product Blog

                              こんにちは、STORES ECでフロントエンドエンジニアをしている@daitasuとバックエンドエンジニアをしている@phayacellです。 STORES ECでは、今年の5月よりエンジニア内の大きな体制変更がありました。 その変更では、フロントエンド/バックエンドで分かれていたチーム体制から、デザイナーやプロダクトマネージャーも含めた職能横断型のチーム体制へと変更になったのですが、この記事では、その際に生じた、今まで各チームで行っていた開発の進め方とのギャップや手法をマージしていく上での課題について、またそれらをどのように解決していったのかについてをお話しします。 チーム改善までの背景 組織体制の変更 元々STORES ECでは、フロントエンド/バックエンド/デザイナーは独立したチームとして動いており、PJTとしてメンバーが切り出されてはいますが、活動の主体としては職能で分かれている組

                                職能横断型スクラム体制になってからのチーム改善活動 - STORES Product Blog
                              1