＼回答があります！／

• 

  石垣雅人

  プロジェクトマネジメント

  1年前
  チーム再編が起きたら、基本的やり直しになると思います。
  タックマンモデルでいうと、最初のほうの形成期に戻ってしまうことになります。よくある話としてはやっぱりチームの過半数が変わってしまった場合、文化もガラッと変わると思うので、1個の目安としては「半分以上変わる」かなと思っています。
  
  例えば、今あるチームに新卒が1人来てとか、そういったことであれば全然問題ないのですが、半分以上が変わるとか、プロジェクトでみんなが個々に散らばっていくふうだと、基本的に全部やり直しになるのかなと思います。
  
  スクラムというやり方自体は、チームの価値、チームの資産で大事に関する考え方もあると思うのですが、やっぱりチームという単位で結構大事になってくるので、チームを壊すと生産性もなかなか振り出しに戻るところがあります。
  
  マネジメントとしては、機能期に至っているようなチームは基本的に、人を入れ替えないようにはした方が良いと思います。強化はするのですが、DMM自体がプロジェクトチーム体制ではなく、プロジェクトごとに人を集めるというものではなく、ちゃんとプロダクトチームの集合体なので、結構そういう文化もあります。
  
  「1プロダクト・1チーム」と、ちゃんとそういうふうにした上で、チームの資産というのは大事にしているのがあるので、基本的にあんまりチームの再編はしないようにするというのが大事だと、気をつけている観点ではあります。
  view数 30

• 

  Takuo Doi

  エンジニア

  1年前
  ちょっと語弊のある言い方かもしれませんが、管理する、予測することに価値を置いている開発においては、No Estimateは適さないのではないかと思います。
  
  ストーリーポイントを見積ることにより、スプリントゴールの設定に根拠を持つことができます。
  ストーリーポイントを見積り、ベロシティを計測することで、リリースの目安を算出することができるようになります。
  
  これらに価値があるのであれば、個人的には見積った方がよいと思います。
  
  - 継続的にサービスを提供しているプロダクトを開発しており、納期を設定することの価値が大きくない。
  - スクラムチームに次のスプリントで対応可能なユーザストーリを判断できるだけの成熟度がある。
  といった状態であれあば、優先度の高いストーリーにフォーカスし続けることで、開発はうまく回るという立場がNo Estimateかと思います。
  
  前者の観点は、開発しているプロダクトや組織の文化に起因するものかと思います。
  後者に関して考えれば、チーム再編が発生すれば、少なくとも成熟度は下がります。ただ、スキルのある人の再編なのか、スキルのない人も含めての再編なのか、文化の共有はできているのか、再編の頻度と、成熟度の向上と再編の頻度とどちらが勝るのかなどによるのかなと思います。
  
  逆に言えば、上司は納期の目安を欲しがっており、それは重要なタスクであり、社外の文化を共有していないパートナーのエンジニアが頻繁に出入りするのであれば、見積った方がメリットは大きい可能性はあります。
  view数 47