タグ

2012年1月22日のブックマーク (5件)

  • 資料公開 Scrumはじめの一歩

    2011年9月3日(土)に早稲田大学理工学部で行われたXP祭り(記念すべ第10回!)で、Agile Buffetというワークショップセッションを長沢さん(マイクロソフトの凄腕エバンジェリスト)、海江田さんと一緒に、Scrumはじめの一歩という初心者向けセッションを、西村さん(アジャイルサムライ監訳者)と一緒に実施してきました。 ご参加頂いた方、お手伝い頂いたスタッフの方、こっそり紛れ込んでもらった仲間たちありがとうございました。 Agile Buffetについては長沢さんのブログ等で公開されると思いますので、ここでは、「Scrumはじめの一歩」について資料を公開いたします。 今回は90分コースでしたので、全体の概要をざっくり抑えたうえで、ワークショップをやって実際のScrumのイメージを掴んでいただくことを目的としてます。次はフルコースで聞きたいという方は是非Scrum Boot Camp

    資料公開 Scrumはじめの一歩
  • 第16回 改善文化の定着と立ちはだかる障害を越える | gihyo.jp

    業務改善が進むにつれて、仕事のやり方を変えていかなければなりません。常に現場の「もっとうまいやり方はないのか?」という問題意識や向上心、創意工夫で改善は成り立ちます。改善にゴールがあるわけではありません。 改善文化、すなわち継続して成長をし続ける組織風土が定着する組織になるか否かは、経営者をはじめ、現場の皆さん次第です。時には目の前に大きな障害も立ちはだかるでしょう。そして、業務改善をより大きな企業活動としていくためには、もはや「改善」ではなく「改革」レベルまで踏み込むことも必要となります。情報システムにも影響します。今回はこのような話をしていきます。 仕事のやり方を変える 業務改善を行うと、少しだけ業務プロセスが変更になる人もいれば、大幅に変更になる人も出てきます。 業務改善の活動に直接関わっていた人とそうでない人との、それまでの活動経緯や効果に対する情報量の差は、いくら社内広報(第7回

    第16回 改善文化の定着と立ちはだかる障害を越える | gihyo.jp
  • 不動産屋がようやく折れてきたが俺も折れそうな件について - 関内関外日記

    承前:不動産屋がなりふり構わず敷金を返そうとしない件について - 関内関外日記(跡地) ※前にも書いたとおり自分は弁護士でも不動産業界の人間でもないので、書いてることが参考になるとは思えないし、参考にしてお前が不利益をこうむっても知った話ではないです。だいたい、これが実話かどうかすらわからないし、俺が犬である可能性も考慮するべきだ。 前回アップした下書きをいくらか手直しし、翌日プリントアウトしたものを会社の人間に見てもらった。結果、「筋は通っているように見えるし、おもしろそうだから送ってみれば」という意見であった。やはり他人の揉め事はおもしろいものらしい。 ただ、条件面についてもいくらか意見をもらい、いくらか変更点を加えることにした。昼休みにガイドラインからの引用の挿入やIllustratorでのそれらしい装飾を施した上で、ガイドライン該当箇所を別添資料として付け足し、速攻でFAX。内容証

    不動産屋がようやく折れてきたが俺も折れそうな件について - 関内関外日記
    anakahala
    anakahala 2012/01/22
    俺も去年の夏に引っ越しする時に揉めたなぁ。最初は敷金全部持っていかれる見積もり。ガイドライン見てこっちで想定の金額計算して、何度かやり取りしてもあっちはこっちの想定にはしない。心折れて数万円妥協した…
  • 受託プログラマの進路 〜アジャイルセールスと手塚モデル〜

    This document introduces the author as a software engineer who works with Redmine, TestLink, and open source projects. It provides an overview of the author's background, interests which include Hadoop and database technologies, and links to the author's blog and social media profiles. The author signs off by noting they are available for any questions.Read less

    受託プログラマの進路 〜アジャイルセールスと手塚モデル〜
  • Scrum ではコードレビューをどうやっているか? - haradakiro's blog

    森崎先生のソフトウェアレビューの講演を聴いて、今やっているレビューの方法をまとめときたいと思ったので、まとめてみます。今回は、コードレビューの話です。Scrum ではといっていますが、レビューのやり方はチームによって違うので、あくまでも例ですよ。PBI とか、仕様、ドメインモデルのレビューの話はまたこんど。 レビューの目的は、もちろん作成するプロダクトの品質向上です。障害を検出するのも、もちろん目的ではあるのですが、それ以降のスプリントで作成されるコードで同じ障害を作り込まないのが目的としては大きいです。そのため、レビューはプロジェクトもしくはチーム立ち上げ後、数スプリントで重点的にやります。後はスプリントの振り返りでレビューをやりたいが出てきたら、チームで決めます。 レビューのやり方 基はチーム全員で集まってやります。最大2時間。それ以上やっても集中力が続かないので。プロジェクタで対象

    Scrum ではコードレビューをどうやっているか? - haradakiro's blog