quinta-feira, 28 de janeiro de 2010

Programador Java

Fazion Sistemas Ltda, empresa especializada em mobilidade, solicita recurso urgente com os
seguintes conhecimentos:
Conhecimentos necessários:
Linguagem:
- Java;
- Servidor Web (Apache Tomcat);
- Conhecimento em Web Service ;
- Adobe Flex;
Banco de Dados:
- MySQL;
- PostGress;
- Oracle.
Engenharia de Software:
- Orientação a Objeto;
- Conhecimento em XML,
- Conhecimento SQL;
Outros:
- Trabalhar em equipe;
- Inglês avançado;
- Acima de 01 ano de experiência em programação
Área de Atuação:
- Desenvolvimento de aplicativos Web integradas as aplicações Mobile (celular)
utilizando a linguagem Java.
Área de formação: Sistemas/Computação/Automação/Mecatrônica ou áreas afins.
Local de Atuação:
- Irá atuar no núcleo de desenvolvimento de Florianópolis, no bairro Agronômica,
próximo ao Beira Mar Shopping. Site www.fazion.com.br
Período de trabalho: Segunda-feira a Sexta-feria em horário comercial. Contrato CLT / PJ.
Benefícios: Vale transporte, vale alimentação.
Os interessados deverão enviar curriculum, para info@fazion.com.br ,com pretensão salarial.

Analista Desenvolvedor Júnior

Desenvolvimento JAVA na criação sistemas web.


Área de Atuação
Área de TI – Suporte de sistemas (Corretivas e melhorias nos sistemas implantados)

Formação
Superior ou em andamento em: Ciência da Computação / Sistemas de Informação e áreas afins.

Conhecimentos requeridos

• Orientação a objetos
• Desenvolvimento de aplicações web (Servlet e JSP)
• Framework Struts 1.x
• Persistência de dados (JDBC)
• CSS

Conhecimentos desejáveis

• Oracle e MySQL
• EJB 3, JPA, Hibernate
• Conhecer framerowks
• Ter conhecimento em análise de sistemas (requisitos, documentações)
• Conhecer design patterns e suas aplicações (MVC, etc...)

Salário

R$ 2.830,50 (CLT)

Benefícios

• Vale alimentação no valor de R$ 374,00 (mês)
• Plano de saúde – Unimed enfermaria/Nacional (sem desconto da mensalidade, paga somente a co-participação) não se estende para os dependentes.
• Plano odontológico – Uniodonto
• Plano de previdência privada: após experiência 30,00 por mês (parte da empresa)
• Seguro de vida (sem nenhum desconto para o colaborador)
• Auxilio educação (obedecendo algumas regras da empresa)

Interessados enviar currículo para: vagas@portal.unimed.com.br com o assunto: Vaga Analista Desenvolvedor Junior para Suporte

Potencializando Scrum

Oi pessoal,

Faz tempo que não coloco nenhum post no Blog, é a correria do dia a dia. Aulas na faculdade, treinamentos, coach, desenvolvimento de software, etc. Meus amigos sabem como eu sou, não paro, os meus dias são divididos em três períodos de trabalho, manha, tarde e noite.

Mas mesmo nesta correria sempre eu busco um tempo para um post no blog, então vamos lá...





A potencialização do processo Scrum já foi comentada neste blog, mas não custa enfatizarmos mais um pouco sobre o assunto.

Jeff Sutherland um dos criados do Scrum, escreveu um artigo fantástico sobre a união de Scrum e CMMI nível 5, onde o artigo traz uma serie de procedimentos necessários para que este casamento seja possível. Estes procedimentos para atendimento do CMMI nível 5 não fazem parte do escopo deste material.

Mas um destes procedimentos está a potencialização do Scrum para o que ele chamou de “Entendendo o Sucesso do Scrum”.

Jeff traz o conceito de “Pronto” e “Feito”, onde “Pronto” são requisitos possíveis de serem implementados e “Feito” é o requisito desenvolvido conforme os critérios de aceitação do Product Owner.

O “Feito” é a nossa coluna de “Done” de um quadro de Kanban (também chamado de Taskboard), que é definido entre a equipe e o Product Owner.

Para aumentar a velocidade da equipe com os requisitos “Prontos”, os mesmos são escritos pelo Product Owner com o auxilio do Scrum Máster, eles juntos realizam um trabalho de preparação do material da próxima Sprint e quando este material chega ao planejamento da Sprint ele possui um nível de maturidade maior, para que a equipe possa realizar a analise de sistemas do mesmo e o seu planejamento de execução.

Jeff faz a observação que: “Pronto e Feito são simples de entender, mas difícil de ser realizado” e “O segredo está no balanceamento apropriado entre o planejamento e a execução de atividades”.

O link do material é:
http://jeffsutherland.com/scrum/PracticalRoadmapMunich20091020.pdf


Os requisitos “Prontos” é o que eu chamei neste material de requisitos quadrados e redondos. Onde um requisito quadrado traz problemas na analise de sistema, planejamento e execução. Já os requisitos redondos permitem a sua analise, planejamento e execução em velocidade e qualidade pela equipe de desenvolvimento do projeto. Toda vez que um requisito quadrado entra na execução da Sprint ele é um candidato a gerar impedimentos e conseqüentemente trazer problemas na execução da Sprint, trazendo impacto na velocidade de produção da equipe.



Abraço a todos,

Abu

quinta-feira, 21 de janeiro de 2010

Vagas de Emprego

Descrição da vaga
Analista Desenvolvedor Júnior
Desenvolvimento JAVA na criação sistemas web.

Área de Atuação
Área de TI – Suporte de sistemas (Corretivas e melhorias nos sistemas implantados)

Formação
Superior ou em andamento em: Ciência da Computação / Sistemas de Informação e áreas afins.

Conhecimentos requeridos
• Orientação a objetos
• Desenvolvimento de aplicações web (Servlet e JSP)
• Framework Struts 1.x
• Persistência de dados (JDBC)
• CSS

Conhecimentos desejáveis

• Oracle e MySQL
• EJB 3, JPA, Hibernate
• Conhecer framerowks
• Ter conhecimento em análise de sistemas (requisitos, documentações)
• Conhecer design patterns e suas aplicações (MVC, etc...)

Salário
R$ 2.830,50 (CLT)

Benefícios
• Vale alimentação no valor de R$ 374,00 (mês)
• Plano de saúde – Unimed enfermaria/Nacional (sem desconto da mensalidade, paga somente a co-participação) não se estende para os dependentes.
• Plano odontológico – Uniodonto
• Plano de previdência privada: após experiência 30,00 por mês (parte da empresa)
• Seguro de vida (sem nenhum desconto para o colaborador)
• Auxilio educação (obedecendo algumas regras da empresa)

