A Rússia é irracional. Existem práticas corretas, existem centenas de vezes que um rake é sentido, mas ainda assim, algo épico acontece com constância invejável. Às vezes, pelo motivo: "Bem, certamente vai me surpreender", às vezes: "Sempre funcionou e funcionou", às vezes apenas por causa de erros. Talvez nos genes.
O primeiro exemplo vívido de jogo incrível (os detalhes são ligeiramente alterados a pedido dos guardas de segurança). O cliente está envolvido na construção de capital. Eu pedi um sistema há vários anos a um contratado que gerencia tudo isso (em particular, trabalho estimado). O sistema foi instalado em uma dúzia de objetos bastante grandes e foi introduzido. De repente, o cliente decidiu pedir que ele desse o código fonte. Como se viu, o contratado existente tinha planos para desenvolver o software e depois vender o resultado como SaaS no mercado. O contrato não diz nada sobre o código. Nós brigamos.
Quando eles nos chamaram para entender, havia cerca de 10 versões diferentes de software (versões de 0,9 a 2,4). Existem 1,5 fontes, esta versão foi coletada uma vez delas. Nenhuma documentação. E o sistema precisa ser desenvolvido e desenvolvido. Eles contaram "reescrever tudo de novo" e "finalizar 1,5" e se estabeleceram no segundo - TtM, de três a quatro meses contra o ano. Eles nos ensinaram como coletar especialistas em suporte, corrigir as fontes, reduzir as bases de código, criar a infraestrutura, organizar uma "transmissão", onde a fonte é recebida, coletada e distribuída por lá. Custou a nós e ao cliente muitas hemorróidas.
Entre, mostrarei algo mais sobre como você pode cometer um erro no processo de desenvolvimento e quais consequências interessantes isso leva a.
Outro exemplo
O cliente - também uma empresa bastante grande - lança lançamentos de ERP. E a piada é que o sistema é tão saudável que não há lugar para testá-lo em uma base completa ou algo semelhante. Simplesmente não há infraestrutura. Mais precisamente, existe, mas é impossível fazer um teste de carga, apenas pequenas coisas locais são verificadas. O lançamento aumenta - e ninguém sabe como ele se comportará na prática. Uma vez, tudo caiu visivelmente, quando o lançamento não se comportou como queria. No final, eles nos convidaram a assistir o que pode ser feito. Discutimos que eles querem ver o HP Performance Center, fazer um piloto, depois integrar, treinar e entregar. Agora libera através dele. Essas operações normalizadas são testadas, um resumo do SLA das operações.
Ou, o cliente do estado chegou para importar a substituição. Os negócios chegam até nós e afirmam: nossos especialistas em TI nos disseram que é muito difícil substituir a base do Oracle pelo Postgress. Nós não acreditamos neles, consulte. Duas semanas de processo - e o resultado: “Bem, sim, mudar a base é fácil. Só então você deve reescrever todo o nível do aplicativo. Um pouco. Aproximadamente 90%. Você tem pacotes enormes, precisa transferir a camada da lógica de negócios - e vem. Os desenvolvedores que criaram o kernel não podem mais ser encontrados, porque o sistema tem oito anos ". Eles acreditavam na equipe de TI. Descobriu-se que eles simplesmente discutiram insuficientemente claramente.
Nós olhamos para algum lugar seguro,
aqui está um exemplo épico . Felizmente, este ainda é simples, simplesmente ninguém faz nada há cinco anos, e o negócio não é de escala federal.
O exemplo a seguir. Colocamos a mesma história com a aceitação de lançamentos. Situação ideal: um contratado terceirizado grava o código, passa para teste, passa nos testes, coloca tudo no repositório e, a partir daí, é montado e distribuído. É lindo? Nice. Vivemos dentro de nossa empresa há três anos, sem exceção (antes disso, não havia todos os departamentos e equipes). Mas o cliente possui um "fundo de algoritmos e programas". Lá, cada artista envia um espaço em branco ou uma lista do código fonte. Eles arderam lá. Como se viu durante a auditoria, o anime foi gravado em um disco em geral. E mesmo que exista um código de fato no fundo, não faz sentido.
Outro cliente semelhante. Eles têm uma dor típica - muitos contratados. Eles fizeram um integrador intra-setorial, verificaram se o contratado traz o software correto. Houve problemas no sentido de existirem direitos de terceiros (bibliotecas de código aberto com licenças virais abertas, por exemplo) - contratados inescrupulosos podem fornecer tudo isso sem o licenciamento em ordem. No caso de código aberto, você ainda pode lidar com o problema, mas às vezes as bibliotecas comerciais se deparam. Culpado de quem será - adivinhe três vezes. Então um de seus contratados faliu e o cliente viveu com esse código. Tais situações devem ser detectadas em um estágio inicial. Ajudamos a configurar o processo corretamente. Temos uma solução como a automação de um fundo de algoritmos e programas. Documentação técnica, versões, códigos-fonte, contratos e todos os links para concursos. Com uma vida média de CIO de dois a três anos, realmente ajuda o próximo a descobrir imediatamente.
Também estamos introduzindo o ágil na Rússia. Eu não ri do circo agora. Quase toda vez que começa como uma história da moda na digitalização de negócios. O principal é que todo mundo está tentando entender quais são essas palavras. Mas ninguém entende. Conceitos ordenam, contratam pessoas estranhas. Eles dizem as palavras “parece”, “hipótese”, startups são convidadas, a aceleração é turva, os smoothies estão bêbados - em geral, tudo isso tem os sinais externos de algum tipo de vale. Em seguida, o Agile começa a aplicar, mas não decola. Se você criar um sistema sério, precisará verificar por um longo tempo. Se você não colocar os processos, os sprints serão longos (um mês ou dois). Se você definir os processos, precisará começar com a infraestrutura de teste, devops, fazer o pipeline de entrega, os processos de trabalho entre equipes e dentro de equipes. E tudo isso geralmente é esquecido. Se os processos dos Velhos Crentes são 98%, o projeto não será realizado. No final, então corremos. Em geral, não reclamamos: pão também. Mas, às vezes, só quero explicar de alguma forma, ou o que, que a TI é primeiro uma infraestrutura e, depois, um TtM rápido. E não o contrário.
O que geralmente dá errado? Conjunto de exemplos
Meus colegas e eu reunimos aqui um conjunto de problemas pendentes que não são muito objetivos, mas descrevem muito bem a situação. Obviamente, só vamos a lugares onde é ruim e não é necessário extrapolá-lo para o estado da indústria. Mas, ainda assim, tenho certeza que você aprenderá algo com sua empresa. Uma pequena parte. Em geral, tudo é descrito pelas palavras: "ineficiência do processo, funcionários desmotivados, ferramentas ruins ou ferramentas pouco usadas". Bem, agora - exemplos.
1. Penalidade por erros no software contribuído por desenvolvedores.Eu nem sei como descrevê-lo racionalmente. Apenas uma multa por bugs identificados. Viva agora com esse conhecimento. Naturalmente, qualquer versão (mesmo pequena) é lançada dez vezes mais devagar do que poderia.
2. Reuniões da manhã à noite.O desenvolvedor deve comparecer a eles. Ele fica calado e acena com a cabeça no telefone. Essas são as mesmas reuniões quando toda a equipe do projeto é necessária na reunião, além do chefe do departamento para controlar. É impossível não vir. Mas quase não faz sentido participar. Esse é o erro tradicional do gerente de projetos, chamado "controle excessivo".
3. Culto à carga. Adotamos metodologias flexíveis e as implementamos rigidamente.O melhor que eu já vi: implementado de forma ágil, mas funcionou como antes. Eles apenas fizeram os desenvolvedores chegarem ao stand-up diário. Eles são construídos e dizem: eu não fiz nada. Isso acontece todos os dias.
4. Ferramentas: implementamos para relatar que implementamos."Temos um servidor de integração contínua e apenas um administrador pode adicionar uma tarefa." "Implementamos um repositório de montagem binária e há um disco muito pequeno, é necessário excluir os antigos e existem apenas as últimas três versões". Ou aqui: um sistema de gerenciamento de tarefas em um ex-arquivo em um disco compartilhado. Portanto, a lista de pendências costuma levar até mesmo em grandes empresas, apesar do fato de existir a Jira. Nesse caso, até que a tarefa caia nesse arquivo, ninguém fará isso. Ele é oficial.
Outra empresa possui uma base de conhecimento interna, mas tudo é armazenado diretamente no sistema de controle de versão: é mais conveniente para o gerente. As distribuições do sistema operacional são adicionadas até lá. Quando não há uma pessoa responsável pelo sistema de controle de versão, os gerentes podem colocar arquivos de gigabyte para transferi-los para a contraparte, porque no Dropbox o local acabou.
5. Padrões de codificação: escritos sem entendimento ou não atualizados por 10 anos.Apenas alguns exemplos: exigimos 100% de cobertura do código com testes e documentação. Em particular, todas as bibliotecas de terceiros. A desvantagem é a falta de testes padrão. Recentemente, vi como um engenheiro implantou o sistema e o usuário não pode fazer o login, porque a chave do teste para o produto não foi alterada.
Mais uma vez, vi como o líder escreveu o código no Notepad.exe e o jogou no compilador sem erros. Ele ainda estava estudando com cartões perfurados. Tal habilidade certamente merece respeito. Mas somente até que essa deformação profissional comece a influenciar os padrões para o restante do departamento de desenvolvimento.
6. Erros de regulamentos.Por exemplo, um horário fixo de almoço, que é totalmente percorrido. Este é um sintoma. Eu pergunto o porquê. Eles explicam: se você está sentado no local de trabalho no almoço, então você é o alvo. Deve responder às cartas em cinco minutos e assim por diante.
Burocratização excessiva: geralmente seguindo procedimentos documentados que levam a uma pilha de papel. Os mesmos planos de teste para todos os espirros. E esta é uma descrição de cada filtro, incluindo tipos de dados em cada campo da interface, comprimento do campo e assim por diante. Isso geralmente é resolvido por exemplos, e não por detalhes completos.
Em uma empresa, não havia ninguém responsável pelo lançamento atual; às vezes, os prazos para o lançamento de produtos por duas semanas eram quebrados.
Comunicações: algo vem do cliente pelo correio. Além disso, ele escreve para quem falou com ele pela última vez. Mesmo se você quiser fazer isso, os comentários sobre a tarefa podem estar em lugares diferentes, incluindo mensageiros instantâneos. Então alguém saiu, alguém veio, alguém excluiu o e-mail - isso é tudo.
7. Luta contra os guardas de segurança.Isso inclui atualizações manuais de todos os sistemas (e você precisa derramar automaticamente, isso economiza muito tempo), soluções físicas com uma unidade flash nos nós da rede, alocação de porta por três semanas e assim por diante.
8. A comunicação entre desenvolvedores e analistas não é estabelecida.Esse é um batente que se repete a cada quinto projeto. Só que o analista escreveu o que é necessário, o desenvolvedor o desenvolveu e um mês depois mostrou-o pronto. O analista corre horrorizado porque não quis dizer isso. Por três semanas este mês, o desenvolvedor trabalhou em vão, embora ele pudesse mostrar parte do projeto e o analista pudesse perguntar como as coisas estão indo. Existem metodologias que simplesmente encerram isso, mas o problema é que, nessa situação, ambas as partes não entendem por que o projeto é necessário e como vai.
9. Desenvolvimento Orientado a Conferências.O líder viu algo legal na conferência e o apresentou sem deixar rastro. Três meses depois repetido. Como resultado, o relatório é bonito, mas o trabalho vale a pena.
Devido a conferências internas, ainda é possível obter o resultado de acordo com o esquema “Sempre 80% pronto”. Em relatórios públicos - "Quase pronto", e é interminável. Trazer para 100% nunca acontece. Porque Bem, por exemplo, veja o ponto 1.
Separadamente, observo o subexame de sistemas de terceiros. Você leu o artigo - uau, legal, vamos usá-lo e depois aprender como. E você encontra muitas restrições, porque o vendedor só derramava mel nos ouvidos nas duas primeiras reuniões. Nós mesmos pisamos em um ancinho. Houve uma implementação interna de um sistema para lojas on-line de documentação sobre o design de infra-estruturas, incl. Data centers para objetos muito interessantes. Foi descoberto um caso de limitação do custo de mercadorias de 100 milhões. O truque é que, na área de assunto, o preço unitário do documento é mais alto. E aí, o sistema teve que escavar o índice para pesquisar e temos investimentos de 1 gigabyte nos documentos. E o tempo de indexação esperado é de um mês. O fornecedor não alertou sobre isso.
10. Assustador para fazer alterações.Existe um estado desse projeto: você precisa refatorar, volte em um mês. Mas não há testes, documentos, nada. E os desenvolvedores estão sentados: "Temos medo de fazer mudanças, temos medo de quebrar tudo".
Também vi como uma empresa desenvolveu a integração com um sistema que não pode ser implantado no lado do desenvolvedor, porque é muito difícil. Os testadores testam a transferência de dados pelo serviço (na medida do possível). Saia para os estandes do cliente antes da entrega - e mais duas semanas de melhorias, porque o modelo de transação estava errado. É uma boa prática criar um esboço para este sistema que retorne algum tipo de resposta. Como resultado, eles fizeram isso, ficou mais fácil testar e aceitar.
Outro cliente pode escrever descrições econômicas em seu idioma usual. Nesse projeto, demos algum tipo de construtor de pseudo-linguagem (um conjunto de padrões), que é então convertido em dados do analista. No espírito de "Se Vanya estiver de licença médica, ele não poderá ir à produção".
E o acorde final. Outra pessoa em uma empresa está codificando diretamente no produto. "Há um pequeno violino, eu sei o que estou fazendo." Obrigado, querido, mas se eu te encontrar, nem sei o que fazer com você.
Em geral, falou. Se você descobrir seus problemas, escreva para oeremeev@croc.ru. Para grandes empresas, temos pilotos quase gratuitos com diagnóstico expresso (pesquisas por gargalos em 3 a 5 dias). Se alguém da sua empresa precisar ser explicado que é impossível suportar dívidas técnicas, - escreva também, podemos contar isso normalmente.