Consultor em uma empresa que não entende a tecnologia! [fechadas]

Consegui o emprego como consultor em uma empresa que tem mais 3 programadores. Meu trabalho é reescrever todo o sistema antigo em Java, Spring etc., mas os programadores da equipe conhecem apenas perl e o gerente não conhece nenhuma programação.

Estou tentando fazer com que eles entendam que tenho 6 projetos para reescrever aqui, mas ninguém tem documentos ou especificações de design. os programadores da equipe nunca tiveram que escrever nenhum documento. Além disso, eu não consigo convencer o gerente a entender as novas coisas sobre tecnologia java. Ele continua pedindo a alguns dos funcionários pontos de vista sobre as coisas, mas a equipe não sabe ou entende.

Para onde vou daqui para que o gerente entenda que os programadores da equipe ou alguém precisam escrever um documento de design para que eu saiba o que construir. ou se eu tiver que escrever os documentos, como obtenho as informações?

Parece meio estranho que a equipe não conheça a plataforma na qual você foi solicitado a reescrever o trabalho deles. O que acontece depois que você sai? Quem apoiará o seu trabalho?

Portanto, você tem um sistema complexo que não possui documentação adequada e deve recriar o sistema em uma plataforma diferente. O que eu faria, na sua posição, é identificar a única pessoa que deve "assinar" o novo sistema. A partir daí, leia algumas histórias de usuário para identificar como dividir os requisitos em partes de tamanho de bits que podem ser descritas em inglês simples. Seu formato é algo como "Como USERROLE, no SISTEMA X, desejo REALIZAR AÇÃO para que o OBJETIVO seja atingido.

Para explicar melhor uma História do usuário, você adiciona 'critérios de sucesso' no formato "Fornecido quando CONDITION for OUTCOME" para explicar o que acontece com diferentes ações na História do usuário pai. Essa é uma maneira decente de dividir a funcionalidade em partes que podem ser entendidas individualmente, e você pode obter ajuda para escrever histórias diferentes de grupos diferentes (apenas verifique se a pessoa de nível superior que assina o trabalho permanece a mesma).

Portanto, reescreva todas as funcionalidades antigas do sistema como Histórias de Usuário e pergunte ao proprietário do projeto se há alguma funcionalidade NOVA que eles desejam na versão Java. Adicione histórias para satisfazer isso, se houver, e comece a codificar.

Basicamente, você precisa expor a inutilidade dos programadores da equipe. Faça com que o proprietário do projeto exija que eles forneçam os Critérios de Sucesso para algumas das Histórias, para que, se eles fornecerem informações ruins, você possa apenas manter isso como seus requisitos oficiais. Qualquer coisa que eles deixarem de fora será culpa deles, não sua.

Estive envolvido em um projeto em que todo o sistema foi gravado no Oracle Forms, mas sem nenhuma documentação. A tecnologia poderia facilmente ter sido Perl. Aqui está o plano de ataque para migrar o sistema para o Oracle ADF (mas também pode ser facilmente qualquer outra plataforma):

1. Crie um conjunto de categorias de código para requisitos de negócios (funcional, bugs, validação, interface do usuário, etc.).
2. Crie um conjunto de categorias para as telas (agrupe-as por funcionalidade semelhante).
3. Crie uma lista de todas as telas para todo o aplicativo e enumere-as em uma planilha.
4. Atribua a cada tela uma categoria de código e um tipo de código (por exemplo, regra comercial, requisito do sistema, técnico).
5. Faça engenharia reversa do código para extrair os requisitos de negócios, criando uma descrição de uma frase de cada requisito.

Neste ponto, você terá documentado as regras de negócios do aplicativo. Isso por si só será ouro para quem, em seguida, precisar manter o sistema. Além disso, você terá a chance de ver quais partes do sistema foram duplicadas. (No meu caso, descobrimos que mais de 60% da base de código foi duplicada.)

A partir daqui, você pode classificar os requisitos de negócios com o gerenciamento. Isso pode envolver a criação de histórias de usuário, por exemplo. Isso também revelará funcionalidade duplicada de alto nível e apresentará oportunidades para simplificar e aprimorar o sistema durante a migração. Incluí uma captura de tela da planilha para mostrar uma maneira de rastrear e documentar os requisitos.

Você pode precisar atualizar o seu Perl. ;-)

Depois de fazer a engenharia reversa do projeto, você pode empregar um conjunto de ferramentas para ajudá-lo no ciclo de vida de desenvolvimento de software. (Estamos usando o JIRA , mas existem muitos outros pacotes de software que funcionariam.) Talvez você precise lutar um pouco, mas depois de ter cumprido os requisitos, será necessário migrar para os seguintes ambientes:

