タグ

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

タグの絞り込みを解除

agileに関するradiocatのブックマーク (12)

  • 西島カーブ - 戦艦大和を作った西島技術大佐 - kawaguti’s diary


    先週末はオープンセミナー広島さんにお邪魔してお話させていただきました。資料は下のものです。資料冒頭で﹁西島カーブ﹂の話をしました。 osh-web.github.io speakerdeck.com 前日に観光に行った呉市の大和ミュージアムで、呉の海軍工廠の成り立ちから戦闘艦を国内生産する話を勉強しまして。そこで科学的管理法が連呼されてて、なんだろうと思って調べたわけです。 yamato-museum.com そうしたら、西島技術大佐の﹁西島カーブ﹂というのにたどり着きまして。 http://hesaka.sakura.ne.jp/nishizima.html もう10数年前に前間孝則の﹁戦艦大和誕生﹂を読んでいた時、主人公であるところの西島亮二が呉工廠で工程管理を行うために生み出された﹁西島カーブ﹂なるものが出てきた。しかしこの工程管理手法についての説明は概略のみであり、また造船所勤めと
    西島カーブ - 戦艦大和を作った西島技術大佐 - kawaguti’s diary
    radiocat
    radiocat 2020/02/15
    戦艦大和誕生は個人的に技術者のバイブルと思えるほど大好きな本なんだけど、何年か前に昇格面接で最近読んだ印象に残っている本を聞かれてこの本を答えたら戦艦趣味の話と思われたらしく経営陣にポカーンとされた。
    リンク

  • #51 野中先生の vibes @ #ScrumInteraction2019 | #omoiyarifm

    radiocat
    radiocat 2019/12/22
    ナレッジオーナーを作る案があったというのは興味深い。
    リンク

  • 【資料公開】レガシーコードからの脱却


    みなさんこんにちは。@ryuzeeです。 2019年10月4日に行われたAWS DevDayの﹁レガシーコードからの脱却﹂のセッション資料を公開します。 内容は、9月に発売になった同名書籍﹃レガシーコードからの脱却﹄の全体像と一部のプラクティスの紹介という形になっています。 時間の関係で紹介できたのはごく一部の内容になっていますので、スライドを見て内容に興味をお持ち頂いた方はぜひ書籍をお読み頂ければと思います。 なお、現在Amazonの在庫が高額な値付けの転売商品？だけになってしまっているので、オライリーの直販か電子書籍(PDF、epub)をご利用ください。45分という短い時間の中で何をお話するかは結構迷いました。本書はレガシーコードを﹁どうやって直すか﹂ではなく﹁どうやって作らないようにするか﹂に軸足を置いていて、そのためのプラクティスとして以下の9つを提唱しています。 やり方より先に
    【資料公開】レガシーコードからの脱却

  • Agile Japan 2019にムービースポンサーとして参加してきました - RAKUS Developers Blog | ラクス エンジニアブログ


    https://www.agilejapan.org/www.agilejapan.org はじめに 楽楽明細のエンジニアをしているid:eichisandenです。 7/18に行われたAgile Japan 2019のムービースポンサーを弊社の方で務めさせて頂きました。 アジャイルジャパン2019にムービースポンサーとして参加させて頂いております。#agilejapan pic.twitter.com/7JmNmuHtZL— 株式会社ラクス 開発部 (@DevRakus) 2019年7月18日 ムービースポンサーになると、招待チケット、関係者チケットを1枚ずつ貰えるのでとてもお得だと思います！ 最近チームでスクラムを初めたこともあり初めて参加させてもらいました。 ︵というかアジャイルのイベント自体が初参加でした！︶ セッションの合間などにインパクトのある楽楽精算のムービーが流されていまし
    radiocat
    radiocat 2019/07/25
    一緒に参加して記事を書きました。 #agilejapan
    リンク

  • デベロッパーとして生きていく ー 認定スクラムデベロッパー になりました！ - ikuo’s blog


    先日、 David Bernstein 氏の 認定スクラムデベロッパー研修に参加し、Certified Scrum Developer︵CSD︶を取得しました。 www.jp.agilergo.com ５日間に渡る研修で、たくさんのことを学びました！ TL;DR これでした！ 今まで学んできたことが1つのストーリーのもとつながり、明確な目的を得ることができました。 何より、デベロッパーとして生きていく自信と勇気を、その方法と一緒にもらったように感じています！ お急ぎでない方向け‥詳細 Agile, Scrum, XP 価値、原則、プラクティスのフラクタル構造XPにおいて、価値、原則、プラクティスは以下のように説明されます。 価値︵values︶‥達人が良し悪しを判断する高度な感覚。ある状況における好き嫌いの根源にあるもの プラクティス︵practice︶‥疑う余地のない、簡単に実施できる
    デベロッパーとして生きていく ー 認定スクラムデベロッパー になりました！ - ikuo’s blog
    radiocat
    radiocat 2019/06/02
    価値の高いエンジニアになるための学びが多そう。
    リンク

  • これからプロダクトオーナーになる人へ


    みなさんこんにちは。@ryuzeeです。 これからスクラムで初めてプロダクトオーナーをやる方に向けてのポエムです。 何はともあれ時間を確保しようプロダクトオーナーは非常に忙しい役割です。片手間でできる仕事ではありません。 例えば、プロダクトオーナーが開発チームのために週1日しか開発チームと一緒の時間をすごせず、後はメールやSlackなどのオンラインツールで非同期かつ遅延のあるコミュニケーションを取る場合を考えてみましょう。そこで起こるのは、開発のリードタイムの増加と手戻りの増加です。細かい確認をすべてオンラインでやることはできないので、開発チームは想像で物事を進めてしまい、後で認識の違いが分かり使った時間を無駄にするか、次回対面で話せるまで結論を先送りにするかのいずれかになります。 プロダクトオーナーは、プロダクトにつき1人です。サポート役をつけることはできますが、最終意思決定者が1人とい
    これからプロダクトオーナーになる人へ
    radiocat
    radiocat 2019/06/02
    開発組織主導でスクラムを始める時にPOをどうするかは非常に悩ましいのでこれは非常にありがたい。
    リンク

  • 恐怖と戦い、実験せよ　“愛される職場”を作るためにできること Part2

    2018年1月11日から13日の3日間、第8回目となるRegional Scrum Gathering® Tokyoが開催されました。スクラムの初心者からエキスパート、ユーザー企業から開発企業まで、立場の異なる様々な人々が集まる学びの場である本イベント。世界中からスクラム開発におけるエキスパートたちが一堂に会し、最新の情報や自身の知見を惜しげもなく語ります。1日目のKeynoteに登壇したのは、『ジョイ・インク 役職も部署もない全員主役のマネジメント』の著者であり、Menlo Innovations CEOのRich Sheridan氏。本パートでは、Menlo Innovations社で実際に取り組んでいる組織づくりの工夫と、その効果について語ります。講演資料はこちら 顧客とのショウ＆テル これまで社内の相互対話に起こそうとしている変革についてお話ししてきました。次は、私たちが変革を起こ

    恐怖と戦い、実験せよ　“愛される職場”を作るためにできること Part2

  • 画面設計とか外部設計とか、もうやめようよ - masayang's diary


    昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した﹁Feature, Story, Scenarioがごっちゃになりかけている﹂プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で﹁コンサルタント﹂の人達が、画面を使ってお客さんと﹁要件定義﹂をしていたらしい。 ﹁この画面でこういうデータを入力すると、こんな画面に遷移します﹂みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
    画面設計とか外部設計とか、もうやめようよ - masayang's diary

  • Agile Japan2018基調講演「モブプログラミングと”フロー”の力（Woody Zuill）」を聞いてきた #agilejapan


    セッション概要5人で1台のコンピュータを使ってプログラミングをする？そんなことをして生産性は高まる？そんな疑問はもっともだと思います。その疑問に回答するのは簡単ではありません。我々が”フロー”の力を理解し始めるまでは - モブプログラミングはどうすれば一つのチームが一緒に効率よく働くことができるかということを探求する過程で発展してきました。一旦始めてみると、我々はモブプログラミングが次のような様々な面でより良い効果を生み出すことにすぐに気づきました。 ・今までよりも多くの作業を終えることができた ・より多くの重要な作業を終えることができた ・作業の品質が劇的に向上した ・チームのナレッジ、スキル、遂行能力が急速に進歩した ・そしてチーム全員がとても楽しんで仕事をしていた1日を通してみんなで一緒に働くことがこれらの良い効果をもたらす主な要因であることは明らかでしたが、それでもこの働き方が
    Agile Japan2018基調講演「モブプログラミングと”フロー”の力（Woody Zuill）」を聞いてきた #agilejapan
    radiocat
    radiocat 2018/07/20
    効率的かどうかを気にしている時点でアジャイルじゃないってことなんだろうな。そしてモブも実装は自分たちでしないといけない。
    リンク

  • スクラムマスターを発狂させる10個のこと

    スプリントバックログの項目ではないタスクをやり続けること妨害事項を隠してしまうことスプリント中はプロダクトオーナーと決して会話しないこと完成の定義を無視することスプリントバックログの前で、「俺やることないや」ということスプリントレビューのわずか５分前から準備を始めることスプリント期間中全部を使ってしまうほどのタスクを小さいタスクに分割しないこといつも遅刻すること次にどのタスクをするべきかいつもスクラムマスターに聞くことスクラムミーティングで関係ない話をしたり、誰かと電話していること

    スクラムマスターを発狂させる10個のこと

  • リモートワークはとても難しいという話をしてきました - だいくしー(@daiksy)のはてなブログ


    "Agile Japan 2017 京都サテライト", "KANJAVA PARTY 2017" で、﹃リモートチームの道具箱﹄というタイトルのセッションでお話をさせていただきました。 connpass.com kanjava.connpass.com リモートワークに取り組んでいるチームで仕事をして3年目になりますが、リモートワークは難しいなーというのを常々思っています。 世の中はどちらかというと、リモートワークという素晴らしい取り組みをどんどん推進しようという流れに向いています。リモートワークの推進には僕も賛同するのですが、一方で、﹁難しさ﹂の部分があまりクローズアップされません。このまま、導入だけが先行してしまうと、結局﹁やっぱりリモートワークなんて止めたほうがいいのでは﹂となってしまう恐れがあって、それを懸念しています。 リモートワークは上手に使いこなせば、柔軟な働き方が促進される
    リモートワークはとても難しいという話をしてきました - だいくしー(@daiksy)のはてなブログ

  • Modern Agile

    Over the past decade, innovative companies, software industry thought leaders and lean/agile pioneers have discovered simpler, sturdier, more streamlined ways to be agile. These modern approaches share a focus on producing exceptional outcomes and growing an outstanding culture. Today, it makes far more sense to bypass antiquated agility in favor of modern approaches. Modern agile methods are defi

  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

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

  • @hatebu

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

はてなブックマーク

公式Twitter

はてなのサービス

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