タグ

ブックマーク / kawaguti.hateblo.jp (14)

  • 許可を求めるな謝罪せよの源流、グレース・ホッパー - kawaguti’s diary

    海外カンファレンスの講演でちょくちょくでてくる軍服の女性がいる。 File:Grace Hopper.jpg - Wikimedia Commons グレース・ホッパーさん。 グレース・ホッパー - Wikipedia 話を聞いてる英語圏のソフトウェア系の人はみんな知っているだろうけど、Wikipediaによれば、最初のコンピュータENIACを設計したエッカートとモークリーが立ち上げた商用コンピュータプロジェクトUNIVACに参加して、「機械語ではなく、英語に近い言語によってプログラミングできるようになるべきである」というポリシーのもとCOBOL作った人でもある(らしい)。 File:Grace Hopper and UNIVAC.jpg - Wikimedia Commons Wikiquote によると “It's easier to ask forgiveness than it i

    許可を求めるな謝罪せよの源流、グレース・ホッパー - kawaguti’s diary
  • プランニングポーカー かんたんガイド 作りました。 - kawaguti’s diary

    デブサミで、ご希望の方にプランニングポーカーを有償でお分けしました。一個単位で輸入すると送料がばかにならないのですが、弊社で多めに買ったものをお分けしており、少量でもコスト安く手に入ります。 (2014年現在は行っておりません。アギレルゴコンサルティング社にお問い合わせください。) Mountain Goat 社製プランニングポーカーカード を一個単位でお分けします。 - アギレルゴコンサルティング株式会社 残念ながら在庫が十分に足りず、ご興味を持っていただきながら手に入らなかった方がたくさんいらっしゃると聞きました。弊社の方でもほそぼそとお分けしておりますので、ご興味のある方は、ご検討いただければ幸いです。ほとんど原価販売です*1。 ※2012/2/20追記: 日マイクロソフトの長沢さんがノベルティとしてプランニングポーカーを配布されていますので、そちらもご参照ください。 使い方の説明

    プランニングポーカー かんたんガイド 作りました。 - kawaguti’s diary
  • More Agile Testing 第一章の非公式翻訳 - kawaguti’s diary

    実践アジャイルテストの続編である、More Agile Testing の第一章が、アジャイルテストの歴史を端的に書いてていいな、と思ったのでその部分だけ訳してみました。 More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley Signature Series (Cohn)) (English Edition) 作者: Janet Gregory,Lisa Crispin 出版社/メーカー: Addison-Wesley Professional 発売日: 2014/09/30 メディア: Kindle版 この商品を含むブログを見る 第一章 アジャイルテスティングはどのように進化してきたのか 私たちは、それぞれ、エクストリームプログラミング(XP)チームの中のソロのテスターとして「アジャイル」なキャリ

    More Agile Testing 第一章の非公式翻訳 - kawaguti’s diary
  • アジャイルテストの世界 - Agile Testing Condensed と実例マッピング - kawaguti’s diary

    リサとジャネットの Agile Testing Condensed という短い書籍があるんですけど、これの翻訳をお手伝いしました。権利周りの調整のお手伝いと、翻訳レビューです。 leanpub.com アジャイルテスティングという、日ではそんなに盛り上がっていない分野がありまして。アジャイル時代にどのように品質を担保するのか、QAやテスターはどのように関わっていくのか、非常に大事なんですけど、なぜか日ではTDD(テスト駆動開発)やテスト自動化についての注目に比べても、今ひとつ盛り上がっていない感じがします。惜しいことです。 Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all me

    アジャイルテストの世界 - Agile Testing Condensed と実例マッピング - kawaguti’s diary
  • 組織はツリーではない - Jim Coplien さんのスケールフリーネットワーク論 - kawaguti’s diary

    RSGT2020の基調講演をやっていただく Jim Coplien さんによる、大規模組織のお話がありました。 この話を聞くのは実は三回目(飲み屋、ウィーンでのScrum Gathering、今回)ですし、ありがたいことに、色んな人に日語で説明することもあるので、周りの人とも話しながら自分なりの認識がまとまってきました。 いや、お前のまとめなんていらないんだよ、とは思いますが、全体をちゃんと書くのは難しいので(ビデオとっとくべきでした)、ざざっと書いておきます。 人々は組織をツリー構造*1で考えがちで、実際に公式な組織アサインはそのように運営されがちだが、末端のノード間やたすき掛けのようなつながりは自然に起きていて、それによって情報流通の効率性が維持されている。これは、兼務をつけて複数部署にマネージャーを頭出しさせるのとも違うし、マトリックス型組織でプロジェクト運営するのともちょっと違う

    組織はツリーではない - Jim Coplien さんのスケールフリーネットワーク論 - kawaguti’s diary
  • モブプロの聖地 Hunter Industries で学んだこと - kawaguti’s diary

    方面は、平成最後とか、令和こんにちわ、連休ながーい、という噂を聞いておりますが、私はなぜか米国に来ていて、フィーバーに参加できておりません。アベンジャーズは一応、公開日に観に行きました。字幕ないし、アメリカンジョーク(推測)とかは聞き取れなかったんだけど、そんなのどうでもいい感じの映像美でしたね。 Hunter Industries にお邪魔してます モブプログラミング・ムーブメントを生み出した、Hunter Industries に来てます。2年前に半日だけお邪魔したんですけど、モブ自体には参加してなくて、もうちょっといろいろわかりたいな、と思いまして。1月にRegional Scrum Gathering で来日してくれた、Director のクリスさんにお願いしてみたら、いいよーってことだったので、お邪魔しに来ました。 ビザの関係で生産活動には従事できないのだけど、横で立ってるの

    モブプロの聖地 Hunter Industries で学んだこと - kawaguti’s diary
  • モブプロの聖地 Hunter Industriees で学んだこと 〜 複数モブ編 - kawaguti’s diary

    は長かったゴールデンウィークが開けるということで、戻って働けるのかしらという話が飛び交ってますが、いかがお過ごしでしょうか。引き続き Hunter Industriees にいまして、学んだことをメモしておこう、というエントリです。前回のエントリは単体のモブプロについて気がついたことが中心でしたが、今日は複数モブについてです。 Hunterで学んだことその8: 仕事領域 = モブ != 人 3つのモブを持つプロダクトに参加していているのですが、それぞれのモブは同じコードベースで、別の仕事をしています。モブごとに紙ベースのタスクボードをホワイトボードに作っていて、WIPは1に制限されてます。 これは私がソフトウェアを作る人生の中でも初めて体験したのですが、モブは作業場所なだけでなく、どの部分をいじっているか、も示します。フィーチャーブランチを切らず、トランクベースで開発しているので、同じ

    モブプロの聖地 Hunter Industriees で学んだこと 〜 複数モブ編 - kawaguti’s diary
  • The Phoenix Project : 自社の情報システムの開発・運営を体験するワークショップ - kawaguti’s diary

    ITプレナーズさんで主催しているDevOpsの体験型研修がありまして、見学させていただきました。 この研修はオランダに拠をおく GamingWorks 社が開発したワークショップをITプレナーズさんが日語化(のお手伝い)をしたものです。GamingWorks 社はAgileやプロマネ向けのゲーム形式研修を手がけているようなので、今後の拡充が期待されます。 https://www.gamingworks.nl/business-simulations/the-phoenix-project/ 継続的デリバリーの先の世界 ここでいう DevOpsについては、Phoenix Project を参考にしていただくとよいかと思います。当初の DevOps の定義はインフラやデプロイの自動化を中心に考えられたものですが、サイロ化が進行した会社が当に変化のスピードを上げるためには、組織間の連携や会

    The Phoenix Project : 自社の情報システムの開発・運営を体験するワークショップ - kawaguti’s diary
  • スクラムマスターは保育園の先生に似ている - kawaguti’s diary

    こんなご相談をいただきまして。 スクラムマスターは支援者だとは思っているんですが言葉が難しく…提案や促し?ではなく「指示」なってしまう場面があり上手く出来なくて うーん、まあそんなに焦らず、刺激を与えたらその反応を、じっくり観察していきましょう。ってなアドバイスをしまして。 スクラムマスターっていうのは、人を変えるというか、理解を促したり、姿勢を矯正していくような仕事なので、「30m走りなさい」って言えるPOとはちょっと違ってですね。人間という複雑なものを複数束ねたチームというのを扱うので、とにかく刺激->反応を見るを繰り返すしかなかったりすると思います。 なので、「こうしてほしい」に「はいやります!」っていう変化は単純、もしくはうわべだけなので、もうちょっと質的な深い変化を観察する必要があるかなと思います。 問題 (ミーティングが長い) -> 対処 (短くしたほうがいい) ... では

    スクラムマスターは保育園の先生に似ている - kawaguti’s diary
  • 熱意ある共犯者 - kawaguti’s diary

    「問題をいたいほどよく知っている人」が、熱意を持って改善のために努力するということ。 こういう人がいると、プロジェクトはうまくいくと固く信じている。言葉は悪いが「熱意ある共犯者」と定義したい。 2009年に参加した参加したカンファレンスで、住友信託銀行(当時)の小吉文子さんのセッションに参加して、こんなことを書いていた。 人事や総務といった業務担当の方を支援する仕事に最近関わらせてもらっていて、開発部門を支援するのとはまた違った趣があるのだけど、成功要因の根っこにあるのは、こういうことなんじゃないかという思いを強くしている。 ずっとこの思いは変わっていないし、誰かと仕事するときには指針としている。変化は情熱のあるエバンジェリスト(イニシエーター)から起こるものだろう。 もちろん仕事には様々な要因が影響し簡単ではない。共犯者の情熱も有限なので、途中で諦めてしまったり、中断して時期を待つことも

    熱意ある共犯者 - kawaguti’s diary
  • BPMやワークフローについてのメモ - kawaguti’s diary

    組織内の業務フローをシステム化するやり方に、ワークフローシステムとか、BPMといったものがある。いくつか調べたので、メモ代わりに残したい。権威でも熟練の実践者でもないので、おそらく間違いや、抜け漏れがあると思われる。 過去の仕事上、内部の人が使うツールというのは幾つか作ってきたけれど、業務システムをガッツリやったことはないので、ワークフローとかBPMとかって言われると、知識の不足は否めない。UCD方面の手法はインタビューや観察などは分かるのだけど、モデリングはあまりわからない。BAとUCDと業務モデリングはとっても近い分野だと思うのだけれど、流派が分かれているのか混ぜるな危険なのか、これという統一的な話を聞かない気がする。 業務モデリングの前提として必要なこと - アカウント管理 まず、人事情報が名寄せされ、しっかり確立している必要がある。某ベンダーさんのコンサルの人がここに苦労した案件が

    BPMやワークフローについてのメモ - kawaguti’s diary
  • 業務知識とIT知識を分けて考える時代は終わったんじゃないか - kawaguti’s diary

    昨日のエントリは思いがけずアクセスをいただきまして、はてブのホッテントリにものったようで、驚いております。ありがとうございます。ここのところお腹の中にぐるぐるしている思いを新年にかこつけて吐き出した記事で、切れない「なまくら刀」のような後味で申し訳なく思っております。 kawaguti.hateblo.jp この記事の中で、業務知識という言葉の定義を曖昧なままに使ってしまって、ブクマコメントで「業務知識とはだな...」というご教示をいくつかいただきました。ご指摘ありがとうございます。 SIerで業務知識といえばお客さんの業務に関する知識 システムインテグレーター(SIer)方面の方は「(自分たちはIT知識を持っている前提で)、ユーザー企業の人が持っているべき知識のことを業務知識と呼ぶ」という認識なのだろうと認識します。そういえば、10年以上前になってしまいますが、業務知識はSIerに必要か

    業務知識とIT知識を分けて考える時代は終わったんじゃないか - kawaguti’s diary
  • ソフトウェア開発における学習曲線を受け入れる by David Bernstein - kawaguti’s diary

    Beyond Legacy Code の著者、David Bernstein (@ToBeAgile ) さんの記事を翻訳しました。ソフトウェアエンジニアは新しいことを常に学ぶ必要性がある、 それはなぜか、というお話です。 David  さんは DevOpsDays Tokyo 2019 (4/9-10) の 基調講演で来日予定です。 Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software 作者: David Scott Bernstein 出版社/メーカー: Pragmatic Bookshelf 発売日: 2015/08/03 メディア: ペーパーバック この商品を含むブログ (1件) を見る ソフトウェア開発における学習曲線を受け入れる David Bernstein著 -

    ソフトウェア開発における学習曲線を受け入れる by David Bernstein - kawaguti’s diary
  • ポジティブふりかえりマッピング - kawaguti’s diary

    アジャイルバンクーバー2010で行われた、リンダ・ライジングさんのポジティブレトロスペクティブと、ジェフ・パットンさんのユーザーストーリーマッピングを活用したふりかえりについてのブログエントリの翻訳です(著者のSteve Rogalskyさんの許可をいただきました)。翻訳にあたっては高橋陽太郎(@poohsunny)さんにレビューのご協力をいただきました。ありがとうございました。 ポジティブな点を述べることで「行った事実」にフォーカスできることと(課題を言うとwishが増える)、インデックスカードで整理する手法を組み合わせているところがよいなと思いました。 原文はこちら Agile Retrospectives - a Rising Patton Fusion http://winnipegagilist.blogspot.com/2010/11/agile-retrospectives-

    ポジティブふりかえりマッピング - kawaguti’s diary
  • 1