• Crie um ambiente de documentação (por exemplo, um wiki).
• Crie um ambiente de desenvolvimento (DEV). Servidores da Web, servidores de banco de dados, repositório de origem, etc.
• Crie um ambiente de teste (TEST) que reflete o desenvolvimento.
• Crie um ambiente de pré-produção (PREPROD) que espelha exatamente a produção e possa atuar como um failover para o sistema de produção.
• Crie um ambiente de produção (PROD).

Pense em usar um serviço orientado à comunidade para atender aos requisitos da documentação do usuário final. Um excelente pacote de software semelhante ao pacote StackExchange é o OSQA . Permita que os usuários construam o sistema de ajuda (é uma estratégia bastante inteligente).

O SDLC se torna:

1. Os desenvolvedores fazem e testam alterações de aplicativos no DEV (usando um repositório ).
2. As ferramentas do sistema implantam automaticamente compilações regulares no TEST.
3. Depois que os testadores estiverem satisfeitos com o aplicativo, ele será implantado no PREPROD. Isso permite que o processo de implantação também seja testado. Mais testes acontecem no PREPROD.
4. Quando os testadores estão satisfeitos com o PREPROD, o aplicativo é finalmente inserido no PROD.

Acho que essa é uma abordagem altamente organizada que funciona bem com diferentes metodologias de desenvolvimento. A primeira passagem, que descrevi aqui, deve ser considerada uma "pincelada ampla" - você não quer ficar muito detalhado (atolado) com minúcias técnicas neste momento. (Os requisitos da interface do usuário, por exemplo, são capturados por cada tela. Contanto que você tenha as telas enumeradas, não é necessário iterar cada campo de entrada - basta vincular a uma captura de tela ou URL de trabalho.)

Por fim, para revisar o código fonte, geramos automaticamente uma série de páginas da web (uma página por "tela" funcional). Isso funcionou bem porque o código PL / SQL pode ser dividido em arquivos separados e convertido automaticamente em HTML com destaque de sintaxe. Com o Perl, isso pode não funcionar tão bem para você. A idéia, porém, é que você pode criar links de âncora na planilha que apontam para a seção de código que impõe os requisitos de negócios. (Além disso, isso também permitiria a vários desenvolvedores fazer engenharia reversa dos requisitos do sistema em paralelo, porque cada desenvolvedor pode enfrentar telas diferentes simultaneamente.)

Um exemplo de trecho de código-fonte (o + é um link de âncora):

Você pode recomendar a contratação de alguns gurus do Perl para ajudar na tarefa de análise.

Não acho muito produtivo apontar que outras pessoas estão fazendo "trabalho de baixa qualidade"; em vez disso, você deve procurar melhorar o produto e dar às pessoas a oportunidade de ajudar com esse objetivo (e talvez aprender como melhorar suas habilidades no processo). Ou seja, você não sabe o que os outros desenvolvedores sabem, nem estava lá quando eles desenvolveram o sistema. Essa abordagem torna todo o processo aberto e altamente visível, pelo qual todos podem contribuir.

Honestamente, os gerentes verão por si mesmos quem é realmente útil e quem quer melhorar.

Eles não têm documentação e seu código é tão ruim que contrataram alguém para reescrevê-lo em outro idioma. Comece a reunir requisitos da fonte. Você encontrará muitos recursos e funcionalidades que não são mais usados ​​ou podem não funcionar corretamente. É igualmente importante saber o que não construir.

Depois de encontrar o que os usuários precisam, determine o que já está no aplicativo atual e o que deve ser construído a partir do zero. As peças existentes são onde você pode ver o código e conversar com os desenvolvedores.

Quem proclama que precisa de tudo nunca se preocupou em verificar. Há um argumento para nunca reescrever um aplicativo, mas isso pressupõe que tudo funcione da maneira que os usuários desejam e que nem sempre é verdade. Eles usam porque não há alternativa. Dê a eles uma alternativa melhor.

Começaria conversando com seu gerente e aceitando a responsabilidade de coletar os requisitos e definir as especificações. Você precisará convencê-lo da necessidade desses documentos e do que eles fornecerão. Eu provavelmente encontraria um exemplo online. Depois, você se encarrega de montar os requisitos e as especificações do sistema. Em seguida, encontre seu gerente novamente para revisar o documento. Depois de ter mostrado a eles o primeiro documento, você poderá obter ajuda na criação do outro 5. Caso contrário, se for eficaz, você provavelmente será responsável por reunir esses requisitos também, mas pelo menos alguém o fará.