Desenvolvimento de Software Adaptativo - Práticas
As práticas de Desenvolvimento de Software Adaptável são impulsionadas pela crença na adaptação contínua, com o ciclo de vida equipado para aceitar a mudança contínua como a norma.
O Adaptive Software Development Lifecycle é dedicado a -
- Aprendizado contínuo
- Mudança de orientação
- Re-evaluation
- Perscrutando um futuro incerto
- Colaboração intensa entre desenvolvedores, gerenciamento e clientes
SDLC Adaptativo
O Adaptive Software Development combina RAD com as Melhores Práticas de Engenharia de Software, como -
- Iniciação do projeto.
- Planejamento de ciclo adaptativo.
- Engenharia de componentes simultâneos.
- Revisão de qualidade.
- Controle de qualidade e lançamento final.
As práticas de Desenvolvimento de Software Adaptável podem ser ilustradas da seguinte forma -
Conforme ilustrado acima, as práticas de Desenvolvimento de Software Adaptável estão espalhadas pelas três fases da seguinte forma -
Especular - Iniciação e planejamento
Iniciação do projeto
Estabelecer prazo para todo o projeto
Decida o número de iterações e atribua uma caixa de tempo para cada uma
Desenvolva um tema ou objetivo para cada uma das iterações
Atribuir recursos a cada iteração
Collaborate - Desenvolvimento simultâneo de recursos
Colaboração para equipes distribuídas
Colaboração para projetos menores
Colaboração para projetos maiores
Learn - Avaliação de qualidade
Qualidade do resultado da perspectiva do cliente
Qualidade do resultado de uma perspectiva técnica
O funcionamento da equipe de entrega e as práticas que os membros da equipe estão utilizando
O status do projeto
Especular - Iniciação e Planejamento
No Desenvolvimento de Software Adaptativo, a fase especular tem duas atividades -
- Initiation
- Planning
Speculate tem cinco práticas que podem ser executadas repetidamente durante a fase de iniciação e planejamento. Eles são -
- Iniciação do projeto
- Estabelecer prazo para todo o projeto
- Decida o número de iterações e atribua uma caixa de tempo para cada uma
- Desenvolva um tema ou objetivo para cada uma das iterações
- Atribuir recursos a cada iteração
Iniciação do projeto
A Iniciação do Projeto envolve -
- Definir a missão e os objetivos do projeto
- Compreendendo as restrições
- Estabelecendo a organização do projeto
- Identificação e definição de requisitos
- Fazendo estimativas iniciais de tamanho e escopo
- Identificando os principais riscos do projeto
Os dados de início do projeto devem ser coletados em uma sessão JAD preliminar, considerando a velocidade como o aspecto principal. A iniciação pode ser concluída em um esforço concentrado de dois a cinco dias para projetos de pequeno a médio porte, ou em um esforço de duas a três semanas para projetos maiores.
Durante as sessões JAD, os requisitos são reunidos em detalhes suficientes para identificar recursos e estabelecer uma visão geral do objeto, dados ou outro modelo de arquitetura.
Estabelecendo prazo para todo o projeto
O prazo para todo o projeto deve ser estabelecido, com base no escopo, requisitos do conjunto de recursos, estimativas e disponibilidade de recursos que resultam do trabalho de iniciação do projeto.
Como você sabe, especular não abandona as estimativas, mas significa apenas aceitar que as estimativas podem dar errado.
Iterações e caixa de tempo
Decida o número de iterações e os comprimentos de iteração individuais com base no escopo geral do projeto e no grau de incerteza.
Para uma aplicação de pequeno a médio porte -
- As iterações geralmente variam de quatro a oito semanas.
- Alguns projetos funcionam melhor com iterações de duas semanas.
- Alguns projetos podem exigir mais de oito semanas.
Escolha o horário com base no que funciona para você. Depois de decidir sobre o número de iterações e a duração de cada uma delas, atribua uma programação para cada uma delas.
Desenvolva um tema ou objetivo
Os membros da equipe devem desenvolver um tema ou objetivo para cada iteração. Isso é algo semelhante ao objetivo do Sprint no Scrum. Cada iteração deve entregar um conjunto de recursos que podem demonstrar a funcionalidade do produto, tornando-o visível para o cliente para permitir revisão e feedback.
Dentro das iterações, os builds devem entregar recursos de trabalho em uma base preferencialmente diária, permitindo o processo de integração e tornando o produto visível para a equipe de desenvolvimento. O teste deve ser uma parte contínua e integrante do desenvolvimento de recursos. Não deve ser atrasado até o final do projeto.
Atribuir recursos
Os desenvolvedores e clientes devem, juntos, atribuir recursos a cada iteração. O critério mais importante para esta atribuição de recurso é que cada iteração deve entregar um conjunto visível de recursos com funcionalidade considerável para o cliente.
Durante a atribuição de recursos às iterações -
A equipe de desenvolvimento deve apresentar estimativas de recursos, riscos e dependências e fornecê-los ao cliente.
Os clientes devem decidir sobre a priorização de recursos, usando as informações fornecidas pela equipe de desenvolvimento.
Portanto, o planejamento de iteração é baseado em recursos e feito em equipe com desenvolvedores e clientes. A experiência tem mostrado que esse tipo de planejamento fornece melhor compreensão do projeto do que um planejamento baseado em tarefas pelo gerente de projeto. Além disso, o planejamento baseado em recursos reflete a singularidade de cada projeto.
Colaborar ─ Desenvolvimento de recursos simultâneos
Durante a fase de Colaboração, o foco está no desenvolvimento. A fase de colaboração tem duas atividades -
A equipe de desenvolvimento colabora e entrega software funcional.
Os gerentes de projeto facilitam a colaboração e as atividades de desenvolvimento simultâneas.
A colaboração é um ato de criação compartilhada que abrange a equipe de desenvolvimento, os clientes e os gerentes. A criação compartilhada é fomentada pela confiança e respeito.
As equipes devem colaborar em -
- Problemas técnicos
- Requisitos de negócio
- Tomada de decisão rápida
A seguir estão as práticas relevantes para a fase de Colaboração no Desenvolvimento de Software Adaptável -
- Colaboração para equipes distribuídas
- Colaboração para projetos menores
- Colaboração para projetos maiores
Colaboração para equipes distribuídas
Nos projetos envolvendo equipes distribuídas, deve-se considerar o seguinte:
- Vários parceiros de aliança
- Conhecimento de base ampla
- A forma como as pessoas interagem
- A maneira como eles gerenciam as interdependências
Colaboração para projetos menores
Nos projetos menores, quando os membros da equipe estão trabalhando em proximidade física, a colaboração com bate-papos informais no corredor e rabiscos no quadro branco deve ser incentivada, pois isso é considerado eficaz.
Colaboração para projetos maiores
Projetos maiores requerem práticas adicionais, ferramentas de colaboração e interação do gerente de projeto e devem ser organizados de acordo com o contexto.
Aprenda - revisão de qualidade
O Adaptive Software Development incentiva o conceito de 'Experimentar e Aprender'.
Aprender com os erros e experimentação requer que os membros da equipe compartilhem códigos e artefatos parcialmente concluídos no início, a fim de -
- Encontre erros
- Aprenda com eles
- Reduza o retrabalho encontrando pequenos problemas antes que eles se tornem grandes
No final de cada iteração de desenvolvimento, existem quatro categorias gerais de coisas a aprender -
- Qualidade do resultado da perspectiva do cliente
- Qualidade do resultado de uma perspectiva técnica
- O funcionamento da equipe de entrega e da equipe de prática
- O status do projeto
Qualidade do resultado da perspectiva do cliente
Nos projetos de Desenvolvimento de Software Adaptável, obter feedback dos clientes é a primeira prioridade. A prática recomendada para isso é um grupo de foco do cliente. Essas sessões são projetadas para explorar um modelo de trabalho do aplicativo e registrar as solicitações de mudança do cliente.
As sessões de grupo de foco do cliente são sessões facilitadas, semelhantes às sessões jad, mas em vez de gerar requisitos ou definir planos de projeto, elas são projetadas para revisar o próprio aplicativo. Os clientes fornecem feedback sobre o software de trabalho resultante de uma iteração.
Qualidade do resultado de uma perspectiva técnica
Nos projetos de Desenvolvimento de Software Adaptativo, a revisão periódica dos artefatos técnicos deve ser considerada importante. As revisões de código devem ser feitas continuamente. Revisões de outros artefatos técnicos, como arquitetura técnica, podem ser conduzidas semanalmente ou ao final de uma iteração.
Em projetos de Desenvolvimento de Software Adaptativo, a equipe deve monitorar seu próprio desempenho periodicamente. As retrospectivas estimulam as equipes a aprenderem sobre si mesmas e seu trabalho, juntas como uma equipe.
Retrospectivas de fim de iteração facilitam a autoavaliação periódica do desempenho da equipe, como -
- Determine o que não está funcionando.
- O que a equipe precisa fazer mais.
- O que a equipe precisa fazer menos.
O Status do Projeto
A revisão do status do projeto ajuda no planejamento do trabalho futuro. Nos projetos de desenvolvimento de software adaptativo, a determinação do status do projeto é uma abordagem baseada em recursos, o final de cada iteração marcado por recursos concluídos resultando em software funcional.
A revisão do status do projeto deve incluir:
- Onde está o projeto?
- Onde está o projeto versus os planos?
- Onde deveria estar o projeto?
Como os planos nos projetos de Desenvolvimento de Software Adaptativo são especulativos, mais do que a questão 2 acima, a questão 3 é importante. Ou seja, a equipe do projeto e os clientes precisam se perguntar continuamente: "O que aprendemos até agora e isso muda nossa perspectiva sobre aonde precisamos ir?"