Interessados enviar currículo para: vagas@portal.unimed.com.br com o assunto: Vaga Analista Desenvolvedor Junior para Suporte

++ Vagas de Emprego

Desenvolvedor Java Web Pleno

A empresa

A Chaordic Systems é pioneira no desenvolvimento de tecnologias de recomendação no Brasil. Nosso departamento de P&D é responsável por entregar soluções robustas de personalização para grandes empresas do varejo eletrônico nacional. Nossos softwares inteligentes empregam técnicas de aprendizado de máquina e mineração em enormes quantidades de dados. Eles são responsáveis por direcionar o processo de consumo online e identificar inteligência coletiva na web.
Alguns dos benefícios oferecidos pela empresa a seus profissionais, são:
Remuneração proporcional à experiência
Plano de Saúde
Participação nos resultados
Possibilidade de residir em Florianópolis
Forte interação com a UFSC e universidades da região
Possibilidade de iniciar um Mestrado ou Doutorado

A vaga

O profissional irá integrar uma equipe de P&D ágil e multidisciplinar responsável pelo desenvolvimento de aplicações Web. São competências do Desenvolvedor Java Web Pleno:
Analisar, projetar e construir componentes de aplicações Web, através de técnicas de modelagem e design orientado a objetos, codificação de algoritmos complexos e abordagens sistemáticas para integração de aplicativos.
Desenvolver aplicações web complexas de alta disponibilidade, com manipulação de grande volume de dados.
Contribuir para o estabelecimento de padrões de desenvolvimento e criação de bibliotecas.
Auxiliar na elaboração de APIs e WebServices.
Auxiliar na modelagem de sistemas de banco de dados de alta performance.

O candidato

O candidato deve ter experiência profissional relacionada à vaga de pelo menos 4 anos e as seguintes qualificações:
Sólidos conhecimentos na plataforma Java e em alguma segunda linguagem.
Sólidos conhecimentos em programação orientada a objetos e padrões de projeto.
Proficiência em desenvolvimento JavaScript, CSS, XHTML e SQL.
Experiência com WebServices utilizando SOAP e/ou REST
Familiaridade com o sistema operacional Linux, controle de versão (subversion), TDD (JUnit).
Experiência prática em metodologias ágeis de desenvolvimento (Scrum e XP).
Vontade e facilidade em aprender novas tecnologias e ferramentas.
Fácil comunicação.
As seguintes características serão consideradas diferenciais importantes:
Titulação de Bacharel, Mestre e/ou certificações em áreas relevantes.
Habilidade em gerenciamento de projetos.
Experiência com desenvolvimento em C++ e Python.
Conhecimento nas seguintes tecnologias: Hibernate, Spring, JQuery, JSUnit, Selenium, Jmeter, Lucene.
Conhecimento de algoritmos de IA, Machine Learning e Data Mining.
Experiência com tunning de MySQL.

Os interessados devem mandar o currículo para rh@chaordicsystems.com. (Evitar currículo no padrão lattes)

quarta-feira, 20 de janeiro de 2010

+ Vagas de Emprego

Vaga: Arquiteto Junior
Local de Trabalho: Itaim Bibi - SP
Forma de contratação: CLT
Escolaridade: Superior em curso ou completo em Arquitetura
Perfil: Imprescindível conhecimento em AutoCAD e experiência no ramo de móveis corporativos. Dinamismo, conhecimentos técnicos, pro atividade, atenção concentrada, visão espacial, ótimo relacionamento interpessoal, firmeza e autonomia completam o perfil.
Pretensão salarial: favor informar pretensão salarial no currículo

Vaga: Desenhista Técnico
Local de Trabalho: Barueri - SP
Forma de contratação: CLT
Escolaridade: Curso técnico ou Superior em curso ou completo
Perfil: Imprescindível conhecimento na leitura, interpretação e confecção de desenhos técnicos. Desejável experiência em Autocad e conhecimentos da área de móveis será um diferencial. O profissional irá interpretar e/ou desenhar tecnicamente móveis de escritório e afins para programação em máquina especial. Força de vontade, atenção concentrada, dinamismo, pro atividade e conhecimentos técnicos completam o perfil da vaga
Pretensão salarial: favor informar pretensão salarial no currículo


Interessados enviar currículo para: consultório-psicologia@bol.com.br COM pretensão Salarial.

Desde já agradeço pela atenção e auxílio

Um abraço e ótima semana

Fabiana Nunes
Psicóloga
consultorio-psicologia@bol.com.br

sexta-feira, 8 de janeiro de 2010

Novo Material de Scrum do Abu

Oi pessoal,

Eu tenho atualizado o material de Scrum do Abu todos os anos, o ano passado foi gerado uma apostila de 125 paginas, com uma coletânea de post realizados no Blog. Este ano eu escrevi 61 paginas sobre Scrum, onde o objetivo foi escrever um material novo, material este que vai ser disponibilizado no Blog em forma de post.

Fiquem a vontade para realizar apontamentos de erros técnicos ou ortográficos. Também fiquem a vontade de encaminhar sugestões de melhorias ou itens não abordados e que deveria fazer parte do material.

Também fique a vontade de distribuir o material a quem desejar.

Para receber o material basta mandar um e-mail para abuzitos@gmail.com

Muito Obrigado,

Abu

Review

Oi pessoal,

Este texto faz parte do material da apostila de Scrum do Abu versão 2.0.

Por favor, fiquem a vontade para fazer criticas com relação a ortográfica e a parte técnica. O e-mail de contato é abuzitos@gmail.com

Após a correção técnica e ortográfica o material vai ser disponibilizado para download.

Novo tabuleiro do Processo do Scrum do Abu - http://blogdoabu.blogspot.com/2009/12/novo-tabuleiro-do-processo-do-scrum.html

Abraços,

Abu


Review, também conhecido como entrega dos trabalhos realizados na Sprint pela equipe de execução do projeto para o Product Owner.

A entrega dos trabalhos realizados ao Product Owner não “deveria” ter surpresas para o mesmo, se nos temos um Product Owner presente durante o ciclo de desenvolvimento da Sprint, ele sabe o que nos estamos entregando e o que não estamos entregando. Ele também sabe os problemas que a equipe teve durante a execução da Sprint, não sendo necessária a apresentação de um “diário de bordo” com o check list de tudo que deu errado e que levou a uma entrega parcial dos trabalhos.

Na reunião de entrega será apresentado ao Product Owner o software desenvolvido para que ele aceite ou não as funcionalidades implementadas, os gráficos, os requisitos selecionados para a Sprint, o que foi feito, o que não foi feito e caso o Product Owner são tenha participado ativamente da Sprint, devemos ter o “diário de bordo” com os problemas que a equipe passou durante a execução da Sprint.

