|
|
|
|
|
|
CHALLENGE IT
Uma empresa ágil. |
 |
| Uma empresa Ágil capaz de transformar idéias em resultados, num curtíssimo espaço de tempo |
|
|
 |
A Challenge IT é uma empresa ágil não somente no desenvolvimento de software. Sua agilidade está na capacidade de transformar o pensamento em ação, a ideia em realidade. Ela é ágil pelo comprometimento de sua equipe e pela metodologia que adota.
A empresa assina o Manifesto Ágil e atua de acordo com seus princípios. Por isso, sua prioridade é garantir a satisfação de seus clientes através da entrega adiantada e contínua de software de valor.
A agilidade nos processos de desenvolvimento de software permite que o cliente tenha a oportunidade de aprender com seu projeto, solicitando mudanças de requisitos em qualquer etapa, inclusive após a conclusão do mesmo, obtendo vantagens competitivas reais.
O maior desafio da Challenge IT é, portanto, entregar ao cliente um software pronto para uso com frequência, que apresente excelência em técnica e design, além de proporcionar um ambiente propício à criatividade e as ferramentas necessárias para que sua equipe se mantenha sempre motivada e atualizada, em interação constante com o cliente.
|
| Metodologia Ágil |
|
A metodologia ágil para o desenvolvimento de software adotada pela Challenge IT é a SCRUM.
|
| O que é SCRUM |
SCRUM é um framework interativo utilizado no desenvolvimento ágil de software. Nele, as tarefas são estruturadas em ciclos de trabalho, denominados sprints, e as interações entre a empresa e o cliente acontecem com intervalos programados.
Durante os sprints, são selecionados os requisitos a serem executados naquela etapa, de acordo com as prioridades do cliente. Ao final de cada sprint, a Challenge IT entrega um produto pronto para o uso.
|
|
Sprints |
Papéis |
Cerimônias |
Artefatos
|
Sprints
Em um SCRUM, Sprint é toda interação que acontece entre a Challenge IT e o cliente (Product Owner).
O Sprint representa um time-box (intervalo de tempo) com duração variável entre duas e quatro semanas, dentro do qual um conjunto de atividades deve ser executado.
No início de cada Sprint, o time envolvido se reúne com o cliente para planejar o que será feito naquele Sprint, de acordo com os itens de maior prioridade no Product Backlog e com a velocidade de trabalho da equipe.
Ao final do Sprint, as funcionalidades implementadas ao produto são apresentadas e demonstradas ao cliente, em uma cerimônia chamada Sprint Review.
Papéis
Product Owner
É o cliente ou a pessoa que o representa junto ao Time. Conhece bem as necessidades do projeto, sendo capaz de priorizar as demandas de acordo com o que trará o maior retorno possível em um menor espaço de tempo. É o responsável direto pelo ROI (Retorno de Investimento).
ScrumMaster
O ScrumMaster desempenha um papel de liderança, gerenciando os interesses do Product Owner mediante o Time e garantindo o uso correto da metodologia SCRUM, através dos seus valores e práticas. É responsável, ainda, por facilitar o dia a dia do Time, protegendo-o das interferências externas e removendo tudo aquilo que atrapalha o bom desenvolvimento do projeto.
Time
São os arquitetos, desenvolvedores, testadores, designers e demais profissionais envolvidos no desenvolvimento do software. É uma equipe reduzida (com, em média, 7 participantes), autogerenciável (seus membros decidem, junto com o Product Owner, as metas de cada Sprint, organizando seus trabalhos para atingir tais objetivos) e multidisciplinar (seus profissionais possuem diferentes aptidões).
Cerimônias
Planning Meeting
O Planning Meeting acontece no início de cada Sprint, quando o Time se reúne com o Product Owner para a definição do que será feito durante aquele Sprint, com o objetivo de que a meta determinada seja alcançada.
Durante o Planning Meeting, o Product Owner detalha os itens prioritários do Product Backlog para que o Time consiga estimar o tamanho de cada item. A partir daí, os membros do Time decompõem cada item em tarefas técnicas, estimando-as em horas de trabalho.
A cada Sprint é elaborado um planejamento do que será realizado, permitindo que alterações sejam feitas no Product Backlog de acordo com as necessidades do cliente.
Sprint Review
A Sprint Review é a reunião realizada entre o Product Owner, o ScrumMaster e os membros do Time ao final do período do Sprint. Nela, são apresentadas todas as funcionalidades implementadas ao longo daquele ciclo, no formato de demonstração, e qualquer pessoa interessada pode participar.
Após a apresentação, o Product Owner analisa quais os itens do Product Backlog foram completados daquele Sprint, definindo com os membros do Time e o ScrumMaster quais serão as novas prioridades no projeto. Sugestões podem ser feitas, cabendo ao Product Owner adicioná-las ao Product Backlog ou não.
A partir daí, um novo Product Backlog é gerado.
Sprint Retrospective
Ao final da Sprint Review acontece a Sprint Retrospective, uma reunião somente entre os membros do time e o ScrumMaster (na posição de facilitador), onde é discutido o que foi bem na Sprint e o que precisa ser melhorado na próxima. É através da Sprint Retrospective que os membros do time conseguem aprimorar seus trabalhos e a si mesmos, num processo de melhoria contínua.
Product Backlog
O Product Backlog é uma lista de funcionalidades, desenvolvida, no início do projeto, pelo Product Owner, com o auxílio do ScrumMaster, sendo organizada por prioridade de entrega.
Essa lista deve incluir todas as funcionalidades visíveis ao cliente, bem como os requisitos técnicos para o desenvolvimento do produto. As tarefas de maior prioridade e complexidade são divididas em subtarefas para que sejam estimadas e testadas.
Ao longo do desenvolvimento do projeto, o Product Backlog pode receber novos itens, ter itens removidos ou repriorizados, de acordo com as necessidades do cliente ou visando um melhor ROI. Há a possibilidade, ainda, de inclusão de alguns requisitos técnicos que, muitas vezes, não são visíveis ao cliente.
Sprint Backlog
O Sprint Backlog é uma lista contendo os itens que serão realizados durante um Sprint, sendo elaborada pelos membros do time, juntamente com o Product Owner, no início de uma Sprint. Ao contrário do Product Backlog, a Sprint Backlog não pode ser alterada.
Gráfico Burndown
O gráfico Burndown apresenta o trabalho remanescente em uma Sprint, ou seja: após o Planning Meeting e a elaboração do Sprint Backlog, o time realiza a montagem do gráfico Burndown. A partir daí, eles devem fazer a somatória do que foi produzido e subtrair este resultado no gráfico Burndown. É importante lembrar que as atualizações do gráfico devem acontecer diariamente.
| O Manifesto Ágil |
| Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar: |
 |
Indivíduos e a interação entre eles, mais que processos e ferramentas; |
|
Software em funcionamento, mais que documentação abrangente; |
|
Colaboração com o cliente, mais que negociação de contratos; |
|
Responder a mudanças, mais que seguir um plano. |
| Ou seja: mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. |
|
|
|
|