Re: スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている - terurouメモ
この記事を読んだ。 note.com よーある話だなと思いつつ、「業務委託はダメで、社員ならOK」という話はちょっと話が雑だなあと思ったので、コメントを書く。 スクラムチームで人の出入りが激しいとキツイ これはそう。 ただ、スクラムかによらず、出入りが激しいとキツイけど… 業務委託では、高パフォーマンス人材は単価つり上げがきつく、結果契約打ち切りになる 実際の事象としてはよくある話。ただし、業務委託のみの話ではなくて、社員でも「会社に不満があったからやめた」は良くある話。 たぶん、ここが気になるのは、このあたりの違いだとは思う。 報酬の見直し頻度 社員だと給与体系の見直しが年1回であるのが普通 業務委託だと契約期間ごと（業界慣習的に3カ月単位が多い認識） 条件交渉者が本人なのか営業なのかの違い 営業の仕事は売上を上げることなので、当然ガンガン言ってくる 対して社員が自分の雇用条件について、
Stack Overflow Developer Survey 2022
In May 2022 over 70,000 developers told us how they learn and level up, which tools they’re using, and what they want. Read the overview → Methodology → The questions we ask in our annual survey help us improve the Stack Overflow community and the platform that serves them. The challenge and opportunity for us is to continue expanding and improving our ability to help all developers and to make th
ドキュメントに固執せよ - gfnweb
どうして人間集団はこんなにも知見の共有を円滑にできないのか？ 改善にはドキュメントにまつわる各個人の心構え・制度設計・技術的解決の全部が必要だという話をしたい． ここでテーマにしているのは，著名OSSなど世の中にいくらでも知見が転がっている対象ではなく，特に企業内の十数人のチームでクローズドに開発しているなどして集合知に頼れない状況下でのドキュメントについてである． 非常に乱暴な言い方をするなら，「コードとか大部分は誰でも書けるようになるものなんよ，そんなところにマッチョイズムとか感じなくてええねん，我々の知的体力や組織性が真に試されるのはドキュメントちゃうんか」という気持ちです — 画力・博士号・油田 (@bd_gfngfn) June 3, 2022 ドキュメントに書く内容の必須項目或るシステム（ソフトウェアなど）について，そのシステムのことを全く知らない人を想定読者としたドキュメント
「1人アジャイル」から始める、アジャイル開発導入のススメ｜Agile Journeyローンチによせて - Agile Journey
みなさん、こんにちは。 ユーザベースという会社でSaaS事業のCTOを務める林 尚之です。 本日、新しいWebメディア『Agile Journey』がローンチされました。私はこのメディアに編集長として関わりますが、本稿では『Agile Journey』がどんなメディアで、なぜアジャイルをテーマとしたメディアを立ち上げたのかをお伝えしたいと思います。 『Agile Journey』はできるかぎり「実践」にフォーカスしていきたいと考えています。すでに世の中には、アジャイルに関する事柄を解説する本や資料がたくさんあり、「ペアプロってなに？」「TDDってなに？」という問いに対する基本的な解は容易に見つかるでしょう。しかし、「やり方を知る・理解する」と、「それをいかに実践するか」には別の難しさがあります。実際、私も「アジャイルをいかにして、実践するか」に関して日々、頭を悩ませていますし、試行錯誤を繰
Four Keysがなぜ重要なのか - 開発チームのパフォーマンスを改善する方法について - yigarashiのブログ
ソフトウェアエンジニアとして働き始めて以来、ずっとソフトウェアデリバリーのパフォーマンスに興味を持って、さまざまな改善活動をしてきた。当初はスクラムを中心としたプロセスの改善に注力したが、最近はチームの成熟に伴って技術的なプラクティスに興味が移りつつある。より広い視点からデリバリーについて考えるのは非常に楽しい仕事だ。 デリバリーのパフォーマンスを改善していくには、定量指標として確立されたFour Keysを計測し改善するのが業界標準となりつつある。恥ずかしながら、私はこれまでこのFour Keysが腹落ちせず、積極的に計測してこなかった。しかし、多方面に興味が向いて知識や経験が蓄積するにつれて、猛烈にFour Keysの重要性が腹落ちしてきた。この記事では、現時点における自分のFour Keysに関する理解と解釈を整理してみようと思う。 Four Keysとは Four Keysの妥当性
スクラムでベロシティを安定化するにはどうしたらよいか - 貳佰伍拾陸夜日記
このブログではあまりこういう話は書いてこなかったけど, 以前少しだけ触れたように, 僕はここ最近エンジニアリングマネージャをやっていて, こういう話題を考える機会はけっこう多い. 具体的には, エンジニアリングマネージャとして複数チームのテクノロジ/プロセス/プロダクト/ピープルのマネジメントを日々やっていて, そのうちのプロセスマネジメントとして, 各チームのスクラムマスタ的な人に助言したり, 開発プロセスの改善のためにチームが起こそうとしている変化を受け入れるようラインマネージャを説得したり, といったことにけっこう時間を割いている. スクラムに関して以下のような話を見かけて, これはまさに日々悩まされていることだった. 一言で言うと「ベロシティの安定化でみんな躓く」という話. これは僕の経験上も納得できる. この記事に寄せられたコメントを見ると, 「で, じゃあどうやってベロシティを
Increasing number of attempts ver. 2021
試行回数の増やし方 2021年度版です
Reading postmortems
I love reading postmortems. They're educational, but unlike most educational docs, they tell an entertaining story. I've spent a decent chunk of time reading postmortems at both Google and Microsoft. I haven't done any kind of formal analysis on the most common causes of bad failures (yet), but there are a handful of postmortem patterns that I keep seeing over and over again. Error Handling Proper
Scrapbox開発プロセス - 橋本商会
つまり、カッチリしたアカデミックな研究と違って常に仮説を持って物事に臨まなくてもまあ良いよという事だが、最終的に揃わなければダメです
MVP（Minimum Viable Product）の意味を理解する。そして、なぜ私はEarliest Testable / Usable / Lovableを好むのか。 | ANKR DESIGN | デザインリサーチ・プロトタイピング・サービスデザイン
数年前、私はこんな絵を書いて、アジャイル開発やリーン開発のついての様々なプレゼンで用いた。 そこから、この絵は急速に広まっていった！記事、プレゼン、さらには本（Jeff Pattonの”User Story Mapping”という素晴らしい読み物なのだが）にまで至る所で姿を見せた。多くの人がこの絵は反復型開発、リーンスタートアップ、MVP(minimum viable product)の本質をよく捉えていると伝えてくれた。しかし、元の文脈から切り離して物事を捉える際にはごく自然なことであるのだが、この絵を誤解している人がいる。簡素化しすぎだと非難する人もいる。（正しい指摘である） この絵はあくまで比喩である。実際の車の開発の話ではなく、車を比喩とした一般的なプロダクトの開発の話なのである。 とにかく、これらのバズからこの考えの背景を話す時だと判断したのだ。 １つ目の例：not like
2021年に作ったモノや技術をふりかえる - laiso
前回までのあらすじ：2020年に作ったソフトウェアや開発技術をふりかえる - laiso Write Code Every Day プログラマーの人にありがちな趣味だと思うんだけどWrite Code Every Day （John Resig - Write Code Every Day）を2008年ぐらいからやっていて、昼に仕事でコード書いて夜になったら自分の楽しみのために何か作るか〜というのを繰替えして生活してる。 John Resig の記事との違いは今読みながら比較していたんだけどGitHubに上げるっていう部分はやらなくなってしまった。クレデンシャルとかハードコードしてるやつとか半分他人のコードコピペしたやつとかの清書がめんどくさいというのがあるし、クローラーなどは自分だけが使うぶんにはいいけど公開した方が迷惑になる——みたいなジャンルのコードが結構あって段々省くようになってし
完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita
これはなにか エンジニア、ビジネスサイドの方に向けた、「良い要件定義の作り方」について書いた記事です。 長文がつらつらと書いてある本稿ですが、要するに言いたいことは、 ● 完璧な要件定義など幻想であり、誰がどう作っても不完全である ● そのため、一番危険なのは、とびきり賢い人が出してきた要件定義で、 「あの人が作ったんだから大丈夫」と盲目的に考えること ● 完璧にはならないことを受け入れ、ベストを尽くす姿勢が大事 ●そもそも、アジャイル開発において、完璧な要件定義は求められていない ●良い要件定義には以下のスタンスが必要 ● UXから逆算する ● 削ぎ落とす ● 個ではなく、チームで作る ● レビューを徹底する ● 3つのシナリオを想定する ということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれ
PR TIMESにおけるリファクタリングデー | PR TIMES 開発者ブログ
こんにちは、業務委託でPR TIMESにJOINしているuzulla (”うずら”, twitter, GitHub)です。本エントリではPR TIMESで行っているリファクタリングデーについてお話したいと思います。 リファクタリングデーとは？なぜ必要か？ PR TIMESは歴史あるサービスです。サービス・機能は追加され、削除され、結果古いコードが大量に存在します。今後もスピード感を維持しつつ成長を続けるためにはそれらの整理・改善・削除、つまりリファクタリングが重要なことはいうまでもありません。 日々の業務においてリファクタリングが行われていれば問題ありませんが、日々サービスの成長にフォーカスしていくとやはり後回しになりがちで、タイミングを失います。 その為に「リファクタリングデー」という「リファクタリング作業を定期的に実施する日」をとりきめて実施しています。現在は月に一回程度開催され、３
プロジェクトの《心配》を捕捉する | タイム・コンサルタントの日誌から
そう思っている人がどれほど多いかは、正確には知らない。いやいや、リーダーであることは、素晴らしい、ぜひ、人の上に立つべきだ。リーダーシップを発揮して、人を動かそう——わたし達の社会は、そんなメッセージに満ちている。人間は生まれつき競争心を持っているし、この世は競争原理でドライブされている。だからみんな、リーダーを目指すべきだ、リーダーの地位は喜ばしい、という事になっている。 リーダーは心配の多い仕事である。一介のエンジニアから、リーダーのポジションに上がると、自分自身の技術のこと以外に、面倒見なくてはいけないことが増える。部下や後輩や外注先の仕事ぶり、彼らの能力や勤務状況、すぐに進歩し変転していく技術の通用力、そして顧客の要求や機嫌など・・。これらを見極めた上で、WBSを決めスケジュールの線表を引き、そして費用や納期の交渉までしなくてはならない。 顧客も納期も自分の部下の顔ぶれも、自分で選
開発イテレーション偏重 - 兼雑記
開発イテレーションを早くすれば、かなりの問題が勝手に解決される、と信じています。なんか最近、他の要素を軽視しすぎていたり、特にイテレーション速度に影響しなさそうなことすらしている気がしていて、信仰とかのレベルかもしれない、という気がしてきたので、ちょっと書いてみようかなと。主に C++ の話です。 仕事とかしてると良い判断力が求められたりしますが、判断というのは結構難しいですよね。アプローチ A と B で悩んだ時に、手が速ければ両方できたりします。開発イテレーションを無限に速くすると、必要とされる判断力はゼロに漸近していきます。やったね。 2手で変更の正当性を高速に確認できるようにする make (かその他のビルドコマンド)てやったらビルドができて、 make check (かその他のテストスクリプト)てやったら遅くないテストが全部走る、という体勢が好きです。試すためにはあっちのディレク
高頻度は問題を容易にする - Martin Fowler's Bliki (ja)
https://martinfowler.com/bliki/FrequencyReducesDifficulty.html 私が気に入っている引用の一つに「もしそれが痛みを伴うのであれば、さらに頻繁にそれを行え」という引用がある。 この言葉は、表面的には馬鹿げたことに見えるという幸せな性質も持っているが、深く探れば価値のあることがわかる。 このことを説明するための例示できる文脈は、統合だ。 ほとんどのプログラマーは、自分の仕事を他の人と統合することは苛立たしくてつらい経験であることを早い段階で学ぶ。 そのため、自然な人間の反応として、できるだけ統合を先延ばしにしようとする。 上記グラフのように、その行動を起こすまでにかかる時間と、その行動に伴う痛みに指数関数的な関係がある場合、その行動をより頻繁に行うと、痛みを大幅に軽減できる。 そして、これが継続的インテグレーションで起こることだ。毎日
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発組織の持続可能性について
強くてニューゲームなプロダクト開発 / Product development in new game plus
【IMO】コードレビューって難しいよね.pdf
自由と責任を開発チームにもたらしたら開発速度が上がった話
