O Propósito do Guia SCRUM - IX

Product Owner - PO

26. Qual a principal função do Product Owner?

• É o responsável por maximizar o valor do produto e do trabalho da equipe de desenvolvimento.

O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto.

27. Quais atividades podemos listar como gestão do backlog do produto?

• Expressar claramente os itens do Backlog do Produto.
• Ordenar os itens do Backlog do Produto do projeto para alcançar as metas e missão do projeto.
• Garantir o valor do trabalho realizado pelo time de desenvolvimento.
• Garantir que o Backlog do Produto seja:
• Visível
• Transparente
• Claro para todos
• Mostrar o que o time de SCRUM irá trabalhar a seguir
• Garantir que a equipe de desenvolvimento entenda os itens do Backlog do Produto satisfatoriamente para o seu desenvolvimento.

O Product Owner pode delegar as atividades acima para a equipe do projeto, mas ele continua sendo o responsável. Ele é uma pessoa e não um comitê, todas as solicitações de alterações devem ser dirigidas a ele.

28. Como garantir o sucesso do Product Owner?

• Respeitando as suas decisões.

Todas as decisões do Product Owner devem ser visíveis no conteúdo e na priorização do Backlog do Produto.

O Scrum Master
 

29. Qual o papel do Scrum Master?

• Garantir que o Scrum seja entendido e aplicado, de forma que o Time Scrum conheça à teoria, práticas e regras do Scrum.
• Ajudar aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais não são.
• Ajudar a todos a mudarem as interações para maximizar o valor criado pelo Time Scrum.

30. Como o Scrum Master trabalha para o Product Owner?

• Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;
• Comunicando a visão, objetivo e itens do Backlog do Produto para a Equipe de Desenvolvimento;
• Ensinando a Time Scrum a criar itens de Backlog do Produto de forma clara e concisa;
• Compreendendo a longo-prazo o planejamento do Produto no ambiente empírico;
• Compreendendo e praticar a agilidade; e,
• Facilitando os eventos Scrum conforme exigidos ou necessários.

31. Como o Scrum Master trabalha para a Equipe de Desenvolvimento?

• Treinando a Equipe de Desenvolvimento em auto gerenciamento e interdisciplinaridade;
• Ensinando e liderando a Equipe de Desenvolvimento na criação de produtos de alto valor;
• Removendo impedimentos para o progresso da Equipe de Desenvolvimento;
• Facilitando os eventos Scrum conforme exigidos ou necessários; e,
• Treinando a Equipe de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido.

32. Como o Scrum Master trabalha para a organização?

• Liderando e treinando a organização na adoção do Scrum;
• Planejando implementações Scrum dentro da organização;
• Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto empírico;
• Causando mudanças que aumentam a produtividade do Time Scrum; e,
• Trabalhando com outro Scrum Master para aumentar a eficácia da aplicação do Scrum nas organizações.

Equipe de Desenvolvimento

A Equipe de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada Sprint. Somente integrantes da Equipe de Desenvolvimento criam incrementos.

As Equipes de Desenvolvimento são estruturadas e autorizadas pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia da Equipe de Desenvolvimento como um todo.

33. Quais as características da Equipe de Desenvolvimento?

• São auto-organizadas. Ninguém diz a Equipe de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis;
• Equipes de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.
• O Scrum não reconhece títulos para os integrantes da Equipe de Desenvolvimento que não seja o de Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; Não há exceções para esta regra.
• Individualmente os integrantes da Equipe de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence à Equipe de Desenvolvimento como um todo; e,
• Equipes de Desenvolvimento não contém subequipes dedicadas a domínios específicos de conhecimento, tais como teste ou análise de negócios.

34. Qual o tamanho ideal para a equipe de Desenvolvimento?

• Cinco a nove desenvolvedores, ou seja, pequena o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho.

35. Quais os problemas das equipes pequenas?

• Menos de três integrantes na Equipe de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade. Equipes de desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint, gerando uma Equipe de Desenvolvimento incapaz de entregar um incremento potencialmente utilizável.

35. Quais os problemas das equipes grandes?

• Mais de nove integrantes é exigida muita coordenação. Equipes de Desenvolvimento grandes geram muita complexidade para um processo empírico gerenciar.

Ao menos que eles também executem o trabalho do Backlog da Sprint, o Product Owner e o Scrum Master não podem ser contados como integrantes da equipe de desenvolvimento.

Grande Abraço,

Gilberto Ribeiro.

Requisitos - XIII

Análise

A etapa de análise é a etapa na qual se faz o levantamento da necessidade existente e define-se de que forma o software a ser criado deverá solucionar esta necessidade.

Em alguns ambientes os desenvolvedores tem o mal costume de pular a etapa de análise passando diretamente a etapa de desenvolvimento. Isso causa frequentemente falhas na definição do software, ou seja, descobre-se após o desenvolvimento que o que foi feito não atende a necessidade existente.

Divisões da etapa de análise

• Levantamento de informações
• Desenho de processo (Use Cases)
• Modelagem de Dados (MER)
• Modelagem do sistema
• Prototipação
• Definições finais

Levantamento de Informações (Analista de Requisitos e de Sistema)

Nesta etapa o analista realiza o levantamento de informações com o usuário. O analista faz uso de muitas entrevistas com o usuário para descobrir as necessidades existentes.

