タグ

ブックマーク / www.ryuzee.com (4)

  • スクラムにおいて欠陥をどのように扱うか

    みなさんこんにちは。@ryuzeeです。 スクラムにおける欠陥の扱い方について考えてみました。 スクラムでは欠陥の扱い方には特に規定はないので、以下はあくまで経験を踏まえた個人的なアプローチであることに注意してください。 欠陥の定義欠陥とは、プロダクトバックログアイテムが「完成」した後に見つかった欠陥のみを指すここでいう欠陥とはソースコードのバグと要求実装の欠落の双方を指す双方の具体的な定義や判断基準はプロジェクトによって異なる(欠陥の定義を作ると良い)バグと技術的負債は異なるスプリントで実装中のプロダクトバックログアイテムにおける動作不良や問題は、その時点では欠陥とみなさないなぜなら完成の定義や受け入れ基準に従ったものを開発チームは作る必要があること、プロダクトオーナーは受け入れ確認の際に、欠陥がある場合にプロダクトバックログアイテムを受け入れるか受け入れないかを決めることができるため対

    スクラムにおいて欠陥をどのように扱うか
    todesking
    todesking 2012/11/11
  • Jenkinsでビルド・パイプラインを作る

    Jenkinsのプラグインでビルド・パイプラインを作ることができるので紹介。 #12月20日のワンクリックデプロイ勉強会の発表のネタバレっぽいのですが。 ビルド・パイプラインとはビルド・パイプラインとは、継続インテグレーションのプラクティスの1つで、テスト等を複数の単位に分割し、順番に流していくものである。一般的には継続的インテグレーションを利用していれば、SCMにソースコードをコミットした段階ですぐにユニットテストを走らせ、以降に、静的解析や結合テスト、受け入れテスト、ステージング環境へのデプロイ、番環境へのデプロイという形で進んでいくことになり、その単位でパイプライン要素を分ける。 当然パイプラインの途中で試験に不合格であれば、その後のプロセスには進めない。 これによって、例えばコミット時には即座にユニットテストレベルの結果を返して開発者のペースを阻害しないようにすることができる。(

    Jenkinsでビルド・パイプラインを作る
    todesking
    todesking 2011/12/07
    Jenkinsのビルドパイプラインプラグイン、いいかも
  • アジャイルにおける罠や落とし穴(失敗例)

    みなさんこんにちは。@ryuzeeです。 Sean Landis氏のTraps & Pitfalls of Agile Software Development - A Non-Contrarian Viewにて、 よくあるアジャイルに関する失敗パターンを挙げられていたので抜粋・意訳にてご紹介します。 個人的に大事だと思うのは4点目です。 「アジャイルはチームと個人の規律、コミットメントやオープンさを機能不全の組織が持つそれよりもより多く必要としている。 にも拘わらず機能不全の組織がまるで銀の弾丸かのようにアジャイルに対して希望をもってしまう。」というのは良く見てきた例のひとつで、こういう組織に限って、色々な理由をつけて教科書通りにやってみることなく、「自社の特別な理由」を盾にして最初から「破」の状態で始めてしまい、また短期的な評価のみで、アジャイルが有効だの効果がないだのと判断をしてしま

    アジャイルにおける罠や落とし穴(失敗例)
    todesking
    todesking 2011/08/23
    "むしろアジャイル開発は必要な努力を正しいタイミングで行うものだと思うのと思うので、少ない努力ってなんだよ?って感じだ。"
  • Agile 書評 アジャイルサムライー達人開発者への道

    アジャイルサムライ−達人開発者への道− 著者/訳者:Jonathan Rasmusson 出版社:オーム社( 2011-07-16 ) 定価:¥ 2,808 Amazon価格:¥ 2,808 単行(ソフトカバー) ( 288 ページ ) ISBN-10 : 4274068560 ISBN-13 : 9784274068560 アジャイルサムライは、Jonathan Resmusson氏が昨年書いたで、日語監訳は永和システムマネジメントの西村さん(@nawoto)と角谷さん(@kakutani)。 僕は僭越ながら翻訳原稿のレビューに参加させて頂いたのだが、当に素晴らしいで、出版を心待ちにしていました。 これからアジャイルな開発に取り組もうとしている人にとっても、既にアジャイルな開発に取り組んでいる人にも役に立つ必携図書であること間違いなしです。 このの特徴 ScrumやXPやLe

    Agile 書評 アジャイルサムライー達人開発者への道
    todesking
    todesking 2011/07/13
    "そのプロジェクトが成し遂げる価値について合意し、現実と向きあって作る物の優先順位を決め、諦めなきゃいけないことを決め、そしてはっきりしていないことは明らかにしていかなければならない。これは発注者にも
  • 1