Time Scrum, Papéis e Aspectos do Framework

Olá, pessoal vamos prosseguir com o Scrum e para fechar o assunto vamos falar hoje sobre o time, papeis de cada um e aspectos deste Framework. Espero que gostem!
Como vimos no post anterior esse Framework utiliza algumas reuniões para delinear seu processo de incremento do produto que ocorre através das Sprints. Então vamos ver quem faz parte do Time Scrum.

O Time Scrum: O time Scrum é composto por desenvolvedores que transformam o Backlog do produto em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. Membros do tipo Scrum frequentemente possuem conhecimentos especializados, como programação, controle de qualidade, analise de negocio, arquitetura, projeto de interface de usuário ou projeto de banco de dados.
Os Times Scrum são auto-organizáveis e cada componente pode atuar em áreas especificas de seu conhecimento como em outras áreas conforme necessidade, mesmo que isso exija do componente aprender e desenvolver novas habilidades.
O tamanho ótimo para um time Scrum é de sete pessoas contato com variação de dois para mais ou para menos. Quando há cinco ou menos membros no time, há menor interação e, como resultado, há menor ganho de produtividade. Ainda pode-se encontrar dificuldade técnicas que acarretaram dificuldades em entregar partes da Sprint trabalhada.
Quando o time possui nove componentes ou mais, há uma necessidade maior de coordenação do time. Times grades geram muita complexidade para que um processo empírico consiga gerenciar.
O Product Owner e o Scrum Master não estão incluídos na conta das equipes, a menos que estes executem mais de um papel na instituição.
A composição do time Scrum pode mudar ao final da Sprint, porém, toda vez que o time muda, o ganho de produtividade reduz porque a auto-organização do time requer entrosamento entre a equipe.

Product Owner: Product Owner é a única pessoa responsável pelo gerenciamento do Backlog do Produto e por garantir o valor do trabalho realizado pelo Time, ele é o dono do produto!
Essa pessoa matem o backlog do produto e garante que ele esta visível para todos. O Product Owner é uma pessoa e não um comitê, por tanto, mesmo que se tenha um comitê que define prioridades do produto, essa prioridade será representada pelo Product Owner e ele é o responsável por seu Backlog.
Para que o Product Owner obtenha sucesso, todos na organização precisam respeitar suas decisões. Ninguém tem permissão de dizer ao Time Scrum para trabalhar em outro conjunto de prioridades uma vez que o Product Owner é quem defini as prioridades do Backlog do Produto.

ScrumMaster: O ScrumMaster é o responsável por garantir que o time Scrum esteja aderindo aos valores do Scrum, às praticas e as regras. O ScrumMaster educa o time treinando-o e levando-o a ser mais produtivo e a desenvolver produtos de maior qualidade.
O papel do ScrumMaster é ajudar o time Scrum a entender e usar o autogerenciamento e interdisciplinaridade. No entanto, o ScrumMaster não gerencia o time Scrum; o time Scrum é auto-organizável.

O Framework Scrum, consiste ainda em trabalhar com eventos com duração fixa, artefatos e regras e agora vamos conhecer um pouco mais dessa parte importante para o processo.

Eventos de duração Fixa: no primeiro post, vimos que temos reuniões especificas para cada etapa e cada reunião possui um Time-boxe, ou seja, uma duração fixa.
As reuniões presentes no Scrum e que possuem um time-boxe especifico são:
Reunião de Planejamento da Versão para Entrega: O propósito dessa reunião é estabelecer um plano e metas que o time Scrum e o resto da organização possam entender e comunicar. Essa etapa responde a pergunta: “Como podemos transformar a visão em um produto vencedor da melhor maneira possível?
O plano da versão para entrega estabelece a meta da versão, as maiores prioridades do backlog do produto, os principais riscos e as características gerais e funcionalidades que estarão contidas na versão. Ela estabelece também uma data de entrega e custo prováveis que devem manter se nada mudar.
Ao se utilizar o Scrum, os produtos são construídos interativamente, de modo que cada sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco. Mas e mais Sprints vão adicionando incrementos ao produto. Cada incremento é um pedaço potencialmente entregável do produto completo.
Quando já tiverem sido criados incrementos suficientes para que o produto tenha valor e uso para seus investidores, o produto é entregue.