Uma boa dica para a realização da entrega do software é a equipe ter testado as funcionalidades antes de realizar a entrega, ter testado o ambiente que o sistema vai rodar e manter o foco na entrega de funcionalidades e não na evolução do sistema que está sendo entregue. Devemos entregar o que foi acordado com o Product Owner, isto é, requisitos implementados aderentes ao que nos foi passado.

Desenvolvimento e Reuniões Diárias

Oi pessoal,

Este texto faz parte do material da apostila de Scrum do Abu versão 2.0.

Por favor, fiquem a vontade para fazer criticas com relação a ortográfica e a parte técnica. O e-mail de contato é abuzitos@gmail.com

Após a correção técnica e ortográfica o material vai ser disponibilizado para download.

Novo tabuleiro do Processo do Scrum do Abu - http://blogdoabu.blogspot.com/2009/12/novo-tabuleiro-do-processo-do-scrum.html

Abraços,

Abu


É uma reunião diária de acompanhamento de execução do projeto realizada pela equipe. Nesta reunião participa com direito a falar apenas os denominados “porcos”, “frangos” podem participar, mas não tem direito a falar nesta reunião.

Esta reunião deve ter no máximo 15 minutos de duração e deve ser conduzida pelo “Scrum Master”. Recomenda-se que esta reunião seja realizada no período matutino, bem no inicio das atividades da equipe. Também recomenda-se que os participantes fiquem de pé. Esta reunião não é para solução de problemas e sim de sincronismo entre os membros da equipe de como está indo a execução das atividades realizadas no “Sprint”.

Perguntas na Reunião Diária


Impedimentos

Impedimento é qualquer coisa que atrapalhe um membro da equipe de executar o trabalho. Os impedimentos podem ser identificados nas reuniões diárias, onde cada membro da equipe tem a oportunidade de comunicar o ScrumMaster do impedimento existente. O ScrumMaster é responsável pela solução dos impedimentos. O ScrumMaster pode realizar reuniões complementares para solucionar os impedimentos identificados quando as reuniões diárias não permitirem a solução.

Um dos fatores de potencialização da equipe Scrum está na ação de retirar da equipe de execução do projeto a responsabilidade de resolver um impedimento. Se deixarmos a equipe de execução do projeto focado apenas na execução e passarmos todos os impedimentos ao Scrum Máster vamos ter um ganho de velocidade e qualidade na execução dos trabalhos.

Dia a Dia da Reunião Diária

Este é o nosso momento de alinhamento das atividades executadas dos nossos requisitos. Mas alem do alinhamento é o momento que temos de lembrar as nossas metas. Nesta reunião vale a pena sempre lembrar ou perguntar para a equipe qual a nossa meta da Sprint, para que todos sempre saibam o valor de negocio que estamos implementando ao produto desenvolvido.

Nossa meta não é apenas fazer algoritmo e sim algoritmos alinhados com a expectativa do Product Owner, que está trazendo ganho ao sistema desenvolvido.

Sprint, Planejamento da Sprint #1, Planejamento da Sprint #2, Sprint Burndown Chart e Execução da Sprint

Oi pessoal,

Este texto faz parte do material da apostila de Scrum do Abu versão 2.0.

Por favor, fiquem a vontade para fazer criticas com relação a ortográfica e a parte técnica. O e-mail de contato é abuzitos@gmail.com

Após a correção técnica e ortográfica o material vai ser disponibilizado para download.

Novo tabuleiro do Processo do Scrum do Abu - http://blogdoabu.blogspot.com/2009/12/novo-tabuleiro-do-processo-do-scrum.html

Abraços,

Abu


A execução do projeto é realizado em períodos de tempo que nós denominamos de Sprint. Uma Sprint tem período maximo de tempo igual a 30 dias e o período menor de tempo igual a uma semana.

Dentro de uma Sprint nos temos que executar o Framework do Scrum, com o planejamento da Sprint, as reuniões diárias, a entrega do que foi realizado no final da Sprint e a Retrospectiva, que é uma reunião de melhoria do processo pela equipe.

Devemos respeitar o período de tempo da Sprint como uma regra inegociável, onde mesmo não tendo realizado todas as atividades necessárias da Sprint nos terminamos a mesma, para que mesmo com uma entrega parcial dos resultados obtidos, seja realizada a entrega.

É importante sempre entregarmos o serviço realizado na Sprint, mesmo que este serviço não tenha sido concluído em sua totalidade.

A quantidade de serviços, isto é, requisitos que vamos implementar dentro de uma Sprint é determinada pela equipe e nunca pelo Product Owner. Quem vai realizar o trabalho deve se comprometer com a quantidade de serviço que vai realizar e nunca se comprometer com o serviço que foi determinado por outra pessoa.

Um dos segredos da Sprint está neste comprometimento, quando a equipe acredita que é possível realizar os requisitos acordados existe uma probabilidade maior de recebermos o que foi combinado.

É melhor trabalharmos com a realidade da velocidade de nossa equipe do que com o desejo que temos de velocidade. Uma equipe que sofre pressão para aumentar a velocidade acaba abrindo mão de alguma coisa e quase sempre o que a equipe abre mão é da qualidade, para que ela possa atender a velocidade esperada.

O problema de abrir mão da qualidade é que os requisitos e suas tarefas acabam não sendo fechados e retornam para a linha de produção. O nosso Product Backlog acaba recebendo os erros gerados durante o desenvolvimento das Sprint e os itens ainda não implementados. Está entrada de serviços com defeito acaba fazendo com que a equipe pare de desenvolver novos requisitos e gaste energia na correção de requisitos já implementados e que estão com defeito, o que pode levar o projeto a um fracasso.

Planejamento da Sprint #1

A reunião de planejamento da Sprint é realizada com a Equipe e o Product Owner e tem o objetivo do Product Owner apresentar a equipe os requisitos que vão ser desenvolvidos na Sprint.

Este planejamento é realizado com todos os integrantes da equipe de desenvolvimento do projeto, onde passamos a ter analistas de sistemas, desenvolvedores, testadores, DBA, web-design e quem mais for necessário.

Com a união de todas estas especialidades passamos a ter um ganho melhor de analise de sistemas e uma visão mais critica de como devemos solucionar os requisitos com a união de todas estás especialidades. O conhecimento também passa a ser compartilhado o que reduz os riscos da perda de uma pessoa na equipe, independente do motivo. Também nesta união de profissionais passamos a distribuidor e potencializar habilidades a todos, onde a ação de analise de sistemas passa a ser aprendida e realizada por todos os profissionais.

Um dos grandes segredos desta reunião é o Product Owner já vir com os requisitos bem definidos, para que a equipe tenha uma compreensão bem abrangente do que deve ser feito com o requisito.

