"Então, quero falar sobre Agile e Scrum ."
"No início do século 21, a maneira como as pessoas pensavam sobre programação virou de cabeça para baixo."
"Todos estavam convencidos de que o planejamento de longo prazo não estava funcionando, então decidiram abandoná-lo completamente."
"Como eles fizeram isso?"
"Veja como."
"Eles inventaram a abordagem de gerenciamento de projetos mais flexível possível."
Aqui estão as principais ideias por trás do desenvolvimento ágil :"
- pessoas e comunicação são mais importantes que processos e ferramentas;
- um produto funcional é mais importante do que uma documentação exaustiva;
- colaborar com o cliente é mais importante do que cumprir os termos de um contrato;
- a vontade de mudar é mais importante do que seguir o plano original.
Aqui estão os princípios de desenvolvimento rápido:
- satisfazer o cliente fornecendo software valioso antecipadamente e continuamente;
- aceitar mudanças nos requisitos mesmo no final do desenvolvimento (isso pode aumentar a competitividade do produto final);
- entregar software funcional com frequência (todos os meses ou semanas ou com mais frequência);
- estreita comunicação diária entre cliente e desenvolvedores ao longo de todo o projeto;
- o projeto é desenvolvido por pessoas motivadas, que recebem as condições necessárias de trabalho, apoio e confiança;
- o método preferido para comunicar informações é uma conversa pessoal (cara a cara);
- software funcionando é a melhor medida de progresso;
- patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante por tempo indeterminado;
- foco constante na melhoria da excelência técnica e design amigável;
- a simplicidade é a arte de não fazer trabalho supérfluo;
- os melhores requisitos técnicos, design e arquitetura vêm de uma equipe auto-organizada;
- adaptação constante às circunstâncias mutáveis.
"O principal problema com o desenvolvimento de software era que, em qualquer estágio, nenhum dos participantes tinha informações completas sobre o que fazer."
"O cliente pode dizer a você como ele imagina o programa, mas ele deixará algo de fora ou tomará algo como garantido."
"O gerente geralmente precisa traduzir os requisitos do jargão de programação para a linguagem do cliente e vice-versa."
"Há muita incerteza."
"Muitas vezes, os requisitos do cliente são assim: faça de alguma maneira e depois me mostre - se eu não gostar, você pode refazer."
"Uh... isso é horrível."
"De acordo com o novo paradigma, os programadores não estão mais desenvolvendo um produto ou programa. Em vez disso, eles estão implementando a funcionalidade que o cliente precisa."
"Qual é a diferença?"
"Bem, suponha que o desenvolvimento do programa levasse um ano. E seis meses se passaram antes que houvesse algo para olhar. É como construir uma casa grande: primeiro, você cava um buraco para a fundação, depois despeja a fundação, o construir as paredes, telhado, guarnição, etc."
"Mas agora os programadores tentam liberar a funcionalidade necessária o mais rápido possível. Isso seria como primeiro construir uma cabana, depois uma casa móvel, depois uma casa pequena e só então uma casa grande - em prestações."
"Considerando que o cliente provavelmente não sabe exatamente o que quer, essa é uma abordagem bastante razoável."
"Suponha que o cliente queira um grande pavilhão de caça."
"Os desenvolvedores constroem uma pequena para ele. Ele passa o inverno nela. Então ele decide que não gosta de casas de madeira. Vamos fazer uma de tijolo."
"Ele passa o verão perto do lago, mas os mosquitos o comem vivo. Ele tinha ouvido em algum lugar que os lagos são frescos, então pensou em ter um. Mas agora ele não quer um lago. E será mais fácil construir a casa desta forma: sem lago significa que não há ameaça de inundações, e você pode construir a casa no chão em vez de palafitas, o que será 25% mais rápido."
"Uma analogia interessante. Os clientes realmente mudam seus requisitos com tanta frequência?"
"Sim, mas o problema não é o cliente."
"Primeiro, é muito difícil imaginar como as coisas serão no futuro. Gerentes, testadores e programadores também fazem isso. Eles também mudam de ideia dependendo de como as coisas acontecem."
"Em segundo lugar, os requisitos do cliente não são o que mais importa? Afinal , o objetivo de todo esse trabalho é criar o que o cliente precisa , não o que ele inicialmente disse para criar ."
"Na verdade, funcionava assim: os analistas de negócios faziam uma lista de todos os requisitos. Eles colocavam essa lista em um contrato, assinavam e trabalhavam apenas de acordo com a lista."
"Se faltasse na lista algo que o cliente realmente precisava, mas havia esquecido, ninguém faria nada a respeito."
"Entendo. É mais fácil seguir um plano, mas nem tudo pode ser feito de acordo com um plano!"
"Exatamente."
"É por isso que os métodos de desenvolvimento ágil foram inventados."
"E hoje vou falar sobre o Scrum — o mais popular entre eles.
"O principal recurso do Scrum é a divisão do desenvolvimento do projeto em pequenas iterações - geralmente de 2 a 4 semanas de duração. Cada iteração é chamada de sprint."
"No início de um sprint, é realizada uma reunião de planejamento do sprint. Ela dura de 3 a 4 horas."
"No final, há uma demonstração de todas as tarefas totalmente concluídas."
"Aqui está como tudo geralmente funciona:"
"Antes do primeiro sprint, o cliente (ou um representante do cliente) forma uma lista de requisitos, ou seja, o conjunto de coisas que o programa deve ser capaz de fazer. Esses requisitos são geralmente chamados de histórias de usuário, e o cliente geralmente é chamado de proprietário do produto ."
"Ele é chamado de proprietário do produto porque o produto foi escrito para ele. Ele, e somente ele, define a lista de requisitos — o quê, quando e em que ordem."
"Além disso, o proprietário do produto geralmente atribui prioridades de tarefas. As tarefas com prioridade mais alta serão implementadas primeiro. A lista completa de requisitos também é chamada de backlog do produto ."
"Quando um sprint começa, todos se reúnem para uma reunião. O scrum master , geralmente um membro da equipe, geralmente conduz a reunião. O objetivo da reunião é selecionar as tarefas ( história do usuário ) para o sprint atual (iteração de desenvolvimento). "
"Primeiro, a equipe atribui a cada tarefa uma estimativa aproximada em dias-homem abstratos, também conhecidos como pontos de história. Em seguida, a equipe decide quantas tarefas terá tempo para concluir durante o sprint."
"Novamente, é a própria equipe que decide quantas tarefas terá tempo para concluir durante o sprint."
"Digamos que o proprietário do produto esperava que a equipe selecionasse as primeiras 7 tarefas, mas selecionou apenas 5, então as tarefas 6 e 7 são adiadas para o próximo sprint. Se isso não for adequado para o proprietário do produto , ele pode aumentar a prioridade das tarefas 6 e 7 para garantir que eles sejam selecionados, mas algumas das outras tarefas serão retiradas do sprint."
"O scrum master também pode propor dividir algumas das tarefas em outras menores e definir prioridades diferentes para deixar o proprietário do produto o mais feliz possível."
"Esse é o objetivo da reunião: as tarefas podem ser alteradas e divididas, as prioridades podem ser alteradas etc. Esse é o trabalho que não estava visível no início, mas que traz muito valor."
"Entendi. É como dirigir um carro. Mesmo que inicialmente você acredite que só precisa seguir em frente, a realidade é que você precisa constantemente evitar buracos, virar para a direita e para a esquerda e ultrapassar os outros ou deixá-los passar por você."
"Sim algo assim."
"A lista de tarefas escolhidas para o sprint é chamada de backlog do sprint ."
"Os programadores decidem quem vai fazer o quê, e só então eles começam a trabalhar." vai fazer hoje".
"Trabalho em equipe. Posso respeitar isso!"
"Para facilitar a visualização, geralmente é recomendável exibir o status atual do sprint em um quadro especial:"
"Observe as três colunas à esquerda."
"Nomes de tarefas abreviados são escritos em post-its. E os post-its são colocados em diferentes colunas, dependendo de seu status (planejado, em andamento, concluído)."
"À direita, você pode ver um gráfico de burndown . Para cada dia, esse gráfico lista as tarefas que ainda não foram concluídas. Idealmente, o número de tarefas incompletas cai para zero durante o sprint."
"Quando o sprint termina, o scrum-master faz uma demonstração para mostrar a lista de tudo que foi completamente finalizado."
"Em seguida, ele realiza uma reunião de retrospectiva do sprint, que também dura algumas horas. Durante essa reunião, os participantes geralmente tentam descobrir o que deu certo e o que (e como) as coisas poderiam ter sido feitas melhor."
"Normalmente, após 2-3 sprints, você pode identificar e eliminar os principais problemas que impedem a equipe de trabalhar com mais eficiência. Isso leva a uma maior produtividade sem aumentar a carga de trabalho da equipe. Isso não era possível antes da era das metodologias ágeis. "
"Às vezes, uma reunião de preparação também é realizada durante o sprint. Seu objetivo é planejar o próximo sprint. Os participantes geralmente esclarecem as prioridades das tarefas nessa reunião. Eles também podem dividir algumas tarefas em partes e/ou adicionar novas tarefas ao backlog do produto . "
"Bem, isso é basicamente tudo o que tenho. Esta é apenas uma visão geral. É impossível explicar tudo em apenas algumas palavras, mas você pode ler um bom artigo sobre o assunto aqui:"
GO TO FULL VERSION