Sprint: Sprint é o tempo em que o time Scrum se dedica para desenvolver o Backlog de produto definido na Reunião de planejamento da Sprint. Durante a Sprint, o ScrumMaster garante que não será feita nenhuma mudança que possa afetar a Meta da Sprint. Tanto a composição do time quanto as metas de qualidade devem permanecer constantes durante a Sprint.
As Sprints ocorrem uma após a outra, sem intervalos entre elas. O Scrum é um framework para projetos cujo horizonte não é superior ao período de um mês, onde já há complexidade suficiente para tal que um horizonte mais longo seria arriscado demais. A previsibilidade do projeto deve ser controlada pelo menos a cada mês, e o risco de que o projeto saia de controle ou se torne imprevisível é contido pelo menos a cada mês.
Somente o Product Owner tem o poder para cancelar uma Sprint, embora ele possa fazê-lo sob influencia das partes interessadas, do Time Scrum ou do ScrumMaster. A gerencia pode solicitar ao Product Owner que cancele uma Sprint sob varias situações como: Mudança de estratégia da corporação, Tecnologia, mudanças de mercado, etc. Em gera uma Sprint só deve ser cancelada se esta não fizer mais parte das circunstancias atuais.
O cancelamento de uma Sprint é traumático e consome recursos já que todos terão que se reagrupar em outra reunião de planejamento de Sprint para iniciar nova Sprint.

Revisão da Sprint: Ao final da Sprint, é feita uma reunião de revisão da Sprint. Para Sprints de um mês, essa é uma reunião com duração de 4 horas e proporcional a Sprints de menor período.
Durante a Revisão da Sprint, o time Scrum e as partes interessadas colaboram sobre o que acabou de ser feito. Baseados nisso e em mudanças no Backlog do Produto feitas durante a Sprint, eles colaboram sobre quais são as próximas coisas que podem ser feitas.
A reunião inclui o Product Owner, o Time Scrum e o ScrumMaster e fornece entradas valiosas para as reuniões de planejamento de Sprints seguintes.

Retrospectiva da Sprint: Essa reunião acontece antes da próxima reunião de planejamento da  Sprint. Nesta reunião, com duração fixa em três horas, o ScrumMaster encoraja o Time a revisar, dentro do modelo de trabalho e das práticas do processo do Scrum, seu processo de desenvolvimento, de forma a torna-lo mais eficaz e gratificante para a próxima Sprint.

A finalidade da Retrospectiva é inspecionar como correu a última Sprint em se tratando de pessoas, das relações entre elas, dos processos e das ferramentas. A inspeção deve identificar e priorizar os principais itens que correram bem e aqueles que, se feitos de modo diferente, poderiam ter deixado as coisas ainda melhores. Isso inclui a composição do Time, preparativos para as reuniões, ferramentas, definições de “pronto”, métodos de comunicação e processos para transformar itens do Backlog do produto em alguma coisa pronta.

Ao final da retrospectiva, o Time Scrum deve ter identificado medidas de melhoria factíveis e essas mudanças se tornaram a adaptação para a inspeção empírica da próxima Sprint.

Reunião Diária: Cada Time se encontra para uma reunião de 15 minutos, sendo essa reunião realizada sempre no mesmo lugar e horário.

Durante a reunião cada membro explica:

1 - O que realizou desde a ultima reunião diária?

2 – O que ele vai fazer antes da próxima reunião diária (que será a próxima reunião)?

3 – Quais obstáculos estão em seu caminho?

As reuniões diárias melhoram a comunicação, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada de decisão, melhoram o nível de conhecimento de todos acerca do projeto.

O ScrumMaster garante que o time realize essa reunião, ensina o time a manter a reunião com o prazo estipulado reforçando as regras garantindo que as pessoas falem brevemente. O ScrumMater também enfatiza a regra em  que somente o time tem poder de fala nesta reunião.

A reunião diária não é uma reunião de status, ela é uma reunião de acompanhamento e inspeção do progresso em direção a meta da Sprint. Só participam pessoas do time Scrum que estão transformando o backlog de produtos em um incremente utilizável. A intenção é sempre otimizar a probabilidade de que o time alcance a meta da sprint.

 

Pessoal, o Scrum é muito mais que um simples Framework ou metodologia.Conheça mais de seus processos pesquisando as referencias abaixo e nos fale de suas experiencias.

