Re: スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている - terurouメモ
この記事を読んだ。 note.com よーある話だなと思いつつ、「業務委託はダメで、社員ならOK」という話はちょっと話が雑だなあと思ったので、コメントを書く。 スクラムチームで人の出入りが激しいとキツイ これはそう。 ただ、スクラムかによらず、出入りが激しいとキツイけど… 業務委託では、高パフォーマンス人材は単価つり上げがきつく、結果契約打ち切りになる 実際の事象としてはよくある話。ただし、業務委託のみの話ではなくて、社員でも「会社に不満があったからやめた」は良くある話。 たぶん、ここが気になるのは、このあたりの違いだとは思う。 報酬の見直し頻度 社員だと給与体系の見直しが年1回であるのが普通 業務委託だと契約期間ごと（業界慣習的に3カ月単位が多い認識） 条件交渉者が本人なのか営業なのかの違い 営業の仕事は売上を上げることなので、当然ガンガン言ってくる 対して社員が自分の雇用条件について、
開発速度が速い #とは（LayerX社内資料）
Cloud Festa 2021 Winter 「デザイナー、データサイエンティスト、 クラウドエンジニア、で実現する共創の世界」 Tsuyoshi Hirayama
質とスピード（2022春版、質疑応答用資料付き） / Quality and Speed 2022 Spring Edition
質とスピード（2022春版、質疑応答用資料付き）
自社開発×アジャイルだからこそ、「スケジュールを決めない」 “組織全体で分担する”プロジェクトマネジメントの考え方
登壇者の自己紹介 南里勇気氏（以下、南里）：登壇者の自己紹介を進めたいので、登壇者の方々に上がってもらいます。本日はよろしくお願いします。 野田克樹氏（以下、野田）：お願いします。 鈴木伸緒氏（以下、鈴木）：お願いします。 坪田朋氏（以下、坪田）：お願いします。 南里：司会のフードテックキャピタルCTOの南里勇気と申します。よろしくお願いします。ふだんはエンジニア・経営者としていろいろやっていますが、今回のテーマはPM×デザインで、もの作りの観点から登壇者の方々にいろいろ聞きたいと思うので、よろしくお願いします。それではdely株式会社の坪田さん、紹介をお願いします。 坪田：今回はCXOというタイトルで「クラシル」を運営するdely株式会社でクラシルの開発責任者としてサービスの方針を決めたり、意思決定しています。 僕自身はデザインを軸としていろいろな事業を作ったり、会社を作ってそれが丸ごと
Web系企業/事業会社への最高の反面教師: "Spotify's Failed #SquadGoals"を読んで - アジャイルコーチの備忘録
はじめに 以前Scrum@Scaleについて@tyantya41717651さん、@zakky_devさんとディスカッションしましたが、先日お二人と、大規模アジャイルフレームワークであるSpotifyモデルと先日公開された失敗記事(「Spotifyは "Spotifyモデル "を使っていない(Spotify's Failed #SquadGoals)」)についてディスカッションしたのでブログにまとめました。*1 はじめに Spotifyモデルと取り上げた理由 モデルの失敗ではなく、ヒトの失敗 扱える以上の自由や権限を与えた悲劇 1. チームへの過剰な権限付与による、サイロ化の加速 2. 分隊のプロセスの自由さや能力不足による、分隊間協力の困難化 3. 全員での意思決定を追求したことによる、意思決定コストの増大 まとめ Spotifyモデルと取り上げた理由 今回Spotifyモデルの詳しい解
ペアプロを極めて最強の開発チームをつくる（1/4）ペアの組み方（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: On Pair Programming 原文公開日: 2020/01/15 著者: Birgitta Böckeler -- ドイツのThoughtWorks社で開発とコンサルティングを担当しています。カスタムソフトウェアチームのテックリードとして日々を「コーディングの日」「コーチングの日」「コンサルティングの日」「仕事を楽しく続ける日」に分けています。 著者: Nina Siessegger -- ドイツのハンブルグ出身の開発者/テックリード/コンサルタント。元ThoughtWorks。コーディングの楽しさ以外に、特にソフトウェア開発の人間的な側面にも強い関心を抱き、高品質ソフトウェアは「コミュニケーション」「共同作業」「信頼関係」を重んじるチームによって成し遂げられると強く信じています。 サイト: martinfowler.c
「プロエンジニアになるための「アジャイル開発」再入門」が素晴らしい - プログラマの思索
倉貫さんの資料プロエンジニアになるための「アジャイル開発」再入門が素晴らしいのでリンクしておく。 新入社員向けのアジャイル研修の資料は、これを使えば十分ではないかな、と思った。 以下はラフなメモ書き。 【研修資料】 【参考】 アジャイル開発とウォーターフォール型開発の違いについて再考: プログラマの思索 アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノート アジャイル開発の本質 ? アジャイルとウォーターフォールの違いとは | Social Change! ソフトウェアは完成しても価値はない ? アジャイル開発は何を解決するのか | Social Change! アジャイル開発とは：「アジャイル開発」をエグゼクティブサマリにまとめてみた | Social Change! ドキュメントをなくしてもうまくいく？ ? 人に依存するリスクへの対処とは
コーディングもテストも持ち回りな新プログラミング手法「モブプログラミング」とは何か――本場 Hunter社に学ぶ
役割分担ではなく協働作業という考え方 プログラミング、コーディングというと、ともすると優秀なスーパーエンジニアが一人で設計、コーディング、デバッグまで進めるという、属人的な作業というイメージがある。大規模プロジェクトでも、プログラマーやエンジニアにはモジュールごとの開発を担当することが多い。それをグループの協働作業でひとつのプログラムを完成させるというのだが、果たしてうまくいくのだろうか。 実は、クリエイティブの場でもこのような協働作業を取り入れる動きがある。ハリウッド映画だ。映画のストーリーや脚本を決めるのに、脚本家や監督、企画系のスタッフらが集まりミーティングをしながら展開を決定していくスタイルが一部で広がっている。クリエイティブと相反するような取り組みだが、読めない展開、多様な登場人物とそれぞれが持つ設定が重層的にからみあうストーリーが可能になる。 映画におけるこの協働作業が、必ずう
続・拝啓『変わらない開発現場』を嘆く皆様へ ～ ウォータフォール ＆ アジャイル編～ – とあるコンサルタントのつぶやき
とあるコンサルタントのつぶやき とあるコンサルタントのつぶやき MCS （Microsoft Consulting Services） の某コンサルタントがまったり語るテクノロジのお話です。 ご存知の方も多いと思いますが、ここ最近、うちの会社の歌って踊れる DevOps エバの牛尾さんが、こんなエントリを書かれていました。 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い http://simplearchitect.hatenablog.com/entry/2016/06/20/080807 「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない http://simplearchitect.hatenablog.com/entry/2016/06/24/080049 特に前者は炎上気味でしたが；、二回分のエントリを通して読めば、牛尾さんが言いたい
最近の開発フローの改善と、「スプリントおじさん」という取り組み - しるろぐ
ここ最近、自分が見ているプロジェクトの1つで、うまくスケジュール通りに作業が進んでいなかったので、その対策をした。 その中でも特に効果があった2つを紹介する。 背景 簡単にプロジェクトの背景を説明する。 スクラムっぽい開発をしている スプリントの期間は2週間 スクラムマスターはいるが専任ではない すでにリリース済みで運用中のWebサービスである 基本的によくあるスクラムっぽい感じで、2週間というタイムボックスの中にチームが作業可能なストーリーを突っ込んで、ひたすら消化する。 スプリントの最後には、レビューをして、次のスプリントの計画を立てる。 スクラムマスターは、一応自分が担当しているが、専任ではないし、他のプロジェクトも見ているので、注意深くチームを見れていない。 課題 以下のような課題があった。 バグの修正や問い合わせ対応など、計画時に含まれていなかったタスクがスプリント中に増えてしま
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
要はアジャイルは行き当たりばったりってことですか？