Planejamento de software (Keep It Simple Stupid)
by Luiz Paulo | dezembro 3, 2008 | 14 Comments »Essa semana eu e parte de nossa equipe, passamos por uma situação complicada. Estamos desenvolvendo um projeto relativamente grande que precisa ser entregue até final do ano. Até aí nada de errado!
Esse projeto já está rolando há algum tempo e passou por todos os processos de desenvolvimento (ou quase todos).
Quando chegou a nossas mãos (desenvolvimento), encontramos uma documentação com várias e várias funcionalidades, só que uma delas nos chamou a atenção, pois estava bem complexa. Com definição de regras e sub-regras para chegar a um determinado objetivo. Até que um dia, tive uma dúvida e resolvi perguntar para o cliente, conversamos bastante até chegarmos a um consenso. Depois de 4 horas de reunião, percebemos que essa funcionalidade não precisava mais do que um cadastro "besta".
Me senti exatamente nessa situação:
Depois de tanto trabalho, a funcionalidade pronta, etc. etc. tivemos que refazer (ainda bem que conseguimos recuperar boa parte do código)!
Com esse quadro, fica a questão. Quem errou?
Seria o cliente por não ter conseguido explicar exatamente o que precisava? Do pessoal que planejou/documentou que não soube dar a melhor solução? Ou do desenvolvimento que não gritou antes a respeito da complexidade?
Na minha opinião, o problema não está ligado diretamente a nenhuma das partes. Todos direta ou indiretamente erraram.
Depois de todo esse tempo de desenvolvimento, houve um amadurecimento da idéia, e com isso as coisas se tornaram muito mais simples.
Sim! Com certeza, se lá atrás quando foi planejado, tivessem ficado 5 minutos a mais discutindo, talvez chegassem a esse resultado mais simples, mas não aconteceu. E deu no que deu.
Existe toda aquela discussão de métodos ágeis ("...se estivesse utilizando Scrum isso não acontecia!"), zilhões de técnicas para processos melhores e menos burocráticos. Concordo que talvez não tivéssemos esse problema, independentemente de métodos e processos, precisamos levar em consideração o que comentei acima, nesse tempo houve um amadurecimento da idéia e os clientes perceberam que aquilo definido não era necessário.
Esquecemos do KISS "Keep It Simple Stupid", princípio básico para desenvolvimento.
Enfim, aprendi muito com isso! Acho que todos crescem com esse tipo de situação. Com certeza depois disso, na próxima teremos mais cautela ao definir uma coisa muito complexa, ou não... (rsrsrs)
Posts Relacionados
Categorias: Artigo, Desenvolvimento web
Tags: , desenvolvimento, kiss, planejamento, projeto, scrum
14 Comentários
Hoje em dia é chic complicar.
Fala-se muito em métodos e metodologias, mas cada um deles só acrescenta mais complexidade ao projeto.
Metodos ágeis? Scrum? XP? Get in Real? Besteira! Tudo isso não passa de «meios» para se atingir um «meio». Se você se encontra no ponto A e quer chegar ao ponto B, o ideal é procurar o menor caminho entre A e B, não acrescentar voltas (leia-se: métodologias) e mais voltas.
KISS é apenas uma sigla bonita – ou nem tanto, stupid – para dizer isso: siga o caminho de menor resistência, faça da forma mais simples para agregar o mínimo de problemas.
Quer saber qual foi o erro? Falha de comunicação, não erro de um ou de outro, ou ausência de uma metodologia complicada e pomposa.
[]'s
Cacilhas, La Batalema
Pode não ter muito a ver, mas lembrei de outra sigla interessante, que representa a filosofia da linguagem Lua, compatível com KISS:
SIMPLE: simple, light-weight and extensible.
[]'s
Cacilhas, La Batalema
@Cacilhas
Concordo que a falta de comunicação atrapalha (ou não ajuda) no desenvolvimento. Mas não concordo com que metodologia é "besteira". Até hoje só tive oportunidade de testar XP e gostei muito. Eu acredito que metodologias bem aplicadas organizam e simplificam as coisas.
Não vejo KISS apenas como uma sigla, mas como um uma filosofia. Tudo no desenvolvimento pode ficar mais simples (sempre)!
[]'s
Admito que exagerei um pouco.
Mas a intenção foi mirar 80m a diante para ver até onde alcançaria. =)
Gostei também de XP, e gosto muito do Getting Real, apesar de algumas falácias, no entanto acho que se dá muito valor à metodologia hoje em dia, a ponto de se esquecer os objetivos.
[]'s
Cacilhas, La Batalema
Conhecendo a empresa e o processo de desenvolvimento(ou ausência de um), esse problema ocorreu exatamente por uma falha nesse "processo torto".
Geralmente, temos um ponto central que faz a interface com o cliente, levantando os requisitos e elaborando a especificação, depois dessa "filtragem" chega às mãos da equipe de um documento para o desenvolvimento da funcionalidade, aí está o erro, não existe interface do desenvolvimento com o cliente. Ao meu ver uma participação mais direta do cliente com a equipe durante o desenvolvimento é fundamental para que o produto final atinja os objetivos idealizados pelo cliente.
Outra solução que pode ajudar é envolver mais pessoas da equipe de desenvolvimento no levantamento de requisitos, com visão de desenvolvimento é possível "cortar as asinhas" do cliente quando esse faz um pedido "mirabolante".É possível também dizer para o cliente se a funcionalidade X é viável ou não para o desenvolvimento já na concepção da funcionalidade e não apenas em tempo de implementação
Discordo quando é dito que metodologias ágeis são besteira e que só acrescentam complexidade ao projeto. Com scrum, por exemplo, isso não aconteceria pois antes do desenvolvimento, toda a equipe de desenvolvimento se reuniria com o cliente para compreender cada funcionalidade a ser desenvolvida.
Scrum não vem pra complicar, pelo contrário, é extremamente simples utilizá-lo, precisamos apenas de post it. Claro que tem toda uma mudança de filosofia, mas não há documentos burocráticos ou desnecessários, formalidades inúteis, etc. Mas isso é papo outro post.
Uma das grandes qualidades que o scrum possui é encorajar a comunicação verbal entre todos os membros da equipe, realizando reuniões antes dos desenvolvimento, reuniões diárias de acompanhamento do que está sendo desenvolvido, etc. Há uma interação entre os membros da equipe, resumindo, há trabalho em equipe e não um monte de gente trabalhando cada um por si.
Enfim, todos concordamos que o problema foi de comunicação, se sempre tivesse um papo do cliente com a equipe antes do desenvolvimento começar, muitas coisas do que fazemos hoje seriam bem mais simples.
[]'s
Rodrigo Lima
@admin
Quando disse que KISS é apenas uma sigla não quis dizer que não haja uma filosofia por trás.
Eu disse «é apenas uma sigla bonita para dizer...» e descrevi a filosofia em seguida, apenas para expor a filosofia.
@Rodrigo Lima
Concordo com você.
Exagerei sim, mas de propósito para criar a tensão necessária para abrir a discussão.
O que quis dizer quando disse que é tudo besteira, foi que se dá muita importância às metodologias – levando a guerras santas entre defensores de uma e de outra metodologias – e o que realmente importa, o resultado, chega mesmo a ser deixado de lado.
Na empresa em questão não é o caso, pelo menos não nessa situação – talvez em outra –, mas tudo acaba no final tendo a ver com falha de comunicação.
[]'s
Cacilhas, La Batalema
Bom, como profissional da área de Requisitos e Processos discordo que metodologias são complicativos para o projeto. Métodos servem para ajudar a atingir um resultado, e eles não precisam ser burocráticos, mas, sim atingíveis e realizáveis.
Participando desse projeto desde o começo posso dizer que o problema ocorreu por falta de comunicação entre todos os stakeholders, inclusive o cliente, e isso gerou no retrabalho que estamos enfrentando.
Quanto à qualidade das documentações acho que tudo só amadurece após a crítica de todos, daqueles que escrevem, daqueles que recebem, daqueles que aprovam. E isso é ainda uma falta constante em nossa realidade, principalmente, por quem as recebem. É bastante complicado para quem a faz - no caso eu - amadurecer ou refinar detalhes sem a ajuda de quem as recebem para apontar o que seria melhor ter. Quais dados faltam? Que tipo de dado poderia facilitar o desenvolvedor?
Acho que todos precisamos aprimorar a comunicação e cobrar uns dos outros que o processo e a participação de todos seja feita com maior frequência (isso é uma coisa que venho conversando com o LP há tempo, que a equipe de DEV precisa participar mais da fase de elaboração do projeto, e sair um pouco da fase de construção - onde normalmente é a única fase em que atua).
Bom fica aqui minha ótica sobre não só esse, mas todos os problemas que estamos enfrentando nesse projeto.
Para bom entendedor meia palavra basta, mas para bom comunicador meia palavra é um inferno!
A parte em que concordo com o Rodrigo é que metodologias podem ser úteis.
@Carol
Muito boa observação.
Deixei meio vaga a ideia da falta de comunicação já porque não acompanhei o processo tão a fundo quanto os envolvidos nesse projeto e não me sinto com propriedade para essa discussão específica.
Concordo com cada ponto que você abordou, exceto um.
Você disse que discorda que metodologias sejam complicativos do projeto. Eu diria que metodologias não precisam ser complicativos.
A crítica ao método que fiz não se aplica ao projeto citado, mas ao texto do L.P.
A crítica que fiz na verdade foi voltada a burocratização das metodologias. Como você disse, métodos não precisam ser burocráticos.
Digo mais: métodos não devem ser burocráticos!
A ideia principal de «metodologia» é facilitar, regular e apontar o caminho de menor esforço, como citei em meu primeiro comentário. O que não podemos deixar que aconteça é a burocratização da metodologia, o que creio não seja o caso.
O caso foi, como disse lá no início, falta de comunicação – não de metodologia –, o que foi resolvido magnificamente com uma simples reunião.
[]'s
Cacilhas, La Batalema
@Carol
Não quis contestar qualidade das documentações geradas, mas o quanto esses documentos são "perdidos" com as inclusão e mudança de requisitos, e inclusão de regras de negócio durante o desenvolvimento que não são percebidos durante o levantamento de requisitos.
Repito, a participação de desenvolvedores na concepção do sistema é essencial para que o produtos atinja os objetivos esperados pelo cliente.
@Cacilhas
Metodologias não precisam mesmo ser fatores complicativos, na minha visão, tem que ser adotada "a melhor chave para apertar a bitola do parafuso". Acho que cada empresa tem sua necessidade e o mais díficil é escolher a chave certa pra apertar a bitola do parafuso, ou seja, implantar a metodologia certa para atingir os objetos.
Acho adoção de metodologia essencial, hoje não temos validação do que é desenvolvido, não sabemos se o que foi desenvolvido realmente funciona ou se atende os requisitos, não temos testes automatizados, etc. Acho que antes de abraçar uma metodologia, o legal seria adotar algumas práticas dela, fazer um período de validação e amadurecimentos dessas práticas, tendo sucesso nisso, aí sim adotamos a metodologia por completo.
[]'s
Rodrigo Lima
Por isso estou adorando blogar.
O conhecimento e as opiniões gerados em torno de um assunto são valiosíssimos!
Pelo que entendi, todos estão dizendo a mesma coisa de forma diferente.
Assim como eu, todos concordam que é aconselhavel utilizar uma metodologia (pra mim deve ser ágil), que quanto menor o caminho de comunicação entre as pessoas (isto inclui o cliente), a comunicação é melhor e os problemas em código principalmente são resolvidos de forma mais simples e uma documentação mínima possível é necessária.
Desta forma acredito que dificilmente um projeto enfrente problemas.
Sou totalmente a favor do Scrum e gosto bastante da filosofia do Getting Real. Ao menos para soluções web, que é onde tenho maior conhecimento.
Abs,
@Joe Rabelo
Caraca! Alguém percebeu! =)
Sim, estamos todos dizendo a mesma coisa de formas diferentes:
- Metodologias facilitam (quando não são muito burocráticas).
- O melhor caminho é o de menos esforço.
- Comunicação é essencial.
- Documentação é importante.
Mas há mais um ponto que eu toquei diversas vezes e ninguém – nos comentários – deu importância: foco.
A crítica que fiz e mantenho de pé – não para implicar com qualquer um, mas para fazer todos questionarem – é quanto à importância que se dá à metodologia.
O foco deve ser no resultado, nunca na metodologia. A metodologia jamais pode ser um fim em si. Ela é um meio para se atingir um objetivo.
Sei que isso é quase off-topic, mas acho importantíssimo reparar na hierarquia de prioridades a ser considerada, e metodologia jamais pode ocupar o topo.
O que constuma acontecer – e não foi o caso do problema exposto no artigo – é que começa a haver guerra santa entre os defensores de metodologias diferentes que se burocratizam e o próprio resultado se torna secundário diante da importância atribuída à metodologia.
Não se pode deixar isso acontecer.
Metodologia é importante sim, mas em seu devido lugar: um regulador, um facilitador, um meio de chegar a um fim.
[]'s
Cacilhas, La Batalema
Não concordo com o primeiro comentário de que métodos e metodologias atrapalham o processo. Tudo depende do tamanho do processo.
Se o processo consiste num desenvolvimento curto, coisas muito simples, sim, eles atrapalham.
Agora, se o processo é longo, com meses de duração, várias etapas de desenvolvimento e entregas, não da pra querer fazer tudo na raça e esperando que todos que fazem parte do processo tenham o bom-senso de deixar as coisas simples.
Quanto mais variáveis são inseridas no contexto de um processo de desenvolvimento, mais metodologias devemos ter para garantir a satisfação de todos (cliente, desenvolvedores, etc...)
[]s!
[...] algum tempo atrás passei por problemas de planejamento e escrevi esse post: Planejamento de software (Keep It Simple Stupid) e esse post gerou muitas opiniões. (Muito bom [...]