No mercado existem profissionais certificados em desenvolvimento utilizando o Scrum, para saber mais acesse: http://www.scrum.org/Assessments/Professional-Scrum-Master-Assessments

Referencias usada para esse artigo:

Guia do Scrum – Ken Schwaber, maio de 2009.

http://pt.wikipedia.org/wiki/Scrum

Scrum - Conceitos básicos

Olá, pessoal hoje vamos falar sobre Scrum esse framework que tem se tornado uma metodologia muito utilizada em empresas que precisam otimizar seus processos.

Primeiramente é importante esclarecer que Scrum não é um processo ou uma técnica para o desenvolvimento de produtos. Ao invés disso, é um Framework dentro do qual é possível empregar diversos processos e técnicas.

Na teoria o Scrum é fundamentado em processos empíricos e emprega uma abordagem interativa e incremental para otimizar a previsibilidade e controlar riscos. Num processo empírico existem três pilares básicos que o sustentam, são eles: A Transparência, a Inspeção e a Adaptação. Vamos falar um pouco mais desses pilares.

A transparência: A transparência garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados.

A Inspeção: Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que as variações inaceitáveis no processo possam ser detectadas o quanto antes.

A Adaptação: Se o processo é transparente, ou seja, sabe-se o que será produzido e entregue e através da Inspeção se garante que nada vai sair do planejado, logo a adaptação não seria necessária, porém, todo produto ou serviço passa por mudanças simplesmente pelo fato dele existir. Essas mudanças ou melhorias ou ate chamadas atualizações são identificadas para que o pilar da adaptação possa ser acionado.

Se o inspetor determinar, a partir da inspeção, que um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, ele deverá ajustar o processo ou o material sendo processado.

Existem três pontos para inspeção e adaptação em Scrum e vamos falar deles agora.

A Reunião diária: A reunião diária é usada para inspecionar o progresso em direção á meta da Sprint e para realizar adaptações que otimizem o valor do próximo dia de trabalho.

A reunião diária possui uma duração de 15 minutos e dever ser sempre realizada no mesmo local. O objetivo dessa reunião é: inspecionar se o que foi programado para a Sprint passada foi concluído, saber o que será feito e como será feito na Sprint do dia e acima de tudo inspecionar se a meta da Sprint esta sendo cumprida.

Nesta reunião participam apenas pessoas do Time Scrum e o ScrumMaster é o responsável por ensinar o time a manter a disciplina quanto o tempo e assunto discutido na reunião.

Revisão da Sprint: Ao final da Sprint, é feita uma reunião para rever a Sprint. O tempo previsto para que essa reunião ocorra é de 4 horas para Sprints de um mês e o tempo proporcional para Sprints de tempo menor, por exemplo, 2 horas para Sprint de duas semanas.

Durante a revisão da Sprint, o time Scrum e as partes interessadas colaboram sobre o que acabou de ser feito. Baseados nisso e em mudanças no Backlog do produto feitas durante a Sprint, eles colaboram sobre quais são as próximas coisas que podem ser feitas. Essa é uma reunião informal, com a apresentação da funcionalidade, que tem a intenção de promover a colaboração sobre o que fazer em seguida.

A reunião inclui ao menos os seguintes elementos: O Product Owner, o Time Scrum e o Scrum máster.

A revisão de uma Sprint é muito importante porque fornece valiosas informações para a próxima Sprint que passara antes por uma reunião de planejamento da Sprint.

Planejamento de Sprint: O planejamento de uma Sprint é quando a interação é planejada. Essa reunião é fixada em oito horas para Sprints de um mês e proporcional para Sprints menores.

A primeira parte da reunião conta com a participação do Product Owner e é fixada em quatro horas de duração. Nesta etapa o Product Owner explica o que é mais prioritário no backlog de do produto. Neste momento é trabalhado o que será entregue durante a próxima Sprint. Cabe somente ao Time Scrum avaliar o que ele é capaz de entregar na próxima Sprint. O principal para ocorrer essa reunião é ter o backlog do produto porque, a partir desse backlog é que se defini o que será entregue.

A segunda parte da reunião, fixada em quatro horas é a etapa onde o time Scrum entende como será desenvolvido o backlog do produto, como será transformada a funcionalidade em um incremento utilizável com um valor e qualidade bem definidos.

