O ciclo de vida do software é conhecido pela maioria dos programadores modernos.
Mesmo um estudante escrevendo seu primeiro programa
<?php echo "Hello, ! " ?>
ou
fprintf( ' !\n');
entende o processo.
- Pensando sobre a tarefa - o estágio da idéia
- Ele pensa sobre a tarefa e de que maneira ela precisa ser implementada - Análise e elaboração de requisitos,
construção de um modelo de software e plano de implementação. Em suma, o estágio arquitetônico. - Programação
- Teste. "O que aconteceu lá"
- Operação.
Entre os estágios 1-5, temos processos de interação contínua.
Para isso, existem todos os tipos de cachoeiras, Scrum, etc.
Então, o problema é que, quando o seu projeto infla para vários tipos de frontend,
como o mundo moderno de TI exige, o cliente deseja maximizar o público para maximizar seus próprios lucros.
E por esse motivo, todos observamos uma abundância de projetos nos quais existem vários tipos de front-ends que interagem via API com um back-end centralizado.
De um modo geral, um "projeto forte padrão" possui três tipos de frentes:
- Site
- Aplicação móvel no Android
- Aplicativo móvel IOS
Com uma única API desenvolvida para troca de dados através do REST.
Um bom exemplo em que vou confiar são as mídias sociais (veja meu artigo anterior sobre seu próprio player com base no YouTube vidos)
Um projeto grande possui três opções para obter lucro ou qualquer critério que
condicionalmente Web, apple e android.
É conveniente que os programadores interajam com a arquitetura de back-end centralizada e se concentrem em sua frente pessoal, que estão desenvolvendo.
E aqui o destaque do artigo aparece.
O fato é que, no nível mais alto da tomada de decisão entre os superiores
um novo recurso é formado, que vai para trás. Mas como o "chefe" é uma pessoa imperfeita,
então ele tem que baixar seus poderes para os níveis mais baixos.
Portanto, em nosso caso, como regra, acima de cada frente também aparecem seus chefes de "baixo nível" de acordo com motivos hierárquicos ou formais. Algo
tipo de timlides para simplificar.
E a tarefa de desenvolver um grande projeto na forma de uma espécie de "ciclo de vida de desenvolvimento"
e a operação do software é dividida em seus ciclos de vida.
E surge a questão de sincronizar os processos de “mini” ciclos de vida, porque se você se antecipa, por exemplo, a um desenvolvedor web de um novo recurso, precisa esperar por um desenvolvedor móvel.
Caso contrário, o significado do novo recurso será perdido em prioridade, porque agora estamos todos na Web e em aplicativos móveis a partir de smartphones.
Vamos pensar em como avaliar a introdução de novos recursos para minimizar os recursos humanos em tal situação.
Aqui vou expressar as teses:
- Ao implementar um recurso em uma das frentes, precisamos levar em consideração os ciclos de outras frentes, ou programar stubs padrão, para que mais tarde possamos “recuperar o atraso” dos recursos de outras frentes e nivelá-los.
- Você pode criar um esquema para o ciclo de desenvolvimento de software como um todo, para que todos saiam bem condicionalmente, o recurso será implementado no prazo, mas pelo menos a independência das equipes front-end entre si será perdida - o feed e o ágil para todo o sistema perderão sua relevância ou aumentará o tempo de iteração. desenvolvimento. Em resumo, mais conversas ocorrerão e o código será escrito mais lentamente.
- As frentes isoladas, em princípio, são mais rápidas, mas são necessários mais testes de integração de custos humanos.
- Os esquemas que estão sendo implementados atualmente - cada frente é desenvolvida separadamente e independentemente uma da outra com um mínimo de interações, mas aqui estão perdidos alguns dos princípios básicos de TI -, de alguma forma, obteremos um grupo diferente de zero de usuários que às vezes verá bugs.
Aqui, a filosofia da pergunta é que os usuários não gostam de bugs por definição. E o cliente procura maximizar os lucros, de modo que uma grande complicação do sistema diminui de alguma forma essa mesma maximização, porque esse é o ciclo final de vida do processo do software.
Em projetos menores, esse processo é ainda pior - muitos clientes oferecem desenvolvimento móvel para o site remoto, embora o back-end e a Web sejam realizados por conta própria e recebam regularmente freios uniformes na implementação de recursos.
Por outro lado, há um obstáculo perigoso à automação formal do processo de implementação - é habitual entre os desenvolvedores perguntar ao usuário sobre atualizações sem interrupção; portanto, no modo silencioso, não funcionará para reverter as alterações sem o consentimento.
Minha ideia é essa - mantendo o principal tipo de ciclo de vida e tendo subtipos nesse caso de frentes independentes, é preciso ter em mente uma prioridade
tipo de frente (por dinheiro, razões históricas ou outras), mas elas devem ser uma unidade abaixo do tipo de ciclo de nível superior.
Ou seja, se a frente prioritária da web funcionar em um scrum semanal, o scrum interno na frente móvel deverá ter o primeiro scrum duplo, duas semanas, caso contrário
confusão começará. Mas a implantação de uma versão grande e comum das frentes deve ser feita ao mesmo tempo, caso contrário, você terá o autor do artigo que o escreve. Vamos pensar ...