É o que eu chamo de requisitos quadrados e requisitos redondos, onde um requisito quadrado é aquele que não tem uma clareza na sua definição e faz com que a equipe tenha dificuldade de achar as tarefas necessárias para a sua implementação e durante a execução do requisito ele gera vários impedimentos. Estes impedimentos podem levar a equipe inclusive a uma implementação parcial do requisito o que leva a uma não entrega do mesmo.

Já os requisitos redondos a equipe consegue no planejamento um entendimento claro do seu objetivo, o que leva a uma definição muito boa das tarefas a serem realizadas e permite um desenvolvimento sem duvidas. Os requisitos redondos aumentam a velocidade de desenvolvimento do sistema pela equipe, isto é, ao invés de pressionarmos a equipe para uma velocidade maior, devemos entregar a equipe requisitos melhores, que permitira um aumento de velocidade com qualidade do produto gerado.

Planejamento da Sprint #2

O planejamento da Sprint #2 passa a ser realizado apenas pela equipe, sem a necessidade do Product Owner. Este planejamento tem o objetivo de determinar como vamos realizar os requisitos, isto é, como vamos transformar o que foi recebido em forma de requisitos em software.

Nesta reunião definimos de maneira rápido como pode ser a tela de um sistema, o modelo de dados em auto-nível, as classes necessárias a serem desenvolvidas, as regras de negocio, etc.

Cada item identificado como sendo parte da solução do requisito passa a ser chamado de tarefas e estas tarefas recebem uma estimativa de horas.

Uma boa pratica e ter tarefas com o tempo de no mínimo de 1 hora e de no maximo um dia de trabalho. Se tivermos tarefas menores de uma hora elas podem ser agrupadas, para chegarem ao tempo de 1 hora. Uma boa dica também é agrupar as tarefas para meio período de trabalho, isto é, em um dia de 8 horas meio período seria de 4 horas. Desta maneira não perdemos tempo com estimativas de tarefas pequenas, deixando elas agrupadas e rotuladas com um conjunto de horas. Também ter agrupamento de tarefas faz com que os integrantes da equipe peguem trabalho sempre para um período de tempo ou um dia inteiro, não sendo necessário o seu deslocamento para pegar trabalhos durante o seu dia de trabalho.

Um requisito passa a ter varias tarefas e cada tarefa passa a receber o tempo necessário para o seu desenvolvimento. A totalização das horas necessárias para a completude dos requisitos selecionados para o desenvolvimento da Sprint faz com que a equipe saiba se os itens selecionados para trabalho são suficientes para o tempo existe ou maior, menor que o tempo que temos de trabalho.

Sprint Burndown Chart

Sprint Burndown Chart é o gráfico que mostra como está a execução das tarefas dentro de uma Sprint.

Nós temos no Eixo Y a quantidade de horas necessárias para a execução da Sprint e no Eixo X o numero de dias da nossa Sprint. A nossa velocidade é a quantidade de horas que a nossa equipe consegue executar por dia.

Sprint Burndown Chart


Calculo de Velocidade da Sprint

Calculo da Velocidade da Equipe na Sprint


A capacidade de produção da nossa equipe é de 110 horas por Sprint e 22 horas por dia. A quantidade de horas das tarefas identificadas no nosso Planejamento de Sprint #2 não deve ser superior a 110 horas. Nós podemos ter mais de 110 horas de tarefas na Sprint, mas isso so ocorre quando a equipe acredita ser capaz de executar às 110 horas mais o excedente.

Exemplo de Tarefas na Sprint



Exemplo de Ciclo de Vida de Uma Sprint

O exemplo do ciclo de vida de uma Sprint apresentado tem o seu inicio em uma segunda feira, mas o inicio da Sprint pode ser em qualquer dia da semana. Também neste exemplo foi definido um período de trabalho de 8 horas, tendo o período da manha e o período da tarde, mas pode ter projetos com períodos noturnos ou de apenas um período.

Também foi colocada a reunião diária no horário da manha, mas ela pode ser realizada em qualquer horário do dia, horário este que tem que ser definido com os integrantes da equipe.

Sprint de 2 Semanas


Sprint de 1 Semana


Executando a Sprint

Após o planejamento da Sprint #1 e #2 a equipe pode iniciar o processo de execução da Sprint. Os requisitos e suas respectivas tarefas são colocados no quadro de Taskboar, também chamado de quadro de Kanban.

Todo dia é realizada uma reunião de alinhamento da Sprint, que vai ser vista no tópico “Reunião Diária”. A execução dos Requisitos deve ser realizada com o conceito “Todos Contra Um”, onde a equipe inteira ataca o primeiro requisito, isto é, suas tarefas.

Caso não tenha serviço para todos, o segundo requisito é aberto e os integrantes da equipe que não estavam trabalhando no primeiro requisito vão para o segundo. Caso não tenha serviço para todos, o terceiro requisito é aberto e assim por diante.

Quando um requisito é terminado ou não existe tarefa para todos, o processo de ajudar no próximo requisito ou abrir um novo requisito deve ser seguido.

A técnica de “Todos Contra Um” faz com que tenhamos ao termino da Sprint sempre requisitos prontos para serem entregues. Quando colocamos uma pessoa em cada requisito, isto é, “Cada um por si” ao termino da Sprint corremos o risco de termos todos os requisitos 90% pronto, mas nenhum realmente pronto.

Um ponto importante do “Todos Contra Um” é que a equipe em Scrum realmente é uma equipe, não buscamos mais o individualismo e sim o coletivo. Não existe mais o melhor desenvolvedor, o melhor arquiteto, o melhor testador, existe a equipe, que vai ser forte ou fraca pela união do grupo.

Todos Contra Um


É comum aparecer requisitos novos durante a execução da Sprint que está sendo executada.

Requisitos novos são ocasionados por uma analise superficial dos requisitos da Sprint, ou por uma necessidade nova do Product Owner. O requisito não planejado ocasionado por uma analise superficial, é um alerta que não devemos jamais deixar de lado o bom trabalho de analise de sistemas. Estes requisitos não planejados vão atrapalhar a execução da Sprint por intermédio de um impedimento de falta de definição de como o sistema deve se comportar.

Mas quando um requisito novo entra na Sprint, independente do motivo, ele deve ser colocado em um espaço visível e bem sinalizado, para que todos os envolvidos no projeto saibam que demandas novas estão consumindo energia da equipe de desenvolvimento. Estas demandas não previstas podem levar a uma entrega parcial dos requisitos acordados pela Equipe com o Product Owner no inicio da Sprint.

Taskbord ou Kanban


A equipe tem autonomia de executar as tarefas do quadro de Taskboard, não sendo necessário uma pessoa ficar atribuindo estas tarefas as pessoas que vão executar.

