本に書いてあるスクラムと、お前らのいうスクラム開発は別物だということにいい加減気づいてくれ
前振り タイトルは煽りの激しい釣りです。ごめんなさい。 Web業界で今流行っている自称スクラムと、RSGTで語られるような本来のスクラムとの間のギャップが大きすぎて説明が面倒臭くなったのでこの記事を書きました。 いい加減「私たちは自称スクラム開発を完璧に回しているから、スクラムの恩恵を将来得られるだろう」「私たちは本来のスクラムとはかけ離れた別物のスタイルで開発をしている。だからスクラムの恩恵は永遠に得られない」という二重思考を他人にするようお願いするのにも飽きましたしね。 さて本題といきましょう 本題 世間で、特に渋谷や五反田や六本木のWeb企業ではスクラムというものはとても流行っています。 しかしどう考えても、Web企業でよくお目にかかるスクラムと国内トップカンファレンスであるRSGTで語られるスクラムとの間には大きな隔たりがあります。 「うちはスクラムやってます」 カジュアル面談で耳
ブラックボックスになりがちな開発チームの内部状況を指標を用いて可視化する｜mtx2s
自社ソフトウェアプロダクトを内製する組織であっても、開発チームがそれをどうやって作り上げているか、開発者ら以外にとってはブラックボックスであり、不可視です。それだけに、開発チームのパフォーマンスや内部状況の良し悪しは、各々の主観や興味によって、不統一な認識を持ってしまうことも多いでしょう。そしてそのような認識のばらつきは、開発する当人たちにとっても実は同じです。 しかし、例えブラックボックスであっても、自動車のダッシュボードのように様々な指標によってその内部が数値化され、可視化されていれば、チームのパフォーマンスに統一的な認識を持たせやすくなります。 本記事では、どのような指標を可視化すべきか、その代表的なものについて取り上げます。 リードタイム（開発、製造）リードタイムは、開発項目ごとの作業期間を計測したもので、短いほど優れていることを示す指標です。計測対象となるプロセス全体を「開発」と
ブルシットプロダクトからチームを守れ! ｢顧客が本当に必要だったもの｣を追求するプロダクトマネジメントを実現するぞ
ユーザーから見て、ただひどいだけでなく、開発したり販売する人たち自身がプロダクトに価値がないと感じており、また買ってもらうことに罪悪感を感じるようなプロダクトやサービスをブルシットプロダクトと呼びましょう。 ブルシットプロダクトとは何か、どのようにして生まれるのか、なにをすれば解消されるのか、顧客が「顧客が本当に必要だったもの」を実現しつづけるプロダクト組織に向けて、組織システムの成長の観点からお話しします。 Regional Scrum Gathering Tokyo 2022 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16109 発表者 https://twitter.com/_N_A_ https://note.com/mryy/n/n6f01561a6253
属人化を排除した結果、「あなたはいてもいなくても同じ」と部下に言われた。 - Everything you've ever Dreamed
僕は食品会社の営業部長、自分で言うのもなんだが部下に慕われている部長と自負している。その証拠に、先日、休みを取ろうとしたら、部下の一人が気を使ったのだろうね、「いてもいなくても同じですから休んでください」と言われた。一瞬、思うところはあったけれども、ポジティブシンキングで目指していた自由に発言できる風通しのいい組織の証明ととらえた。実際、営業部を今の体制に変えたのは僕なのである。 ４年前、僕は中途入社した。それまでの経験から案件の発掘から成約まで一人でやりきってしまう営業マンを揃える営業組織に限界と疑問を感じていて、意見を同じくする社長のもとで、これまで組織を変えてきたのだ。ホークアイで見込み客を見つけ、マジカルトークで有力案件に育て、ミラクルな企画提案で契約を取るスーパーな営業マンを僕は否定しない。でもスーパーマンに依存した仕事のありようは組織としては正しくない。スーパーマンが退職したと
組織のなかで働く技術 - やしお
会社には専門分野の技術とは別に、組織の中で働くための一般的な技術がたくさんある。学校で体系的に教えてもらうものじゃないから会社に入って身に着けていく。僕自身もう会社に入って8年半になるからずいぶん知見が溜まってきた。後輩や新人がその習得に自分と同じ時間をかけるのはもったいない。一度全体を整理しておきたいと思っていた。 それで書いてみたら長くなって、3分の2に圧縮したけどまだ長いのであらすじだけ先に書いておく↓ 働く上でいろいろな制約が存在していて、その制約に対抗する手段としていろいろな技術がある。この制約-手段のつながりを見ず単に結果としての技術だけを覚えても応用がきかないし身につかない。この技術にはレベルがあって、このレベルがちぐはぐだと上手くいかない。 「能力と時間」、「ルール」、「他人の感情」、「自分の感情」、「人間の生理」という5つの制約について「制約→技術」を展開していく。最後に
新メンバーが多い大型プロジェクトでの不確実性との戦い方 - スタディサプリ Product Team Blog
ペアプロ・モブプロ、スキルマップ、1-on-1等々… チーム開発にまつわる各論・方法論・話題をよく見る昨今、関心の高まりは歓迎さるべきことながら つまるところそれらが現実のどのような問題を解決していくのか？ どのように相互作用するのか？ これらが有機的に結びつくことで現実のどのような問題を解決していくか？ こうした疑問に答えたり、具体例とともに記した記事はさほど多くないのではと思います。 本記事では昨年度に筆者のチームが約7ヶ月携わったプロジェクトにて、プロジェクト特性に起因する不確実性と我々がいかに戦ったかを記します。チーム開発を行う方にとってこの記事が実りあるケーススタディとなれば幸いです。*1 なお、本記事では以下のことは本旨とは逸れるため割愛させていただきます。 プロジェクトの機能的側面 技術的不確実性 各取り組み単体の詳細 はじめに / プロジェクトの雰囲気を伝える図 この記事で
なぜ、マネジメントが重要なのか？ 米Microsoftで働く日本人エンジニアが語る、“楽しく開発”するために必要なこと - Part3
2018年1月11日から13日の3日間、第8回目となるRegional Scrum Gathering® Tokyoが開催されました。スクラムの初心者からエキスパート、ユーザー企業から開発企業まで、立場の異なる様々な人々が集まる学びの場である本イベント。世界中からスクラム開発におけるエキスパートたちが一堂に会し、最新の情報や自身の知見を惜しげもなく語ります。2日目のKeynote「敢えて属人化せよ！ エキスパートの集団こそが最強のチーム」に登壇したのは、Microsoft本社で活躍するエンジニア、河野通宗氏。日本からアメリカへと移った中で感じたカルチャーショックと、その開発環境について語ります。 ハッカソンがエンジニアにもたらすもの 河野通宗氏（以下、河野）：では、話の続きをやります。（スライドを指して）ハッカソンの力って書いてあるんですけど、ハッカソンって、みなさんどういうイメージを
『開発基盤チームとして課題を探したらマネジメントをしていた』という発表をした - Feedforce Developer Blog
こんにちは。増田（id:masutaka26）です。発表が無事終わり、何かゲームでも買おうかなと思ってます。 さて、フィードフォースでは毎週金曜日 16:00 から、社内技術勉強会を開催しています。当番制の持ち回りで技術に関連したことを発表します。 先週金曜日は私の当番で『開発基盤チームとして課題を探したらマネジメントをしていた』という発表をしました。 技術チーム以外の方もたくさん聞きに来てくれて、ありがたかったです。🙏 発表の内容 前回含めて、これまでの発表は全てコードが登場していました。今回のようなコードが登場しないマネジメントの話は、内容が拡散しがちで難しかったです。結局まとまりませんでした...。 今回は敢えて後から読めるプレゼン資料にしました。なのでプレゼン資料としては冗長な書き方になっています。 まとめるとこんな内容です。 コミュニケーションの不確実性を解消することが、マネジ
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
Developers summit 2017の 【16-B-7】セッションのスライドです。Read less
チーム力向上のためのエトセトラ - Qiita
この半年間、久しぶりに開発チームのマネージャ的な立場もやることになったので、「ふつうの受託開発チームのつくりかた」以来、工夫したことをまとめておきます。「ふつうの受託開発チームのつくりかた」未見のかたはぜひそちらも見てみてください! チームに名前を付ける 私の受け持つチームは伝統的に「ラスカル」の名を付けるようにし、チームのアイデンティティを保つようにしています。チームメンバも本当は出来るだけ長く担当してもらいたいのですが、大きなSIerだとそれが難しいこともあります。 通常のプロジェクトチームだと、サブシステム名くらいで呼ばれることでしょう。これは、そのプロジェクトが終わったらチームも終わり、で帰る場所も無くなることを意味しますし、愛着をもって働くことは難しくなります。 メンバが多少入れ替わっても、チームは継続する"モーニング娘。方式"であれば、またいつか戻ってくることもできるし、OBと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オープンソースのベストプラクティスを企業内で実践/How to implement InnerSource
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
チームとプロダクトをぶっ壊した話