• O analista deve estar atento as informações fornecidas pelo usuário, cada detalhe mencionado por usuário as vezes pode resultar em mudanças no planejamento que o analista já estava realizando.
• O analista não deve se confundir quando o usuário tentar indicar como algo deve ser feito fisicamente (estrutura de tabela, tela, programas, etc.). O usuário não tem conhecimento técnico para fazer essa indicação, o analista deve extrair do usuário apenas as especificações ligadas ao negócio da empresa.
• Nem sempre o usuário tem todas as informações que o analista precisa. Muitas vezes o usuário tem uma informação sobre o seu trabalho no momento, mas a diretoria tem um planejamento futuro em relação ao trabalho que afeta a aplicação e não é de conhecimento do usuário. Assim sendo o analista deve consultar outras pessoas além dos usuários da aplicação.

Desenho de Processo

• O desenho de processo é realizado com os dados colhidos no levantamento de informações. É uma demonstração gráfica da forma de funcionamento do negócio descrito pelo usuário.
• O desenho de processo é utilizado para apresentar o resultado do levantamento ao usuário. Na verdade as duas etapas são recorrentes, caso o usuário identifique erros no desenho de processo volta-se ao levantamento para acerta-los e assim consecutivamente até que o usuário aprove o desenho de processo.

Modelagem de Dados

Tendo o desenho de processo sido realizado parte-se para o modelo de dados. A criação do modelo de dados irá novamente se utilizar das informações obtidas durante o levantamento, mas poderá também ter necessidade de novas informações e obrigar o analista a retornar para a etapa de levantamento.

• O modelo de dados não é tão compreensível para um usuário leigo como o desenho de processo, portanto apresenta-lo ou não ao usuário pode ser uma decisão do analista.
• O modelo de dados deve ser dividido em lógico e físico, um estando mais próximo das características do negócio enquanto o outro demonstrando características físicas do banco de dados.
• O analista de sistemas nem sempre é um DBA, portanto o modelo de dados deve ser aprovado pela equipe de administradores de dados.
• Tendo o modelo de dados sido aprovado gera-se um script 0 do banco de dados, o script inicial deste banco
• Toda futura alteração do modelo de dados deve  ter a aprovação do DBA, que aproveita seu conhecimento das alterações para se preparar para a fase de implantação. As alteração são realizadas na forma de scripts evolutivos do banco de dados de forma a complementarem o script 0. Assim sendo ganha-se uma sequencia histórica de mudanças realizadas no banco de dados.

Modelagem do Sistema

Feita a modelagem de dados, modela-se o sistema que irá manipular esses dados. Pode-se utilizar DFDs, típicos da análise estruturada, ou diagramas de classe e Sequências, típicos da análise orientada a objetos.

• Obtêm-se como resultado desta etapa descrições gráficas dos módulos que serão gerados no sistema, quer sejam formulários/funções em aplicações estruturadas quer sejam classes/componentes em aplicações orientadas a objeto.
• Todas as etapas de análise são interligadas. A modelagem do sistema pode afetar todas as etapas anteriores, eventualmente exigindo que o analista retorne ao levantamento.
• É papel do analista, durante este processo, realizar suposições sobre diversas situações de negócio que porventura o usuário não tenha imaginado, garantindo assim que o sistema funcione de forma flexível mesmo frente a situações inesperadas. 

Prototipação

Feita a modelagem do sistema parte-se então para a construção do protótipo.

• O protótipo é um modelo das telas do sistema que tem por intenção obter do usuário a aprovação da navegabilidade do sistema e da forma como suas funcionalidades serão visualmente implementadas. 

Definições finais

Tendo obtido a aprovação do usuário para o desenho de processo e o protótipo a fase de análise encontra-se concluída em sua etapa mais formal.

Da fase de análise obtêm-se definições sobre como serão as fases seguintes:

• A partir das definições de análise é possível desenvolver um cronograma de execução
• A partir do cronograma e das necessidades do usuário é possível prever o pessoal que deverá ser envolvido nas fases seguintes do projeto (qtd. Desenvolvedores)
• A partir das informações acima é possível fazer uma previsão de custo do projeto e a partir desta informação a diretoria identifica sua real viabilidade.

Curiosidades sobre a etapa de análise

A etapa de análise na verdade não termina. Mesmo durante as etapas seguintes a análise continua a ocorrer,  se aprofundando mais tecnicamente no sistema. Eventualmente descobre-se na etapa de codificação novas características do negócio que alteram definições feitas em análise.

• O analista é, em geral, um gerente de projetos. Após a etapa de análise ele estará gerenciando os desenvolvedores na execução da especificação do sistema.
• O analista é em geral um já foi um desenvolvedor, mas que adquiriu um linguajar de negócios que permite que ele se comunique com os usuário na mesma língua destes, podendo desta forma extrair informações durante o levantamento.
• Quando desenvolvedor é comum que o analista não esteja 100% atualizado com as tecnologias atuais. 

Desta forma nem sempre o analista consegue realizar as melhores opções em termos de tecnologia para o projeto e, nos piores casos, o analista chega a ter dificuldade de falar com os desenvolvedores. Neste caso é necessária a presença de um outro personagem, o arquiteto do sistema, que tem por finalidade definir as tecnologias a serem aplicadas para execução do projeto, definir as metodologias de desenvolvimento a serem usadas pelos desenvolvedores e fazer a tradução entre o analista e os desenvolvedores quando necessário. 

A equipe de suporte deve trabalhar em conjunto do analista ou do arquiteto do projeto na definição física do projeto, iniciando uma especificação de equipamentos que serão necessários ao projeto.

Grande Abraço,

Gilberto Ribeiro.