【資料公開】強いチームの作り方 | Ryuzee.com
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。
ユーザーストーリーをうまく使えていない5つの兆候
みなさんこんにちは。@ryuzeeです。 Marc Löffler 氏が書かれた “5 Signs That Your User Stories Suck” という記事が分かりやすかったので抜粋・意訳にてご紹介しましょう。 以下にあげるようなことは、そもそも「何のためのユーザーストーリーなのか？」ということを考えずにプラクティスとして取り込んでしまっているが故に起こる問題であるとも言えます。 一年半ほど前に、ユーザーストーリーを台無しにする方法について書いた。 それから現在までの間に、ぞっとするようなユーザーストーリーをほかにも見てきた。 それがこの記事を書こうと思った理由だ。 以下にあげるのが、あなたがユーザーストーリーをうまく使えていない兆候のリストだ。 1. ユーザーストーリーが単なるラッパーになっているもしユーザーストーリーがたった1つのタスクから構成されていたとすると、それはユー
スクラムにおいて欠陥をどのように扱うか
みなさんこんにちは。@ryuzeeです。 スクラムにおける欠陥の扱い方について考えてみました。 スクラムでは欠陥の扱い方には特に規定はないので、以下はあくまで経験を踏まえた個人的なアプローチであることに注意してください。 欠陥の定義欠陥とは、プロダクトバックログアイテムが「完成」した後に見つかった欠陥のみを指すここでいう欠陥とはソースコードのバグと要求実装の欠落の双方を指す双方の具体的な定義や判断基準はプロジェクトによって異なる（欠陥の定義を作ると良い）バグと技術的負債は異なるスプリントで実装中のプロダクトバックログアイテムにおける動作不良や問題は、その時点では欠陥とみなさないなぜなら完成の定義や受け入れ基準に従ったものを開発チームは作る必要があること、プロダクトオーナーは受け入れ確認の際に、欠陥がある場合にプロダクトバックログアイテムを受け入れるか受け入れないかを決めることができるため対
ゴールを決め過ぎてしまうことによって陥る罠
みなさんこんにちは。@ryuzeeです。 Bob Hartman氏のAgile antipattern: Target fixationが良い記事なので、抜粋・意訳にてご紹介します。 日本でよく言われるのが、「期日までに使わない（と思われる）機能も全部作れ、契約だから」。 限られた時間軸の中で変化を受け入れながら進めている中でこういうのを要求されると、品質やチームのモチベーションやコラボレーションを犠牲にしはじめてしまいます。 このような状況が続けば焼畑農業のようにチームには何も残らなくなります。 結果として顧客にとっても幸せな結果にはなりません。 期日を約束したりストーリーポイントのゴールを約束したり、その他のゴールが命取りになることがある。これらだけでは本質的に悪くは無いとしても、下記に述べるその他の項目と組み合わさると、問題となるだろうチームはゴールを達成するために品質を端折り始める
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