Uma vez selecionado o Backlog do produto, a meta da Sprint é delineada. A meta da Sprint é um objetivo que será atingido através da implementação do backlog do produto.

Ate agora falamos de pilares presentes num processo empírico e de como esses processos são acompanhados. No próximo post vamos falar do time Scrum, quem são os componentes do time, qual o papel de cada um e qual o resultado final dessa interação. Não deixe de ler!

Referencias usada para esse artigo:

Guia do Scrum – Ken Schwaber, maio de 2009.

http://pt.wikipedia.org/wiki/Scrum

Introdução à modelagem utilizando UML

Ola Pessoal,
hoje vamos valar sobre modelagem UML, espero que gostem!

UML ou Unified Modeling Language é uma linguagem de modelagem não proprietária de terceira geração. A UML não é uma metodologia de desenvolvimento, o que significa que ela não diz para você o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicação entre objetos.

Basicamente, a UML permite que desenvolvedores visualizem os produtos de seus trabalhos em diagramas padronizados. Junto com uma notação gráfica, a UML também especifica significados, isto é, semântica.

Os objetivos da UML são: especificação, documentação, estruturação para sub-visualização e maior visualização lógica do desenvolvimento completo de um sistema de informação. A UML é um modo de padronizar as formas de modelagem. A UML é o padrão da industria para modelagem de softwares que usam a orientação a objetos (OO).

Entre os anos 80 e 90 havia muitos conflitos na definição de nomenclatura na área de modelagem. A escolha de padrões era feito a gosto pessoal do que por fatores técnicos. Com isso os três nomes mais respeitados nessa área, cada qual com seus conceitos sendo eles o Ivar Jacobson, Grand Booch e James Rumbaugh, decidiram criar um modelo único que veio a ser UML. A UML seria como uma planta para construção do seu sistema e pretende ser a linguagem de modelagem padrão para modelar sistemas concorrentes e distribuídos.

A modelagem UML antecede as etapas de desenvolvimento ou analise de Hardware e ate mesmo de infraestrutura, estamos pensando apenas nos fluxos e ações de um sistema.

A modelagem UML apresenta de forma gráfica os elementos essências usados na orientação a objetos como as Classes, Atributos, Objetos, Troca de Mensagens, etc.

A modelagem UML utiliza-se de vários tipos de Visões para apresentação de diagramas UML e cada tipo possui uma característica e função principal.

·         Visão do modelo de Usuário: apresenta a visão do usuário em relação o sistema, sendo descrita principalmente pelo uso dos casos de Uso.

o   Diagramas de Caso de Uso.

Para montar esse diagrama é preciso obter os elementos: Ator, Casos de Uso e Relacionamentos.

O Ator é representado por um boneco e um rótulo com o nome do autor. O ator pode ser um usuário humano ou outro usuário sistema.

Casos de Uso: A UML pretende ser a linguagem de modelagem padrão para modelar sistemas concorrentes e distribuídos.

Relacionamentos: Define uma funcionalidade do sistema do ponto de vista do usuário. O relacionamento pode ocorrer entre Atores e entre Atores e Casos de Uso.

Os tipos de relacionamentos podem ser:

Associação: Define uma funcionalidade do sistema do ponto de vista do usuário.

Generalização: Esse tipo de relacionamento é comum quando temos Atores que se relacionam e esse tipo de relacionamento mostra que um Ator herda de outro Ator seus casos de uso, ou seja, ambos atores possuem casos de uso comuns.

Include: Indica que um dos casos de uso é essencial para o comportamento do outro caso de uso. Exemplo: Caso de Uso A relaciona-se com o Caso de Uso B com tipo Include. Essa relação diz que o Caso de Uso B é essencial para o Caso de Uso A.

Extend: Ponto de extensão de um caso de uso é uma indicação de que outros casos de uso poderão ser adicionados a ele. Quando o caso de uso for invocado, ele verificará se suas extensões devem ou não ser invocadas.

Um relacionamento extend de um caso de uso B para um caso de uso A indica que o caso de uso B pode ser acrescentado para descrever o comportamento de A. A extensão é inserida em um ponto de extensão do caso de uso A.

·         Visão do modelo Estrutural: apresenta a estrutura do sistema.

