アジャイルな開発とチームづくり - Mitsuyuki.Shiiba
社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて
「チームでプロダクト開発するための取り組み」の補足 - maru source
昨日、Cookpad TechConf 2017にて「チームでプロダクト開発するための取り組み」というタイトルで登壇しました。 speakerdeck.com www.youtube.com 発表後にTwitterをエゴサーチしてると、評判が良かったようで一安心していました。 しかしその評判が想像以上に良くて、ちょっと自分の中でギャップを感じました。 で、よくよく考えてみると、一つ前提が抜けていたなと思い、今ブログを書いています。 その前提とは チームメンバーはすごく技術力も実装力もあるエキスパート 僕などよりも全然高いレベル 対象とするプロダクトを現時点で作れるレベルの能力を持っている もしくは作れるレベルのポテンシャルを持っている かつ、自分自身で成長・自走していくことができる というものです。 この前提があると何が良いのかを少し説明します。 一つ。チームメンバーには作ろうとしているプ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術的負債と向き合う