Está autonomia ocorre porque desde o inicio do projeto todos os integrantes da equipe de execução do projeto estavam juntos entendendo o que deve ser feito. Também estavam juntos no Planejamento da Sprint #1 e #2. Não existe necessidade de um “controle manda faz”, a equipe sabe o que deve ser feito e não ter um controle sobre a equipe neste momento, potencializa a capacidade de execução da mesma.

O controle dentro da Sprint passa a ser compartilhado por todos da equipe, não ficando a responsabilidade para uma pessoa. Isso é o que nos chamamos de auto-gestão.

quinta-feira, 7 de janeiro de 2010

Priorização e Distribuição de Requisitos por Sprint’s

Oi pessoal,

Este texto faz parte do material da apostila de Scrum do Abu versão 2.0.

Por favor, fiquem a vontade para fazer criticas com relação a ortográfica e a parte técnica. O e-mail de contato é abuzitos@gmail.com

Após a correção técnica e ortográfica o material vai ser disponibilizado para download.

Novo tabuleiro do Processo do Scrum do Abu - http://blogdoabu.blogspot.com/2009/12/novo-tabuleiro-do-processo-do-scrum.html

Abraços,

Abu


A priorização do Backlog é realizada pelo Product Owner. Está priorização é realizada com o objetivo de selecionar os principais requisitos para construção.

Em Scrum a priorização é fundamental para a redução do risco de cancelamento do projeto, pois quanto mais rápido for entregue o que realmente é importante ao Produtct Owner, menor o risco do projeto ser cancelado.

A priorização faz com que o comprometimento do Product Owner seja muito forte, pois o Product Owner é o responsável pelo retorno do investimento (ROI) e desta maneira ele que tem que ter a visão clara dos requisitos que realmente devem ser feito antes dos outros.

Com a priorização nos passamos a ter um “Tema” do sistema, como “Cadastro de Clientes”, tendo seus requisitos sendo executados conforme o desejo do Product Owner e não “todos” os requisitos sendo executados de uma única vez.

Com este modelo de trabalho um “Tema” passa a receber mais funcionalidades durante todo o desenvolvimento do projeto.

Executando a Priorização

Uma boa técnica é a MoSCoW, onde os requisitos são distribuídos por Sprint respeitando a priorização.

Priorização com MoSCoW


Devemos executar primeiro todos os requisitos “Must”, isto é “Tem que ter” do nosso projeto. Quando não existir mais requisitos “Must” atacamos os requisitos “Should” e assim por diante, até o termino de todos os requisitos que o nosso projeto possui.

Um ponto importante do Scrum, a cada nova Sprint o Product Owner tem a liberdade de escolher os requisitos que vão ser executado na Sprint. Com esta liberdade a priorização dos requisitos no projeto é planejada Sprint a Sprint e nunca uma vez so no inicio do projeto.

Com a definição de prioridades dos requisitos que devem ser executados a cada Sprint o Product Owner busca o resultado em seu ROI (retorno de investimento), pois o cliente está recebendo sempre o que é mais importante para ele a cada Sprint.

Estimativas, Velocidade da Equipe, Quantidade de Sprint’s e Product Burndown Chart

Oi pessoal,

Este texto faz parte do material da apostila de Scrum do Abu versão 2.0.

Por favor, fiquem a vontade para fazer criticas com relação a ortográfica e a parte técnica. O e-mail de contato é abuzitos@gmail.com

Após a correção técnica e ortográfica o material vai ser disponibilizado para download.

Novo tabuleiro do Processo do Scrum do Abu - http://blogdoabu.blogspot.com/2009/12/novo-tabuleiro-do-processo-do-scrum.html

Abraços,

Abu


O ato de estimar o tempo necessário para a conclusão de um projeto sempre tem uma porção de “chute”, nós apenas sabemos o tempo necessário para a realização de uma tarefa quando está tarefa já esta concluída.

Antes de sua conclusão apenas temos uma noção do tempo que vai ser necessário, ou apenas um desejo do que acreditamos ser possível de ser realizado.

Um projeto de um ano, onde existe um erro de uma hora por dia de trabalho, ao término de um ano teremos mais de 200 horas de atraso.

Em desenvolvimento ágil nós realizamos a estimativa de um projeto pela contagem de pontos, onde um ponto é uma forma de comparação de esforço necessário para a realização de um requisito.

Mas nós também temos uma estimativa em horas, que é realizada na quantidade de tarefas existente em uma Sprint.

A estimativa em pontos busca a visão do esforço do projeto e deve ser reestimada varias vezes durante o projeto, para corrigirmos imperfeições iniciais. Já a estimativa da Sprint, utilizando tarefas estimadas em horas tem o objetivo de saber se a quantidade de trabalho identificado é comportada pela equipe.

Contando os Pontos

O cliente solicitou uma data de termino da entrega do projeto, para que ele possa realizar uma analise de riscos com relação a data limite da entrega do projeto e o inicio do período de vendas de material escolar.

A equipe se reúne com o Product Owner para realizar as estimativas necessárias. Os requisitos utilizados são os de tamanho de “Temas”.

Com cada um dos requisitos escritos em papeis e colocados sobre a mesa a equipe busca os de menos esforço de trabalho. Está busca tem o objetivo de escolher um requisito que vai ser utilizado como ponto de referencia, uma ancora em relação aos demais.

A participação do Product Owner é fundamental, pois a cada requisito em tamanho igual a um “Tema” a equipe pode solicitar maiores informações e o Product Owner passa a responder estas informações. Está reunião inclusive é um ótimo momento de anotarmos mais requisitos contidos num “Tema”, para atualização do nosso Product Backlog.

A equipe por consenso identifica o requisito de tamanho menor, este requisito é o de Categoria de Produtos. Para facilitar o processo de contagem de pontos buscamos os requisitos que são um pouco maior que o menor, pois sempre aparecem requisitos menores ao que nos estamos utilizando como base, isto é, ancora.

Por consenso a equipe escolhe o Cadastro de Clientes e este recebe o valor igual a dois pontos. Dois pontos neste momento da técnica de estimativa não tem nenhuma correlação com o tempo necessário para a relação do projeto, apenas representa o tamanho do esforço necessário para a construção deste “Tema”.

Com o requisito de tamanho igual a dois passamos a comparar este requisito com os demais e atribuir aos demais os valores em pontos correspondentes. A escala de pontos utilizado é a de Fibonacci, 1, 1, 2, 3, 5, 8, 13, 21, 34, ?.

O processo de contagem de pontos, nós utilizamos o Planning Poker, baralhos com os pontos de Fibonacci, para que ninguém da equipe influencie o outro. Jogamos as cartas viradas para baixo e todos ao mesmo tempo viraram as cartas para cima, onde podemos realizar a analise dos pontos jogados.