o   Diagrama de Pacotes: Objetivo principal é agrupar classes em pacotes. Todo sistema que não for comum precisa ser dividido em pacotes para ficarem mais fáceis de entender.

 

o   Diagrama de Classes: Especifica a estrutura estática do sistema segundo a abordagem orientada por objetos. Mostra a estrutura de classes e como estas se relacionam com seus Atributos, Métodos, Associações, Agregações, Heranças e Dependências.

ü  Garantir que a classe informe o comportamento necessário às realizações dos casos de uso.

ü  Garantir que sejam fornecidas informações suficientes para implementar a classe sem ambiguidades.

ü  Tratar dos requisitos não funcionais relativos à classe.

ü  Incorporar os mecanismos de design usados pela classe.

o   Diagrama de Objetos: variante do diagrama de classes. Representa um exemplo do diagrama de classes num determinado instante da execução do sistema. Utilizam quase a mesma notação que o diagrama de classes, a diferença é que o diagrama de objetos mostra os objetos que foram instanciados num relacionamento de classes.

o   Diagrama de Estrutura Composta: Um diagrama de estrutura composta pode ser utilizado para mostrar a decomposição de uma classe estruturada. Como exemplo, a figura a seguir mostra um diagrama de estrutura composta para bilheteria no sistema de ingressos. Esta classe é decomposta em três partes:

·         Uma interface com o vendedor de ingressos

·         Um guia de desempenho que recupera desempenhos de acordo com a data e outros critérios

·         Um conjunto de bancos de dados que contém os dados nos desempenhos e ingressos.

Cada peça interage por meio de uma interface bem definida especificada por suas portas. Toda a bilheteria interage com o exterior por meio de uma porta. As mensagens nessa porta são enviadas para a classe de vendedor de ingressos, mas a estrutura interna da classe de bilheteria é oculta para os clientes externos.

·         Visão do Modelo Dinâmico: apresenta à dinâmica e o comportamento do sistema, sua interação com o usuário e com sistemas externos.

o   Diagrama de Sequencia ou Diagrama de Comunicação/Colaboração: Para modelarmos como os objetos do sistema interagem entre si, é utilizado o diagrama de sequência ou o de colaboração. Usa-se modelar um diagrama para cada função (use-case) definida no diagrama de use-cases

o   Diagrama de Transição de Dados: É uma representação do estado ou situação em que um objeto pode se encontrar no decorrer da execução de processos de um sistema. Com isso o objeto pode passar de um estado inicial para um estado final, através de uma transição.

o   Diagrama de Maquina de Estado (estado de objetos): Este diagrama procura acompanhar as mudanças sofridas nos estados de uma instância de uma determinada classe. O diagrama de máquina de estados é um dos diagramas disponíveis na UML para a modelagem dos aspectos dinâmicos de sistemas. Assim como o diagrama de sequencia, o diagrama de máquina de estados muitas vezes baseia-se em um caso de uso descrito em um e apoia-se no diagrama de classes. 

o   Diagrama de Tempo: Apresenta o comportamento dos objetos e sua intenção em uma escala de tempo, focalizando as condições que mudam no decorrer desse período.

·         Diagrama de Implementação: apresenta aspectos estruturais do sistema relacionados ás necessidades de implementação.

o   Diagrama de Componentes: Serve para marcar como nosso sistema está dividido por módulos. E quais as dependências entre cada módulo. O diagrama de componentes enfatiza os componentes de software físico (imagens, bibliotecas, pacotes...).

Sua finalidade é adaptar a estrutura de modelo para refletir a organização da equipe ou as restrições da linguagem de implementação.

·         Visão do modelo de Ambiente: apresenta o modelo alvo e as necessidades para se colocar o sistema em funcionamento.

o   Diagrama de implantação ou Instalação: Descrevem os componentes de hardware e software e sua interação com os outros elementos de suporte ao processamento.

Representa a configuração e a arquitetura de um sistema em que estarão ligados seus respectivos componentes, sendo representado pela arquitetura física de hardware, processadores e etc...

Pessoal, agradeço a oportunidade de postar mais este post para todos e espero que gostem!

Não esqueça de enviar seus comentários, sugestão, critica e elógio para nós!

Abraço!

Referências usada:

http://pt.wikipedia.org/wiki/Uml