「稲作」のメタファーで「現在・未来」の「ゲイン・ペイン」に注目したら、とても前向きにふりかえりできた - Money Forward Developers Blog
こんにちは、クラウド会計の開発チームでスクラムマスターをしているasatoです。 自作のふりかえりフレームワークがいい感じに機能したので紹介します 🙌 その名も「稲作（Rice Cultivation）」です。 背景 私はスクラムマスターとして、チームのふりかえりをファシリテーションする機会が多いです。当然のようにお気に入りのふりかえりフレームワークがあります。その辺は、個人のブログで語っています。 ブログでも語っている通り、私は「象・死んだ魚・嘔吐」が好きです。メタファーが想像力を掻き立ててくれます。 象🐘：誰も言わないので言いにくいと感じているが、大きな障害物だと思っているもの（英語の慣用句 “Elephant in the room” より） 死んだ魚🐟：今はそこまで気にならないが、放置すると大きな障害物になりそうなもの 嘔吐🤮：その他、自分の中でモヤモヤしているもの い
結果的にスクラムになってる！なのがいいと思う！ #RSGT2017
Regional Scrum Gathering Tokyo 2017
プロダクトマネジメントクライテリア
プロダクトマネジメントを体系化したクライテリアです。企業がプロダクトを成功に導くために必要な要素を多角的かつ具体的に記載してあります。対象はプロダクトマネージャー個人ではなくプロダクトを取り巻くチームとし、プロダクトマネジメント全体をスコープにしています。
ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編）
ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編） アジャイル開発の代表的な方法論であるスクラムをテーマに、都内で1月に開催されたイベント「Regional Scrum Gathering Tokyo 2024」で、経験豊富なアジャイル開発のエキスパートとしてウクライナを拠点にアジャイルコンサルタントをしていたドミトロ・ヤーマク（Dmytro Yarmak）氏が、ロシア軍の侵攻後にウクライナ軍に入隊し、中隊長としてリーダーシップを発揮するためにさまざまなメソッドを駆使して軍隊の組織を変革していった経験を語ったセッション「A True Story of Agile Coaching in Ukrainian Armed Forces」が行われました。 軍隊という、企業とは異なる構造や目的を備えた組織で、しかも多くの民間人が入
ストーリーポイントではなくアウトカムで開発速度を測る #LayerXテックアドカレ - LayerX エンジニアブログ
こんにちは。LayerX バクラク事業部 バクラクビジネスカード開発チームEMの @shnjtk です。新しいMacBook Proがとても気になっています。スペースブラックいいですね。欲しい。 この記事は LayerXテックアドカレ 13日目の記事です。前回は @itkq による 情報の流通性を上げコミュニケーションを活性化させるNotionデータベース でした。次回は @yossylx が担当します。 今回は、開発チームの開発速度をどのようにして測るかということについてお話します。 ストーリーポイントによるベロシティの計測 ストーリーポイント（SP）とは、アジャイル開発において、開発しようとするユーザーストーリーや機能、その他のタスクの大きさを表す見積もりの単位であり、タスク同士の相対値で表現されます。例えば「この機能はSP 3」、「この機能はSP 5」のように使われます。タスクの完了
Sprint Planning をやめた話 - スタディサプリ Product Team Blog
小中新規開発グループ (a.k.a. tara チーム) の qsona です。 tara チームでは、スタディサプリ中学講座というプロダクトを開発しており、約1年前 (2022-02) に本リリースして以来、継続してプロダクト開発を続けています。 tara チームのプロダクト開発は、基本的にスクラムの手法にのっとる形で行っています。ビジネス的な境界により分けられた3つのスクラムチームが存在します。 スクラムの運用については、それぞれの現場において悩みごとが起きがちだと思いますが、tara チームでもご多分に漏れず、うまくいっていること・いっていないことが存在します。今回は、その3つのうちの1つのチームである「学習コアチーム」において存在した、Sprint Planning に関する (あるいはそこから掘り出された) 課題と、それに対してどう対処したかについて書きたいと思います。 なお、本
【資料公開】プロダクトバックログ Deep Dive
みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 今年もスクラム実践者の祭典であるRegional Scrum Gathering Tokyoが、2022年1月5日〜7日までの3日間開催されました。 このイベントで「プロダクトバックログ Deep Dive」というタイトルで発表しましたので、資料を公開します。 スクラムガイドでも、プロダクトバックログという単語の登場回数は非常に多く、それだけ重要だということが分かります。 一方で網羅的にまとまっている資料が日本語ではあまり存在しなさそうなので、今回用意してみました。 内容については、過去にこのブログで説明している箇所も多数ありますが、1箇所にまとめたことに意義があるということでご了承ください。 みなさんのお役に立てば幸いです。 内容に関するご意見やフィードバックは、T
ウォーターフォールを殺しにきている書籍「継続的デリバリーのソフトウェア工学」を読んだ - 勘と経験と読経
読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第52回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。 #51 V字モデルの深淵を覗き込んで反省する：「単体テストの考え方（UTPPP）」を読む（後編） - 勘と経験と読経 #50 V字モデルの深淵を覗き見た気分：UTPPPを読む（前編） - 勘と経験と読経 #49 「デジタルトランスフォーメーション・ジャーニー」でDXできる？ #デッドライン読書会 - 勘と経験と読経 #48 頭を良くしたいので「哲学思考トレーニング」を読んだ #デッドライン読書会 - 勘と経験と読経 #47 いまさら「マスターアルゴリズム」読んだ #デッドライン読書会 - 勘と経験と読経 さ
SQUARE ENIX OPEN CONFERENCEゲーム開発プロジェクトマネジメント講座
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1 ©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4 ©SQUARE
予測型マインドセットと適応型マインドセットの違い、アジャイル思考の本質 | Social Change!
多くのマネージャや経営者に会ってきた中で、マネジメントの手法や組織のあり方の背景には、大きく二つの流派があるのではないか感じています。 一つは、未来の目標を決めて突き進もうとする考え方。もう一つは、将来は予測しきれない前提に立ち、変化に対して柔軟であろうとする考え方。 この本質的な部分で考え方（マインドセット）が合っていないと、世の中にある多くの手法や制度を真似てもうまくいかない。これは、どちらが正しいといった話ではなく、違いを認識することが重要ではないかと考えて整理してみました。 本稿では、この２つのマインドセットを「予測型マインドセット」と「適応型マインドセット」と定義して、その違いについて深掘りをしてみましょう。 未来の想像を先にするか、現在が続く先に未来があるか 「未来の働き方はどんな風になっていると思いますか？」 先日、とある大企業のイノベーションを担う部門の人たちから、リモート
企業システムにアジャイルは必要か
2015/6/22にアイ・ラーニング様にて開催された「悩める管理職のためのエンタープライズ・アジャイル導入セミナー」の講演資料です。Read less
「納品のない受託開発」の先にある「エンジニアの働きかたの未来」
こちらの勉強会で話した資料です。 http://dev-revolution.doorkeeper.jp/events/8881 勉強会のまとめはこちらです。 http://togetter.com/li/631383
永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance
この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。 俺の価値創造契約 from Fumihiko Kinoshita 永和さんの価値創造契約とは 新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。 2013年営業実績、0件 資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。 受託開発の弊害と指摘される「価値あるシステムを作り
ペアリング対コードレビュー: 開発者文化の比較
前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって
ファイル連携 データ連携のHULFT | セゾン情報システムズ
HULFTシリーズ製品一覧 ファイル連携、データ変換、データ変換に関する様々なソリューション製品をご紹介します。
ペアプログラミング - 大々的な報道にも反応はいまひとつ
ペアプログラミングを実践する技術系企業が増えていることに注目し始めた Wall Street Journal が，自らの見解を Computer Programmers Learn Tough Lesson in Sharing (共有を通じて厳しい教訓を学ぶコンピュータプログラマたち) という記事に発表した。 Facebook やモバイル決済の新興企業 Square など，技術系企業の間でペアプログラミングが人気です。その信奉者は，カップルによる効果を賞賛のことばで語ります。ペアコーダはコストの高いソフトウェアエラーを捕まえることができる，Web サーフィンのような時間の浪費もない，というように。 しかし実践してみれば，すぐに問題に突き当たる。デートするのとは訳が違うのだ。 現実はむしろ，最悪のブラインドデート以下かも知れません。やっかいな問題があっという間に山と積み上がり，パートナーを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
大規模なアジャイル開発の現場と技術負債 / Technical Debt
Scrum and Knowledge Creation
要はアジャイルは行き当たりばったりってことですか？
ソフトウェアの負債を扱う
