Desenvolvimento ágil
1. O significado de agilidade
O desenvolvimento ágil é uma centrada no homem , iterativa , incrementais metodologia de desenvolvimento. No desenvolvimento ágil, um grande projeto é dividido em vários pequenos projetos que são interconectados e podem ser executados de forma independente e concluídos separadamente.Nesse processo, o software estava em uso.
As três palavras-chave mencionadas acima estão descritas abaixo:
Tomando as pessoas como o núcleo: é sabido que, no modelo de desenvolvimento em cascata, um grande número de documentos será exibido.Os desenvolvedores geralmente desenvolvem com base em documentos e tudo é baseado em documentos; enquanto o desenvolvimento ágil defende a escrita de menos documentos, com foco na comunicação pessoal entre as pessoas. Comunique-se para resolver problemas do projeto, enfatizando as pessoas como o núcleo
Desenvolvimento iterativo: refere-se à decomposição de uma tarefa grande que é complexa e possui um longo ciclo de desenvolvimento em várias tarefas que podem ser concluídas em um pequeno ciclo. Esse ciclo é uma iteração; ao mesmo tempo, cada iteração pode produzir ou desenvolver um software que pode ser entregue. Produtos>
Desenvolvimento incremental: refere-se a cada versão lançada do software, que adicionará uma função completa que os usuários podem perceber. Pode-se entender que a iteração é dividida de acordo com as novas funções
2. Quão ágil?
O ágil descrito acima é mais uma ideia, mas quais são as maneiras de implementar o desenvolvimento ágil? Existem dois métodos comuns de Scrum e XP: Antes de explicar as etapas específicas, fale sobre suas diferenças.
A diferença que pode ser encontrada em qualquer lugar da Internet é: Scrum se concentra no processo, o XP se concentra na prática. Para explicar esta frase brevemente, Scrum é projetar alguns métodos para definir a agilidade do gerenciamento e do processo. XP é uma escavação profunda de pensamentos ágeis a partir de detalhes específicos e o método de realização de um determinado trabalho. As diferenças são as seguintes:
1. As equipes Scrum e XP trabalham de maneira iterativa, mas o ciclo Scrum é geralmente de duas semanas a um mês, e o ciclo XP é de uma ou duas semanas.
2. A equipe Scrum não aceita nenhuma alteração de tarefa em um sprint. Em uma iteração da equipe do XP, se a nova história de usuário tiver o mesmo tamanho e tamanho da original, ela poderá ser substituída pela nova.
3. A equipe do XP trabalhará estritamente de acordo com a prioridade da tarefa. Todas as tarefas são priorizadas pelo cliente e a equipe deve trabalhar sob essa prioridade. Mas a equipe da equipe scrum decidirá por si mesma em que ordem eles concluirão todas as tarefas.
4. O Scrum não define nenhum método de prática de engenharia, apenas fornece uma estrutura prática para você. Mas o XP, Extreme Programming, fornecerá algo assim. Tal como teste -driven desenvolvimento, testes automatizados, programação par, design simples, reconstrução, e assim por diante.
Vamos falar sobre Scrum e XP separadamente
Processo Scrum
Etapas do Scrum:
1. Primeiro precisamos determinar um Backlog do Produto (uma lista de requisitos do produto organizados por prioridade), que é de responsabilidade do gerente do produto
2. A equipe Scrum faz uma estimativa e um plano de carga de trabalho com base na lista Backlog do Produto;
3. Com a lista Backlog do Produto, precisamos selecionar uma História (história do usuário) da Reunião de Planejamento da Sprint como meta para esta iteração.O período de tempo dessa meta é de 1 a 4 semanas e, em seguida, colocar Esta história é refinada para formar um Sprint Backlog; (PS: Sprint significa uma iteração)
4. O Sprint Backlog é concluído pela equipe Scrum, e cada membro é refinado em tarefas menores com base no Sprint Backlog (na medida em que a carga de trabalho de cada tarefa possa ser concluída em 2 dias);
5. Durante o Sprint Backlog selecionado pela equipe Scrum para concluir a reunião de planejamento, é necessária a Reunião Diária do Scrum (reunião permanente diária). Cada reunião é controlada em cerca de 15 minutos. Todos devem falar e enfrentar todos os membros. Relate o que você fez ontem, prometa o que deseja realizar hoje e também pode fazer perguntas que não pode resolver Figura);
6. Alcançar a integração diária, o que significa que deve haver uma versão que possa ser compilada e demonstrada com sucesso todos os dias; as ferramentas podem ser usadas para enviar, atualizar, testar e liberar
7. Quando uma história é concluída, ou seja, o Backlog da Sprint é concluído, significa que uma iteração é concluída. Conduziremos uma Reunião de Revisão Srpint (reunião de apresentação), também conhecida como reunião de revisão. Cada membro da equipe Scrum deve demonstrar sua própria conclusão Produtos de software
8. A última é a Reunião Retrospectiva da Sprint, também conhecida como reunião resumida, que se alterna para falar, resumir e discutir melhorias e colocá-la na próxima rodada de requisitos de produtos da Sprint;
Prática Agile XP
XP significa Extreme Programming (abreviação de Extreme Programming). A programação extrema é uma maneira de trabalhar que enfatiza o trabalho em equipe, e é uma das muitas maneiras ágeis. Diferentemente do Scrum, o Scrum é uma estrutura de métodos de trabalho, da organização ao design da equipe, e o XP se concentra em práticas técnicas e de engenharia específicas. O XP visa usar a combinação razoável de práticas de engenharia, para que os desenvolvedores possam responder com confiança às necessidades do cliente. Enfatize o mecanismo do ciclo de feedback , o ciclo de feedback entre o cliente e a equipe de P & D, o ciclo de feedback para teste e desenvolvimento, o ciclo de feedback entre a implementação específica do código e o teste de unidade e o ciclo de feedback entre o par. A Extreme Programming acredita que, no processo de desenvolvimento de software, a mudança é onipresente, as pessoas não devem evitar a mudança, mas devem se adaptar às mudanças, adaptar-se às mudanças através do feedback.
Prática de engenharia XP:
1. Liberação pequena
Cada versão deve ser a menor possível, é claro, o pré-requisito é que cada versão tenha valor comercial suficiente e valha a pena publicá-la. Como os pequenos lançamentos podem tornar a integração mais frequente, mais freqüentes os resultados intermediários obtidos pelo cliente e mais freqüentes os comentários, o cliente pode entender o andamento do projeto em tempo real, de modo a apresentar mais opiniões para o planejamento na próxima iteração. Para alcançar maior satisfação do cliente.
2. O jogo do planejamento
A idéia principal do jogo de planejamento é formular rapidamente um plano de resumo e melhorar gradualmente o plano à medida que os detalhes do projeto se tornam mais claros. O resultado do jogo de planejamento é um conjunto de histórias de usuários e um plano de resumo para a próxima iteração ou dois. "Os clientes são responsáveis pelas decisões de negócios e as equipes de desenvolvimento são responsáveis pelas decisões técnicas" é um pré-requisito para o sucesso do jogo de planejamento. Em outras palavras, o escopo do sistema, o tempo de liberação da próxima iteração e a prioridade das histórias de usuário devem ser determinados pelo cliente; e o tempo de desenvolvimento necessário para cada história de usuário, o custo de diferentes tecnologias, como formar uma equipe e cada história de usuário. O risco e a sequência de desenvolvimento específica devem ser decididos pela equipe de desenvolvimento.
3. Cliente no local
Para garantir que os resultados do desenvolvimento estejam próximos das expectativas do cliente, a metodologia XP acredita que o mais importante é convidar o cliente para o site de desenvolvimento. Portanto, é muito importante para o projeto XP que os clientes esclareçam as histórias de usuários no local e tomem as decisões de negócios correspondentes.
4. Design Simples
Essa prática parece fácil de entender, mas geralmente é mal compreendida, e muitos críticos acusam o XP de ignorar o design. De fato, a prática simples de design do XP não é ignorar o design, e acha que o design não deve ser concluído de uma só vez antes da codificação, porque isso só pode ser construído com "a situação não vai mudar" ou "podemos prever todas as alterações" e coisas do gênero. Baseado em mentiras.
5. Programação em pares
Todo o software é feito por dois programadores sentados lado a lado na mesma máquina.
6. Desenvolvimento Orientado a Testes (Teste)
Escrever testes de unidade é um ato de verificação e um projeto. A gravação de testes de unidade evita um número considerável de loops de feedback, especialmente na verificação funcional. Os programadores trabalham em um ciclo muito curto, escrevem um script de teste automatizado com antecedência e depois codificam para fazê-lo passar.
7. Refatoração
A refatoração é uma maneira de melhorar o código sem afetar a implementação da função.O XP exige que os desenvolvedores tenham a coragem de refatorar o código quando sentirem o cheiro ruim do código. O objetivo da refatoração é reduzir o risco de alterações e tornar o código mais elegante.
8. Integração Contínua
O significado da integração contínua é exigir que a equipe do XP faça a integração do código tantas vezes quanto possível todos os dias, após o teste de unidade, para garantir que o sistema seja aprovado. Dessa maneira, os erros causados pela refatoração e propriedade coletiva do código podem ser expostos e eliminados antecipadamente. Depois que uma pessoa confirma, todos os outros são responsáveis pela integração do código.
9. Propriedade do código coletivo
Qualquer par de programadores pode melhorar qualquer código a qualquer momento. Nenhum programador é o único responsável por qualquer módulo ou tecnologia em particular, e todos podem participar de qualquer outro aspecto do desenvolvimento.
10. Padrões de Código
A metodologia XP acredita que ter padrões de codificação pode impedir as equipes de discutir detalhes que não estão relacionados ao progresso do desenvolvimento.
11. Metáfora do Sistema
É a imagem futura do sistema, uma visão global que liga todo o sistema; torna a localização e a aparência de todos os módulos individuais óbvias e intuitivas. Se a aparência do módulo não corresponder à metáfora inteira, você saberá que o módulo está errado.
12. Velocidade sustentável / semana de 40 horas
As horas extras têm sido um lugar comum para os desenvolvedores e também é uma estratégia mais comumente usada pelos gerentes.A metodologia do XP acredita que as horas extras acabarão com o entusiasmo da equipe e, eventualmente, levarão ao fracasso do projeto. Somente se o time durar, há esperança de vitória. Eles trabalham duro a uma velocidade que pode ser mantida por um longo tempo, economizam energia e consideram o projeto uma maratona, não um sprint a toda velocidade.