Quando as cartas possuem valores iguais significa que a equipe chegou a um consenso do tamanho do esforço, mas quando as cartas possuem valores diferentes é sinal que a equipe não esta fechada em um consenso. Neste momento entra o Scrum Máster como um facilitador perguntando a cada pessoa da equipe o porquê dos valores de suas cartas, o que cada pessoa está identificando de esforço a mais do que o outro colega de trabalho.

As duvidas, incertezas, requisitos que nos acreditamos ser verdadeiros e contidos no requisito de tamanho igual a “Temas” do requisito que está sendo estimado, nos devemos perguntar ao Product Owner, para que ele valide e deixe claro para a equipe a abrangência do esforço necessário.

Não existindo mais duvidas as cartas são jogadas de novo e a equipe busca o consenso do esforço. O processo pode ser repetido quantas vezes forem necessárias, com o tempo a equipe acha o seu ponto de equilíbrio nas estimativas.

É importante sempre deixarmos como consenso do resultado do processo de Planning Poker as cartas de maior valor, para que todas as pessoas da equipe se sintam a vontade em executar o requisito estimado no tempo que ela acredita ser exeqüível.


Exemplo de Pontos Contados
Tema - Pontos
Cadastro de Clientes - 2
Cadastro de Produtos - 2
Carrinho de Compras - 13
Busca de Produtos - 2
Categoria de Produtos - 1
Histórico de Compras - 5
Rastreamento de uma Compra - 8
Pagamento por Cartão de Credito - 8
Pagamento por Boleto Bancário - 13
Exportação de Dados p/ EPR - 13
Total - 67 pts


Determinando o Tempo do Projeto

O primeiro passo para sabermos o tempo do projeto é a definição do tamanho da nossa Sprint, lembrando que uma Sprint é um tempo de trabalho, que pode ser de uma, duas, três ou quatro semanas, mas uma vez definido o tamanho da Sprint ela não deve ser modificada até o termino do projeto, para não termos que regêramos gráficos e informações do projeto sobre o novo tamanho da Sprint, o que irá gerar um re-trabalho.

A equipe junto com o Product Owner determina que a Sprint vai ser de uma semana. Uma vez sabendo o tamanho da Sprint é perguntada a equipe a quantidade de pontos que a equipe consegue executar em uma Sprint. Este valor está diretamente vinculado ao que tem que ser feito e a quantidade de pessoas que a nossa equipe possui. Também neste valor está incluso o nosso processo de desenvolvimento do software, onde ele deve abranger tudo que for necessário, como testes de software, UML, documentação e o que for definido pela equipe e os interesses do cliente, representado pelo Product Owner.

A equipe definiu a quantidade de 10 pontos por Sprint, agora temos condições de dar uma previsão ao cliente do tempo necessário para o desenvolvimento do sistema, bastando apenas pegar a quantidade de pontos contados e dividir pela quantidade de pontos que a equipe é capaz de executar. A quantidade de pontos que a equipe é capaz de executar por Sprint é a “Velocidade da Equipe”.

O resultado da operação matemática chegou ao valor de: 67 / 10 = 6 com resto de 7. Seis (6) é a quantidade de Sprint’s necessárias para a realização do projeto. Vamos arredondar para sete (7), pois temos o resto da divisão. Sete semanas são iguais a aproximadamente dois meses de trabalho.

Podemos também realizar o calculo da Velocidade da Equipe com as informações coletadas após a execução da primeira Sprint e com este dado calculamos o tempo de execução do projeto.

Product Burndown Chart

Também conhecido como o gráfico de ciclo de vida do projeto, que tem o objetivo de mostrar como está o andamento do projeto inteiro.

Colocamos no Eixo Y os pontos do projeto e colocamos no Eixo X a quantidade de Sprint’s. Passamos uma reta mostrando a meta dos pontos a serem executados pela quantidade de Sprint’s do nosso projeto, respeitando a Velocidade da Equipe.

Uma segunda linha é gerada a cada execução de Sprint, com o objetivo de mostrar se a nossa meta foi alcançada ou não. A cada execução de Sprint a nossa velocidade pode ser recalculada e conseqüentemente o tempo do projeto passa a sofrer alteração.

Este gráfico fica muito bem disponibilizado em uma parede do lado da equipe de desenvolvimento. Quando todas as pessoas envolvidas no projeto, direta ou indiretamente aprenderem a ler este gráfico não existe mais a necessidade de responder aos interessados a pergunta: “Como está indo o projeto de Venda de Livros pela Internet?”, pois a informação está disponibilizada a todos, permitindo uma comunicação direta e rápida. Se o escopo do projeto passa a sofrer alterações o gráfico sofre a necessidade de ser atualizado, mas este item vai ser visto melhor nos próximos tópicos deste material.

Product Burndown Chart

Product Backlog

Oi pessoal,

Este texto faz parte do material da apostila de Scrum do Abu versão 2.0.

Por favor, fiquem a vontade para fazer criticas com relação a ortográfica e a parte técnica. O e-mail de contato é abuzitos@gmail.com

Após a correção técnica e ortográfica o material vai ser disponibilizado para download.

Novo tabuleiro do Processo do Scrum do Abu - http://blogdoabu.blogspot.com/2009/12/novo-tabuleiro-do-processo-do-scrum.html

Abraços,

Abu


Uma vez realizada a apresentação da Visão do Produto para os envolvidos no projeto uma relação de requisitos deve ser elaborada para que o sistema possa ser desenvolvido. Está relação de requisitos nos chamamos de Product Backlog.

Podemos organizar a nossa lista de requisitos de varias maneiras, sendo uma organização apenas por requisitos referentes ao negocio a ser desenvolvido, ou uma lista com a relação de requisitos envolvendo o negocio a ser desenvolvido mais os requisitos não funcionais do sistema.

A estimativa do tamanho do projeto é realizada sobre os requisitos existentes na nossa lista de Product Backlog, mas para a realização desta estimativa nos utilizamos os requisitos em auto-nível chamados de “Temas”. Um “Tema” é um requisito que tem contido dentro dele requisitos menores. Nós vamos ver melhor a parte de requisitos no universo ágil no tópico denominado de historias.

Todos os envolvidos no projeto podem adicionar requisitos a nossa lista de requisitos do sistema, mas apenas o Product Owner pode priorizar os requisitos.

A priorização destes requisitos contidos no Product Backlog permite uma visão temporal de quando uma determinada funcionalidade vai ser realizada no projeto. A principio pode ser considerado um desperdício de tempo, pois no decorrer do projeto está priorização irá ser mudada conforme a necessidade do Product Owner, mas ela ajuda a todos os envolvidos a terem a visão de como o projeto vai ser executado já no início do mesmo, mesmo sabendo que podemos ter mudanças de prioridade.

Exemplo de Product Backlog

