Bom toda a hora do dia. Foi a vez de falar sobre o design de projetos. Pela minha própria experiência, sei que às vezes é mais difícil criar um projeto do zero do que arrumar o que já existe. Isso se deve em grande parte ao legado que você ou você deixa para trás. Neste artigo, tentarei lhe dizer a que vale a pena prestar atenção especial e sugerir um plano curto para seguir.
Compreensão do projeto
Antes de planejar algo, você precisa entender qual projeto você precisa implementar. Para mim, identifiquei várias categorias de projetos, como:
- Um artesanato único é um projeto que visa criar algum tipo de conceito gráfico e sua venda adicional aos investidores. Características distintivas desse tipo de projeto são:
- Documentação insana. A idéia básica é clara, mas os casos de negócios estão em completo caos e não há buracos lógicos a serem considerados.
- Prazos. Até 3 meses desde a escrita da documentação até o protótipo.
- Não há planos de desenvolvimento e nenhum suporte adicional está planejado.
- Equipe pequena. Geralmente até 5 pessoas, incluindo designers.
- Falta de processos de negócios. Toda interação é caótica, com base na comunicação interpessoal, no esclarecimento de pontos-chave e / ou na invenção em movimento.
- As funções estão borradas. Não existe uma divisão clara de poderes e áreas de responsabilidade.
- Sem dados reais. Todos os dados são gerados para "beleza" e adaptados para melhor exibição.
- Para acelerar o desenvolvimento, dependências externas são usadas completamente.
- Uma inicialização é um projeto configurado para implementar uma ideia específica, com desenvolvimento subsequente. Geralmente, esses projetos são desenvolvidos de acordo com um modelo em espiral e, por esse motivo, têm quase as mesmas características distintivas do primeiro tipo (embarcação única):
- Divisão clara em etapas. Mínimo: termos e uma lista de funcionalidades que devem ser implementadas em um determinado período de tempo.
- Documentação relativamente sã. As análises realizadas, os parâmetros de referência para as etapas de conclusão definidas, os refinamentos geralmente ocorrem durante o sprint. Na maioria das vezes, usa cascata, apesar do Agile reivindicar.
- Prazos médios para a funcionalidade principal. Em média, de 6 a 12 meses.
- Nos estágios iniciais, são usadas dependências externas, que eventualmente mudam para sua própria implementação.
- Equipe pequena. Geralmente até 7-10 pessoas.
- Há uma separação de papéis, mas a responsabilidade é borrada.
- Um projeto pode sofrer mutação. Em um estágio, o conceito ou a abordagem da implementação pode mudar. Geralmente, isso ocorre devido aos requisitos dos investidores, uma idéia inicialmente falhada ou erros na arquitetura.
- Dados condicionais ao vivo. Executando em grupos focais ou analisando dados ao vivo de recursos de terceiros. É verdade que isso nem sempre acontece ...
- Um sistema de informação é um projeto que implementa uma idéia com planos de integração em serviços de terceiros.
- Existe um plano de desenvolvimento.
- Documentação claramente escrita. Mínimo: descrição da API documentada.
- Pode ser necessário integrar-se a serviços de terceiros, instalar muletas ou reconstruir partes do sistema.
- Existem versões intermediárias, hot fixes.
- Equipe média. Geralmente de 10 a 20 a 30 pessoas.
- Separação clara de responsabilidades.
- Requisitos de segurança: após a análise, são criados casos que podem levar ao colapso do sistema.
- O tempo é dedicado aos testes.
- Usado pelo Agile.
- Quase sempre há uma lista de pendências.
- Somente dependências externas que são caras de implementar por conta própria são usadas. É praticado em pé de igualdade com os proprietários.
- Um sistema fechado é um projeto volumoso projetado para atender às necessidades específicas do Cliente, com mais refinamento.
- Cliente específico.
- Existe um plano de desenvolvimento.
- Documentação de design para desenvolvimento. Para ajudar os usuários, uma documentação separada foi gravada a pedido do Cliente.
- Diferenciação de direitos do usuário.
- Quase sempre há uma lista de pendências.
- O tamanho da equipe geralmente é maior que a média. Por via de regra, de 10 pessoas a uma perda de frequência cardíaca.
- Usado pelo Agile. Periodicamente, chegam tarefas adicionais que devem ser implementadas a todo custo.
- Demonstrações inesperadas. As demandas ocorrem a pedido da gerência sênior, portanto, um circuito de teste viável nunca será redundante.
- A solução Saas é um projeto volumoso com configuração flexível e personalização adicional para um cliente específico.
- Sistema multimodular. O sistema é dividido em várias partes. Que pode ser usado individualmente, mesmo fora do escopo de um projeto específico.
- Planejamento claro. Mínimo: os custos de mão-de-obra são estimados para a implementação de recursos. Está previsto o tempo para modernização e refatoração.
- Documentação volumétrica. Quase tudo é descrito, como regra, incluindo casos de teste.
- Como regra, não há dependências externas e suas próprias implementações de partes do sistema são gravadas. Mesmo se houver implementações de terceiros.
- Várias equipes de desenvolvimento. Todos são responsáveis por sua parte do desenvolvimento, seja de apoio ou de frente.
- Teste a cobertura de tudo e de tudo. Testes automáticos, de unidade, de regressão e de integração são usados.
Todas as gradações são condicionais e os tipos de fluxo são mais frequentemente encontrados. Quero observar que todos os tipos podem sofrer mutações, a única nuance está no custo da modernização. Por exemplo, o projeto era originalmente uma "embarcação única" e depois evoluiu para um "sistema fechado". Geralmente, isso leva a uma reescrita completa ou quase completa do sistema ou sua refatoração. Como você sabe, isso não é economicamente viável. Pelo mesmo motivo, é aconselhável entender que tipo de projeto você precisa criar do zero e tentar determinar seu destino futuro.
Para determinar o tipo de projeto, abaixo fiz perguntas, tendo recebido uma resposta para a qual ficará claro o que eles querem de você:
- O objetivo do projeto?
- Uma lista completa do que precisa ser implementado?
- Existe alguma documentação?
- Quais são os prazos? Datas precisas são desejáveis.
- A interação externa é planejada com sistemas de terceiros ou o projeto terá uma API externa
- Existem desenvolvimentos?
- Tamanho da equipe?
- Quem é responsável por quê? Quem define tarefas, quem aceita, quem tem direitos de veto.
- Existem planos de desenvolvimento e quais são eles?
- Quem é o cliente?
- Existe um orçamento para a compra de soluções chave na mão?
- Em que metodologia você planeja trabalhar
- Existem análogos?
Como você pode ver, a lista não é tão grande. No entanto, por algum motivo desconhecido, poucas pessoas fazem essas perguntas antes de começar a fazer qualquer coisa. Você pergunta por que eu deveria entender o tipo de projeto ?! Você sempre tem que fazer o projeto viver para sempre ?! Em geral, você está certo, mas há nuances, como em uma piada cheia de vapor. Essas nuances são recursos e cronogramas. Não esqueça que trabalhamos para o bem dos negócios e realizamos as tarefas. Quando você conhece o tipo de projeto, pode sacrificar algo sem uma pontada de consciência para atingir seus objetivos.
Seleção de tecnologia
Na escolha, é melhor aderir à regra: a tecnologia não deve ser supernova, mas também desatualizada. Se a tecnologia ou estrutura for nova, isso pode resultar em problemas como:
- Procure pessoal qualificado
- Perspectivas de desenvolvimento: nos estágios iniciais, o desenvolvimento pode morrer ou, inversamente, se a tecnologia for antiga, os bugs precisarão ser corrigidos por nós mesmos.
- Falta de soluções chave na mão para as novas e falta de atualizações para as antigas.
Essa lista de problemas é relevante não apenas em relação à tecnologia, mas também às dependências de terceiros. Todos os itens acima podem enterrar o projeto pela raiz.
Antes de escolher algo específico, pense algumas vezes. Crie uma tabela notória de benefícios com fatores de importância para o projeto.
Este exemplo é para um projeto fictício:
O nome da funcionalidade do projeto.
| Relação de importância do projeto
|
|---|
Trabalhar com formulários
| 3
|
Encaminhamento
| 1
|
Facilidade de escrever animação
| 0,3
|
Como pode ser visto na tabela, os critérios importantes para a seleção são “trabalhar com formulários” e “rotear”. A simplicidade da criação de animação para este projeto não é significativa. Em seguida, atualizaremos a tabela adicionando novas colunas de tecnologia. No nosso caso, haverá dois.
O nome da funcionalidade do projeto.
| Relação de importância do projeto
| Tecnologia 1
| Tecnologia 2
|
|---|
Trabalhar com formulários
| 3
| +
| ±
|
Encaminhamento
| 1
| +
| ±
|
Facilidade de escrever animação
| 0,3
| +
| -
|
Com base nos dados da tabela, entendemos que a “Tecnologia 2” trabalha com formulários e roteamento é manca, e criar uma animação é como chamar Satan. Como resultado, o peso específico dessa tecnologia é 2. Você pergunta por que 2? Tudo é simples! Se você definir ±, nessa tecnologia um funcional específico será implementado, mas com algum tipo de "muleta", ou será mais trabalhoso. Em nossa comparação, a "Tecnologia 1" será mais lucrativa, com um total de 4,3. Penso que a explicação sobre a formação dos montantes é desnecessária. Esta tabela funciona não apenas com tecnologia, mas com tudo o que requer comparação e seleção da lista. O principal é não esquecer que quanto mais critérios você escrever, mais fácil será para você fazer uma escolha.
Arquitetura
Atualmente, é possível escolher entre uma variedade de serviços diferentes que fornecem ferramentas para o projeto arquitetônico. É verdade que qualquer um deles tem desvantagens, para alguns é crítico, mas para alguém não. Como sou velho, prefiro um pedaço de papel e uma caneta ou um quadro e um marcador.
Para entender o que pegar em primeiro lugar, você precisa descrever as principais partes do sistema e, em seguida, escolher a maneira de construir a arquitetura. Como regra, na prática, apenas três são usados:
Descendente - os desenvolvedores passam de nós grandes do sistema e vão para os menores. O significado da arquitetura é que os componentes prioritários são nós grandes que contêm outros menores.
Crescente - os desenvolvedores buscam peças pequenas e vão para peças maiores. O significado da arquitetura é que, a princípio, muitos componentes pequenos são criados e outros maiores já são montados a partir deles.
O monólito é uma arquitetura indivisível, geralmente chamada de "legado". De fato, é uma estrutura rígida, cuja mudança requer soluções sem "muletas". Essa é a pior opção, mas, como tudo em nosso mundo, ela tem o direito de existir. O monólito é usado para implementar funcionalidades específicas e não planeja mantê-las no futuro. Comparado a outros, a velocidade dessa abordagem é muitas vezes mais rápida. Bem, só porque você pode fechar muito os olhos.
A escolha da arquitetura depende dos objetivos do projeto e da velocidade do desenvolvimento. Geralmente, o primeiro método é usado quando os prazos não estão se esgotando e o número de módulos grandes é pequeno. Sua característica é que é possível representar com precisão o relacionamento entre módulos específicos. Das desvantagens, posso observar um longo tempo de desenvolvimento associado a uma sequência de ações.
O segundo método é preferido quando é necessária alta velocidade de desenvolvimento e não há entendimento da arquitetura de nível superior. Um recurso são os muitos componentes pequenos que às vezes são usados em diferentes unidades grandes. Vale ressaltar que quase todo o desenvolvimento pode ser realizado em paralelo, sem levar em conta outras tarefas. As desvantagens dessa abordagem serão componentes que não atendem aos requisitos da arquitetura de nível superior e, portanto, terão que ser reescritos ou criar a possibilidade de customização.
Como mostra a prática, todas as técnicas de desenvolvimento são reduzidas a uma abordagem em espiral, caracterizada por um aumento gradual da funcionalidade. Não considero apropriado considerá-lo na estrutura deste artigo.
Planejamento
O chamado "Roteiro" ajudará você a fazer seu trabalho com mais eficiência. De fato, esse é um cronograma, com prazos condicionais para a entrega de um determinado funcional. As datas podem ser adiadas, mas, como mostra a prática, com a implementação adequada dos pontos acima, a alteração será de até 30%. Na prática, isso geralmente é de 10 a 15%. O planejamento permitirá que você acompanhe o progresso do projeto, veja a flacidez, faça ajustes na forma de recursos ou uma mudança nos prazos, etc.
Pelo qual mais tarde eles vão agradecer
Qualquer projeto começa com a documentação e, quanto mais, melhor! Portanto, não seja preguiçoso - nós documentamos TUDO. Sim, levará algum tempo, mas, posteriormente, poderá salvá-lo da ira da liderança, se algo der errado, não sua culpa. Além disso, não esqueça que, depois de aparecer no projeto, as pessoas terão que entender o que você criou. E sem documentos, isso não será fácil.
Conclusões
Este artigo descreve como agir e o que procurar ao iniciar um projeto. Esses estágios são universais para frente, verso, teste ou todos juntos. Evitei deliberadamente as especificidades da tecnologia, para não ser enganosa.
Quando você tem uma escolha sobre qual pilha de tecnologia usar, arquitetura e precisa determinar o prazo para o projeto, a tabela abaixo pode ajudá-lo:
Tipo / Recursos do Projeto
| Embarcações descartáveis
| Inicialização
| Sistemas de informação
| Sistemas fechados
| Soluções Saas
| Alguns outros projetos
|
|---|
Nº de pessoas com menos de 5 anos
| | X
| X
| X
| X
| |
Número de pessoas de 7 a 10
| | | | | | |
Número de pessoas de 10 a 30
| X
| | | | | |
Quantidade acima de 30
| X
| X
| | | | |
Data de conclusão até 3 meses
| | X
| X
| X
| X
| |
Prazo de entrega de 6 a 12 meses
| | | | | | |
Período superior a 12 meses
| X
| | | | | |
A documentação
| | | | | | |
Requisitos de integração com outros sistemas
| | | | | | |
Cliente específico conhecido
| | | | | | |
Suporte adicional planejado
| | | | | | |
Planejamento
| | | | | | |
As funções são claramente delineadas
| | | | | | |
Dependências externas permitidas
| | | | | | |
Existem dados ativos para testes e análises.
| | | | | | |
Requisitos de segurança
| | | | | | |
Teste necessário
| | | | | | |
Requer documentação ou instruções do produto
| | | | | | |
Implementação modular necessária
| | | | | | |
Várias equipes de desenvolvimento
| | | | | | |
Total
| | | | | | |
Como usar a tabela, acho que todo mundo já adivinhou, mas por precaução - exatamente o mesmo que o anterior, apenas com uma pequena adição na forma de células preenchidas. Isso significa que o valor não pode ser usado para este projeto. Além disso, observe que a tabela pode estar incompleta; adicione as linhas que considerar necessárias.