20%ルールに頼らない: 技術的負債を解消する 組織的な取り組み / Developers Summit 2023 Summer2023.07.27に開催されたDevelopers Summit 2023夏の登壇資料です 登壇者：湯前 慶大(VP of Engineering)
Why do some developers at strong companies like Google consider Agile development to be nonsense?
Answer (1 of 113): Because they only have experience in "doing" agile, rather than in "being" agile. Doing agile is cargo cult, while being agile is a conscientious and disciplined application of the scientific method toward software development. Developers are very technical, but I think most fa...
「Appleのソフトウェアへの不満」はOS Xの開発方法にフェデリギの「スプリントシステム」が採用されたからではないか？という匿名の元OS X開発者の書込みが面白い。
HackerNewsは投資会社YコンビネータLLCが運営する掲示板ですが、この掲示板に投稿されたスレッド”Apple has lost the functional high ground“のコメント欄に元AppleのOS Xエンジニアと現Appleエンジニアが書き込んで意見を交わしているとTUAWなどが紹介しています（HackerNewsは匿名性なの話半分ですが）。 元AppleのOS Xエンジニアの書込みは以下の通りで、彼の意見としては「騒がれているAppleのソフトウェア（OS X）の品質の話については昔の方が悪いと思う。昔の方が良かったという方は、古いOS Xが単に古く安定していたからで、近年のOS Xに違和感を覚えているならそれはクレイグ・フェデリギが導入した”スプリントシステム”が原因で更新頻度が頻繁になったからだと思います。」というものです。 Former OS X deve
共感力が低いエンジニアのための、とあるスタートアップの現場の話
http://startuptechtalk.doorkeeper.jp/events/17559
「スクラムでは遅過ぎる」との声も。Google主催『Startup Tech Night』で聞いた、少人数で高速開発を進めるコツ - エンジニアtype | 転職type
転職・求人情報サイトのtype エンジニアtype スキル 「スクラムでは遅過ぎる」との声も。Google主催『Startup Tech Night』で聞いた、少人数で高速開発を進めるコツ 「ユーザーを中心に考え」て、「すばらしいプロダクトを作る」ことこそが、インターネットの世紀を生きる企業が行うべき最も重要なことである。良いプロダクトさえあれば、マネタイズやマーケティングの戦略もすべて後付けで立てられるからだ――。 Google会長のエリック・シュミット氏が著書『How Google Works』でこう述べるように、インターネットをベースにビジネスをする企業にとって、プロダクトを開発・発展させることこそがすべてである。ことさらスタートアップとなれば、開発・改善のスピードが大手と競争するための源泉となるだろう。 そんなスタートアップのエンジニアや、今後転職を考えるエンジニアを応援すべく、1
アジャイル開発とWF型開発をハイブリッドにしたマネジメント・デザインパターン - プログラマの思索
アジャイル開発を日本風にアレンジしたプロセスをマネジメント・デザインパターンとして説明した記事があったのでメモ。 【参考】 ウォーターフォール開発とアジャイルの本質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ 【1】WF型開発とアジャイル開発には、それぞれの特徴があり、適用の問題点がある。 WF型開発は、仕様変更に弱く、無駄なドキュメントが多い。 アジャイル開発は、変化に強く、スピード重視で開発できるが、従来のプロセス手法と発想を変えないといけないので、実現しづらい。 上記の記事によれば、各プロセスの特徴は、「WFが形式知の作成を行うことで、開発体制と開発工程を管理する手法」「(アジャイル開発は)フォーカス管理の最適化」。 つまり、WF型開発
開発ワークフローを、いつどう変えるか | GREE Engineering
こんにちは、岡崎 @watermintです。 このエントリは GREE Advent Calendar 2013の記事です。この記事は5日目の記事です。 今日はGREE Tech Talk #04 スマートフォン時代のソフトウエアテストが弊社セミナールームで行われます。岡崎は「Jenkinsによるテスト自動化の会社への導入」というパネルディスカッションに参加させていただきます。パネルディスカッションの内容がどうなるかは会場の皆様からのご質問などによって変わっていくと思いますが、今日の記事では開発ワークフローについての考えを紹介します。 開発プロセスをなぜ変えるのか 開発プロセスを変えようとするモチベーションはいくつかあると思います。組織規模、ビジネスモデルなどによって多少諸条件は違うとしても大まかには次のような目標を達成することがモチベーションになるでしょう。 開発メンバーが変わっても対応
「アジャイル」と「ウォーターフォール」 - Digital Romanticism
アジャイルがダメだと思う7つの理由へのだいぶ遅い反応 導入 もうだいぶ前の話になってしまいましたが、アジャイルに関するブログエントリ「アジャイルがダメだと思う7つの理由」は予想以上に波紋を呼び、それに呼応していくつものエントリが公開されました。発端となったエントリに関していうと、通常であれば必要となる数々の留保事項や前提事項を書かずに切り込んでいるという点において、間違いなく「煽り」であると言えます。ただ、「アジャイル」という言葉をとりまく数々の事象をかなり的確に指摘することによって、「アジャイル」という言葉をパブリックな場所で語っている少なからぬ人たちに対して、（意識的か無意識的かは問わず）ある種のポジショニングを強いたという意味で、実にいい釣り針なのではないでしょうか。 個別の論点に関する「アジャイルでは全体スケジュールにコミットできない」「いや、アジャイルだって全体スケジュールにコミ
チケット駆動開発で作業管理はしないほうがいい - arclamp
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
