忙しい人向けダイジェストをこちらに用意しました。 https://www.agile-studio.jp/post/agile-contracts
広告技術部の石田です。 RSGT2021での学びをきっかけに、私たちのチームでは一日の業務をモビングとフラクタルという方法で行うようになりました。 しかし、ひとくちにそう言われても具体的なイメージが湧かない人も多いのではないでしょうか。 この記事では、モビングとフラクタルの二つをわかりやすく解説します。 特にフラクタルはなじみの薄い用語なので、まずフラクタルについて図を使って説明した後にモビングの解説をします。 フラクタルを図で解説 それではまずこちらの図をご覧ください。 フラクタルで過ごす一日の流れ フラクタルとは元々は幾何学の概念で、全体とそれを構成する部分が自己相似(再帰)となるものをいいます。 フラクタルスプリントは一日をひとつのスプリントに見立て、その中を同じような構造を持った小さなスプリントで構成します。 私たちのチームでは30分の短いスプリントを一日中繰り返すこと、そして最初
広告技術部の石田です。 今年もRegional Scrum Gathering Tokyo 2021が開催され、参加してきました。 そこで色々な学びがあったのですが、この記事では講演を聴いて自分たちのスクラムを大幅に変えたという話をしたいと思います。 なぜかというと、毎年RSGTに参加するとパッションが高まるというか、胸が熱くなって帰ってくるわけですが、今回はかつてないほどに「こういうことやりたい!」という気持ちになったからです。 3つの「やりたいこと」 やりたいことを挙げるとそれは3つありまして、 「やりたいことをやりたい」(やりたくないことに耐えるのではなく) 「それを成果につなげたい」(ただ勝手なことをやって自己満足ではなく) 「同僚と気持ちよく働きたい」(単なる同調や馴れ合い所帯ではなく) これらをすべて同時に叶えたいと思いました。 「体験の共有」が鍵になる そして、RSGT202
スクラムガイド2020からは、IT以外の分野にも適用してもらいたいみたいなので、ソフトウェアに特化したものはできるだけ排除する(とはいえ、なかなか難しいね) スクラムガイドでは「我々は1990年代初頭にスクラムを開発した」とあるので、まずは当時の状況を把握しておくとよさそう。おおざっぱに言うと、ソフトウェア業界的にウォーターフォールじゃダメだという雰囲気になっていて、何かいい方法がないものか……とみんなが模索していた時代。 そこで、過去の文献を遡り、当時でも使える概念が発掘された。それが、以下の竹内・野中論文である。Jeff Sutherlandはここから「スクラム」という名前を拝借しており、両名は「スクラムの祖父」と称される。 Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard
これはなに 世の中の3人~8人程度のソフトウェア / システム開発チームの多くは,俗に言う「アジャイルな開発手法」のプラクティスを実践し,1週間から1ヶ月に1度といった定期的なタイムボックスを設けてチームの開発プロセスや成果物などを対象とした「ふりかえり」をしていると思います。 そして,日本の多くの現場では,「KPT」と呼ばれる Keep (続けること) / Problem (問題になっていること) / Try (次のタイムボックスで新しく試みること) を挙げる方法による振り返りをしているのではないかと思います. 私が開発リードを務めているチームでは,KPT とは違ったフレームワークで週に1度のふりかえりを行っていて,割とうまくいっていると思っているので,それを紹介しようと思います. KPT は「チーム」のふりかえりには向かない 最近個人的に思っているのは,KPT はチームのふりかえりには
みなさんこんにちは。@ryuzeeです。 スプリントを始めるには、スプリントプランニングを実施します。 プロダクトオーナーはあらかじめプロダクトバックログの並び順を最新にしておき、プロダクトオーナーはどれを実現したいのかを提示するとともに、開発チームは実際にどれくらい実現できそうなのかを考えた上で、対象となるプロダクトバックログアイテムを選択します。その上で、選択したプロダクトバックログアイテムを実現する方法を開発チームは検討し、作業計画をたてます。 このときに考慮が必要になるのが、スプリントのキャパシティです。 キャパシティとは何かスプリント期間が1週間の場合で考えてみましょう。 1週間スプリントの場合、休日を抜くと5日間になります。その間毎日8時間働くとするとスプリント期間中の総時間数は40時間になります。 しかし、この40時間に人数をかけ合わせたものがキャパシティになるわけではもちろ
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く