Rotina do Product Owner

PProduct Owners (Donos do Produto ou PO) tem responsabilidades diárias com o time de desenvolvimento como revisão, planejamento, detalhamento, e discussões. Product Owner são responsáveis pelos requisitos de software (Epics, Features, Stories). Esta responsabilidade é de ponta-a-ponta do ciclo de vida do software. Os requisitos de software mais granulares são chamados Stories  em um projeto que utiliza metodologia ágil (Scrum, SAFe, DaD, …).

Neste post vou comentar sobre a rotina de um PO. Os exemplos são reais e mostram como é a prática em um ambiente de projetos ágeis. Você terá que adaptar para o seu contexto. Aqui temos o conceito como MVP, Scrum, SAFe, Comunicação Assíncrona, Times remotos e multiculturais. Vou tentar explicar cada um deste pontos.

O primeiro tópico é sobre a rotina do PO. Mais especificamente a rotina de acompanhamento das Stories sendo desenvolvidas pelo time.

Rotina Matinal do PO

Minha rotina quando estou usando o chapéu de PO é a sequinte:

  1. Verificar se existe alguma dúvida ou impedimento (On Hold or Blocked). 
    1. Caso Exista, responder ou direcionar a melhor forma de resolver o assunto.
    2. Indicar prioridade da Story (On Hold) sobre novas Stories no backlog, caso necessário.
  2. Verificar o que está pronto (In Review).
    1. Caso o teste resulte em Bugs ou Comportamentos não esperados então é indicado para o Dev o cenário.
    2.  Caso o teste resulte em novos casos não especificados anteriormente é criado novas Stories para o proximo Sprint.
    3. Caso tudo está como esperado é respondido um OK :-) .
  3. Verificar Backlog
    1. As prioridades continuam as mesmas?
      1. Caso Sim, então não é necessário mexer nas prioridades.
      2. Caso Não, então é necessário mover as Stories mais importantes para o topo da lista do backlog.
    2. Existem tarefas até o fim do Sprint?
      1. Caso sim, garanta que estas Stories tem os detalhes necessários.
      2. Caso não, Verifique com a equipe se é importante adicionar mais stories no backlog.

Com os passos comentados você garante que o time pode iniciar o dia sem impedimentos e alinhados com os objetivos comuns. O proximo passo é a preparação das próximas iterações (Sprints), vou escrever sobre isto na próxima alteração.

Preparando as Próximas Stories

… próximo tema …

Cenários Esperados ou Erros Comuns

… próximo tema …

 

Ultima alteração: 27 Out 2015

Gostou? útil? Então por favor faça um Like, Retweet, Share ou comentário no Twitter,  ou LinkedIn.

Composite Design Pattern using Java and Database

Compositecomposite Design Pattern helps the developer to abstract a information tree structure in code. The following example shows how to use in a Hierarchical Filter need. This page is in a continuous writing mode, check later for new updates or ask me on my twitter.

The main idea here is to present how to use it, if you want a background on composite patter I recommend Gamma et al. book[1]. The diagram to present the composite is the follow, for this diagram I use OPM (Object Process Methodology)[2] which shows a Hierarchical Flow process containing multiple Filters subprocesses which is invoked by it.

composite-design-pattern-for-hierarchical-flow

Figure 1 – Composite design pattern

The implementation requires two steps the pattern coding, the controller coding for filter and flow loading.

<Next writing topic>

Jumping to controller implementation. The controller will load the composite classes according to database configurations. As first step the configuration of the composite hierarchy is needed, the suggestion here is to keep the configuration inside the database as a entity relationship model. Database tables will provide the model for further view(e.g. JSON) implementation. The following diagram show how use a composite within conjunction with traditional database implementation.

Configuring-and-using-a-composite-class

Figure 2 – Business Controller in conjunction with Composite Pattern

The configuring process can be implemented using database as datasource which will store  all composite information.

References:

[1]Design Patterns: Elements of Reusable Object-Oriented Software

[2]Object-Process Methodology: A Holistic Systems Paradigm

Ultima atualização: 20/Set/2015