Sou um grande fã de listas de verificação. Há uma lista de verificação de viagem , lista de verificação móvel e até uma lista de verificação do Scrum .
Contexto : você foi contratado por uma grande corporação e recebeu a missão de configurar todo o ambiente de desenvolvimento de software, processos, equipe etc. Você tem "carte blanche". Você será responsável pela criação dos incrementos de trabalho do software. Tamanho do projeto: 2000 homens / dias.
Quais itens você adicionaria à seguinte lista de verificação (intencionalmente pequena e incompleta):
- Instale um servidor de integração contínua
- Escreva um DoD
- Escreva as diretrizes de codificação de uma página
- Criar uma lista de pendências de produtos
- Instale um sistema de rastreamento de erros
- Programar Horário de Face Regular
project-management
development-process
Thomas Owens
fonte
fonte
fonte
Revisões post-mortem - Como você está trabalhando em blocos, eu agendaria uma revisão de uma a duas horas (dependendo do tamanho da equipe) para ter uma reunião cara a cara (se possível), onde todo mundo sai e diz o que foi feito corretamente, o que poderia ser feito melhor e o que não era necessário. Ser capaz de aprender com seus erros no processo de desenvolvimento antecipadamente significa que você pode evitar cometê-los mais tarde, quando não tiver muito tempo para trabalhar.
fonte
Vamos começar contratando uma boa equipe dos profissionais certos para o seu projeto. Em um aplicativo comercial típico, você precisa contratar um desenvolvedor de banco de dados e um dba, um responsável pelo controle de qualidade, um administrador de sistemas, analistas de negócios, desenvolvedores de aplicativos, um especialista em interface do usuário e líderes de equipe no mínimo. DBA, administrador do sistema, analistas de negócios e controle de qualidade devem estar em uma cadeia de relatórios separada da equipe de desenvolvimento. O especialista em banco de dados de desenvolvimento deve reportar-se ao mesmo líder técnico que os desenvolvedores de aplicativos e o especialista em UI.
Configure o espaço do escritório. Os escritórios particulares são ótimos se você puder obtê-los (desejo-lhe muita sorte com isso), mas no mínimo você precisa de mesas, telefones, computadores, quadros brancos e duas salas de conferência dedicadas. Verifique se há um local para almoços, uma geladeira, refrigerantes, lanches e café disponíveis. Refrigerantes e café gratuitos ainda melhores.
Configure os servidores dev / qa / staging e prod para o aplicativo e os bancos de dados. Os bancos de dados nunca devem estar no mesmo servidor que os aplicativos. Dependendo do tamanho e do escopo do projeto, você pode precisar de vários servidores ou SANs, etc, para cada ambiente.
Assim que os servidores forem configurados, agende backups do sistema de arquivos, do banco de dados e dos logs de transações do banco de dados. Faça isso no primeiro dia em que tudo estiver configurado. Contrate uma empresa como a Iron Mountain para fazer backups fora do local semanalmente.
Configure um sistema de controle de origem e crie um documento descrevendo como será usado. Não se esqueça de insistir para que TODAS as alterações estruturais do banco de dados e as inserções de dados para tabelas do tipo de pesquisa estejam em scripts no controle de origem. Isso facilitará a implantação.
Compre software comercial ou faça o download de software de código aberto para o conjunto de ferramentas que você decidiu usar com licenças para todos os usuários pertinentes.
Compre máquinas para desenvolvedores que estão gritando rápido e têm dois monitores. Compre pelo menos uma máquina de usuário de teste que geme lentamente e é típica do que os usuários terão em seus desktops.
Treine seus novos desenvolvedores em como você deseja que as coisas sejam feitas. Se você tem uma equipe grande o suficiente para ter alguns desenvolvedores juniores, programe treinamento extra para eles e inclua o tempo no planejamento do projeto. Monitore os juniores de muito perto por pelo menos três meses. Monitore de perto todos os novos funcionários durante o primeiro mês. Livre-se dos desenvolvedores de madeira morta e desonestos o mais rápido possível.
Determine o que precisa ser feito em que ordem (o caminho crítico). Não atribua tarefas no final do caminho crítico até que as tarefas das quais dependem estejam concluídas.
Crie planos e requisitos de teste.
Organize regularmente reuniões de progresso agendadas com os clientes. Eles merecem saber o que você está fazendo e quais são os obstáculos. Não deixe de dizer quando as coisas vão se atrasar. Se você estiver a três semanas de um prazo e já sabe que vai perdê-lo, esse déficit não desaparecerá magicamente antes que você precise informar o cliente. Certifique-se de que o cliente saiba que requisitos adicionais significam custos e tempo adicionais e que todos os requisitos adicionados terão que ter outras tarefas descartadas ou o prazo mudará de acordo com a quantidade de horas nas novas tarefas. Deixar isso claro desde o início economizará muita dor e horas extras e excederá os custos absorvidos pelo seu grupo e não pelo cliente.
Configure um ambiente para teste de desempenho, não apenas a velocidade de um usuário, mas onde você possa testar o número esperado de usuários simultâneos. Não espere para fazer esse teste até o dia anterior ao lançamento.
No planejamento do projeto, suponha que o controle de qualidade encontre bugs e que eles levem tempo para serem corrigidos. Não programe o controle de qualidade por apenas um dia no final.
Crie dados de teste aproximadamente do tamanho que você acha que o banco de dados terá. Faça com que todos os desenvolvedores testem seu código no banco de dados desse tamanho. Não permita que os desenvolvedores desenvolvam apenas um pequeno banco de dados em suas máquinas pessoais. Essa é uma causa frequente de código que funciona bem até atingir a produção.
Planeje recompensas no orçamento. Desmotiva as pessoas quando trabalham duro por meses e apenas os gerentes recebem bônus. Diga também obrigado com frequência e por escrito.
Pode ser necessário um sistema de gerenciamento de projetos ou, pelo menos, configurar planilhas para rastrear o que você precisa rastrear. Ao fazer o planejamento do projeto, assuma no máximo seis horas por dia em seu plano. Isso ajuda a contabilizar o tempo que não será gasto no projeto, como férias, ausência por doença, feriados, reuniões de RH, análises de desempenho etc. Se você souber que o projeto está em um período de alta indisponibilidade (por exemplo, um projeto que é executado de 1 de novembro a 1 de janeiro nos EUA), pode ser necessário conceder subsídios extras para mais férias e férias. Não é justo esperar que os desenvolvedores desistam de suas férias e ninguém pode prever quando coisas como tempo de doença, dever do júri, tempo de luto etc. acontecerão. Suponha que eles acontecerão com sua equipe neste projeto.
fonte
Algumas coisas que não vejo na pergunta e nas respostas subseqüentes:
Plano de recuperação de desastres. Como você está fazendo backup das caixas de desenvolvimento, teste, teste etc.? Todo desenvolvedor tem o que precisa para trabalhar em casa em um dia ocasional de neve? Etc.
Plano de treinamento. Quantas semanas do ano de treinamento seus desenvolvedores precisam manter a nitidez? Alguém está rastreando? (Uma planilha pode ser suficiente para a maioria das equipes.) Tenha um mecanismo para que eles relatem (enviando a alguém um e-mail dizendo que assistiram 2 horas de webcasts sobre "o que quer que seja" provavelmente seja o suficiente)) e que a gerência planeje - por exemplo, quem devemos enviar para o que conferência este ano.
a Posição da ferramenta. É este o tipo de local "oferecemos a todos uma assinatura do MSDN; não instale mais nada em suas máquinas de trabalho" ou um "queremos o seu código, mas não nos importamos com o que você usa para editar, compilar e testá-lo" "tipo de lugar. Tome e registre a decisão.
o ALM integrado que você puder suportar ou pagar. Geralmente, a razão para a "incompatibilidade de impedância", entrada dupla, sobreposição de ferramentas e integração de aplicativos de cadeira giratória é que o sistema cresceu em pedaços. Começando do zero, você quer mostrar que seu pessoal pode permanecer em uma única ferramenta durante todo o ciclo. Não digitando código em X, compilando com Y, testando com Z, alterando o status do item / tarefa de trabalho com A, relatando seu tempo gasto com B, informando à pessoa que estava esperando que agora pode prosseguir com C, tentando descobrir o que fazer em seguida com D, ajudando o progresso geral com E etc.
fonte
Negocie mais dias de trabalho.
É um evento raro quando as pessoas alocam o suficiente inicialmente.
[Mais tarde ... renegocie ainda mais ...]
fonte
Vendo que eu tive o maior problema com bibliotecas de terceiros e seu uso:
Por quê? Não sei dizer o número de vezes que as bibliotecas de terceiros (proprietárias) tiveram bugs heniosos que nos enviaram semanas de tempo de desenvolvimento, porque não tínhamos processo para subir ou descer. Ou lidando com desenvolvedores dizendo "qual versão você usou? Por que você usou funções marcadas como obsoletas?"
fonte
Um grande custo para as organizações não é atribuir orçamento à segurança durante todo o ciclo de vida do desenvolvimento, isso significa que a segurança geralmente acaba ocorrendo após o fato de um conjunto de atividades ou controles ineficazes e dispendiosos, implementado tarde demais para fazer muito bem.
Obtenha a segurança integrada no plano inicial do projeto, com os principais marcos, da mesma forma que faria com todos os outros aspectos do desenvolvimento, e use um processo iterativo para manter as orientações de segurança atualizadas. A aprovação final da segurança deve ser uma verificação sem surpresas, de que todos os controles de segurança foram implementados conforme o projeto.
Caso contrário, você acabará executando a segurança após a implementação - onde pode custar de 8 a 10 vezes mais (números do Gartner, IBM e outros), incomodará as pessoas, pois a funcionalidade provavelmente será afetada e pode ser tarde demais para impedir a exploração e danos.
fonte
1. Leve para a equipe
Pergunte aos programadores! Realmente, isso é a coisa mais importante. Você encontrará muita resistência se os desenvolvedores não estiverem diretamente envolvidos nessa mudança. Afinal, é sobre como eles funcionam, não você. Escusado será dizer, mas tentar forçar métodos e ferramentas nas pessoas geralmente sai pela culatra horrível.
2. Inspecione e adapte
Faça com que a equipe descubra a melhor maneira de trabalhar, usando sua experiência para ajudá-los a entrar na trilha escolhida. Depois, regularmente e de forma colaborativa, analise como você está (eles) e adapte o processo para torná-lo melhor.
fonte