*[本]「アジャイル開発の法務」: スクラムでの進め方・外部委託・偽装請負防止・ＩＰＡモデル契約とカスタマイズ - 機雷がなんだ！ 全速前進！
Agile Studioさんから書籍「アジャイル開発と法務」をプレゼントしていただきました。 books.rakuten.co.jp はじめに アジャイル開発を実践する上で、契約は悩ましい問題のひとつだと思います。 本書はIPAモデル契約策定に携わった弁護士（梅本氏）が書かれた書籍で昨年2022年11月に発売されたものです。2023年1月30日(月)に開催されたAgile Studioさんのウェビナーに参加したら幸運にも献本いただけました。ありがとうございます🙇 本の構成 本の構成は、下記のような章立てになっています。 ＜構成＞ ■第１章 アジャイル開発の紹介（P.1~30：30頁） 第１ アジャイル開発の概要 第２ アジャイル開発とウォーターフォール開発との比較 第３ プロトタイピング開発、スパイラル開発との比較 第４ アジャイル開発（スクラム）の進め方 第５ アジャイル開発を成功させ
![*[本]「アジャイル開発の法務」: スクラムでの進め方・外部委託・偽装請負防止・ＩＰＡモデル契約とカスタマイズ - 機雷がなんだ！ 全速前進！](https://cdn-ak-scissors.b.st-hatena.com/image/square/bfe6c37be686d6e1df132d92ecb42d7aa8a0edeb/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fo%2Forinbou%2F20230318%2F20230318144138.png)
僕らのモブプログラミングは「全員でプログラミングをする」ということではなかった - Mitsuyuki.Shiiba
## 去年の夏ぐらいからサポートしているチーム で、それまでもちょこちょこモブプログラミングを試してはいたんだけど、3月からは思い切ってそれを基本として開発をするようにした。つまり、3月からは1日中モブプログラミングをするのを毎日やってる。 プログラミングだけじゃなくて、設計も、運用も、テストも、全部モブでやってるので、僕らはそれをモブワークと呼んでる。 ## やっていく中で学んだのは モブプログラミング（モブワーク）は「全員でプログラミングをする」ということではなくて「全員で考えて取り組む」というだけのことだった。 サービスにとってどう動くのが良いかを全員で考える。 目の前のプロジェクトのことだけではなく、少し先を見据えてメンバー間の知識やスキルの共有や、チームがまだ詳しくない分野の学習をすることも含めて、どこにトレードオフスライダーをセットするのが良いかを全員で考える。 ## 全員でプ
半年モブプロしたらチームが大きく成長した話 - Feedforce Developer Blog
こんにちは！フィードフォースで EC Booster というプロダクトを作っている @sukechannnn です。 この記事は Feedforce Advent Calendar 2020 の 11日目の記事です。 昨日は kogai さんの 趣味の本屋を始めました でした。実際に自分でECサイトを立ち上げて運営するのって、言うは易く行うは難しですよね。すごいです。 さて、内容に入っていきます。 EC Booster チームではメイン開発をモブプログラミングで行っています！ EC Booster はEC事業者様の集客を支援するサービスで、主に Google ショッピング広告を扱っています。また、今年１１月にフリープランをリリースし、より多くのEC担当者様をご支援できるよう機能開発を進めています。 アプリケーションの構成は、フロントエンドが React + Flow (TypeScript
実験によってチームのやり方として定着してきたものを6個 - Mitsuyuki.Shiiba
この2ヶ月ぐらいサポートしてるチームで、実験を重ねる中でチームのやり方として定着してきたものがあるので、温かいうちに書いとく。6個ある。 背景 どういう背景かを簡単に： エンジニア4人とリーダー1人、プロデューサーが2人のチーム。全員家からリモートでつないでる。 サポートに入る前はチームは計画重視の指示型開発で全員別々の作業をアサインされて取り組んでいた そこに「自己組織化チームにしたいけどそういう経験者もいないしプロジェクトも忙しい中なのでサポートしてほしい」と声をかけてもらって参加 2週間くらい観察して色々周りを整えたあとにチームに入って、スクラムを導入して1週間スプリントを6回終えたところ 自分はリーダーの代わりに入らせてもらうことにした。まずはチームのやり方を色々変えてしまって、チームが落ち着いてきたら徐々にリーダーと一緒にそのリーダーならではの道を探して、最終的にはそのリーダーに
共通認識を揃えて前置きの謝罪を減らす - Konifar's ZATSU
不要な摩擦を減らすために、一言謝罪を入れてしまいそうになることがある。特にテキストコミュニケーションで多い。たとえば以下のような一言である。 「横からすみません」 「忙しいところすみませんが」 「休日にメンション失礼します」 「もう認識されていたらすみません」 「行き違いだったら申し訳ないんですが」 「自分の認識違いだったらすみません」 こういうちょっとした気遣いはとても重要で、それ自体を否定することはない。ただしやりすぎは健全ではないと思っていて、こういった謝罪による前置きは減らせるようにしていきたい。たとえば有休や育休を取る時には、ただの前置きだとしても謝罪はしない方がよいと思う。過度な気遣いは文化の形成においてマイナスに働くこともありうる。 これをどう解決するかというと、共通認識を揃えておくことが必要だと思う。 例えばSlackで「深夜にメンションすみません」という謝罪は、Slack
「職能横断チーム」の実践におけるアンチパターンと対策 - yigarashiのブログ
近年のアジャイルムーブメントにおいて「職能横断チーム」は当たり前の概念になっています。ユーザーに価値を届けるのに必要なあらゆる機能をチームが備え自律的にコントロールすることで、リードタイムを短縮するとともに、イノベーションが起こりやすい環境を作ることができます。しかしながら、7〜8人を超える大きめの集団になってくると、開発の効率を著しく下げるアンチパターンを踏んでしまうことがあります。 「職能横断チーム」の実践におけるアンチパターン そのアンチパターンとは「いつも全員一緒」です。バックエンドエンジニアだろうとアプリエンジニアだろうと、デザイナーだろうとプランナーだろうと関係なくとにかく全員です。サイロ化のカウンターとしての「職能横断チーム」に囚われ過ぎてしまって、チーム内に部分集合を作ることを極端に避けてしまっている状態です。その結果、10人もいる会を開いて細かい相談で時間が伸びたり、そも
ダメなデイリースタンドアップについて。 - Sooey
ダメなデイリースタンドアップについて。 CarbonFiveのブログにWhy Your Daily Standup Sucks (and how to fix it)といういいエントリがあったので、ポイントを簡単に訳して紹介しておきます。 詳細を話しすぎる 誰かが詳細を聞きたがったら、それはスタンドアップの後で話し合え みんな準備不足 毎日同じ時間にやることがわかっているのだから、準備をしたうえで時間通りに参加しろ スタンドアップの前に記録した作業時間、コミット、作業中のストーリーを確認しておけ 問題解決しすぎ デイリースタンドアップでは状況のアップデートだけをせよ 議論や問題解決をするときではない 合言葉は"take it offline" 障害を取り除こうとせよ スタンドアップの「あと」で障害に取り組め 誰かから「それについては力になれるよ」と聞ければ充分 ホワイトボードをスタンドアッ
「カンバン仕事術」には「始めるのをやめて，終わらせることを始める」ための実践的なアプローチが凝縮されていた - kakakakakku blog
2016年に出版されて，読もう読もうと思いつつ積読になってしまっていた「カンバン仕事術」をやっと読んだ． もう，とにかく良かった．カンバンに限らず，アジャイルな開発プロセスに興味がある人は全員読むと良いんじゃないかと思うほどオススメできる良書だった．僕が推進しているプロジェクトのメンバーに繰り返し，繰り返し説明している話（WIP，終わらせることを始める，振り返り，緊急など）も全て書かれていた．僕自身もっと早く読むべきだったし，メンバーにも読んでもらえば良かった ( ﾟдﾟ)!!! カンバン仕事術 作者: Marcus Hammarberg,Joakim Sundén,原田騎郎,安井力,吉羽龍太郎,角征典,?木正弘出版社/メーカー: オライリージャパン発売日: 2016/03/26メディア: 単行本（ソフトカバー）この商品を含むブログ (7件) を見る WIP 制限 仕掛りタスク (WIP)
自己組織化された開発チームへの踏み出し方
弊社のEureka Meetupで「自己組織化された開発チームへの踏み出し方」についてお話しました。 eureka Meetup #04 -チーム開発ナイト- - connpass https://eure.connpass.com/event/56441/
効果的なミーティングを実施するための10のルール | FICCナレッジブログ | FICC
平均的なオフィスワーカーが非生産的なミーティングに失う時間は毎月16時間。年間では5週間程と言われています。目的が不明瞭であったり、十分な対話が行われなかったり、強いイニシアティブが取られなかったり。様々な理由で参加者のリソースは無駄となり、膨大なリソースの損失が発生しています。 効果的なミーティングを円滑に実施するためには、招集者だけでなく、参加者全員の意識付けが必要です。ミーティングを行う際は以下のルールを守り、無駄なく目的を達成できるようにしましょう。 1. ミーティングの必要性を確認する 仕事に必要なのはより多くのディスカッションではなく、課題を解決するアクションです。参加者全員のリソースを一度に消費する対面でのミーティングではなく、メールで十分な場合もあります。ミーティングを招集する前に、必ずその必要性を確認しましょう。 2. 目的を定義し、アジェンダを作成する ミーティングの生
朝会は文字通り朝にやれ - 勘と経験と読経
アジャイルではないソフトウェア開発プロジェクトでも一般化しつつあるプラクティスの一つに朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム)がある。正しい読み方は知らないけれど、「ちょうかい」ではなくて「あさかい」って言うのが通例のような気がする。要は毎日プロジェクトメンバーが集まって、簡単に現在の状況や問題点を共有するショートミーティングをやるということ。時間を短く保つために立ってやるため、デイリー・スタンドアップ・ミーティングと呼ばれることもある。http://capsctrl.que.jp/kdmsnr/wiki/bliki/?ItsNotJustStandingUpの解説がお薦め。 朝会が朝会じゃなくなってしまうとき 朝会はアジャイル開発のプラクティスの一つだけど、ツールや既存の開発プロセスとも親和性が高いので導入もしやすい。日本の会社社会ではもともと朝の訓示や連絡など
デイリースタンドアップのコツ - まとめ
原文(投稿日：2010/01/30)へのリンク デイリースタンドアップを良いものにするためには、どのようなコツやテクニックがあるだろうか。ほとんどのアジャイルチームではデイリースタンドアップが実施されている。しかし、Joakim Karlsson氏は次のように言う。 「世の中のデイリースタンドアップのほとんどは、はっきり言って退屈なものです。」全員が参加を強制される単なるミーティングと化しており、ひどい時には日次に加えて伝統的な週次ミーティングにも参加しなければならないのだ Paul Wynia氏は、プロジェクトリーダがアジャイルのトレーニングを受けたこともアジャイルを経験したこともなく、デイリースタンドアップを日次進捗ミーティングとして扱った例を挙げている。 そのリーダが各参加者に対して詳細に説明させたのは、各機能、バグ、前日に行った認識合わせとこれから行う見積もりを含む作業でした。参加
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スクラム開発におけるマネジメント、目標設定・フィードバック・評価 / Management in Scrum