タグ

2011年4月22日のブックマーク (7件)

  • カンバンを導入する正しい理由5個

    みなさんこんにちは。@ryuzeeです。 前回の投稿の続きです。 今度はMichael Dubakov氏が5 Right Reasons to Apply Kanbanということで、正しい導入理由5個について説明していますので、抜粋・意訳にてご紹介します。 カンバンを導入する正しい理由5個 1. いつでもリリースできるようにするスクラムやXPではイテレーションの途中でリリースすることはできない。 カンバンであればいつでもリリースできるかもしれない。 ユーザーストーリーの準備ができたたら、それをリリースする。 このような開発プロセスを作ることは挑戦的だろう。 このような開発プロセスでは、フィーチャー単位でソースコードレポジトリのブランチを管理し、頻繁にマージや結合やテストを行う必要がある。 ただこうすることで頻繁にリリースすることができるようになるのだ。 これはやってみる価値がある。 プロダ

    カンバンを導入する正しい理由5個
  • カンバンを導入する間違った理由5個

    みなさんこんにちは。@ryuzeeです。 ちょっと古い記事ですが、TargetProcessのサイトMichael Dubakov氏による5 Wrong Reasons To Apply Kanbanという良い記事があったので、抜粋・意訳にてご紹介します。 5つの間違い1.ユーザーストーリーの多様性我々のストーリーは1ポイントから40ポイントまでさまざまなので、大きいストーリーがスプリントに入らない。なのでカンバンを使う 2.スプリントがうまくいかない1スプリントの中でほとんどのストーリーが完成しない。なのでカンバンを使う 3.ふりかえりミーティングがうまくいかないふりかえりミーティングが無駄になっている。チームメンバーはプロセスの改善に協力してくれず、ミーティング自体をなくしたい。なのでカンバンを使う 4. 人的リソースの共有と機能別組織開発チームが1つで、プロジェクト間でメンバーを共有

    カンバンを導入する間違った理由5個
  • 【資料公開】自動テスト vs 手動テスト

    みなさんこんにちは。@ryuzeeです。 SlideShareを徘徊していたところ自動テストと手動テストに関する良いスライドがあったので、翻訳して公開します。 ライセンスはオリジナルに準じてCC BY-SA 3.0とします。 内容としては、僕自身も一貫して主張しているテスト自動化の必要性の話で、主に以下の観点で記載されています。 作業量とコスト再利用性ユニットテストによる良い設計への誘導手動テストのリスクリスクマネジメント書き方が若干極端な箇所もあると思いますが、全体としてはかなり分かりやすいのではないでしょうか。 なお、テストの自動化に際しては、必ずしも全てのテストを自動化「しなければならない」わけではありません。 スライドではROIの例があがっていますが、テストの自動化のコスト>手動コストの1回あたりのコスト×実行回数になる場合もあり得るので、ROIやテスト自動化によって得られる効果に

    【資料公開】自動テスト vs 手動テスト
  • The Basic Flow of Agile Development | PDF

    What is Scribd?AcademicProfessionalCultureHobbies & CraftsPersonal GrowthAll Documents

    The Basic Flow of Agile Development | PDF
  • CSS:初心者の頃にハマったスタイルシートのあれこれ … IE7多め

    CSS、スタイルシート。初心者のころには CSS のスタイルがうまくいかなくて、半日や丸一日悩んだこともいっぱいありました。最近では、やっとひと通り覚えて、思うようにできるようになったかなーという感じです。今回は初心者だったころ、ちょっと悩んだことなどをいくつかまとめてみました。 Webサイトの見た目をデザインしていくのに欠かせない CSS。度々これってどうやるんだろうとか、どうしてこうなっちゃうの?というものに遭遇します。また、今までは IE6 をターゲットに含めてましたけど、そろそろ IE7 からをターゲットにすればいいのかなーと思うこともあって、過去のスタイルシートの書き方の習慣を変えようかなとも思っています。 スタイルシートを書いていて、今まで遭遇した不具合やその回避方法、また今まではこうしてたけど、これからは変わるかもしれないなーといものをまとめてみました。もうそんなことしてない

    ikasam_a
    ikasam_a 2011/04/22
  • スクラムを失敗させる方法

    1. ふりかえり(レトロスペクティブ)をしないか、間違ったふりかえりをするふりかえりをせずして、どうやって物事をよりうまくできるようにすることができるというのだろうか? ふりかえりは、全てのチームメンバーがうまく行ったこと、もっとうまくできるだろうことについて議論できるという点で必要不可欠だ。 そしてもちろん言うまでもなく、失敗から学習しなければならない。もしそういったことが行われていない(形式的なふりかえり)なら、ふりかえりは役に立っていない。 2. ダメなプロダクトオーナープロダクトオーナーはいつでもプロジェクトのために時間を使えるようでなくてはならない。 プロダクトオーナーはスプリントプランニングやふりかえりに参加しなければならない。 また一方でプロダクトオーナーはスプリント中のタスクは見積りしてはならない。見積りはチームの責任なのだ。 プロダクトオーナーはビジネス上の優先順位に基づ

    スクラムを失敗させる方法
  • 「アジャイル開発の基本的な流れ」 - ヲトナ.backtrace

    先日、アジャイル開発にはじめて取り組む現場向けのプチ講習をやりました。 アジャイル開発の一連の流れとそれぞれやる事をお話しして、これから自分達が何をやっていくのかを把握してもらおうというのが目的でした。 その後、実際にスプリントを始められるように準備をしましょうというところまでやりました。 その時に使った資料を公開しておきます。 実際の現場でやる時は口頭で解説つけたり詳細な部分は実際にやる際に説明したりするので、資料的には一連の流れとそれぞれがやる事をダーっと説明している内容なのですが、ちょっとしたチートシートみたいな感じには使える気がします。 The Basic Flow of Agile Development あと、今回はいつも資料の公開用に使っている slideshare が調子が悪いので Scribd を使ってみました。

    「アジャイル開発の基本的な流れ」 - ヲトナ.backtrace