なぜ我々は筑波大を便利にすることができなかったのか？ - いなにわうどん
早いもので筑波に来て 3 度目の春を迎えます。2 年前の春を憶えていますか。 筑波大学を便利にするサークルが爆誕 元々は大学の KdB と呼ばれる開設科目データベースがダウンし、その代替サイト「KdB もどき」を作成したことに端を発します*1。懐かしいですね。 ミラーを立ち上げただけと言えばそうなのですが、新入生が大学をディスりながらシステム開発！みたいな構図が予想以上にウケたっぽく、Twitter がバズったりメディアに取り上げられたりしている間にサークルを新設する流れになりました*2。 togetter.com 筑波大には学生が開発した数多のサービスやアプリケーションが存在しますが、その多くは個人レベルで開発が行われているため、開発者が大学を離籍するとシステムが保守されなくなる傾向にあります*3。そこで、筑波大学の学生生活を便利にする各種サービスを総括的に管理・保守することで持続可能な
アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント - forest book
www.shoeisha.co.jp 最近、開発方法論や組織論に関心をもっています。2020年改訂スクラムガイド を読んだり、実際に業務でもスクラムを実践している開発チームで働いています。しかし、まだスクラム開発者として働き始めて2ヶ月なので新人です。これまで私はスクラムを実践している開発チームで働いたことがなく、いま初めてスクラムチームで開発者として実践しています。とはいえ、チケット駆動開発 + イテレーション開発 は10年以上実践してきており、厳密な定義では正しくないかもしれませんが、広義ではアジャイル開発という枠組みで開発を実践してきたと私の中では捉えています。そして、私の周りでうまくまわっていないスクラム開発をみかける度にチケット駆動 + イテレーション開発でうまくいくのになぜスクラムのような効率の悪い開発をしているのか？とすら内心では思っていました。 本書を読み終えて、結論から言
「雑に立てられるissue」で疲弊しないためにOSS開発者ができること - 2021-12-04 - ククログ
要約：OSS開発プロジェクト運営者の側でとれる対策はいくつかあるよ。issueは基準を設けてどんどん閉じてしまおう。GitHubならActionsで自動化も簡単だよ。自動テストを整備するように、必要なコストだと思って割り切るといいよ。 結城です。 GitHub Actionsに関することならなんでもありらしいアドベントカレンダーとのことでしたので、ほんのちょっとかすっているだけではありますが、4日目にエントリーさせて頂きます。 「軽率に寄せられる報告や要望がOSS開発者を疲弊させる」という問題について語るOSS開発者は少なくないです。私の観測範囲内では最近も、イシュートラッカーにissueを立てようとすること自体に待ったをかける記事1や、「要望には初手で『なぜ自分で実装しない？』と訊ね、次に『継続的にメンテナンスしてくれるの？』と訊ねるドライな対応がおすすめ」という趣旨に受け取れる発言など
［CEDEC 2017］「ゼルダの伝説BotW」の完璧なゲーム世界は，任天堂の開発スタイルが変わったからこそ生まれた
［CEDEC 2017］「ゼルダの伝説BotW」の完璧なゲーム世界は，任天堂の開発スタイルが変わったからこそ生まれた ライター：西川善司 CEDEC 2017は，任天堂からの登壇者が例年に比べて非常に多い。数えてみると8件あった。「海外のカンファレンスでは登壇する一方，日本国内のカンファレンスにはあまり出てこない」という，これまでの傾向からは一転した新しい動向と言える。「ゲーム開発シーンにおける知見の共有」において，これまであまり積極的でなかった任天堂だが，意識を変えてきたのだろうか。 いずれにせよ，CEDEC 2017で任天堂は，「ゼルダの伝説 ブレス オブ ザ ワイルド」（Nintendo Switch / Wii U，以下，ゼルダの伝説BotW）関連セッションを4本も持った。今回はその中から，開発者でない一般のゲーマーにも分かりやすかったと思われる「『ゼルダの伝説 ブレス オブ ザ
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
開発現場で一度は耳にする「何で聞いてくれなかったの！？」なんて台詞は二度と聞きたく無い。 - ぐらめぬ・ぜぷつぇんのはてダ(2007 to 2011)
異なる二種類以上の開発現場で、ほぼ同様の条件で題名の「何で聞いてくれなかったの！？」という台詞がマネージャ/リーダから発せられるのを確認した。 ソフトウェアの開発現場で受託・内製問わない（両方の開発現場で確認）。ある担当者にアサインしたソフトウェアコンポーネントが（１）完成した後バグが発覚し、マネージャ/リーダが感知していない作りや設計になっていた、（２）〆切に近づいているが仕上がる感じが無く、確認してみたところ実装上の問題に嵌っていたりマネージャ/リーダが予測できないトリッキーなor複雑な設計orコードになっていた。 そのような場合に、「何でもっと早く相談してくれなかったんだ・・・」というマネージャ/リーダの無念の思いが込められ、「何で聞いてくれなかったの！？」という台詞が担当者に降りかかる。 最初に結論、というかリーダ/マネージャに対する「お願い」になってしまうが、離れ小島的にやけに静
エンジニアによる技術革新を妨害するのはエンジニア:Geekなぺーじ
エンジニアによる技術革新に対する大きな障害は、非エンジニアではなくエンジニアであるという場合もあります。 技術者やエンジニアは、新しい発想に対して無駄にネガティブな意見を連発したり、単なる抵抗勢力でしか無くなる瞬間もあるような気がしています。 例えば、熟練度が高いエンジニアほど新しいものよりも、枯れたものを好む傾向があるような気がします。 以下、エンジニアによる抵抗勢力的発言としてありそうなものを考えてみました。 なお、フィクションなのでご注意下さい。 (自分が過去にやって「あれは自分が間違っていた」と思ったことが一部含まれたりしているわけではないのでご注意下さい。そんなことはありません。) 1.「先行事例が既にあるよ」 ちょっとでも似たようなものがあれば「先行事例があるから無駄」という意見を言う人がいます。 「このような先行事例がある」というアドバイスは非常にありがたいのですが、「やるの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ruby、jQueryなどの廃れていくOSSを開発している人達はどういう気持ちで日々それらを開発しているんですか？
Agile 2016の基調講演: モダンアジャイル