Meu último artigo Os
segredos do design bem-sucedido do IP (sistema de informação) no exemplo da construção do hospital causaram às vezes uma discussão acalorada nos comentários. Portanto, decidi declarar várias teses com base nessa discussão.
Design não é para programadores
Muitas vezes, ao discutir os métodos de design e implementação de um projeto de sistemas de informação, você ouve críticas desses métodos por desenvolvedores (programadores).
Às vezes, os desenvolvedores simplesmente não veem que, além de escrever código, um projeto possui um componente organizacional sério, que é identificar, formular e concordar com os requisitos - a tarefa mais difícil é educar os usuários e reconstruir todos os processos - e não apenas um dia.
Caros programadores, para descobrir o que um sistema deve fazer, você precisa conhecer não C # ou JAVA, mas possuir uma área de assunto. Para projetar um sistema de logística, você deve ser um logístico: ter experiência neste campo ou em vários campos semelhantes e relacionados. Portanto, existem analistas de negócios cuja tarefa é determinar a aparência funcional do sistema.
Na melhor das hipóteses, o cliente fornecerá de 30 a 50% das informações necessárias, o restante deve ser pensado de forma independente. E pensar é extremamente crítico. A princípio, o cliente não sabe o que quer! Como regra, ocorre um desenvolvimento conjunto de um modelo de negócios e somente então uma lista de funções é compilada.
Isso requer conhecimento da área de assunto. Precisamos entender o cliente em resumo: ele ainda conta a idéia, e você já sabe por que ele precisa e, o mais importante, como é organizada, como essa empresa deve funcionar e não apenas software.
Notas ágeis
Agile é uma nova religião?
Tópico de discussão Agile vs. A tecnologia de design (cascata, cachoeira, cachoeira) é mais como uma disputa entre fanáticos religiosos! O artigo não era sobre Agile, mas todos os comentários eram sobre "flexíveis". Gente! Bem, é realmente impossível parecer mais amplo e ver que, para ambos os métodos, há um lugar sob o sol ?!
Na minha opinião, a forte rejeição do Agile é uma reação ao impulso extremamente agressivo dessa tecnologia. Ouvindo os “pregadores” das tecnologias flexíveis, parece que antes do Agile o mundo não existir, não havia muitos anos de experiência em desenvolvimento de software e, em geral, todos os que trabalhavam antes de nós eram tolos e terríveis pecadores, já que o Agile não era iluminado. Ingênuo! Essa visão de mundo é típica para adolescentes, mas nós ...
Vamos diminuir o grau e tentar avaliar sobriamente as diferentes abordagens para cada projeto.
O Agile não é adequado em qualquer lugar, assim como a tecnologia de design
Como um comentarista escreveu,
“Agile não é para TI, e não sobre TI. Ágil para negócios e profissionais .
” De fato, às vezes você precisa obter um resultado muito rápido, entrar no mercado com pelo menos algo para investir em um lugar e encontrar investidores. Ou há o desenvolvimento de novas tecnologias, cujos requisitos são difíceis de serem feitos. Esse é definitivamente um nicho ágil.
Por outro lado, onde você encontra clientes suficientes dispostos a trabalhar em tecnologias flexíveis? 70-80% dos pedidos no mercado são agências governamentais que usam tecnologia de design padrão. Além disso, de acordo com GOST 34. E eles pagam bem por isso.
Além disso, esses métodos podem ser combinados em um desenvolvimento: o núcleo é criado usando a tecnologia de design e algumas partes são criadas por tentativa e erro (Agile). Bem, nem tudo é possível pensar com antecedência. Além disso, há flexibilidade na tecnologia de design: existe uma operação experimental, durante a qual muita coisa pode mudar.
Ágil é como os desenvolvedores pensam
Não posso garantir para todos, mas parece que os programadores pensam "de maneira flexível", o Agile atende à estrutura de seus pensamentos! Afinal, a programação é uma busca constante pelas melhores soluções. Você se senta na tarefa, ainda não sabe como deve ser resolvido. Você não pode prever com antecedência nem o resultado nem os prazos (sim, você multiplica os prazos dos desenvolvedores por 6 a 10 vezes e é a única maneira de obter uma imagem real, porque eles se esqueceram de testes e melhorias). Este é o pensamento de muitos programadores, porque são indivíduos criativos. Portanto, você não precisa forçar indivíduos criativos a se envolverem no tédio do projeto. Para fazer isso, existem analistas, gerentes de projeto.
Percebemos que o Agile é a essência dos desenvolvedores pensantes. Mas o cliente pensa o contrário! E o cliente quer entender o que ele paga, "tocar" o resultado futuro, antes do início do desenvolvimento. E então o jogo começa com um objetivo: é conveniente para os desenvolvedores e o cliente não dorme à noite, pense se vai dar certo ou não, e se dá certo, o que acontece quando dá certo e quanto vai custar. Mas para o programador da Laf, eu trabalho com calma, o que farei, depois farei quando terminar, depois terminarei o que pedir, eles pagarão muito. Não é?
Mas às vezes o cliente deve dizer o seguinte: fazemos coisas novas, portanto não estamos prontos para prever o tempo, o custo ou o resultado. Você concorda? Então nós fazemos. Isso é pelo menos honesto.
Sempre vire sua cabeça
O desenvolvimento de software difere de outras áreas em que você aprende algo o tempo todo. Cada projeto é como um novo mundo. Cada projeto tem seus próprios requisitos. Portanto, a cabeça deve sempre ser mantida ligada. Não fique preso a apenas uma técnica, uma abordagem. Eu tenho que improvisar, quase sempre.
Para criticar algo, você precisa estudá-lo.
Ao criticar a tecnologia de design ou o Agile, os críticos raramente conhecem o assunto de sua indignação. Poucos são os que realmente estudaram (incluindo padrões: GOST, ISO, IEEE) e tentaram aplicar seriamente a tecnologia de design. Mas seus críticos são suficientes. Pouquíssimas equipes são realmente bem-sucedidas (para que o cliente fique satisfeito!) Aplique o Agile, mas há “pregadores” suficientes.
E, novamente, não confunda Agile e caos. Se você não sabe como projetar e, portanto, escolhe métodos flexíveis, terá uma bagunça.
Os aplicativos Agile de sucesso podem exigir ainda mais esforço do que a tecnologia de design. Maior coerência da equipe, qualificações de seus membros, capacidade de encontrar uma linguagem comum com o cliente.
Leia outros artigos do autor: