アジャイルでも、ウォーターフォールでもない。リクルートの新決済システムは「異色のコラボ」で作られた - はてなニュース
アジャイル・スクラム開発とウォーターフォール開発──開発手法を巡ってしばしば対立項に置かれるこの二つのスタイルは、考え方はもちろん、段取りやマネジメントの方法もまるで異なります。そんな全く異なるスタイルをとる二つのチームがコラボレーションし、開発プロジェクトを推進していくことは現実的に可能なのでしょうか？ そんなコラボレーションを、決済というミッションクリティカルな領域で実現し、新たなシステムのリリースにこぎ着けた実例がリクルートにはあります。 英語や英会話の学習を支援する『スタディサプリENGLISH（以下、スタサプENGLISH）』では、今や主流となりつつあるサブスクリプションモデルに決済システムが対応できていないという課題がありました。そこで、決済・金融関連のシステムを開発するチームと共同で、新たな決済システムの開発に取り組みました。 『スタサプENGLISH』のチームは、内製の開発
「スクラムマスターがいることでどんな利益があるの？」と言われた時点で専任のスクラムマスターは不要なのかもしれない。でもその先の話がしたい。
「スクラムマスターがいることでどんな利益があるの？」と言われた時点で専任のスクラムマスターは不要なのかもしれない。でもその先の話がしたい。 はじめに 「スクラムマスターがいることでどんな利益がなるの？」 スクラムマスターをやっていると時々この質問を受けることがあります。 スクラムを始めたばかりのチームや組織はもちろん、広報BLOGに「専任のスクラムマスターをおくことにこだわってます。」とCTOが書いているような企業の中にいても こうした問いかけを受ける事があります。 この記事では私が実際にこの問いかけを受けてから、ずーと考えていたことを、なるべく整理してまとめています。それでも雑な文章になっていること、そして個人的な見解でしかない事はご承知おき頂けますと幸いです。 この記事の概要 この記事をまとめるこんな感じです！ 「スクラムマスターがいる事でどんな利益になる？」と言われたら信頼されていな
現職と前職で感じたスクラムの違い - Qiita
はじめに 今の会社に転職してきて２ヶ月が経ち、まだまだ分からないことも多いですが少しずつ環境にも慣れてきたので頭の中を整理するためにも今感じていることをアウトプットしたいなと思い書きました！ 現在、私が参画しているチームはスクラムをベースとして開発を行なっており、前職もスクラムでの開発を経験していたので、その違いを整理していきます。 前職 スクラムを導入するまでの背景 前職では、美容医療・精神科クリニックを運営している会社で、クリニックスタッフが使用する社内システムの開発に携わっていました。働き方としてはフル出社になります。 チーム構成は以下で、私はメンバーでした。 チーム構成（7名） ディレクター(PM) 1名 リーダー 1名 アーキテクト 1名 メンバー 4名 はじめからスクラムを導入していた訳ではありませんでした。 開発の流れとしては、クリニックスタッフまたは関係者からディレクター（
スクラムガイドに載っていないスクラムのはじめかた - チームでスクラムをはじめるときに知っておきたい5個のコツ - / How to start Scrum that is not written in the Scrum Guide
Scrum Fest Fukuoka 2024にて。 https://confengine.com/conferences/scrum-fest-fukuoka-2024/proposal/19555/5 プロフィールやお問い合わせはこちらからどうぞ！ https://agile-monster.com/profile/ https://agile-monster.com/contact/
大学のアジャイル教育に奮闘した10年からの学び─短期の集中授業でアジャイルをどう実践するか？ - Agile Journey
ソフトウェア開発において、アジャイルという考え方はかなり浸透しています。多く出版物やWebコンテンツ、さまざまなコミュニティやセミナーが存在し、アジャイルの情報には触れやすい状況になってきました。一方で企業においてアジャイルを導入しようとする際に開発チームのどこを変えるべきか、組織固有のルールとどう折り合いを付けるかなどに頭を悩ませる方も多いでしょう。 『SCRUM BOOT CAMP THE BOOK』などの著作で知られ、アジャイルコーチとして企業の組織づくりを支援する永瀬美穂（@miholovesq）さんは、これまで複数の大学で授業におけるアジャイル導入も支援し、その成果を発表する「Agile PBL祭り」を主催してきました。永瀬さんによると、学生は前提知識もないところからソフトウェア開発を学ぶため、社会人エンジニアより自然とアジャイルに取り組める面もあるそうです。 大学はなぜ教育にア
Driving Value with Sprint Goals - Qiita
『Driving Value with Sprint Goals』は、スクラムのスプリントゴールに絞ってまるまる1冊書かれた本です。 不確実性とプランニング 第1章では非常に重要なことが述べられています。「手前の霧」と不確実性を霧というメタファーで表現していますが、ソフトウェア開発においても霧に覆われた状況に置かれることがままあります。この時に本物の霧に対してはやらないのに、何故かソフトウェア開発では、霧が存在しないかのように振る舞ったり、霧を取り除こうと考えたり分析したりできると信じたりしてしまうことがある、と指摘しています。実際に目前を霧に覆われた状況に置かれたら、計画を立てるよりも、慎重に進んでみて新しく明らかになった情報を元に次の行動を判断する。それを繰り返すはずだ、と。これは非常に秀逸な喩えだと思いました。 不確実性や複雑性に遭遇したときに、人はそこに解決策があると考えるために、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
