成功する実践的モブプログラミング - Qiita
※ https://zenn.dev/erukiti/articles/mob-programming に移動しました。この記事はいずれ消す予定です。 モブプログラミング（以下モブプロ）とは、複数人で一つの成果物（プログラムコード）を生み出すという、チーム作業のテクニックです。似たテクニックにペアプログラミングがありますが、モブプロは3人以上（4〜5人を推奨）でやるものであり、また、目的や効果も全く違うものです。 モブプロのコンセプトは、チームでコミュニケーションをして問題を解決するというチーム戦 です。これ最重要なので、あとで何回も登場します！ この記事には「成功する実践的モブプログラミング」というタイトルを付けています。ここでいう成功の定義は、モブプロが実際に効率よく実践できることとします。モブプロに関する記事・情報は「イベントでお試ししてみた」とかが多い傾向があるため、ここでは実践に
【PDF公開】Scrum Starter Guide
みなさんこんにちは。@ryuzeeです。 以前、「スプリント1を始める前にどんな準備をするか」という記事を公開したのですが、この記事に内容を加筆修正してPDF化したものを用意しましたので公開します。 スクラムは非常に軽量なフレームワークで、Howについてはほとんど触れられていないため、これから立ち上げるときにどんなことをやればよいのか困ってしまう人も多いようです。 何も準備せず、いきなりスプリントで開発を始めようとしたり、逆に何か月もかけて事前準備をしてしまい、ウォーターフォールと変わらないやり方をしている例も見かけます。 本書では、スクラムを始めるときにどんな準備をしてから始めればよいかを整理しています。あくまで筆者の経験を整理したものですので鵜呑みにせず取捨選択しつつ活用ください。 PDFをダウンロードする 最初は同人誌などで出そうかなと思ったのですが、色々大変そうなので、無料でご利用
Scrum.orgの認定トレーニングであるPSPOを受講した際に、トレーニングの中で出てきたプロダクトオーナーの成熟度レベルについて、Scrum.orgのブログに記事があったので、著者のRobbinに連絡をして、許可をいただいたので、記事の翻訳をこちらにアップします。 元の記事はこちら https://www.scrum.org/resources/blog/growing-product-owner-five-product-owner-maturity-levels プロダクトオーナーの役割は、組織において様々な異なる方法で実装されています。プロダクトオーナーの責任と権限は、組織、部門、チーム、そしてプロダクトオーナーによって異なります。これは、人が成長しなければならない役割であることから、ある程度は説明できます。この役割には、いくつかの特定の能力と考え方が必要です。さらに、多くの組織
ソフトウェア開発サイクルの改善を行う際に認識すべきボトルネックの種類 - stefafafan の fa は3つです
去年認定スクラムマスターになって、実際に自分の開発チームにScrumを導入したり、最近ではチーム内でテックリード交代して開発プロセスの高速化についてより考えるようになってきた。 Agile, Lean, XP, DevOps, Four Keys, Team Topologies など様々なフレーズを見かけたり本を読んだりしたところ大体皆同じ場所を目指していると感じるけど、イマイチ自分の脳内インデックスが貼れていない気がしたのでこのエントリで軽く考えを整理してみようと思う。 とにかく改善のサイクルが回っていない (ソフトウェア開発に限らない) 開発速度が上がらない (ソフトウェア開発者側) Extreme Programmingのプラクティス DevOpsのプラクティス チーム内での連携が上手くいっていない チームの構成がイマイチ・他チームとの連携が上手く取れていない まとめ とにかく改善
スクラムでの見積もり - Qiita
はじめに スクラムでの見積もりは意外とさらっと書かれている事が多く、作業見積もりと規模見積もりがごちゃごちゃの状態でスクラムを進めていた結果、チームの中で見積もりに対する不信感が強くなり「このままではいけない」と感じたため、まとめました。 また、似たような記事があまりネット上で見かけなかったため、ここにざっくりと分かるように集約しました。ぜひ、自分のようにごちゃごちゃになってしまっている方に届けば嬉しいです。 まず何のために見積もるか アジャイルのチームにとって、作業を見積もることは、良い予測を追求しようとするだけではありません。チームが要求を深く理解し、開始する前に何を構築しようとしているのかをより深く考え、一定時間内にチームで協調して取り組むことで、構築しているものに対して大きな価値を生み出すことを促します。 (アジャイルメトリクス p40より) 見積もりによってプロジェクトの状態が見
大学のアジャイル教育に奮闘した10年からの学び─短期の集中授業でアジャイルをどう実践するか？ - Agile Journey
ソフトウェア開発において、アジャイルという考え方はかなり浸透しています。多く出版物やWebコンテンツ、さまざまなコミュニティやセミナーが存在し、アジャイルの情報には触れやすい状況になってきました。一方で企業においてアジャイルを導入しようとする際に開発チームのどこを変えるべきか、組織固有のルールとどう折り合いを付けるかなどに頭を悩ませる方も多いでしょう。 『SCRUM BOOT CAMP THE BOOK』などの著作で知られ、アジャイルコーチとして企業の組織づくりを支援する永瀬美穂（@miholovesq）さんは、これまで複数の大学で授業におけるアジャイル導入も支援し、その成果を発表する「Agile PBL祭り」を主催してきました。永瀬さんによると、学生は前提知識もないところからソフトウェア開発を学ぶため、社会人エンジニアより自然とアジャイルに取り組める面もあるそうです。 大学はなぜ教育にア
アジャイルとリーン・スタートアップを組み合わせた開発プロセス ~第１回 概要~ - selmertsxの素振り日記
2019年8月にAzitに入社して4ヶ月。 私はSREとしての役割を期待されてAzitに入社したけれども、気がつけばバックエンドエンジニア兼スクラムマスターをやっていました。 バックエンドエンジニアとしては、AWSインフラ環境の完全な作り直しとTerraformによるコード化、Railsの負債解消、監視設定のコード化などを行っていました。 スクラムマスターとしては、初期の3ヶ月はアジャイル開発(スクラム、XPを組み合わせたもの)、そして12月からの1ヶ月はリーン・スタートアップ開発の導入等を行いました。 ここでは、スクラムマスターとして考えた開発プロセスについて資料にまとめます。 なおこの文章は、0-1 の開発フェーズではなく、すでにリリースされたサービスに途中で加わったスクラムマスターの目線で書かれており、対象とする読者も私と同じような境遇にあるスクラムマスターとなっています。 この開発
ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（後編）
ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（後編） アジャイル開発の代表的な方法論であるスクラムをテーマに、都内で1月に開催されたイベント「Regional Scrum Gathering Tokyo 2024」で、経験豊富なアジャイル開発のエキスパートとしてウクライナを拠点にアジャイルコンサルタントをしていたドミトロ・ヤーマク（Dmytro Yarmak）氏が、ロシア軍の侵攻後にウクライナ軍に入隊し、中隊長としてリーダーシップを発揮するためにさまざまなメソッドを駆使して軍隊の組織を変革していった経験を語ったセッション「A True Story of Agile Coaching in Ukrainian Armed Forces」が行われました。 軍隊という、企業とは異なる構造や目的を備えた組織で、しかも多くの民間人が入
Scrum Fest Osaka 2020 #京都トラック での登壇資料です。
こんにちは、コミューン株式会社でスクラムマスターを担っているヤマシタ（@yama_sitter）です。 前回「スプリントの属人性を減らしたらベロシティが安定した話」という記事を書きました。 この記事で紹介した取り組みに至るまでの過程に興味がある、という声を頂いたので、その過程、及び過程を振り返って得られた気付きを紹介させて頂きます。 ちなみに少し長いです。 ご了承下さい。 まずは結論から 取り組みの出会いから定着に至るまで 「WIP制限の導入」に至るまで 出会い 導入 定着 「タスクサイズの制限の導入」に至るまで 出会い 導入 定着 「死亡前死因分析（プレモーテム）の導入」に至るまで 出会い 提案 定着 改めて振り返ってみて まとめ 取り組みに出会えたのも上手くハマったのも正直偶然 「気付いてもらう」ことが大事。最後に決めるのはメンバー 「とりあえずやってみよう」くらいの気持ちで改善に取り
「みんなのPython勉強会」では、Pythonを中心としてプログラミングを様々なシーンに生かす方法を一緒に学んでいます。今回は初級、中級のサーバーサイドエンジニア向けに、開発現場のアドバイザーでもある長沢氏がアジャイルとDevOpsについて話しました。後半はアジャイルとDevOpsをどう取り入れればいいかについてです。 従来の開発計画とアジャイルの計画の違い やっと本題のうちの1つ、アジャイルの話に入ります。アジャイル開発自体の成り立ちの話は今日はしません。今日話しておきたいのは従来型、わかりやすく言うとウォーターフォールに近いものの開発のやり方とアジャイルのやり方はだいぶ考え方が違うというところをお伝えしたいです。 従来の開発の計画の仕方というのは基本的にはすべてのスコープをはっきりさせます。ウォーターフォールは要件定義を最初にやりますよね。要件定義で全部決め、すべての要件が固まって見
介護や医療、ヘルスケアなどの領域で、高齢社会に適した情報インフラを提供している株式会社エス・エム・エスの西村直人（@nawoto）です。私は2005年からソフトウェア開発においてアジャイル開発を実践しており、現在はアジャイル開発の考え方を軸にチーム開発の支援などを行っています。 エンジニア組織ではリリースを頻繁にできることが望まれますが、リリースすることに疲れたりしませんか？僕たちは「リリース疲れ」と呼んでいますが、疲れが溜まるようにどんどんリリースが辛いものに感じてきます。エンジニア以外に言ってもあまり理解してもらえませんが……。 そんな悩みを解決するべく、エス・エム・エスの開発チームで行ったのは、レゴを組み立てること。え、なんでレゴ？そんな「リリースレゴ」という取り組みについてご紹介します。 プロダクト開発を継続すると起こる「リリース疲れ」 事業は長く継続していくように構築されているも
「スクラムフェス仙台」は初心者からエキスパートまでさまざまな参加者が集い、学び、楽しむことができるアジャイルコミュニティの祭典です。ここで登壇したのは、森一樹氏。ふりかえりを日常とするチームができるまでを「プロダクトオーナー」という観点でふりかえり、それを再現するために必要だった要素について話しました。全4回。1回目は、異動から見えた、内情と課題について。 ふりかえりのエバンジェリスト・森一樹氏 森一樹氏：よろしくお願いします。みなさんこんにちは。 （会場拍手） 現地の方もオンラインの方も、よろしくお願いします。オンラインの方はすみません、私はだいぶ久々に現地登壇をするので、Discordのコメントを拾う余裕がなさそうです。とはいえ、コメントをもらえるとあとから見返した時にすごくうれしいので、ぜひよろしくお願いします。 今日は「プロダクトオーナーのための、ふりかえりが日常に溶けるチームの作
テスト活動の納得感を持ってテストケースを激減させた話 #D3QA / Improving convinced testing activities
以下のイベントの投影資料です。 https://d-cube.connpass.com/event/187308/ お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料内にあるURL】 ▽P2：書籍『Agile Testing Condensed』 https://leanpub.com/agiletesting-condensed-japanese-edition ▽P36：書籍『A Practical Guide to Testing in DevOps』 https://leanpub.com/testingindevops ▽P55：プランニングポーカーかんたんガイド https://www.slideshare.net/Ryuzee/ss-11644359/4 ▽P69：Agile Testingのエッセンス #scrumosaka h
「Scrum Fest Osaka」はスクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。KEYNOTEで登壇したのは、楽天グループ株式会社の椎葉氏。「誰も嫌な思いをしない変化」をタイトルに、自身が開発グループのサポートをしたときの取り組みについて話しました。全3回。1回目は、開発チームをサポートしたきっかけとそのミッションについて。 「スクラムをやっている」とは「前に進むための選択をしている」ということ 椎葉光行氏：ついに始まりましたね、スクラムフェス大阪。全国で、長崎も青森もいて、オンライン開催だし。いろいろなコミュニティもいっぱい参加しているし、名前のとおりスクラムなお祭りという感じですね。僕は今は緊張していますがすごく楽しみにしています。 今年も光栄なことに声をかけていただいて、自分もちょっと心の準備できたのでがんばっていこうかな
「なんとなくスクラム」を見直して改善に取り組んだらチームの意識が変わった - ANDPAD Tech Blog
はじめに はじめまして、アンドパッドSWEの小川です。 アンドパッドの開発組織では、アジャイル開発の手法を取り入れたチームづくりや開発プロセス改善に関する取り組みが盛んに行われています。 今回は、私が所属する施工案件管理チームで最近行った取り組みについて紹介したいと思います。 背景 これまでも、チームの開発プロセスにはアジャイル開発のフレームワークであるスクラムの手法を取り入れていました。たとえば、開発タスクはカンバン上で管理し、会議体としては毎日の朝会、週ごとのスプリントプランニングとレトロスペクティブを行っていました。 しかしながら、実際にはスクラムガイド記載の内容に従っておらず、「なんとなくスクラム」をやっているだけという面がありました。 たとえば、スクラムガイドが定義するスプリントプランニングはスプリントに実施するタスクを決定するための会ですが、我々の実施していた会では仕様や機能に
めちゃめちゃ使いこなす観察、理解、知識、解像度! そしてコンテキスト!!/observation-understand-knowledge-resolution-context
https://confengine.com/conferences/scrum-fest-mikawa-2021/proposal/15981 私たちは観察、理解、知識を用いて仕事をこなしています。 これらは「心の働き」といえるものです。 仕事の成果の質を左右する重要な活動で、 子供の頃から慣れ親しんだ活動です。 では、心を働かせるとはどのような活動なのでしょう。 私はほとんど答えることができませんでした。 このセッションでは何気なくしてきた観察、知識、理解を 明らかにし、その質を高め方を紹介します。 プロフィール https://note.com/mryy/n/n6f01561a6253 関連動画 シン・仮説検証 70000枚の付箋で分かった仮説検証のエッセンス https://speakerdeck.com/moriyuya/shin-hypothesis-testing 仕組みと働
我々はなぜテストをするのか？
Scrum Fest Niigata 2022 発表資料です。 https://confengine.com/conferences/scrum-fest-niigata-2022/proposal/16449 Dan North: �“BDD Is Not About Testing" https://www.youtube.com/watch?v=6nSwRSbc27g
TL;DR ADOP はヘキサゴナルアーキテクチャの実装パターンとして考えられます。 パターンという名前はそれに由来します。 あえて名付けた理由はこぼれ話をご確認いただけると幸いです。 ADOP の概要 ADOP (Application Domain Others Pattern) は中長期的に運用可能なコードへ誘導するアプリケーションアーキテクチャパターンです。 ADOP は次の特徴があります。 最小限のルールである 指針が明確である 特定の技術スタックに縛られない テスタビリティが確保される これらの特徴は、コードを自然と中長期的に運用可能なコードへ導きます。 まず、簡単にそれぞれがどういった意味を成すのかを確認してきましょう。 最小限のルールである どれほど完璧な作戦であっても、その実行が不可能であれば何の意味もありません。 プログラミングにおいてもそれは同じことで、制約を守るため
こんにちは！ SmartHRで開発したり、アジャイル推進したり、筋トレしたりしてるkouryouです。 SmartHRでは顧客の価値の最大化を目指し、日々開発プロセスの改善を行っています。 特に私の所属する基本機能のDチーム*1では、以前からクロスファンクショナルを強く推進しています。 本日はクロスファンクショナルとは何なのか？やってみてどんなメリットがあったのかをまとめました。 クロスファンクショナルとは スクラムガイドでは機能横断型と翻訳されています。 機能横断型というのは、エンジニアリング、デザイン、QAなど複数の職能（スキル）を持つことを表しています。 そして機能横断型という言葉は、チームに対して使われることが多いですが、個人に対しても使われます。(例: プロダクトエンジニアがデザインもできる、QAエンジニアがコードも書けるなど) SmartHRにおいてチームが機能横断型であること
開発チーム運営では問題発見・改善だけでなく、良かったことの共有も大事にする - $shibayu36->blog;
開発チームをスクラムなどを使って運営している時、改善がどんどん行われることは良いことである。しかし、その時によく起こりがちなのが、問題発見と改善にフォーカスしすぎた結果、チームの悪いところばかり見すぎてしまうことだ。過剰に悪いところばかり見てしまうと、徐々にチームが疲弊してしまうといったことが起こる。改善が捗ることは良いことだが、それでチームが疲弊してしまわないように注意しなければならない。 ちなみにスクラムガイドを参照してみると、スプリントレトロスペクティブの目的には「うまくいった項目や今後の改善が必要な項目を特定・整理する」と書かれている。つまり、デイリースクラムやふりかえり会などでは、問題発見と解決だけでなく、良かったことを言語化し再生産可能にすることも重視されているのである。 以上から、開発チーム運営では問題発見・改善だけでなく、良かったことの言語化・共有を大事にし、その2つをうま
2010年頃の話だが、ある台湾の大手部品メーカーを訪れた時の話だ。 「どうぞリラックスして、日本語でお話下さい」と、日本名が記された名刺を渡されたことがある。肩書きは技術担当の副総経理（副社長）と、相当な重職だ。 台湾では誰もが知るような有名上場企業なのに、なぜ日本人がこんな要職に就いているのか。 驚き戸惑いながら名刺交換し着席すると、程なくして董事長（会長：CEO）も入室し、人懐こい笑顔で語りかけてきた。 「ようこそ、はるか日本からよくお越し下さいました」 その日本語は淀みなく、発音を含めて全く違和感がない。そんな驚きが顔色に出ていたのか、董事長は自己紹介を兼ねて話し始めた。 「日本語は松下幸之助の著書で覚えました。翻訳本では彼の本当のメッセージがわからないので、原著を取り寄せ読んでいるうちに覚えたんです」 「正直、驚きました。しかし発音はどこで身につけられたのですか？日本に留学されてい
登壇者の自己紹介 司会者：ここからは、クロージングに入ります。クロージングは、Scrum Inc.、アヴィ・シュナイアーさま、JJ・サザーランドさま、Scrum Inc. Japan、クロエ・オニールさまによるご講演とディスカッションです。それでは、モデレーターのクロエさま、お願いいたします。みなさま、拍手でお迎えください。 （会場拍手） アヴィ・シュナイアー氏（以下、シュナイアー）：おはようございます。Agile日本！ クロエ・オニール氏（以下、オニール）：今日、アヴィが英語で登壇してくれるので、私が日本語に訳します。よろしくお願いします。 （会場拍手） 始める前に、Agile Japanのみなさんに感謝したいと思います。ここに呼んでくれてどうもありがとうございます。 コロナが明けてからみなさんが集まるのは初めてだと思います。以前、私も日本でトレーニングをしていたので、今回は見覚えのある
Shape Up: Stop Running in Circles and Ship Work that Matters
Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience. sidebar#close mouseup->tweet#update input->tweet#update keydown->tweet#update scroll@window->tweet#update" data-bookmark-id="/shapeup"> � !nkU � �nkU Shape Up Stop Running in Circles and Ship Work that Matters by Ryan Singer Buy the print edition Start reading →
「笑顔の合意」のテクニック - 噛み合わない会話と対立を克服するための、エモさを排した実践的なスキルと技法 -
2023年1月12日（木）のRegional Scrum Gathering Tokyo 2023の登壇資料になります。 このセッションでは、他者との噛み合わない会話と対立を終わらせ、相互理解や合意に辿り着けるようにするためのスキルおよび技術を、アンガーマネジメント・NVC（Nonviolent Communication）・マインドフルネスの3つの観点から、講演者自身の実践事例を含めて、「エモさ」を抜きに整理しお伝えします。 セッションの詳細は、こちらも併せてご参照ください。
この記事ははてなエンジニア Advent Calendar 20227日目の記事です。 昨日は id:utgwkk さんでした。 さて、今日はスクラムの話です。スクラムの導入とリードは自分のキャリアにおける重要な仕事のひとつで、気づけば3年ほどスクラムと取っ組み合ってきました。ここ1年くらいで、ようやく安定してテンポ良く開発が回るようになって、大仕事に一区切りついたような気持ちでいます。そうして少し肩の力が抜けた結果、最近はスクラムというフレームワークから一歩引いた位置に自分の目線が移動しつつある気がしています。自分の考えのスナップショットを取るには絶好のタイミングと思われるので、スクラムについての学びや、自分のスクラムに対する目線をまとめてみようと思います。 スクラム導入のキモ まずは、自分が経験したり見聞きした様子から、スクラム導入のキモだと思う点を2つほど書いてみます。どちらも越えが
建設的相互作用の論文を読むと「完全に理解した」を完全に理解できる。そして効果的なペアプログラミングの心得。 - freee Developers Hub
この記事はfreee Developers Advent Calendarの3日目です。 皆様こんにちは。freeeでスクラムマスターをやってます ichy こと Takeru Ichiiです。過去にアジャイル開発関連の記事を2本ほど書かせて頂いており、去年のアドベントカレンダーでは私のスクラム開発と無関係なペペロンチーノを混ぜて書かせていただきました。 developers.freee.co.jp 今年もなにか無関係なものを混ぜつつ新作を書こうかと思ったんですが、ちょっと本業が立て込んでおり、間に合いませんでした。そこで、今回は社内Blogの転載に近い形になってしまうのですが、小噺を楽しんでいただこうかと思います。なお本来であればビーフシチューのレシピを紹介しようかと思っていましたが、そのお話はまた今度させていただこうかと思います。 今回の記事の元ネタのご紹介 今回の記事は2021/10
翔泳社主催のディベロッパーの祭典「Developers Summit 2024」が2月15日ベルサール羽田空港で開催された。その年のITエンジニアが業務、趣味などでおすすめしたい技術・ビジネス書をWeb投票し顕彰する「ITエンジニア本大賞2024」の最終審査プレゼン大会と大賞の授賞式が行われ、当日会場では最終ノミネートされた書籍の著者や編集者がプレゼンを行い自著のアピールを行った。 「ITエンジニア本大賞2024」プレゼン大会ノミネートメンバー(左側から、「プロジェクトマネジメントの基本が全部わかる本」橋本将功さん、「何歳からでも結果が出る 本当の勉強法」望月俊孝さん、「チームを動かすIT英語実践マニュアル」ラファエル・ヴィアナさん、「1冊ですべて身につくJavaScript入門講座」Manaさん、「『技術書』の読書術」IPUSIRONさん、増井 敏克さん、「単体テストの考え方/使い方」マ
「Zombie Scrum Survival Guide (The Professional Scrum Series) (English Edition)」という本を発見したので読んだ感想。良い本でした。 Zombie Scrum Survival Guide (The Professional Scrum Series) (English Edition) 作者:Schartau, Johannes,Verwijs, Christiaan,Overeem, BarryAddison-Wesley ProfessionalAmazon 2022/9 追記：翻訳本が発売されるようです 表紙が興味深い ゾンビスクラムサバイバルガイド！ さて、本書は著者たちの言う「ゾンビスクラム」への対策ガイドである。アメリカ人は本当にゾンビが好きだなぁ・・・ 本書は架空の組織ゾンビスクラムレジスタンスが発行
Hiroyuki Ito2019-07-30LINE株式会社のSET（Software Engineer in Test）です。「SETタスクフォース」（以下「SETチーム」と表記）のリーダーとして、主にLINEプラットフォームのサーバーサイドで、テスト自動化を活用したプロダクト開発ライフサイクルの改善を立案・実施・主導しています。また、アジャイルコーチも兼務しています。 はじめに こんにちは。LINE株式会社のSET（Software Engineer in Test）の伊藤 宏幸（Hiroyuki Ito）です。 皆さんのチームでは、タスクの引き継ぎに際して、どのような準備をされていますか？ また、onboarding（新しいメンバーをチームに慣れさせ、成果を出せるよう導くこと）で、どのような工夫をされていますか？ さらに、チーム・メンバーの成長のために、どのような仕組みを取り入れてい
ソフトウェア開発に関わる人々の新たなきっかけを生み出す場となることを目指す「Qiita Conference」。ここで「働きやすく、成長し続けられるエンジニア組織を目指して 」をテーマに株式会社カオナビの松下氏が登壇。ここからは、CTOに就任して行った取り組みと、CTO室の設立について話します。前回はこちらから。 CTOに就任して行った3つの組織的な取り組み 松下雅和氏：ここからはCTOとして組織全体の話をしようと思います。当時「ニューノーマル時代のカオナビへ」ということで、オフィスの移転を行っています。カオナビでは、働き方を選択するのは企業ではなく、社員がするべきだと考えています。 出社は義務ではなく、自由に出社しても自宅でもいい。出社するなら居心地のいい環境を提供するのが企業の義務だと考えているので、すごくいい環境のオフィスを提供してもらった記憶があります。 働き方では、ハイブリッド勤
はじめに あなたのふりかえりを更に拡張するふりかえりカタログ（コミュニティ版）を公開いたします！ ふりかえりカタログ（コミュニティ版）は、ふりかえりの手法（現在）84個とその特徴を網羅したカタログです。下記画像はイメージです。 Miroにて作成したものをどなたでも利用可能です！ 利用はこちら => ふりかえりカタログ（コミュニティ版） 2021年1月にpdf版/speakerdeck版でリリースして以降、なんと約8万viewと、長く多くの現場にご利用いただいています。そちらを、より使いやすく、みんなで編集できる形にしたものが今回のコミュニティ版です。 過去バージョンのDLはコチラ => ふりかえりカタログ（SpeakerDeck版） ふりかえりカタログ（コミュニティ版）とは ふりかえりの様々な手法をまとめたカタログです。 ふりかえりの各手法を「手法名」「手法を使う場面」「手法のイメージ」「
デブサミ2023夏でスポンサー枠を取って「見えない壁を越えよう！アジャイルやマイクロサービスを阻む「今までのやり方」」という講演をしてきました。資料はこちら。 「アジャイルやマイクロサービス」という「これからのやり方」に取り組む時、苦労するのは「今までのやり方」とのギャップです。これは「ウォーターフォールやモノリス」との手法的な違いというよりも、その裏側にある組織やITの仕組み、さらには文化に起因するものです。 なぜなら、今までは「安定して効率的に対応し続ける」ことが正解であり、そのために仕組みを作り上げてきたからです。このような「今までの組織やITの仕組み」のままで、ただ単に「これからのやり方」に取り組んでも失敗してしまうのです。 「今まで」と「これから」のギャップ 失敗1：半島型 新しい手法を試すにあたり、これまでの仕組みとは意図的の距離を置く必要があります。そうしないと、これまでの仕
企業は製品開発や新機能の追加、収益増加に向けた戦略開発といったさまざまなプロジェクトを立ち上げており、その管理アプローチは企業ごとにさまざまです。「世界的な大手IT企業はどのようにプロジェクトを管理しているのか？」という疑問について、ソフトウェアエンジニア・マネージャーとしてSkypeやUber、Microsoftなどの大手IT企業で働いてきたGergely Orosz氏が解説しています。 How Big Tech Runs Tech Projects and the Curious Absence of Scrum - by Gergely Orosz - The Pragmatic Engineer https://newsletter.pragmaticengineer.com/p/project-management-in-tech まず、Orosz氏は100社を超えるさまざまな企
David Bernstein : Five Development Practices for Building Software with Scrum
How Big Tech Runs Tech Projects and the Curious Absence of Scrum
Project management is a topic most people have strong opinions on, and I’m no exception. To answer the question of how different companies run engineering projects, I pulled in help from across the industry. In this issue we’ll cover: Project management approaches across the industry. An overview of a survey with over 100 companies represented, plus key takeaways.Project management at Big Tech. Ho
スクラムチームで実践しているソロプロとモブプロを両立したスウォーミングの紹介 - Cybozu Inside Out | サイボウズエンジニアのブログ
みなさんこんにちは。kintone フロントエンドリアーキテクチャプロジェクト（フロリア）で、エンジニア兼スクラムマスターとして活動している村田（@kuroppe1819）です。 現在、フロリアには兼務も含めて約 30 人のメンバーが参加しています。フロリアは小さな 4 つのクロスファンクショナルチーム体制で、それぞれが独立したスクラムチームとして活動しています。 今回はその中のひとつのチームである、サイレントリリースを部分的に試みているチーム（Mira チーム）で取り組んだ、ソロプログラミング（以下、ソロプロ）とモブプログラミング（以下、モブプロ）を両立したスウォーミングの実践事例を紹介します。 スウォーミングとは？ まずはスウォーミングという言葉について説明します。 Swarming を直訳すると「群れる」です。ソフトウェア開発の文脈では 1 つの問題やタスクを皆で群がって解決するとい
最速でフロントエンドを刷新するための開発フロー - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロリアでQAエンジニアをやっている中園です。 現在サイボウズでは kintone のフロントエンドリアーキテクチャプロジェクト（フロリア）と称して、Closure Tools から React へと置き換えるプロジェクトが進行中です。 フロリアの詳細については 次の記事をご覧ください。 今回は、フロリアのチームの一つで、利用者に気づかれない形で React への置き換えを行っている Mira チーム1の開発・テストフローの紹介をします。 "最速で" React に置き換えたい Mira チームはただ React に置き換えるのではなく「最速で React に置き換える」という目標があります。 フロリアの各チームはそれぞれのチームごとにオーナーシップを持っており、チームごとに意思決定を行っています。Mira チームでは「最速で置き換える」という目標に向かって、開発スピードを向上
スクラムフェス新潟2023 アジャイルテスター視点で、ユーザーストーリーマッピングを活用した効果的なプロダクト開発 https://confengine.com/conferences/scrum-fest-niigata-2023/proposal/18346
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロダクトオーナーとしての成長：プロダクトオーナーの5つの成熟度レベル
大手ユーザー企業に入ってマネジメントでやってみたこと
スクラムは「気付いてもらう」とうまくいく、と気付いた話 - Commune Engineer Blog
アジャイルもDevOpsも費用対効果より機会損失で考える DASAアンバサダーが贈るこれからの開発現場へのアドバイス
「リリース疲れ」を解消するために「リリースレゴ」をやってみた - エス・エム・エス エンジニア テックブログ
無計画に見える計画・チーム感の欠如・とりあえずがんばる文化 “ふりかえりエバンジェリスト”が異動先で直面した組織の課題
いいチームなのにがんばりがうまく噛み合わない 誰にも嫌な思いをさせずにチームが前に進むための選択
ADOP (Application Domain Others Pattern)
SmartHRにおけるクロスファンクショナル実践例 - SmartHR Tech Blog
年配社員をリストラすれば企業は強くなるのか？ 優秀人材から解雇した八田與一の教え：朝日新聞GLOBE＋
「国民性にはアジャイル要素があるのに、ビジネス文化になると合わない日本」 多くの人に忘れられがちなトヨタ生産方式のポイント
スクラムチームを3年リードして得た学びと目線 - yigarashiのブログ
アジャイル開発向けソフトウェア開発委託契約書（準委任型） 情報処理学会
エンジニアが選ぶ2024年度「ITエンジニア本大賞」大賞に輝いたのは？
「ゾンビスクラムサバイバルガイド」読んだ飼育係の日記 - 勘と経験と読経
仕事をよりクリエイティブにするための「Learning Session」ノススメ
エンジニア組織のロール再定義、横断で動くためのCTO室設立… 組織改善にはボトムアップとトップダウンのどちらも大切
ふりかえりを更に拡張する「ふりかえりカタログ（コミュニティ版）」 - Qiita
アジャイルやマイクロサービスを阻む「今までのやり方」 - arclamp
大手IT企業はどのように社内の開発プロジェクトを管理しているのか？
アジャイル開発の時代 / Open Seminer Hiroshima 2020
User Story Mapping - Scrum Niigata