Nos já temos uma relação de requisitos identificados na Visão do Produto e a qualquer momento novos requisitos podem ser adicionados ao projeto. O nosso Product Backlog não é constituído uma única vez e sim continuamente construído.

O documento gerado pela Visão do Produto possui os requisitos em auto-nível: Cadastro de Clientes, Cadastro de Produtos, Carrinho de Compras, Busca de Produtos, Categoria de Produtos, Histórico de Compras, Rastreamento de uma Compra, Pagamento por Cartão de Credito, Pagamento por Boleto Bancário e Exportação de Dados de Vendas para um sistema de ERP existente na empresa. Para cada requisito em auto-nível, chamado de “Tema” nos passamos a adicionar os requisitos menores, denominados de historias.

Devemos lembrar que jamais podemos ignorar um requisito identificado, mesmo na visão do produto se um requisito menor for apresentado ele deve ser anotado e agrupado ao seu “Tema” principal.

O Carrinho de Compras com o processo de analise do sistema passa a ter os requisitos menores: Adicionar produtos ao carrinho de compras, remover produtos do carrinho de compra, custo da entrega dos produtos conforme o meu CEP, desconto existentes em cada produto e itens do carrinho de compra devem permanecer no sistema até o desejo do comprador.

Vários requisitos menores foram criados pela própria equipe de desenvolvimento e o Product Owner vai validar cada um deles, desta maneira todos os envolvidos no projeto passam a ser donos do produto a ser criado.

O Tema “Cadastro de Clientes” recebeu os requisitos menores: Endereço do Cliente, Endereço de Entrega, Telefones de Contatos, Histórico de Compras.

Podemos organizar o nosso Product Backlog em uma planilha com as colunas: Tema, Historia, Pontos, Prioridade, Sprint. As colunas desta planilha vão ser definidas nos próximos tópicos.

Visão do Produto

Oi pessoal,

Este texto faz parte do material da apostila de Scrum do Abu versão 2.0.

Por favor, fiquem a vontade para fazer criticas com relação a ortográfica e a parte técnica. O e-mail de contato é abuzitos@gmail.com

Após a correção técnica e ortográfica o material vai ser disponibilizado para download.

Novo tabuleiro do Processo do Scrum do Abu - http://blogdoabu.blogspot.com/2009/12/novo-tabuleiro-do-processo-do-scrum.html

Abraços,

Abu


Visão do Produto ou Escopo do projeto é a apresentação da abrangência do projeto a equipe de desenvolvimento do projeto. A visão do produto não tem o objetivo de ser uma apresentação detalhada dos requisitos e sim uma apresentação em auto nível de todos os módulos que vão ser construídos. Nesta apresentação pode ser apresentado a equipe fatores de sucesso, características de qualidade desejada, as metas e o que mais for necessário.

A visão do produto pode ser realizada varias vezes durante o projeto, não sendo uma regra a sua apresentação apenas no inicio do projeto. Com está reapresentação no decorrer do projeto diminuímos o risco do desvio do entendimento dos nossos objetivos durante a execução, fazendo com que todos mantenham o alinhamento com a “Meta” do projeto, e não apenas no inicio do projeto.

Executando a Visão do Produto

Os participantes devem ser convidados com antecedência. No convite ter o local da reunião, a hora, data e o assunto da reunião. Na sala de reuniões deixar disponível para todos os presentes etiquetas coloridas colantes (post-it’s), papel e canetas. A reunião pode ser filmada ou apenas o som gravado.

Durante a apresentação pode ser realizada a apresentação de slides, filmes, ou qualquer tipo de recurso que permita a transmissão de conhecimentos às pessoas que estão assistindo.

Está reunião não tem o objetivo de ser uma analise de sistemas, isto é, as pessoas que estão participando tem a liberdade de realizar perguntas, mas não existe a necessidade de se fazer uma analise detalhada dos itens apresentados. O objetivo da reunião é de apenas saber o que vamos fazer, quais as principais entregas, o que é cada modulo em auto nível e principalmente, fazer com que todos os envolvidos passem a ter conhecimento do projeto, pois este conhecimento e a participação na reunião de visão do produto leva a equipe a um comprometimento com o trabalho que vai ser realizado.

Exemplo de Visão do Produto

Dia XX hora YY encontra-se reunido na sala de reuniões da empresa ACME a equipe do desenvolvimento do novo projeto da empresa. Junto com a equipe também esta presente o representante do cliente, o nosso Product Owner.

A apresentação do projeto é realizada com alguns recursos visuais e o escopo do mesmo é apresentado. O nosso projeto é de um software de venda de livros pela internet.

O Product Owner apresenta nos slides dados do sistema atual e seus problemas existentes e acrescenta as expectativas com relação ao novo sistema a ser realizado.

Um dos focos de sucesso está no “Carrinho de Compras”, onde o sistema atual apresenta problemas de usabilidade e de performance de execução. Também é apresentado pelo Product Owner um risco para o projeto, onde o risco apresentado é que se o “Carrinho de Compras” não for construído com foco nas expectativas do cliente o projeto não tem porque continuar.

Mais um novo risco é apresentado ao nosso projeto, nos temos uma data limite de construção do sistema, pois o cliente deseja colocar o novo software em funcionamento antes do período de compra de material escolar, para que ele “O Cliente” possa ter retorno do investimento que está sendo realizado no novo software com as vendas de seus produtos.

A equipe de desenvolvimento inicia a sabatina de perguntas ao Product Owner, para que todos possam ter o mesmo entendimento do que deve ser realizado, quando as perguntas entram em partes bem especificas, isto é, o entendimento aprofundado de um determinado modulo o Scrum Máster faz o papel de moderador e comenta que teremos o momento mais adequado para a realização da analise dos requisitos do sistema a ser desenvolvido e que este momento é para que todos saibam a onde pretendemos chegar com o nosso projeto.

Ao termino da reunião a equipe de desenvolvimento do sistema sai da reunião com as suas anotações e uma tabulação rápida destas anotações permite a criação de uma lista de requisitos em alto nível do nosso projeto.

O Scrum Máster apresenta a todos os integrantes da equipe o documento tabulado: Cadastro de Clientes, Cadastro de Produtos, Carrinho de Compras, Busca de Produtos, Categoria de Produtos, Histórico de Compras, Rastreamento de uma Compra, Pagamento por Cartão de Credito, Pagamento por Boleto Bancário e Exportação de Dados de Vendas para um sistema de ERP existente na empresa.

As diferenças entre mentor e coach

segue o link

http://cbn.globoradio.globo.com/comentaristas/max-gehringer/2009/12/21/AS-DIFERENCAS-ENTRE-MENTOR-E-COACH.htm

[]s

Abu

Papéis no Scrum

Oi pessoal,

Este texto faz parte do material da apostila de Scrum do Abu versão 2.0.

