タグ

関連タグで絞り込む (155)

タグの絞り込みを解除

開発に関するwata88のブックマーク (286)

  • 高度に発達したウォーターフォールはアジャイルと見分けがつかない - An Epicurean


    tl;ldr ウォーターフォールという言葉を悪口として使うのは良くないんじゃない？ 空想上の開発手法ウォーターフォールと進化したウォーターフォール アジャイル開発の説明がされるとき、アンチパターンとして﹁ウォーターフォール﹂が使われることがあります。これは﹁ダメな開発現場﹂と同義で使われており、共通仮想敵としての空想上の開発手法とも言えます。 それは、曰く、硬直化していて変化や手戻りを許さず、一本道でフィードバックサイクルがない、数十年アップデートされていない古臭い手法のことらしい。 もちろんそういう開発をしている現場もまだ数多く存在するでしょう。ただ、ウォーターフォールをカイゼンし進化させている人達もいます。そういう人たちの話を聞くと、例えば以下のような話を聞きます。 一ヶ月で1ウォーターフォールを回す 前の手順に戻る手続きが定められている 初期フェーズから開発者を巻き込む 定期的なレビ
    高度に発達したウォーターフォールはアジャイルと見分けがつかない - An Epicurean

  • 開発者イベントやコミュニティ参加についての期待や効果 - 株式会社ヘンリー エンジニアブログ


    VP of Engineeringの id:Songmu です。冒頭に、大事なお知らせですが、今週土曜日(6/22)に開催される、Kotlin Fest 2024にヘンリーはスポンサーをしています。スポンサーブースも出展しますので、是非お立ち寄りください。私もいます。 また、Henryの開発者の一人でもあり﹁Kotlin サーバーサイドプラグラミング実践開発﹂の著者でもある、 @n_takehata が、2024年版 Kotlin サーバーサイドプログラミング実践開発というタイトルで登壇します。是非こちらも聞きに来てください。 ヘンリーも社員数が増えてきたこともあり、このスポンサーを機に、イベントやコミュニティ参加に関する制度づくりを始めました。また、それらに参加する社員も増えて欲しいと思っています。そのために、改めて、社員がイベントやコミュニティに参加する意義を考え直して整理した内容が本
    開発者イベントやコミュニティ参加についての期待や効果 - 株式会社ヘンリー エンジニアブログ

  • エンジニア運用工数40%削減！Bill One における運用改善のとりくみ - Sansan Tech Blog


    Bill One Engineering Unitの田上です。運用改善と題したプロジェクトによって、エンジニアの運用工数を半年で40%削減することに成功したので、今回はその取り組みをご紹介します。 背景 Bill One のエンジニアリング組織では、フルサイクルエンジアリングで開発と運用を行っており、開発者自身が運用対応︵本番環境で発生したエラーの調査・対応、ユーザからの依頼・問い合わせの対応など︶を行っています。 エンジニアが自身の開発したプロダクトへのフィードバックを迅速かつダイレクトに受け取れる非常に良い方式ではあるのですが、その対応工数があまりにも多くなりすぎて開発工数が逼迫するようになっていました。 その状況をどうにかするため半年の期限付き特命チームとして運用改善チームを立ち上げることにしました。 立ち上げ 組織内のフラストレーションの高まりを背景に、2名のエンジニアが新たなチー
    エンジニア運用工数40%削減！Bill One における運用改善のとりくみ - Sansan Tech Blog
    wata88
    wata88 2024/06/18
    工数ってなんだろう
    リンク

  • 設計の知識と技能で駆動するソフトウェア開発

    Object Oriented Conference 2024 登壇の機会をいただいたので、ここ数年、設計について考えていることを、言語化してみました。 はじめに 設計と開発プロセスの関係性 ソフトウェア設計の知識と技能 ① ソフトウェア設計の基礎知識 a. 基本課題 b. 解決のアプローチ c. モジュール化：基本となる４つの技法 ② モジュール化 a. モジュールの分類 b. オブジェクト指向プログラミングのモジュール化 c. ドメイン駆動設計のモジュール化 ③アプリケーションのモジュール構成（参照モデル） コア（中心） ポート（境界） アダプタ（周辺） ④モデル駆動設計 全体 事業活動、要件、アーキテクチャ コア（中央） 業務ロジック、ドメインモデル 業務機能、アプリケーションサービス アダプター（周辺） 記録モデル、データベーススキーマ 連係モデル、プロトコル設計 対話モデル、イン

    設計の知識と技能で駆動するソフトウェア開発

  • 網羅的なPRDやDesign Docを書かなくなった - kosui

    2024/06/12 16:16 結論を追記 2024/06/12 20:29 より記事の内容を分かりやすく理解頂くため、タイトルを「PRDやDesign Docを書かなくなった」から変更 2024/06/13 20:39 結論にフロー情報・ストック情報に関する意見を追記 結論 この記事では、「様々な観点を考慮して網羅的にドキュメントを書いて、それを関係者にレビューしてもらう」のではなく、関係者と同期的に対話しながら、観点や選択肢やそのトレードオフを洗い出すことで、少ない手数でより良い答えが見つけられると主張する。 ただし、対話のために必要なドキュメントは事前に書いておくべきだし、対話した結果はドキュメントに残すことが望ましい。そして、そのドキュメントのフォーマットはPRDやDesign Doc以外でも良い。例えば、ADRはアーキテクチャに関する議論の過程と結果を述べる上で必要十分なフォー

    網羅的なPRDやDesign Docを書かなくなった - kosui
    wata88
    wata88 2024/06/12
    対話せよという話に尽きる
    リンク

  • カスタマーサポートだけど、開発チームに敬意が持てない


    うちの会社のシステム、ほぼ毎日いろんなバグが見つかってお客さんからクレームがきてる。 バグが直った時に、slack上では開発チームに﹁修正ありがとうございます﹂って送ってるけど、なんで自分たちが﹁ありがとうございます﹂と言っているのかよくわからない。 開発チームが品質の悪いシステムをつくって、 お客さんがバグを見つけて怒って、 カスタマーサポートがお客さんのサンドバッグになって、 開発チームがバグを直して、 カスタマーサポートが開発チームにお礼を言う。 なにかがおかしい。なんだこれ。 自分で引き起こした問題を自分で解消してなぜ感謝される構図になっているんだろうか。ただのマッチポンプじゃないか。 カスタマーサポートはお客さんをサポートするための仕事なんだよ。 不出来な開発チームのための緩衝材じゃないんだよ。 本当はサポートだけじゃなく、サクセスみたいなことも色々やっていきたいと思ってるよ。
    カスタマーサポートだけど、開発チームに敬意が持てない

  • Inside Bluesky’s Engineering Culture

    Programming note: this week, there will be no The Pulse on Thursday. I’m attending Craft Conference in Budapest, Hungary and delivering my annual conference talk the same day. My keynote is titled “What’s Old is New Again.” I’ll share the recording in the newsletter, once it will become available. I hope you enjoy this detailed deepdive on a lean and nimble startup (Bluesky) for the week! Bluesky

    Inside Bluesky’s Engineering Culture

  • Inside OpenAI: How does ChatGPT Ship So Quickly?

    👋 Hi, this is Gergely with a subscriber-only issue of the Pragmatic Engineer Newsletter. In every issue, I cover challenges at Big Tech and startups through the lens of engineering managers and senior engineers. OpenAI might be the hottest company in tech right now. The company is behind the popular large language-based model, ChatGPT, and also built the GPT-3, GPT-3.5 and GPT-4 models which seve

    Inside OpenAI: How does ChatGPT Ship So Quickly?

  • ふりかえり実践会 - BOOTH

    ふりかえりによる楽しいカイゼンをはじめましょう！（DL版）ふりかえりカタログ(¥ 0), We Love 技術同人誌～技術書界隈を盛り上げる本～(¥ 1,000), （DL版）ふりかえり実践会セット(¥ 7,500), （物理＋DL版）ふりかえり実践会セット(¥ 8,020), （冊子＋DL版）チームビルディング超実践ガイド(¥ 2,180), （電子版）チームビルディング超実践ガイド(¥ 2,000), （DL版）チームビルディングチートシート(¥ 0), （DL版）ふりかえりチートシート(¥ 0), （冊子版）ふりかえり読本 実践編～型からはじめるふりかえりの守破離～(¥ 2,680),

    ふりかえり実践会 - BOOTH

  • 顧客のBurning needsを解決する | chikathreesix


    こんにちは、@chikathreesixです。エンジニア起業家としてAutifyというAIを用いたソフトウェアテストの自動化製品を開発するスタートアップのCEOをやっています。 この記事では、BtoBスタートアップがProduct Market Fitするために必須である﹁顧客のBurning needsを解決する﹂ことについて、アメリカのアクセラレーターAlchemist Acceleratorにて学んだ経験を元に書きました。 僕らがどのように顧客のBurning needsを見つけ、Autifyという製品にたどり着いたのか、その過程と失敗について共有することで、エンジニア起業家やBtoB SaaS起業家の方々の参考となれば幸いです。 ※BtoCには当てはまらないケースもあるかもしれませんが、僕はBtoCの事は全くわからないのでご容赦ください。 弊社は2019年の1月にアメリカのトップス
    顧客のBurning needsを解決する | chikathreesix

  • 開発チーム作成ガイドを公開します - Cybozu Inside Out | サイボウズエンジニアのブログ


    こんにちは。シニアスクラムマスターの天野 @ama_ch です。 サイボウズの開発組織において、今後の成長を加速させるためには、組織の基本単位をスクラムチームのような自律的な小さなチームにしてスケールさせることが非常に大切だと考えています。サイボウズは比較的スクラムが普及している組織ではありますが、組織内のすべてのチームがスクラムを採用しているわけではありません。 フレームワークとしてスクラムを採用するかどうかはチームの自由です。しかし、健全なチーム環境を整えることはすべてのチームにとって重要です。チームやチームワークに関する情報は巷に多く存在しますが、我々のようにすでにある程度の規模で活動しているプロダクト開発組織で、チーム環境を整えるために実践的に使える情報がないことが悩みでした。 そこで、これまでのチームに関する学びと実践を踏まえ、サイボウズの開発組織の文脈において、スクラムを実践し
    開発チーム作成ガイドを公開します - Cybozu Inside Out | サイボウズエンジニアのブログ

  • メンバーレイヤーから 開発生産性向上 を始めるために - Qiita


    はじめに 開発生産性をテーマとした技術イベントに出まくった結果、ある程度体系化された知識のおすそわけ記事です。 この記事を読めばわかること 開発生産性のトピックでよく語られている前提の部分 開発生産性を語るうえで大事なざっくりとした体系的な知識 開発生産性を測るためによく使われるメトリクス 雑に言えば、数字とってデータ駆動でPDCA回そうという話です。 この記事を読んだ後に、﹁開発生産性の議論 ナンモワカラン ...。﹂という人でも﹁まずはこの辺調べてみよう﹂ができる状態になればいいなと思って書いてます。 この記事を読んでもわからないこと 開発生産性の文脈におけるビジネスサイドとのコミュニケーションらへん 開発生産性の文脈における経営層とのコミュニケーションらへん 目次 開発生産性についての前提 開発生産性と言うクソデカワードの認識をそろえる 開発生産性には3つのレベルがあることを知る な
    メンバーレイヤーから 開発生産性向上 を始めるために - Qiita

  • SPI原点回帰論：事業課題とFour Keysの結節点を見出す実践的ソフトウェアプロセス改善 / DevOpsDays Tokyo 2024

    2024年4月16日より開催された「DevOpsDays Tokyo 2024」の登壇資料です。 https://www.devopsdaystokyo.org/ ▼関連資料 テストだけで品質は上がらない?! エセ自己組織化した品質組織からの脱却 https://speakerdeck.com/visional_engineering_and_design/jasst24-tokyo 開発者体験を見える化し「計器飛行」の実現を目指すSODA構想 〜事業の成長とプロダクト組織能力の相関関係を見いだすには〜 https://speakerdeck.com/visional_engineering_and_design/developer-experience-day-2023 ファクトから始める改善アプローチ 〜「LeanとDevOpsの科学」を実践して〜 https://speakerdec

    SPI原点回帰論：事業課題とFour Keysの結節点を見出す実践的ソフトウェアプロセス改善 / DevOpsDays Tokyo 2024

  • 失敗から学ぶシステム開発委託 - CARTA TECH BLOG


    はじめに こんにちは、CARTA HOLDINGSでエンジニアをしているこんちゃん(@konchanSS)です。 この記事は筆者が新しく発足したプロジェクトのシステムを外部委託で作った経験をチームで振り返った際に得た学びを﹃システムを作らせる技術﹄によって補強したものです。 この記事を読んでくれた方は是非﹃システムを作らせる技術﹄を一読して欲しいです。 システムを知らないあなたにこそ読んでほしい この記事はビジネスサイドや、PdMだったりマネージャーといったいわゆるシステムの開発を依頼する側の人たちに向けて書いています。 意図した通りのシステムを作ってもらうための術を知ることはあなたにとって以下のメリットがあります。 意図した通りにシステムが動くことで業務の効率的になる 貴方がやろうとしているビジネスを促進させる システムを作ってもらうための術を知ることがなぜそのようなメリットを享受できる
    失敗から学ぶシステム開発委託 - CARTA TECH BLOG

  • Engineering manager archetypes.

  • Staff archetypes

    Most career ladders define a single, uniform set of expectations for Staff engineers operating within the company. Everyone benefits from clear role expectations, but career ladders are a tool that applies better against populations than people. This is particularly true for Staff-plus engineers, whose career ladders often paper over several distinct roles hidden behind a single moniker. The more

    Staff archetypes

  • デイリースクラムの進め方


    みなさんこんにちは、@ryuzeeです。 今日はデイリースクラムについて、概要や注意点を紹介します。 なお、あくまで一般論であることに注意してください。スクラムの基本は﹁透明性・検査・適応﹂です。自分たちで随時やり方を検査して、もっとうまくできるように適応していかなければ効果はあがりません。 1. デイリースクラムの目的 2. デイリースクラムの参加者 3. デイリースクラムのタイムボックス 4. デイリースクラムの事前準備 5. デイリースクラムのファシリテーション・進行 6. デイリースクラムのアンチパターン 1. デイリースクラムの目的 スクラムを利用するとき﹁フレームワークで決められているから﹂というだけの理解で進めてはいけません。これは全てのイベントに当てはまります。 スクラムのイベントはすべて、検査と適応が行われるように明確に設計されています。 デイリースクラムの最大の目的は、
    デイリースクラムの進め方

  • エラーメッセージからは、それでどうなったの？が知りたいね｜cba

    エラーメッセージには、どんなエラーが起こったかに加えて、それによってユーザーはどうなったのか？を書いておきたい アラートがとんできて自分がそのエラーメッセージを見たときには、ユーザー影響を知りたいから コードを読んで「この部分だからたぶんこうなってるね」って毎回調査するの大変だもんね ライブラリとかのエラーメッセージじゃなくて、アプリケーションロジックのエラーメッセージの話 FooBarAPIの呼び出しに失敗しました、だけじゃなくて、それによってユーザーはどうなったのか 失敗したからリトライするよ、なのか、失敗したからエラーページを表示しちゃうよ、なのか そういうのはアラートを受け取ったときに考えるんじゃなくて、コードを書くときに考えたいー！ みたいな話をしてたら、いいねってほめられた 僕がアプリケーションロジックでエラーが発生した場合のログを書くときは、だいたい↓のようなことを書くので

    エラーメッセージからは、それでどうなったの？が知りたいね｜cba

  • ARCHITECTURE.md

    ARCHITECTURE.md Feb 6, 2021 If you maintain an open-source project in the range of 10k-200k lines of code, I strongly encourage you to add an ARCHITECTURE document next to README and CONTRIBUTING. Before going into the details of why and how, I want to emphasize that this is not another “docs are good, write more docs” advice. I am pretty sloppy about documentation, and, e.g., I often use just “si

  • NeWork 開発チームが自主的な改善を行う 20%ルールを1年間運用してみて - NTT Communications Engineers' Blog

    NeWork 開発チームでは開発時間の 20%を主体的にプロダクトの改善に当てています。この取り組みの導入の背景や 1 年間運用して見えてきた良かったことや課題などをご紹介します。 目次 目次 はじめに NeWork とは 開発チーム改善活動 背景 活動内容 導入して良かったことと課題 良かったこと スプリントに積んだバックログアイテムが基本的に消化できるようになった エンジニアのモチベーション向上 インタラクションの改善もプロトタイプを通して納得感を与えられる コードの品質が上がる 課題 新機能を作った場合に他チームとの連携が難しい 新機能が放置されがち コンフリクトが起きる おわりに はじめに こんにちは。NeWork 開発チームの 2 年目エンジニアの中里です。普段はアジャイル開発エンジニアとしてフロントエンド・バックエンドを問わず、機能開発や改善を行っています。 この記事では、Ne

    NeWork 開発チームが自主的な改善を行う 20%ルールを1年間運用してみて - NTT Communications Engineers' Blog
  • 1 2 3 4 5 6 7 8 9 10 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.