Por favor, fiquem a vontade para fazer criticas com relação a ortográfica e a parte técnica. O e-mail de contato é abuzitos@gmail.com

Após a correção técnica e ortográfica o material vai ser disponibilizado para download.

Novo tabuleiro do Processo do Scrum do Abu - http://blogdoabu.blogspot.com/2009/12/novo-tabuleiro-do-processo-do-scrum.html

Abraços,

Abu



Scrum possui apenas três papeis, sendo eles: Product Owner, Scrum Master e a Equipe.

Product Owner (PO)

Conhecido também como dono do produto é o responsável pela definição do projeto, levando a equipe de desenvolvimento o que chamamos de Visão do Produto.

Uma vez transmitida a Visão do Produto a equipe de desenvolvimento o dono do produto é responsável pela priorização dos requisitos e definição dos mesmos.

O Product Owner pode mudar as priorizações, adicionar ou remover novos requisitos conforme as suas necessidades. Ele apenas não pode mudar o trabalho que já está em codificação pela equipe de desenvolvimento.

Uma das grandes chaves de sucesso do Scrum está no Product Owner, por intermédio da definição e clareza dos requisitos. Os requisitos não devem chegar parcialmente definidos a equipe de desenvolvimento, caso isso ocorra a capacidade de produção da equipe vai diminuir.

O Product Owner também é responsável pelo retorno de investimento (ROI) do projeto. É difícil definir ROI, mas no Scrum ele se materializa com a priorização dos requisitos e codificação dos mesmos. No Scrum a entrega o mais rápido possível ao Product Owner dos módulos que ele tem necessidade caracteriza ROI e o Product Owner com o sistema em funcionamento pode avaliar o que está sendo construído ou até mesmo utilizá-lo o mais rápido possível.

Também uma das chaves de sucesso do Scrum com o Product Owner está na sua disponibilidade a equipe de desenvolvimento de software. As vezes ter o Product Owner sempre disponível é difícil, mas é uma meta a ser seguida.

Devemos lembrar que o Product Owner é o representante do cliente e a equipe de desenvolvimento de software tem que atender as suas expectativas e orientações. O Product Owner tem o poder de aceitar ou rejeitar um trabalho realizado pela equipe de desenvolvimento de software.

Scrum Máster (SM)

O Scrum Máster é uma pessoa da equipe de desenvolvimento do software que possui algumas responsabilidades diferentes dos demais. Entre as responsabilidades está a de manter o processo do Scrum ativo, garantindo que o projeto vai ser realizado seguindo as boas praticas do Scrum.

Também faz parte das responsabilidades do Scrum Master identificar todos os problemas que estão ocorrendo durante o desenvolvimento do sistema, que faz com que a capacidade de produção da equipe diminua ou até mesmo não permita que a equipe continue trabalhando. Estes problemas nos chamamos de obstáculos ou impedimentos e devem ser solucionados pelo Scrum Master. Quando o Scrum Master não tem condições de solucionar o impedimento ele deve buscar a pessoa que pode resolver o problema identificado.

A produtividade da equipe é mais uma responsabilidade do Scrum Master, pois ele deve fazer com que a equipe de desenvolvimento do sistema fique focada o maximo possível na sua área de atuação, que é a construção do software. Neste ponto nos falamos que o Scrum Master tem que ser uma blindagem da equipe, não permitindo que eventos externos atrapalhem os trabalhos que estão sendo realizados.

Um ponto importante é que o Scrum Master não tem que ter autoridade sobre a equipe, isto é, qualquer integrante da equipe de desenvolvimento de software pode ser o Scrum Master e até mesmo fazer um rodízio desta responsabilidade. A troca de Scrum Master entre as pessoas da equipe deve ser realizada com cautela, nunca a cada sprint (fase, ciclo ou iteração) de desenvolvimento e sim por projeto ou por versões (releases) do sistema.

Podemos ter também um Scrum Master coringa, para que caso o Scrum Master do projeto não possa estar presente com a equipe, uma pessoa da equipe já saiba que ele é o responsável por executar as atribuições de trabalho do Scrum Master.

Equipe (EQ)

É a responsável pela execução do projeto, sendo protegida pelo Scrum Master e tendo como foco o atendimento das necessidades do Product Owner.

Uma equipe em Scrum é constituída de no mínimo 2 pessoas e no maximo de 7 pessoas. As equipes são menores para potencializar uma das maiores armas do Scrum, a comunicação entre a equipe.

Três pessoas nos temos uma comunicação direta entre cada integrante da equipe, conforme a equipe vai aumentando a complexidade de comunicação entre todos os integrantes vai aumentando.

Equipes enxutas chegam a ter a sua capacidade de produção melhor que equipes grandes. Este aumento de velocidade ocorre em virtude da potencialização da comunicação entre os integrantes da equipe.

Complexidade da Comunicação



A formação da equipe é multidisciplinar, sendo ela constituída de: Engenheiros de Software, Arquitetos, Programadores, Analista, Peritos em Qualidade, Testadores, Web designers.

Mas em Scrum as equipes são generalistas e não especialistas. Todos os integrantes da equipe podem e devem desempenhar todos os papeis, conforme a necessidade e definição da equipe.

Nos utilizamos equipes multidisciplinares e generalistas para que o projeto possa ter uma velocidade de execução maior e uma redução de riscos com relação a definição do produto que está sendo realizado. Os generalistas permitem com que todas as pessoas do projeto sempre executam qualquer atividade. Com a equipe generalista nos passamos a potencializar a capacidade de produção que o nosso projeto possui, removendo o risco de um integrante da equipe ficar parado aguardando o trabalho que deve ser executado ficar disponível. Os multidisciplinares permitem a redução do risco nas definições do produto, permitindo a integração das mais diversas áreas na busca de um produto melhor.

As equipes em Scrum são auto-organizadas, isto é, elas definem a sua forma de trabalho e evoluem está forma de trabalho pela sua própria avaliação de como está sendo executado o projeto.

Dentro da equipe de Scrum é instituído o conceito de auto-gestão, onde a equipe passa a ter autonomia de tomada de decisão para o seu foco de atuação, que é o de desenvolver o sistema solicitado pelo Product Owner.

sábado, 2 de janeiro de 2010

Sugestão para o Material do Abu de Scrum?

Oi Pessoal,

Eu terminei hoje a primeira versão da revisão do "Material do Abu" sobre Scrum.

O Material foi totalmente reescrito, existe apenas um item do material antigo.

A foto do kanban mostra os temas tratados.

Quem tiver alguma sugestão de um tema para ser adicionado ao material basta colocar um comentário neste post ou mandar por e-mail.



Assim que o material passar por uma revisão ortográfica eu deixo ele liberado.

[]s
Abu