Esta seqüência de artigos tem o objetivo de demonstrar algumas técnicas de testes simples, contribuindo para homologadores/analistas de testes em início de experiência. Espero que contribua.
Por Fernando Palma, Setembro de 2009
TÉCNICA DE TESTE PARA TELAS DE PESQUISA
Ao validar uma tela de pesquisa, o homologador deve fazer os seguintes testes: Testar todas as combinações existentes dos campos para garantir que a tela funciona. Para uma busca com ?a? campos, existirão 2ª combinações.
Ex: 3 filtros são dispostos em uma pesquisa. Portanto, então seriam 8 combinações.
A melhor técnica para alcançar este fim, é utilização de números binários, como demonstrado a seguir:
Como a tabela demonstra, 8 combinações de busca são realizadas.
Mas estes não são todos os testes, pois para cada campo preenchido, o desenvolvedor deve testá-lo preenchendo uma vez com parâmetros que retorne(m) registros(s) e outra vez com parâmetros que não retorne registro. Então, seriam na verdade 2 (ª + 1) à 2 elevado a ?a? mais 1 combinações diferentes. No exemplo acima, seriam 16 combinações, na verdade.
Obs: Considerando que ?R? represente um parâmetro que retorne registro(s) e ?N? um parâmetro que não retorne nenhum registro.
O interessante desta técnica é imaginar uma tela com diversos filtros. 6, 8, 15 filtros de pesquisa. Representariam estes valores elevado ao cubo, quando traduzido em testes. Três conclusões podem ser tiradas, portanto:
1- O gerente responsável pelo projeto de software deve definir o nível de qualidade que é requerido para o sistema. Baseado nesta especificação, ou melhor: neste requisito de qualidade, o analista de testes/homologador executa a metade, um terço, ou até 1% das combinações existentes.
2- Quando parte das combinações são executadas, cabe ao Analista de Testes definir quais delas serão escolhidas, por representarem maior risco de falhas.
3- Ao receber os requisitos do sistema, no inicio do projeto, o Analista de Testes deve prevenir com estimativas de quantidade de testes que serão gerados. Esta colaboração é importante para que haja um balanceamento eficaz diante de escolhas, como esta: “quantos filtros existirão na tela?”. Nem sempre o que é fácil de implementar é fácil de testar. Por isso, muitos analistas de testes já utilizam o conceito denominado “pontos de testes” para os requisitos de teste, que equivale aos “pontos de função” dos requisitos de sistema.
Ao validar uma tela de pesquisa, o homologador deve fazer os seguintes testes:
[list]Testar todas as combinações existentes dos campos para garantir que a tela funciona. Para uma busca com “a” campos, existirão 2ª combinações.[/list]
Ou a pessoa pode manter a sanidade mental dela e usar TDD. (Ou tá achando que o Google tem uma pessoa para testar todas as bilhões combinações de pesquisa dela?)
F
fernando.palma
Olá Bruno,
existe uma parte do artigo que faz referência a esta quantidade de testes que deve ser executada:
"O interessante desta técnica é imaginar uma tela com diversos filtros. 6, 8, 15 filtros de pesquisa. Representariam estes valores elevado ao cubo, quando traduzido em testes. Três conclusões podem ser tiradas, portanto:
1- O gerente responsável pelo projeto de software deve definir o nível de qualidade que é requerido para o sistema. Baseado nesta especificação, ou melhor: neste requisito de qualidade, o analista de testes/homologador executa a metade, um terço, ou até 1% das combinações existentes.
Como assim definir o nivel de qualidade??? :shock: :shock: :shock:
Só existem dois niveis de qualidade possiveis: “Total” e “Nenhuma”. Qualidade não é negociavel, qualidade é requisito básico.
Se voce nao tem tempo habil pra implementar todos os requisitos do sistema, voce tem que negociar ou o tempo ou os requisitos, nunca, jamais, em tempo algum a qualidade.
E
eliasn
Olá YvGa,
Qualidade é negociada sim em nível de serviço, não como tu estás pensando mas em termos de entrega do sistema.
Não existe um sistema livre de bugs, logo a qualidade “total” não existe!
Quando uma aplicação é desenvolvida, em empresas mais maduras (diga-se empresas que realmente sabem o que é Teste de Software e os reais benefícios que ele traz) existem uum nível de aceite: o gerente de teste determina o % de bugs, pela sua criticidade, que o sistema pode ter. Mas isso é sempre alinhado com o cliente.
Tento em vista que o cliente sabe que existe bugs, a qualidade é negociada.
Uma vez que a área de teste encontrou 10 defeitos, sendo 3 críticos, 5 médios e 2 baixos. Podemos negociar de entregar o sistema para funcionamento com os 3 erros criticos e os 5 médios corrigidos, deixando os 2 baixos para a proxima entrega.
Essa é a visão da área de Teste, que Controla a Qualidade.
Na mesma linha, na visão da Garantia da Qualidade, nos procedimentos inciais para desenvolvimento e testes, o gerente (desenvolvimento e/ou testes) podem definir o nível de qualidade adotando quais características da qualidade a aplicação terá que atacar prioritatiamente (veja ISO 9126). É muito dificil uma aplicação aplicar 100% das características da qualidade, logo não existindo assim também uma qualidade “total”
Abraços!
N
neofito
Isso aí é pra usar com fábrica de software, waterfall. Todos nós já conhecemos os problemas desse modelo.
Y
YvGa
Desculpe, Elias, mas eu discordo.
O foco deve ser sempre qualidade total. Eu concordo que nas primeiras iteracoes, e mesmo no inicio da vida util dos sistemas existem problemas. Mas voce vai ter que resolve-los todos antes de poder dizer que o sistema foi implantado.
É exatamente o que o Neofito colocou, essa sua teoria vem da boa e velha fabrica de software que ja provou por a + b que é ineficaz.
Repito, qualidade não é negociavel. Se nao funciona voce nao entrega, se funciona mais ou menos voce nao entrega. Se funciona mas contem pequenos bugs suportaveis voce conserta-os e entrega.
Erros existem e sempre um ou outro passa, mas nunca passa quando sabe-se da existencia dele.
F
fernando.palma
?Repito, qualidade não é negociável. Se nao funciona voce nao entrega, se funciona mais ou menos voce nao entrega. Se funciona mas contem pequenos bugs suportaveis voce conserta-os e entrega.?
YvGa,
O nível de qualidade de um serviço ou produto é variável e negociável, depende do que este serviço/produto irá atender.
Ex: Quando um gerente de projetos planeja a entrega do de um sistema, ele precisa analisar conhecer o escopo do sistema a nível de requisitos não funcionais:
quantos usuários irão utilizar a aplicação;
quantos acessarão o sistema simultaneamente;
qual a carga de informação que será tratada nas transações do sistema.
Entre outros.
Baseado nestes requisitos, ele entrará em acordo de nível de qualidade tais como performance, disponibilidade e níveis de serviço em geral que o sistema deve atender. Irá então formalizar os critérios de aceite do sistema e gerenciar a qualidade, através dos processos de controle e garantia da qualidade.
O Analista de testes por sua vez, irá especificar os testes que atendam ao nível de qualidade que o gestor do projeto aprovou com o cliente.
Voltando para o exemplo anterior da tela de consulta:
Eu estou entregando em Novembro um sistema para uso interno em uma Universidade aqui em Salvador. Este sistema irá atender a 3 mil professores entre os meses de Novembro de 2009 e Março de 2010.
Digamos que neste sistema descrito acima, exista uma tela de consulta com 5 campos. Eu com certeza irei orientar que os testes sejam realizados para cobri apenas uma parte de todas as combinações possíveis (da análise combinatória apresentada).
Exemplo de quantidade de testes que eu faria:
Campo 1 Campo 2 Campo 3 Campo 4 Campo 5
1 0 0 0 0
1 1 0 0 0
1 1 1 0 0
1 1 1 1 0
1 1 1 1 1
Como pode ver, estes não são todos os testes que possíveis de se realizar. Existem mais combinações. Entretanto, eu assumo o risco de não estar testando todas elas.
Razão:
Digamos que ao omitir alguns testes, eu esteja correndo o risco de 5% de ocorrer um bug em produção, nesta tela de pesquisa, ao realizar uma consulta.
Este bug será relatado ao servicedesk e representará um custo, em média de 100 reais por hora para ser corrigido (por conta da indisponibilidade e alocação de recursos.
Lembrando que estes números são ilustrativos.
Na verdade eu estou correndo o risco de 5% com impacto de 100 reais a hora. Em uma estimativa de 10h de paradas (pessimista), eu estou dando um prejuízo de 0,05 * 100 * 10 = 50 reais.
O custo que eu teria para testar todas as possibilidade é maior do que 50 reais, ainda mais pelo fato de eu não possuir uma ferramenta.
Agira tomemos um contra-exemplo: um sistema bancário.
Uma única falha de minutos em um sistema de banco, pode significar milhões em perdas financeiras. Por isso, ao implementar um sistema de banco o nível de qualidade deve ser negociável ao extremo. Deve ter um alto nível de qualidade e isso tem um custo.
O google , por exemplo, deve ter ferramentas poderosas de testes que realizam todas a combinações possíveis em “pesquisa avançada”. Isso porque um erro de pesquisa no google é mais custoso do que no meu caso.
Segue abaixo, um gráfico clássico para profissionais de qualidade:
Esta imagem mostra o numero de testes executados e o número de erros. O Gerente de projetos deve moderar os testes feitos para encontrar o ponto de cruzamento entre a linha amarela e a vermelha: numero de testes começa a ultrapassar o custo do número de erros.
Testar demais é tão ineficiente quanto testar pouco.
F
fernando.palma
Caso alguém queira participar mais do tema concordado ou discordando:
Com gestões ágeis, o processo muda. As entregas e avaliações são constantes. Entretanto, o nível de qualidade deve existir, indendente de modelo cascata ou iterativo.
Alias, eu já to bem cansado dessa conversa, esses graficos, essa burocracia… trabalho numa empresa que tem exatamente esse discurso, exatamente essa forma de trabalho, e te digo com todas as letras isso é engodo, blablabla pra justificar os altos salarios de um monte de gente que nao tem a menor ideia do que esta fazendo.
Qualidade não é negociavel, e só cliente e mais ninguem pode dizer se o sistema esta apto ou nao para ir pra producao.
Esse monte de bolinha e linhazinha colorida pra la e pra ca nao faz nada, nao serve pra nada, nao agrega valor, nao deixa o cliente satisfeito. So serve pra alimentar as ilusoes dos diretores “semi-competentes” que adoram graficozinhos. Enquanto isso gasta-se milhoes e milhoes em software por ano. Sendo que a maioria, a maioria mesmo, dos projetos falha.
F
fernando.palma
Desculpe, Fernando, mas eu insisto.
Alias, eu já to bem cansado dessa conversa, esses graficos, essa burocracia… trabalho numa empresa que tem exatamente esse discurso, exatamente essa forma de trabalho, e te digo com todas as letras isso é engodo, blablabla pra justificar os altos salarios de um monte de gente que nao tem a menor ideia do que esta fazendo.
Qualidade não é negociavel, e só cliente e mais ninguem pode dizer se o sistema esta apto ou nao para ir pra producao.
Esse monte de bolinha e linhazinha colorida pra la e pra ca nao faz nada, nao serve pra nada, nao agrega valor, nao deixa o cliente satisfeito. So serve pra alimentar as ilusoes dos diretores “semi-competentes” que adoram graficozinhos. Enquanto isso gasta-se milhoes e milhoes em software por ano. Sendo que a maioria, a maioria mesmo, dos projetos falha.
Concordo que a satisfação do cliente é foco principal. Mas nem sempre o cliente sabe o que precisa, não é verdade?
Entendo o seu ponto de vista e também prefiro atuar do que exibir gráficos. Claro que é mais produtivo. Entretanto, no momento que desenvolvemos um sistema, nós como analista devemos entender dos requisitos do negócio para prever o nível satisfatório de: disponibilidade, performance, trafego, etc.
Caso a gente não desenho um pouco de gráfico e não faça nossas contas, o que faremos? Intuição? Ou esperamos o cliente dizer OK e liberamos em produção. E se o sistema apresentar performance baixa e der prejuízo a empresa? Pense grande: imagine se nós dois estivermos responsáveis por desenvolver o site do submarino. Como fazemos isso sem cálculos, gráficos, números, estatísticas, forecasts…como?
O cliente pode até olhar o sistema e validar. Mas ele estará assinando atestado de falência.
Nao concordo. Muitas vezes ele nao sabe expressar o que quer, mas ele sabem bem o que quer.
Em que os graficos e os calculos ajudariam? Em que?? A sua pergunta é de resposta simples. Se nós estivermos responsáveis por desenvolver o site do submarino e nenhum de nós dois nunca desenvolveu um site como o do submarino e na nossa equipe na ha ninguem que tenha desenvolvido um site como o do submarino, o nosso submarino imaginario vai naufragar.
E pode fazer grafiquinho a vontade que nao vai salvar nada.
Separei uma frase em particular do teu post:
e tambem:
Essas suas colocacoes mostram claramente que voce, apesar de citar e comentar aí no seu blog, nao faz a menor ideia do que sejam as metodologias ageis. Sao a solucao pra tudo? nao nao sao. Resolvem todos os problemas do desenvolvimento de software. Nao nao resolvem. Mas elas superam e muito as “metodologias” tradicionais.
O que eu posso te sugerir é o seguinte:
Se sua preocupação é fazer software de qualidade, estude as metodogias ageis e esqueca esse blablabla de graficos e planilhas. Se a sua preocupação é conseguir uma boa “colocação” em uma fabrica de software como gerente de TI ou galgar posicoes em uma em que ja esta, ganhar um salario alto e entregar software mais ou menos, continue com essa sua estrategia de auto-promocao e conversa pra boi dormir que os diretores adoram.
P.S. Espero que nao leve pelo lado pessoal.
F
fernando.palma
Essas suas colocacoes mostram claramente que voce, apesar de citar e comentar aí no seu blog, nao faz a menor ideia do que sejam as metodologias ageis. Sao a solucao pra tudo? nao nao sao. Resolvem todos os problemas do desenvolvimento de software. Nao nao resolvem. Mas elas superam e muito as “metodologias” tradicionais.
O que eu posso te sugerir é o seguinte:
Se sua preocupação é fazer software de qualidade, estude as metodogias ageis e esqueca esse blablabla de graficos e planilhas. Se a sua preocupação é conseguir uma boa “colocação” em uma fabrica de software como gerente de TI ou galgar posicoes em uma em que ja esta, ganhar um salario alto e entregar software mais ou menos, continue com essa sua estrategia de auto-promocao e conversa pra boi dormir que os diretores adoram.
P.S. Espero que nao leve pelo lado pessoal.
YvGa,
gostei muito do diálogo. Acredito realmente que eu devo estudar um pouco mais de metodologias ágeis. Convivi um pouco com a teoria, desde o XP, mas depois do seu post, cheguei a conclusão que poso ter conhecimento superficial do asunto por alta de aplicação.
Fique tranquilo, diálogos são sempre bem vindos.
O que quis dizer com a incerteza do cliente sobre o que ele quer é o seguinte:
Convivo com isso, quando solicito os níveis de serviço desejados para apicar…encontro respostas ambíguas, incertas e não tão importantes. vc entende? O cliente as vezes realmente quer o que não é importante para ele. E deixa de pedir o qu eé importante…
Quando estudamos requisitos não funcionair, priridades, pontos vitais do negócio…quando fazemos isso, sabemos o que o cliente precisa. O ideal é fazer parte do trabalho dele por algum tempo e transformar os requisitos dele em requisitos de TI.
Se você tiver algum material de Scrum e outras metodologias ageis para indicar, será bem vindo.
Essa parte já não concordo tanto. Existem diferente segmentos. Você nunca será reconhecido se não tiver produtividade, não interessa no que acredita ou que metodologia usa. Eu não sei extamente o que quis dizer com “blablala”. Talvez um exemplo possa esclarecer.
Y
YvGa
Fernando, nao me leve a mal se eu for um pouco rude, quero deixar claro antes que é rude com essa forma de pensamento e nao com voce em particular
Como todos os gerentes voce tem a labia afiada, aqui voce falou, falou e nao disse nada. Quantos usuarios? simultaneos? A carga? Esses sao requisitos a serem atendidos. Eles podem ser negociados, a qualidade do que foi negociado nao.
“Cliente, será realmente esse o numero de usuarios que utilizara a aplicacao? Essa é uma previsao de medio/longo prazo? Esse numero pode ser menor agora e com o tempo ser aumentado?”
“Cliente, será realmente esse o numero de usuários simultaneos ou essa é uma previsao baseada somente no numero de usuarios cadastrados? Esse numero pode ser menor agora e com o tempo ser aumentado?”
“Cliente, essa é a carga simultanea real prevista, ou é uma hipotética para medio/longo prazo.”
Baseado no que o cliente responder voce vai implementar esses requisitos, e eles vao ter que atender aquilo a que voce se propos, do contrario nao ha qualidade no seu trabalho.
Essa é uma ideia absurda, se é economicamente inviavel voce testar todas as possibilidades, voce TEM que conversar com o cliente, explicar que nao é possivel por agora ter todas as possibilidades de consulta. Ele vai dizer quais devem ficar e quais podem esperar. Voce nao tem como saber isso, voce nao pode dizer o que é testado e o que não é. Voce pode definir que tais variacoes serao implementadas, mas na hora que for pra producao, determinados usuarios podem precisar justamente daquelas que nao foram testadas. E ai? Ah vai pro servicedesk, mas o sistema nao funciona pra aquele usuario, logo nao tem qualidade nenhuma pra ele.
O custo de um cliente insatisfeito pode ser muito maior que esse calculo ridiculo que voce pos ai. O que foi implementado nao atende os requisitos e um sistema que nao atende os requisitos no prazo que foi estipulado, pode ter o contrato revisto. Nao é todo mundo que cai nessa conversa nao.
Voce tambem nao pode decidir o que é critico e o que nao é. Aquela pesquisazinha que voce considera bobagem pode ser critica para um usuario que voce nem conhece. Nenhum gerente tem condicoes de dizer o que é e o que não é critico. Só o cliente pode dizer, e se o japones da quitanda diz que o cadastro de clientes dele é critico, pra mim é tao crítico quanto a possibilidade de perdas financeiras do banco. Ambos devem ser tratados da mesma forma.
Ninguem esta falando em testar demais, tem que testar o que precisa ser testado, nao o que o gerente acha que talvez, quem sabe possa ser testado.
Impressionante como os gerentes, ou pretensos gerentes, subestimam testes unitarios, muitas vezes seque sabem o que sao. Subestimam tanto ou mais do que nós desenvolvedores os superestimamos.
Y
YvGa
Entao, Marcos, é como eu disse pro Fernando a minha revolta nao é contra o Fernando, mas sim contra a ideia que ele defende. E to traumatizado sim hehehe, porque vivo num ambiente que prega exatamente essa teoria e resultado disso é lixo.
Sobre os seus exemplos do post-it, quero deixar claro que nao prego baderna. Se a equipe que voce citou usasse testes unitarios esse tipo de problemas seriam bem menores.
Y
YvGa
Fernando, tem sim algum material interessante sobre scrum
Um livro sobre user stories, mas bastante interessante pra quem esta estudando scrum.
Tambem sobre extreme programming
F
fernando.palma
Fernando, tem sim algum material interessante sobre scrum
Obrigado cara! Quero ficar mais afiado no assunto, apliquei em tempos de faculdade mas pouco na área comercial (aqui em minha cidade, Salvador).
O que quis argumentar, acima de tudo é que existem sim diferentes especializações, decisões, formas de aplicar, construir. Todas têm vantagens e desvantagens.
Fazendo uma analogia, uma professora minha de faculdade critica os alunos por falarem o tempo inteiro de novas tecnologias como frameworks Java, mcritias ela considera que eles têm GAPS em conceitos de engenharia de software. Já o pessoal mais técnico da minha empresa, critica o setor da qualidade, pois consideram que eles são profissionais fora do “mundo de ti”.
Resumindo: cuidado com conceitos radicais. Dificilmente existirá alguma situação em que um profissional aprende e se dedica a algum segmento e acaba conquistando cargos meio que “na enganação” só por que os "diretores adoram. Eu convivo com profissionais que não confio no ponto de vista, mas procuro respeitar.
YvGa,
acima de tudo, gostei da troca de idias. Espero voltar a estudar um pocuo de SCRUM assim que possível e voltar aqui para torcarmos mais “figurinhas”
O pessoal usa as ferramentas de maneira errada e acreditam que só por usa-las estão garantindo a qualidade. Já vi projetos atrasarem porque o gerente de projetos não conseguia arrumar o MS Project direito e deixou os desenvolvedores esperando ele concertar a m*.
É a mesma coisa daqueles que reunem todo dia e chamam isso de Scrum, depois saem falando que metodologia ágil não funciona.
Marcos: você disse tudo
Y
YvGa
Concordo, Fernando, mas no meu caso, nao sao conceitos, e por mais que possam parecer radicais, sao experiencias praticas. Eu trabalhei numa empresa em que estava sendo intruduzido o uso de Scrum + xp e as coisas funcionavam e aplicacoes ate mais criticas das que trabalho hoje, saí pra ir pra outra que fazia propaganda da utilizacao de XP. É uma empresa séria, nao é esbornia nao, ela busca entregar um produto de qualidade, mas usa conceitos e metodologias que só atrapalham.
É por experiencia pratica, nao teoria, que eu te digo o que funciona e o que nao funciona. Parece pretensao, mas é vivencia pratica.
F
fernando.palma
Concordo, Fernando, mas no meu caso, nao sao conceitos, e por mais que possam parecer radicais, sao experiencias praticas. Eu trabalhei numa empresa em que estava sendo intruduzido o uso de Scrum + xp e as coisas funcionavam e aplicacoes ate mais criticas das que trabalho hoje, saí pra ir pra outra que fazia propaganda da utilizacao de XP. É uma empresa séria, nao é esbornia nao, ela busca entregar um produto de qualidade, mas usa conceitos e metodologias que só atrapalham.
É por experiencia pratica, nao teoria, que eu te digo o que funciona e o que nao funciona. Parece pretensao, mas é vivencia pratica.
Entendo bem você: eu sinto isso no dia-a-dia tb. Principalmente quando mudo de projeto/empresa. As vezes temos vontade de dizer que está tudo errado… Bom, eu vou seguir sua dica e estudar mais o SCRUM. Já tive experiências boas e ruins com que usei até hoje. Será um conhecimento a mais.
Bom, só mais alguns detalhes, para não deixar de pontuar
Essa é uma ideia absurda, se é economicamente inviavel voce testar todas as possibilidades, voce TEM que conversar com o cliente, explicar que nao é possivel por agora ter todas as possibilidades de consulta.
Não me parece tão absurda. Todo sistema tem um nível de testes planejado.
Imagine o exemplo: no meu contrato estou desenvolvendo 2 sistemas. Um deles é SRH (de rcursos humanos) que atenderá 12 mil usuários. O outro é um sistema para o setor de administração de arquivos (SIARC). 10 pessoas trabalham neste sistema.
O nível de qualidade do primeiro deverá ser maior, fatalmente. Imagine que exista uma tela em que a usabilidade pe ruim, existe um erro não tratado ou um campo de CPF sem mascara, uma consulta com N campos (como o exemplo).
Se exemplos de uma tela com má usabilidade ocorrerem no SRH, terei centenas de chamados por dia para o servicedesk e irá acabar impactando no meu setor de desenvolvimento também. O cliente, por sua vez, também irá perder: tempo parado por causa da indisponibilidade.
Já no caso so SIARC, apenas 10 profissionais usam. A chance deles cairem neste erro não tratado, ou inserir um CPF invalido, etc, é bem menor. Digo mais: se eu treinar eles apenas uma vez e pedir atenção a estes pontos, é possível que o servicedesk nunca receba uma ligação destes profissionais.
Eu fiz questão de dar este exemplo porque ele é real. Mas quero sua opinião e dos demais aqui. O que você(s) acha(m)? Não é razoável investir na qualidade apropriada para cada situação? O plano de gestão de qualidade não é válido?
Permitir que um bug passe por erro, descuido, falha em prever que determinado fluxo seria utilizado de determinada forma, isso tudo bem. É um erro e todos cometemos erros. Mas assim que descobertos tem que ser solucionados.
Permitir que um erro vá para a producao, tendo ciencia de que ele existe é subestimar o usuario. No seu exemplo voce esta tratando os usuarios do RH com mais presteza do que os do admnistrativo, e estes nao vao gostar disso, pode apostar. Isso está muito proximo de má fé.
Um cliente que nao tem seus requisitos todos atendidos nao deveria pagar pelo produto. A tendencia é que as coisas mudem e os clientes fiquem cada vez mais exigentes, porque aos poucos eles vao tomando conhecimento de que esse “pessoal de informatica” adora uma papagaiada e nao resolve nada.
S
sergiotaborda
correção: “O seu sistema não é livre de bugs e logo a qualidade no seu sistema não existe”.
Isto é uma grande asneira. Esta forma de trabalho é uma enganação. Estúpidos são os clientes que caem nesta asneira.
A razão é muito simples : O que seria o % de bugs ? numero de bugs sobre numero de features ? Errado
numero de bugs conhecidos sobre numero de features. O problema é que em um sistema com testes corretos (automáticos e com cobertura) o objetivo e descobrir e eliminar todos os bugs. E “todos” significa os que conhecemos e os que não conhecemos.
Teste é na realidade uma forma de fazer o bug sair da sua toca… e depois pisá-lo.
O Aceite é uma forma incompetente de resolver a situação. É forçar o cliente a aceitar pagar por algo que tem defeitos.
Este clientes não sabem o que estão fazendo e estão sendo enganados.
É como ir fazer uma cirurgia e tolerar que o médico cometa uma % de erros . Vc se arriscaria a ser operado com margem a 1% de erros ? Basta 1 erro para que vc morra. Da mesma forma , basta 1 erro para que o cliente perca milhares de reais.
Qualidade não é negociável. Tentar fazer isso é sinal que estamos lidando com uma péssima empresa.
Todos os defeitos são críticos.Todos eles causam dano. O que acontece é que uns tem que ser resolvidos com mais prioridade que outros.
Isto é simplesmente uma palhaçada sem pés nem cabeça. O curioso é que sim é uma prática comum.
Agora , vc senhor cliente que paga por estes software, imagine o dinheiro que lhe estão estorquindo.
Ele obrigam vc a aceitar coisa com defeito (indo contra o codigo do consumidor … ah! putz software não é um consumivel…)
e depois cobram para corrigir esses defeitos (que eles mesmos colocaram). Vc contrata empresas assim porquê ? Não tem nada melhor que fazer com o seu dinheiro ?
A ISO 9126 não cobre bugs. Ela cobre qualidade no sentido ISO do termo que nada têm a haver com numero de defeitos.
Qualidade neste sentido é o mesmos que atenção a requisitos não funcionais. E nesse caso o software atende ou não atende. E isso é medido quando ele não tem defeitos. Por exemplo, o sistema deve ter disponibilidade 99.99% ( veja bem que as qualidades ISO são mensuráveis). Se ele tem disponibilidade 99,9% não atende. Isto não tem nada a haver com bugs.
F
fernando.palma
Tenho nojo de coisas que funcionam mais ou menos.
Tenho dó de seus clientes.
Permitir que um bug passe por erro, descuido, falha em prever que determinado fluxo seria utilizado de determinada forma, isso tudo bem. É um erro e todos cometemos erros. Mas assim que descobertos tem que ser solucionados.
Permitir que um erro vá para a producao, tendo ciencia de que ele existe é subestimar o usuario. No seu exemplo voce esta tratando os usuarios do RH com mais presteza do que os do admnistrativo, e estes nao vao gostar disso, pode apostar. Isso está muito proximo de má fé.
Um cliente que nao tem seus requisitos todos atendidos nao deveria pagar pelo produto. A tendencia é que as coisas mudem e os clientes fiquem cada vez mais exigentes, porque aos poucos eles vao tomando conhecimento de que esse “pessoal de informatica” adora uma papagaiada e nao resolve nada.
Eu não sei se eu entendi bem, mas vicê sugere que para todos os sistemas todos os bugs sejam corigidos? Você entende o custo disso?
Eu trabalhei como Analista de Testes durante 2 anos e meio. Gosto de ver os bugs corrigidos. Mas uma coisa é clara: nem todos os bugs são corrigidos para todos os sistemas. Isso é fato. Quando o meu analista de testes encontra 250 erros, fazemos uma avaliação. Normalmente 200 são corrigidos e o restante realmente pode ficar para próximas entregas. Não considero isso algo "próximo de agir de má fé. Você já gerenciou custos? Já comparou o custo de eliminar o bug com o custo do impacto dele? É só uma pergunta para provocar mais diálogo, não entenda como desafio (a linguagem escrita é uma fonte de maus entendidos).
Só para complementar: quando eu testava, se me colocassem 50 vezes para homologar, eu achava bugs nas 50 vezes. Se fossem 100, tb. Sempre existem alguns bus residuais, escondidos.
O tamanho da aplicação e para o que ela será usada é importante sim. Se você produz bicicletas ou brinquedos para crianças, existem níveis de qualidade exigidos pelo inmetro. Se você produz aeronaves, os níveis são infinitamente maiores: cada equipamento dentro de um avião de voo doméstico tem nu mínimo duas redundâncias e níveis de testes extremos.
Imagine outro cenário: você desenvolve sistemas para supermercados e para hospitais. Qual deve exigir um nível extremo de testes e correções? Os dois devem ter os mesmos cuidados?
Mais alguém acha que para todo produto devem ser realizados todos os níveis de testes e corrigido o máximo de bugs?
Isso vindo de alguém que foca na qualidade do software, me assusta.
F
fernando.palma
Mas uma coisa é clara: nem todos os bugs são corrigidos para todos os sistemas.
Isso vindo de alguém que foca na qualidade do software, me assusta.
Converse com alguns profissionais da Qualidade. Leia um livro do Alexandre Bartie ou qualquer outro que aborde com profundidade os testes de software.
Qualquer literatura ou prática sobre testes, esta afirmação é verdadeira: muitos cenários são considerados bugs. O bom nível de qualidade garante que o sistema atende aos requisitos e não trará impacto negativo no processo do negócio do cliente (ou interno, como meu caso).
Eliminar todos os bugs de um sistema é uma tarefa impossível. Não existem sistemas livres de bugs. Repito: quanto mais um sistema é testado, mais bugs são encontrados. Sejam eles de mínimo, pequeno, médio ou grande impacto. Eu tenho conciência em não enviar sistemas para produção que contenham bugs de grande impacto. Mas, quanto aos de impacto mínimo, eles irão. Os exemplos que ilustrei tentam demonstrar isso: o número de usuários e para o que este sistema será utilizado também são fatores determinantes da qualidade. Eu também já coordenei servicedesks: sistemas com que são utilizdos por milhares de usuários tendem a provocar mais dúvidas de usabilidade que os que tem 5 ou 10 usuários. Por isso, devemos nos preocupar mais com a usabilidade deles. Sites precisam de um nível alto de usabilidade, pois se o usuário não se adapta, ele não volta..
A diferença entre o usuário de sistema desktop para usuário web:
A menos que vc tenham uma definição de bug que significa “tudo com o que eu não concordo” é possivel sim ter um sistema livre de bugs. quando vc diz “bug” e pensa “a cor do label está errada” isso não é considerado um bug do ponto de vista do desenvolvedor.
Bug no entender do desenvolvimento é vc apertar um botão e o sistema lançar uma excection ou não produzir o resultado esperado.
Quando certo promenor do software não está de acordo com a especificação isso é chamado : defeito. Bugs não são defeitos no sentido que , embora ele vão contra a especificação, não era suposto. Não era propósito do desenvolvedor que acontecesse aquilo.
Portanto, quando se colocar o label azul em vez de amarelo ou o botão está 3px mais para o lado esquerdo isso não é um bug.
Sistema sem bug é possivel sim. Basta que vc tenha uma equipa qualificada de desenvoldedores seguindo boas práticas te tendo testes automáticos. Um sistema livre de defeitos realmente não é possivel porque sempre vão existir descrepâncias entre o era suposto e o que está lá. Isto se deve na realidade ao mito de que é possivel documentar toda a especificação de um software e é considerado defeito aquilo que, embora nunca tenha sido especificado vai contra aquilo que a equipe de “qualidade” pensa ou acha ,mesmo quando é totalmente ridiculo.
Se vc seguir esta linha e nunca especificar vc vai deduzir logicamente que todo o software é um enorme defeito porque nem sequer a existência do software está especificada. Este é o clássico exemplo de que porque as metodologia tradicionais não funcionam. elas são baseadas em lógicas falhas.
O entendimento moderno é o seguinte:
Se o label está verde e não ha especificação, então não ha defeito ali. O que ha é opção de melhoria. E melhoria sempre é opcional, não critica e negociável (exactamente o contrário de correção de defeito que é obrigatória, critica e não negociável).
O defeito só vem se havia uma especificação explicita e clara que deveria estar diferente.
Um outro problema na metoodologia tradicional é que o estado de desenvolvimento sempre reflete o request mais recente. então se a especificação escrita pedia azul , mas o cliente mudou para verde , verde é o correto. É comum a equipa de qualidade depois dizer que é um defeito porque foi especificado azul. O problema é que eles não atualizaram a especificação para aquilo que o cliente pediu. Modernamente o tester está dentro da equipa de desenvolvimento e sabe quando e porque a especificação foi alterada. Desta forma,mesmo não havendo um documento escrito existe sempre uma estória que pede a alteração. Isso é suficiente para a rastrabilidade.
Não é possivel ter uma ambiente de testes correto numa metodologia tradicional. Simplesmente não funciona.
Se vc tem uma equipa competente, metodologia competente e gerencia competente sim vc consegue ter zero bugs e zero defeitos.
Não que eles não aparecem, mas que vc sempre os vai resolver antes da entregua.
Entregar software com defeitos ou bugs conhecidos é reserva mental. Punivel por lei e moralmente e profissionalmente inaceitável.
F
fernando.palma
Cara, acredite: até sistemas da microsoft e google contém bugs. Mesmo no coneito moderno: algo que realmente em determinada situação não funciona.
Repito: procure um analista de testes experiente e faça essa pergunta: é possível eliminar todos os bugs de um sistema?
R
rubensdemelo
Eu ja li aquele livro do Alexandre e do Emerson Rios, para a certificação da ALATS e até fiz a prova, mas não passei.
Uma coisa é você identificar o bug e deixar passar, outra coisa é não conseguir identificar e consequentemente não corrigir. É isso que a metodologia prega(ou não), os software não são livres de erros, porém o processo tem que garantir a menor quantidade possível, independente do impacto ou não.
Esse seu argumento de que a quantidade de usuários fará com que se sejam encontrados mais erros não me parece muito correto.
Imagine o cenário:
Um software que controla uma aeronave, se tiver um bug, por mínimo que seja, vai causar um grande impacto. Quantos usuário utilizaram este sistema? Piloto e co-piloto?
Ok, vamos para a web então, já que é um ambiente “palpável”:
No site da TAM ou GOL, tem uma passagem que é de 38,40 ao invés de 384,00. É um erro simples, um label incorreto, nada de grave. Imagine a quantidade de pessoas que acessam os sites para comprar passagens.
Um erro não deixa de ser erro pela quantidade de usuário que serão impactados. Erro é sempre erro, para 1000 usuários ou para 1.
Você vai negociar com o seu cliente essa qualidade?
S
sergiotaborda
fernando.palma:
quote
Um cliente que nao tem seus requisitos todos atendidos nao deveria pagar pelo produto. A tendencia é que as coisas mudem e os clientes fiquem cada vez mais exigentes, porque aos poucos eles vao tomando conhecimento de que esse “pessoal de informatica” adora uma papagaiada e nao resolve nada.
Eu não sei se eu entendi bem, mas vicê sugere que para todos os sistemas todos os bugs sejam corigidos? Você entende o custo disso?
[/quote]
O custo é zero se eles nunca existirem para começo de conversa. O problema não é a correção do bug, mas a sua existência.
Se o sistema tem 250 erros perto da homologação pelo cliente, despeça a sua equipe de desenvolvimento. A sua equipa de qualidade ou o seu gerente. Ou todos, já que é de uma incompetência incrivel todos deixarem as coisas chegarem nesse estado.
E já comparou com o custo de ele não existir ? O custo de resolver um bug que não existe é zero.
O fato é que software bem feito não tem bug. E não tem bug porque os desenvolvedores usam metodologias corretas para os evitar
e não porque existe uma equipa de testes.
claro, que , se todos as equipas de desenvolvimento usarem essas metodologias centenas de equipas de qualidade serão despedidas. E claro que eles não querem isso. Portanto eles têm que defender que é natural um software ter bug e farão de tudo
para isso seja verdade (até não alterar a especifcação para depois poder dizer que está errado)
E o seu gerente não despediu esses desenvolvedores incompetentes ? algum está errado nessa historia.
[quote]
O tamanho da aplicação e para o que ela será usada é importante sim. Se você produz bicicletas ou brinquedos para crianças, existem níveis de qualidade exigidos pelo inmetro. Se você produz aeronaves, os níveis são infinitamente maiores: cada equipamento dentro de um avião de voo doméstico tem nu mínimo duas redundâncias e níveis de testes extremos.
[quote]
outro erro comum de quem vive na antiguidade. Software não é produto industrializável. Essas normas do inmetro de que fala não se aplicam.
Nese tipo de software - se o cliente, o hospital, soubesse o que faz - faria auditoria de software independente. Isso é que é o correto.
Ou seja, a qualidade é medida por pessoas diferentes de quem o fizeram e de forma imparcial. Detalhes, para isso é preciso uma especificação ( ou seja, não vai funcionar porque a especificação nunca é completa)
Qualquer desenvolvedor profissional acha. E todos acham ainda mais :esses testes têm que ser automáticos (aka não precisamos de equipas de qualidade e redatores de especificações. Precisamos de desenvolvedores que saibam programar testes automáticos!)
F
fernando.palma
Rubens, todos os seus pontos foram sensatos. Achoq ue você postou um bom tópico:
Um software que controla uma aeronave, se tiver um bug, por mínimo que seja, vai causar um grande impacto. Quantos usuário utilizaram este sistema? Piloto e co-piloto?
Ok, vamos para a web então, já que é um ambiente “palpável”:
No site da TAM ou GOL, tem uma passagem que é de 38,40 ao invés de 384,00. É um erro simples, um label incorreto, nada de grave. Imagine a quantidade de pessoas que acessam os sites para comprar passagens.
Em TODOS estes casos o nível de qualidade deve ser grande, no caso da aeronave extremo. Eu realmente dei o exempo baseado em quantidade de usuários, mas não é a única variável. Talvez, seria melhor colocar a palavra piroridade do bug. Estes seus exemplos demonstram erros simples, mas de prioridade máxima. Não pode deixar passar.
Agora, se você está desenvolvendo um sistema para uso próprio (uma agenda, pro exemplo), imagino que o nível de testes e correção de erros será menor, sim?
Muito legal o nosso ponto de discussão, estou gostando…
Eu estou pegando um exemplo de quando eu testava sistema: um sistema com centenas de telas e funcionalidades que gerencia as solicitações de projetos para a infraestrutura de salvador. É comum sistemas maiores terem quantidades grandes de bugs, ou melhorias.
o custo existe. Existe uma tecnica de testes de inserir espaços em branco nos campos e tentar salvar. Isso pode gerar erro. É algo simples de corrigir, apenas usar “trin”, por isso se eu encontrar este erro em qualquer sistema eu mando voltar e corrigir. Mas, caso fosse algo custoso de corrigir, eu avaliaria: quem vai usar? Quantos usuários? Qual a probabilidade de alguém inserir espaços em branco? Qual seria o impacto disso? (no caso do avião o imacto é imenso).
Daí é realizada a comparação: custo de corrigir x custo do impacto caso ocorra x probabilidade de ocorrer.
Quando testamos aplicações grandes com infinitos fluxos, sempre existem bugs residuais que serão descobertos.
Rubens, todos os seus pontos foram sensatos. Achoq ue você postou um bom tópico:
Um software que controla uma aeronave, se tiver um bug, por mínimo que seja, vai causar um grande impacto. Quantos usuário utilizaram este sistema? Piloto e co-piloto?
Ok, vamos para a web então, já que é um ambiente “palpável”:
No site da TAM ou GOL, tem uma passagem que é de 38,40 ao invés de 384,00. É um erro simples, um label incorreto, nada de grave. Imagine a quantidade de pessoas que acessam os sites para comprar passagens.
Em TODOS estes casos o nível de qualidade deve ser grande, no caso da aeronave extremo. Eu realmente dei o exempo baseado em quantidade de usuários, mas não é a única variável. Talvez, seria melhor colocar a palavra piroridade do bug. Estes seus exemplos demonstram erros simples, mas de prioridade máxima. Não pode deixar passar.
Agora, se você está desenvolvendo um sistema para uso próprio (uma agenda, pro exemplo), imagino que o nível de testes e correção de erros será menor, sim?
Muito legal o nosso ponto de discussão, estou gostando…
Realmente a discussão está muito boa, muito saudável.
Atualmente estou desenvolvendo um sistema para a minha sogra, cadastrar pedidos dos clientes. Coisa simples, o famoso CRUD. Qual é o nível de qualidade que eu devo garantir? O que eu devo priorizar? Para ela, fará alguma diferença se um campo de CPF estiver com máscara ou não? Se o campo nome não tiver um limite de caracteres? Se o botão de incluir estiver desalinhado?
Uma coisa é garantir a satisfação do cliente, outra coisa é garantir a qualidade do software.
Eu garanto pra ela que o sistema vai incluir, alterar, exlcuir e emitir relatórios, porém não vou garantir a interface mais bonitinha possível.
E então, o meu sistema pode ser considerado um sistema de qualidade? Ou posso dizer que eu atendi as necessidades do cliente? Ou posso dizer que garanti a satisfação do cliente?
S
sergiotaborda
.
S
sergiotaborda
O ponto é :alguem especificou para o desenvolvedor que veria ser possivel salva campos com espaços em branco ?
Não ? Então não é defeito. Vc não tem nem sequer a opção de “mandar voltar”. O máximo que vc pode fazer é sugerir uma melhoria.
(esse conceito de mandar volta já errado para começo de conversa, mas pronto)
Esta é a melhor. Vc é só o tester. Quem é você saber a importância ou o impacto disso ?
Esta é uma caracteristica da equipe de qualidade. Acham que sabem tudo e têm poder de veto.
Essa responsabilidade é do gerente de projeto e do cliente , não é da equipe de testes.
Quando testamos aplicações grandes com infinitos fluxos, sempre existem bugs residuais que serão descobertos.
O que é isso ? uma desculpa ?
Não importa o tamanho da aplicação (não existem aplicações pequenas) . Competência é competência.
F
fernando.palma
O ponto é :alguem especificou para o desenvolvedor que veria ser possivel salva campos com espaços em branco ?
Não ? Então não é defeito. Vc não tem nem sequer a opção de “mandar voltar”. O máximo que vc pode fazer é sugerir uma melhoria.
(esse conceito de mandar volta já errado para começo de conversa, mas pronto)
Você está certo. Deveria estar especificado ou pelo menos em um banco de conhcimento da equipe.
Mas, caso fosse algo custoso de corrigir, eu avaliaria: quem vai usar? Quantos usuários? Qual a probabilidade de alguém inserir espaços em branco? Qual seria o impacto disso? (no caso do avião o imacto é imenso).
Daí é realizada a comparação: custo de corrigir x custo do impacto caso ocorra x probabilidade de ocorrer.
Esta é a melhor. Vc é só o tester. Quem é você saber a importância ou o impacto disso ?
Esta é uma caracteristica da equipe de qualidade. Acham que sabem tudo e têm poder de veto.
Essa responsabilidade é do gerente de projeto e do cliente , não é da equipe de testes.
Eu já fui analista de testes, mas hoje sou gerente de projetos. Neste expelo, estou me colocando como gerente de projetos.
Cara, acredite: até sistemas da microsoft e google contém bugs. Mesmo no coneito moderno: algo que realmente em determinada situação não funciona.
Repito: procure um analista de testes experiente e faça essa pergunta: é possível eliminar todos os bugs de um sistema?
Um bug só existe quando alguém o identificou, então é possível ter um sistema livres de bugs sim… basta corrigi-los!
F
fernando.palma
O que é isso ? uma desculpa ?
Não importa o tamanho da aplicação (não existem aplicações pequenas) . Competência é competência.
Bom, este ponto é abstrato para abordar, prefiro não colocar “lenha na fogueira”. mas existem sim, aplicações complexas que conterão bugs pro resto de usa existência.
F
fernando.palma
cara, não sei se esta semântica está correta. Acredito que um bug existe independente de ter sido encontrado. Mas vou rever este conceito, pode ser que você esteja certo…
S
sergiotaborda
fernando.palma:
O que é isso ? uma desculpa ?
Não importa o tamanho da aplicação (não existem aplicações pequenas) . Competência é competência.
Bom, este ponto é abstrato para abordar, prefiro não colocar “lenha na fogueira”. mas existem sim, aplicações complexas que conterão bugs pro resto de usa existência.
Apenas e só se ninguém procurar pelos bugs. Se vc procura e não encontra é porque não tem. bugs só existem quando identificados e reproduzidos, sim. A repetabilidade é condição sin qua non para que seja considerado um bug porque só bugs que podem ser repetidos podem ser resolvidos.
O erro é pensar como vc por que isso simplesmente leva ao desleixo. Vc não procura o bug vc deixa o bug ser encontrado. É diferente.
A metodologia de testes moderna obriga vc a procurar o bug. A exercitar o sofware de mil maneiras antes dele estar pronto para homologação. Estar testado e com zero bugs identificados é condição sin qua non para que o software seja considerado pronto e intergável.
qualquer coisa fora disto é desleixo, reserva mental ou falta de profissionalismo. Tudo razões para o contrato seja terminado , indenizações sejam pedidas e pessoas sejam demitidas.
S
sergiotaborda
Aahh! isso explica muitas coisas…
Vc tem duas opções , ou aprende a fazer direito ou desiste de ser gerente. O seu ponto de vista é totalmente retrógrado e ultrapassado.
S
sergiotaborda
Discord totalmente. Um bug não identificado é um BUG não identificado. Assim que encontrar, tem de corrigir e tomar medidas pra evitar que outro aconteça.
Percebem que a discussão é porque estão chamando de bugs a coisas diferentes?
Bug em si, o máximo que dá pra ser negociado é o prazo de entrega, se identificou 10 bugs, sendo 3 críticos e o cliente está precisando, poderia estudar liberar uma versão com a correção dos principais e deixar os mais demorados pra entregar em seguida.
Essa é a máxima tolerância que acredito que um software pode ter. Passar um bug batido acontece, tanto no Google quanto no Windows. Recentemente a MS corrigiu um bug do IE que tinha 9 anos!!
Cite um caso de bug num software do google. fiquei curioso …
Que os softwares da MS tem bugs não é novidade. E os têm exactamente porque a microsoft adopta a politica que vcs estãos defendendo - que é lícito enviar software com bug para o cliente.
Vc está confundindo “risco” com “erro”. Vc deixaria-se ser operador por um médico que comprovadamente deixa material de cirurgia
dentro do paciente em 1 de cada 10000 operações ? eu não deixaria.
É claro que existe o risco de qualquer médico fazer isso, mas a probabilidade é tanto menor quanto a qualidade e o profissionalismo dele.
O problema não é o erro acontecer , o problema é ele não ser corrigido e existem forma de os corrigir antes que aconteçam.
cenário 1: vc é operado e vai para casa . depois vc descobre que tem uma tesoura dentro si. Vc processa o hospital. O erro aconteceu e permaneceu.
cenário 2: vc é operado e o médico deixa a tesoura dentro de si. antes de vc da sala o material é contabilizado. É dado por falta da tesoura. Vc é aberto e a tesoura tirada. Vc vai para casa e sem problemas. O erro aconteceu mas foi corrigido a tempo. Ninguem é processado.
A analogia é simples: O software é vc, a tesoura deixada é o bug. O médico é equipe/empresa de desenvolvimento. contabilizar o material é boa prática. é isto que vcs não entenderam : se vc seguir boas práticas os defeitos entregues são ZERO. Isso não significa que não aconteceram, o sistema pode ter milhões de defeitos. quer dizer que TODOS foram corrigidos. Não tem essa de entregar o software com alguns erros. Seja 1 , 10 ou mil.
Entregar software com erros identificados é absolutamente imperdoável. O problema é que os clientes ainda não aprenderam a se defender disso. Eles não enxergam que podem processar a empresa que fez o software.
Qualidade de software é exigida mas não é verificada. Esse é o problema. E por isso ideias como as vossas ainda sobrevivem e é por isso que a produção de software atrai tantos picaretas anti-profissionais.
F
fernando.palma
Nunca aconteceu com você de tentar acessar o e-mail do google e dar erro?
Tem graça. Se vc chama isso é um bug , isso diz muitas coisas sobre você…
Isso não é um bug do software do google. Leia a noticia direito!
E não , nunca deu erro quando acesso o gmail (nem nenhum outro software ou api do google)
P.S. Pare de cria sobre-assinaturas. Use o recurso de assinatura…ah! vc já está usando… use direito.
F
fernando.palma
A indisponibilidade do sistema demonstra uma falha de requisitos não funcional. Disponibilidade é um requesito de qualquer sistema: não funcional.
Se ele ficou indisponível, ocorreu uma falha, que em GSTI nós chamamos de incidente. O software do google falhou.
Dei um ctrl + C no texto:
Ele acrescenta que estão tentando resolver o problema e esperam ter mais informação a respeito em breve.
Sugere ainda o uso de IMAP ou POP --para receber e-mails via softwares como Outlook Express, por exemplo-- enquanto o problema persiste.
O escritório do Google no Brasil informa que ainda não sabe a extensão, [size=18]tampouco a causa do problema[/size]. No entanto, a companhia diz que a instabilidade não atingiu todas as contas ao mesmo tempo. Alega que ainda há contas funcionando e que o retorno das outras será gradual.
O analista de pesquisas Júlio Boaro, da Escola do Futuro da USP, afirma que é nessa hora que percebe como depende da internet. “Todo o laboratório usa, é o e-mail padrão daqui”, diz ele. “Dá vontade de ir pegar o ônibus para ir embora, ou começar a arrumar papéis.”
Em fevereiro e maio deste ano, internautas também relataram dificuldades para acessar o e-mail do Google.
Ok, vou usar menos as assinaturas. Não quero infrigir regras da comunidade.
Alguém concorda/discorda que isto é uma falha de sistema? Independente da característica semântica da palavra “bug”.
Quando planejamos uma aplicação, devemos evitar falhas de requisitos não funcionais tais como performance, disponibilidade, segurança entre outros.
F
fernando.palma
Outros bugs do google:
-No inicio do orkut, ocorriam pagias de erro.
-Não sei se ainda ocorre hoje, mas as vezes o orkut dava um número de amigos/usuários de comunidade errado: enumera(va) 12 onde existe(am) 13 ou 14
[b]
Com o número de fãs isso sempre ocorreu.
Fernando, esse exemplo que voce postou nao tem nada a ver com o assunto que esta sendo discutido.
Como esta bem claro no texto, ninguem sabe o que aconteceu. E voce ja diz logo que é bug. Isto pode ser causado por n problemas. E ainda que sejam bugs, ninguem vai ser obrigado a daqui pra frente conviver com eles, porque um gerente qualquer gritou la da sala dele: “Ei, deixa isso assim mesmo. Isso nao é importante.”
Os erros acontecem, mas conhecendo o erro permitir que ele va pra producao é irresponsabilidade e descaso.
As tuas ideias beiram o absurdo, e o pior de tudo é que sao frequentes.
Eu nao uso produtos do google com tanta constancia pra dizer se é livre de bugs ou nao.
Sobre o Orkut, lembre de que ele nao foi feito pela Google, ele foi comprado e melhorou muuuuuuuito depois disso.
A
aleck
Aceitar que o sistema será entregue com uma % de bugs é o mesmo que aceitar a baixa qualidade da equipe técnica. Hoje existem metodologias e técnicas que impedem que erros de implementação ocorram.
Se basear no google ou em outro software open source não é correto, pois em sua grande maioria são criados por hobbistas e com o tempo vão amadurecendo até se tornarem aplicativos realmente a nível de produção, é só notar que o google normalmente coloca a palavra BETA nos aplicativos ainda novos.
Agora se uma empresa chega pra mim com um sistema CRUD e me coage a assinar um aceite eu no mínimo mudarei meu fornecedor.
S
sergiotaborda
Na boa, você claramente não sabe do que está falando.
Disponibilidade nunca é 100%. É esperado que possa existir falha (falha não é bug!!!) por isso se mede em percentagem.
A disponibilidade mede-se pelo tempo de disponibilidade sobre o tempo de funcionamento. Se o google ficou fora algumas horas , ou mesmo 1 dia. Isso é uma disponibilidade de (365-1)/365 = 99,73 % o que é muito bom. Teriamos que comparar com a disponibilidade
prevista para saber se houve incidente. Se o previsto foi 99% não houve. Se foi 99.9% houve. E repare que vc precisa de esperar 365 dias para concluir se houve ou não. Mesmo que tenha havido não é um bug do software. Disponibilidade é uma qualidade da aplicação! O software do google não falhou.
Na boa, se vc não sabes estas distinções básicas vc quer vir explicar como se testa software ? Assim não dá. Não de explicar o que não se sabe.
F
fernando.palma
Concordo!
F
fernando.palma
Teriamos que comparar com a disponibilidade
prevista para saber se houve incidente. Se o previsto foi 99% não houve. Se foi 99.9% houve.
Sempre que um sistema fica indisponível (indisponibilidade não prevista) é um incidente.. Incidente é qualquer evento que cause ou possa causar parada em um serviço de TI.
A comparação que você fez foi para saber se o nível de Acordo de Nível de Serviço foi ou não violado. Caso sim, pode existir uma multa contratual, pois o nível de serviço entregue foi abaixo do que foi acordado.
B
bobmoe
Discord totalmente. Um bug não identificado é um BUG não identificado. Assim que encontrar, tem de corrigir e tomar medidas pra evitar que outro aconteça.
você não entendeu… ninguém não pode falar que um sistema está bugado enquanto não tiver um erro para apontar! Portanto, aquelas pessoas com lama até o pescoço, virem com aquele papo “todo software tem bugs” pra cima de quem corrige e previne problemas é muita cara de pau!
[/quote]
Y
YvGa
marcosalex:
Ninguém está defendendo que bug não deve ser corrigido , mas se foi descoberto depois da entrega do cliente e a alteração demandar tempo, o tempo vai ter de ser trabalhado junto com as outras entregas.
Voce nao esta defendendo, o Fernando esta. Se foi descoberto depois da entrega é outra historia, e realmente pode demandar tempo. Mas se foi descoberto antes da entrega não pode ser ignorado.
F
fernando.palma
Eu também não estou entendendo porque eu defendo que bugs não devem ser corrigidos rsrs…
Fui analista de testes, gosto da área e sempre fui chato para encontrar e corrigir errros. Em momento algun eu defendi que bugs não devem ser corrigidos.
marcosalex wrote:
Ninguém está defendendo que bug não deve ser corrigido , mas se foi descoberto depois da entrega do cliente e a alteração demandar tempo, o tempo vai ter de ser trabalhado junto com as outras entregas.
Voce nao esta defendendo, o Fernando esta. Se foi descoberto depois da entrega é outra historia, e realmente pode demandar tempo. Mas se foi descoberto antes da entrega não pode ser ignorado.
O que eu estou expondo neste tópico é que a gestão deve tomar cuidado para identificar o nível custo x benefício de um projeto (sistema ou não sistema)
Existem balanças a serem equilibradas:
Qualidade x Custo
Reatividade x Proatividade
Se você pesar demais para um lado só da balança, você está errado. Investir em testes demais pode trazer mais custos (desnecessários). Corrigir certas falhas ou bugs (vamso deixar de lado a semântica das palavras), pode ser ineficiente. Você consegue visualizar isso?
Como o rapaz disse antes : erro de CRUD é inaceitável. Você tem que ser um bom gestor para fazer a balança parar no meio.
S
sergiotaborda
Você sabe porquê ? Porque todos os software feitos nos EUA têm uma cláusula de não inputabilidade, o que significa que se der merda vc não pode processar o fornecedor. O famoso “este software não é garantido para um terminado fim ou uso”.
Aqui , nunca vi essa clausula (porque é ilegal) o que significa que vc sim pode processar empresas que fizeram software que lhe causou prejuizo.
Vc está dizendo que erros não descobertos existem mesmo assim ?
Isso é uma falácia. Compare com “Aliens não descobertos existem” ou “Deus não descoberto existe” ou "Cidade perdida das antigas civilizações com capacidade de warp não descobertas, existem ".
Falha de lógica.
É inaceitável que se defenda a pior qualidade do software em vez da melhor qualidade. Inaceitável mesmo. Não importa se é o que todo o mundo faz. Eu não faço.
B
bobmoe
não existe isso de abrir mão de algo necessário, só pq já se fez muito. Se precisar tem que fazer.
F
fernando.palma
fernando.palma wrote:
Se você pesar demais para um lado só da balança, você está errado. Investir em testes demais pode trazer mais custos (desnecessários). Corrigir certas falhas ou bugs (vamso deixar de lado a semântica das palavras), pode ser ineficiente. Você consegue visualizar isso?
não existe isso de abrir mão de algo necessário, só pq já se fez muito. Se precisar tem que fazer.
Concordo “não existe isso de abrir mão de algo necessário, só pq já se fez muito. Se precisar tem que fazer.”. Acho que o Marcos está sendo mais pontual do que eu: “Ou estão interpretando errado ou distorcendo”.
O papel da gestão é justamente saber decidir sobre “o que é necessário”.
As balanças que eu falei são os pilares da gestão. Não só de TI.
F
fernando.palma
Acrescentando ao assunto, eu mesmo escrevo sobre o impacto dos bugs de software e o prejuízo de testar pouco ou não corrigir erros que devem ser corrigidos. Ex:
As balanças que eu falei são os pilares da gestão. Não só de TI.
Tais balanças são extremamente burocráticas e não condizem com o mundo real, pois teste é investimento e caso não ocorram na proporção necessária irão onerar o cliente no futuro, vide manunteções corretivas.
Uma equipe com desenvolvimento guiado a testes (tdd?) e um bom analista de testes na fase de homologação garantem sim uma cobertura de 100%, a menos que algo esteja errado no processo.
Erro técnicos de codificação(nullPointer) sequer devem chegar aos usuários, o analista de testes deve buscar erros de implementação como funcionalidade x ou y não condizer com o requisito do cliente.
Fico imaginando rios de dinheiro fluindo do bolso dos clientes em processos burocráticos e ineficientes quando leio tópicos como este.
F
fernando.palma
Cara, não existe 100%. É uma dos conceitos pré-liminares de qualidade e testes. Como você garante que 100% dos caminhos de um sistema “imenso” foram cobertos?
A depender do sistema e de seu porte, é como você garantir todas as possibilidades do jogo da mega-sena. Não é uma analogia exagerada. Existem infinitas possibilidades.
Ferramentas ajudam a cobrir os testes, mas nunca escutei dizer que alguma ferramenta garante 100%.
R
rubensdemelo
Aquele que garante um software livre de erros que atire a primeira pedra.
Quem conseguir garantir em 100% a cobertura dos testes está sendo, no mínimo, inocente.
Existem coisas que apenas os usuários são capazes de realizar.
M
mochuara
fernando.palma:
O papel da gestão é justamente saber decidir sobre “o que é necessário”.
As balanças que eu falei são os pilares da gestão. Não só de TI.
Aqui vai uma dica para o seu próximo blog post: Como tornar os gerentes necessários?
J
JavaLivros
Software é a projeção pelos requisitos desejáveis, o que acontece na implementação é que Bugs sistemicos pode ser fator de refatoração seja por novas especificações ao comportamento da VM ou seja por requisitos novos acrescentados ao dominio envolvido na criação do mesmo, uma coisa que achei interessante foi aPalestra do Paulo Silveira sobre TDD, acho que ele faz uma excelente abordagem e recomendo ver o video, pois na certa a forma que vocês estão aqui pensando esta bem equivocada, à chegar proximo do software ideial.
Vc está dizendo que erros não descobertos existem mesmo assim ?
Não, estou dizendo que não posso afirmar que não tem erro só porque você não achou. Novamente você parece nunca ter visto uma lista de bug fixes ou Service Pack. Se o cliente identificou um erro depois, significa que aquele programa estava com um erro.
sergiotaborda:
É inaceitável que se defenda a pior qualidade do software em vez da melhor qualidade. Inaceitável mesmo. Não importa se é o que todo o mundo faz. Eu não faço.
De novo, você está ditorcendo ou entendendo errado. Ninguém defendeu pior qualidade. Mas acho que você entendeu e por algum motivo obscuro está prolongando a discussão. Novamente, insisto pra você se relaxar. hehehehe
Nunca vi tanta besteira num topico so, % de bugs, meus deus!
Bugs são completamente diferente de problemas na especificação original do software. Seu processo que está 100% bugado!
J
JavaLivros
mochuara:
Bugs são completamente diferente de problemas na especificação original do software. Seu processo que está 100% bugado!
Não viaja se você não sabe o que é “especificação sobre o código começa ir atrás disso”, outra coisa bugs é fator de troca de informação entre codigos seja por algoritmos desalinhado seja por falta de fazer uma laminação correta sobre o mesmo.
Aquele que garante um software livre de erros que atire a primeira pedra.
Quem conseguir garantir em 100% a cobertura dos testes está sendo, no mínimo, inocente.
Existem coisas que apenas os usuários são capazes de realizar.
Comentário típico de quem acha que testar é navegar pelo sistema “clicando” nas telas.
Cobertura é algo muito simples, ou vc tem ou não tem, não existe essa de só o usuário consegue.
Sou o único aqui que acha que desenvolvimento de sistemas é uma ciência exata?
F
fernando.palma
Comentário típico de quem acha que testar é navegar pelo sistema “clicando” nas telas.
Cobertura é algo muito simples, ou vc tem ou não tem, não existe essa de só o usuário consegue.
Sou o único aqui que acha que desenvolvimento de sistemas é uma ciência exata?
Bom , se existe uma maneira de você testar um sistema ERP garantindo 100% de cobertura, então realmente eu que estou atrasado. Estou sendo sincero.
Não afirmei que é inexata. Mas TI é cada vez mais complexa. Não só em desenvolvimento de sistemas, mas como todo.
F
fernando.palma
Claro que testar não é só navegar (testes de caixa preta). Obviamente.
M
mochuara
JavaLivros:
mochuara:
Bugs são completamente diferente de problemas na especificação original do software. Seu processo que está 100% bugado!
Não viaja se você não sabe o que é “especificação sobre o código começa ir atrás disso”, outra coisa bugs é fator de troca de informação entre codigos seja por algoritmos desalinhado seja por falta de fazer uma laminação correta sobre o mesmo.
Sistema com “32% de bug não conhecido” pra mim é sinal que foi tempo gasto em estimativas e não em trabalho real. Eita informação inútil, nenhum analista de negócios esta preocupado com isso…
Se compartilhasse com a opinião dos gerentes de plantão eu procuraria uma forma de me congelar para o futuro porque atualmente não existe compilador de UML, ou de blablabla (e o marcio duran prova que ele esta distante). Software hoje em dia é executado por máquinas somente e ainda especificados por código portanto qualquer processo que afaste os programadores dos usuários e do processo de especificação do software, menor será as chances do processo da certo.
Existe um apelo gande entre o circulo dos “gerentes” por ferramentas pra especificar software e esse é um interesse que parte de um grupo de usuários que é legítimo. O que me impressiona é programadores acreditarem nessa utopia, ou então fingirem tao bem.
F
fernando.palma
rubensdemelo wrote:
Aquele que garante um software livre de erros que atire a primeira pedra.
Quem conseguir garantir em 100% a cobertura dos testes está sendo, no mínimo, inocente.
Existem coisas que apenas os usuários são capazes de realizar.
Comentário típico de quem acha que testar é navegar pelo sistema “clicando” nas telas.
Como você garante 100% das verificações/correções de especificação do software?
Fernando Palma
V
victorcosta
Galera tá viajando, acha que só porque faz TDD e passa todos os testes o software não tem bug. Acha que empresa decente corrige todos os bugs antes de lançar
Sejam realistas, é impossível não lançar um browser como o Chrome sem bugs, além de ser um programa altamente complexo ele vai rodar em uma variedade enorme de hardwares, sites, SOs, nenhum desenvolvedor vai conseguir criar teste pra simular tudo. Tem muito bug que eles não vão conseguir reproduzir ou vai demorar até descobrir o problema, até parece que vão deixar de lançar versão nova por causa disso
F
fernando.palma
Justamente. Estou impressionado com o fato de pessoas afirmarem que é possível encontrar e eliminar 100% dos bugs.
M
mochuara
victorcosta:
Galera tá viajando, acha que só porque faz TDD e passa todos os testes o software não tem bug. Acha que empresa decente corrige todos os bugs antes de lançar
Ninguém esta afirmando que TDD é a ultima palavra em exterminar bugs. Até porque desenvolver software livre de bugs não é o objetivo de ninguém. Meu não é, e o seu? Ninguém compra software porque é livre de bugs mas porque atende melhor as suas necessidades. Nesse aspecto se vc usa TDD é porque esta preocupado em desenvolver software de uma forma iterativa dando atenção a continuas melhorias no design.
Y
YvGa
Por favor, o pessoal da gerencia aí, nao queiram distorcer agora, como se estivessemos todos dizendo que bugs nao podem existir.
A discussao aqui é: qualidade de software é negociavel?
Ninguem esta dizendo que nao existem bugs, o que eu acho um absurdo, um caso de picaretagem, é voce saber que o bug existe e falar “ah deixa isso ai, isso nao eh importante.”
Um bug encontrado em producao tem que ser sanado o quanto antes, respeitando as prioridades do cliente, DO CLIENTE.
Nao é uma questao de semantica, voce considera tam em vez de TAM um bug? Voce considera 10 real em vez de 10 reais bug?
A
aleck
fernando.palma:
Como você garante 100% das verificações/correções de especificação do software?
1 - A menos que vc utilize um ciclo de desenvolvimento que siga o waterfall, vc pode sim demonstrar o resultado para o cliente a medida que as funcionalidades ficarem prontas, evitando o desgaste de refazer toda uma nova funcionalidade apenas pq alguem entendeu errado o que o cliente pediu.
2 -Correções só existem para funcionalidades que possuiam bugs, ou seja, não é o assunto em questão.
3 - Uma funcionalidade é constituida de uma método ou o agrupamento destes, se cobrirmos 100% destas funcionalidades em nossos testes podemos sim chegar aos 100%.
4 - Um sistema não se faz apenas por código e sim com processos bem definidos e capacitação das pessoas envolvidas neste. Um sistema para ser colocado em produção exige a dedicação e comprometimento de tais profissionais, caso algum destes não esteja capacitado ou desinteressado em gerar algo com qualidade, tudo vai por agua abaixo, seja utilizando metodologias ageis ou não.
5 - A maneira que você expoe os fatos, me parece que um sistema depende tão somente da parte burocratica para que seja entregue, e pior, entregue com qualidade aceitavel e não qualidade de verdade.
Entendo que nem todas as empresas possuem a coragem e colaboração de seus profissionais para entregar sistemas que realmente agreguem valor ao negocio e possuam baixo custo de manutenção, mas não é por isso que devemos aceitar esta realidade. A idéia é melhorar sempre e acho que é por isso que estamso discutindo este assunto.
F
fernando.palma
Entendo que nem todas as empresas possuem a coragem e colaboração de seus profissionais para entregar sistemas que realmente agreguem valor ao negocio e possuam baixo custo de manutenção, mas não é por isso que devemos aceitar esta realidade. A idéia é melhorar sempre e acho que é por isso que estamso discutindo este assunto.
aleck, achei que seu ponto de vista foi bem razoável, ao ocntrário de colocações meio “radicais” que observei este tópico.
Concordo. Quero isso. Mas não é simples, há momentos que devemos usar a balança, concorda?
Ou você defende a posição que quanto mais qualidade melhor?
A
aleck
fernando.palma:
Entendo que nem todas as empresas possuem a coragem e colaboração de seus profissionais para entregar sistemas que realmente agreguem valor ao negocio e possuam baixo custo de manutenção, mas não é por isso que devemos aceitar esta realidade. A idéia é melhorar sempre e acho que é por isso que estamso discutindo este assunto.
aleck, achei que seu ponto de vista foi bem razoável, ao ocntrário de colocações meio “radicais” que observei este tópico.
Concordo. Quero isso. Mas não é simples, há momentos que devemos usar a balança, concorda?
Ou você defende a posição que quanto mais qualidade melhor?
Acho apenas que a qualidade é proporcional ao custo em relação ao desenvolvimento inicial e a manutenção/melhorias.
Em relação ao custo do projeto a qualidade irá aumentar o custo total do projeto e em relação a manutenção e melhorias, a qualidade provavelmente irá diminuir este custo.
Além do mais, vejo que o tempo de vida de um sistema costuma ser maior que o tempo de desenvolvimento, então a manutenção ao meu ver pesa mais que o valor inicial de criação.
No meu ponto de vista este é o verdadeiro equilibrio, gastar mais para não ter dor de cabeça no futuro.
M
ManoJava
A discussão foi boa e pelo que vejo envolveu pessoas com conhecimento na prática sobre testes e qualidade de software, mas vemos que são opiniões variadas e que expressam diferentes pontos de vista sobre o que é qualidade, acho que o melhor a fazer é juntar os pontos positivos de cada um e chegar a um consenso sobre o que realmente é qualidade de software e se esses bugs residuais podem ser admissiveis em um sistema entregue ao cliente, gostei de todos os posts mas vejo que em alguns pontos as opiniões pessoais ofuscaram as profissionais e partiram para um lado meio ofensivo, mas entendo que discussões como estas envolvendo profissionais inseridos em projetos de grande porte sempre geram essas discussões calorosas, mas é pra isso q servem os fóruns né, então continuem discutindo que estarei acompanhando e tirando o melhor de cada post para aplicar no meu dia-a-dia.
Att.
F
fernando.palma
Em relação ao custo do projeto a qualidade irá aumentar o custo total do projeto e em relação a manutenção e melhorias, a qualidade provavelmente irá diminuir este custo.
Além do mais, vejo que o tempo de vida de um sistema costuma ser maior que o tempo de desenvolvimento, então a manutenção ao meu ver pesa mais que o valor inicial de criação.
Ok, estamos falando a mesma língua. Você se refere ao nível de confiabilidade, resiliência e sustentabilidade do sistema. Se mantemos níveis baixos achando que iremos economizar com isso, sofremos o efeito inverso: o prejuízo lá na frente é maior.
Quando falo das balanças, refiro-me a isso: quem coordena o projeto tem que identificar a qualidade que equilibre a balança e não traga maior custos lá na frente.
Quando eu dei exemplos lá em cima, pontuei: existem sistemas que eu desenvolvo internamente que serão utilizados por 3, 5 usuários em um determinado tempo. ex: contagem de votos de uma eleição.
Um sistema como este é utilizado anualmente e os profissionais já o conhecem. Certos investimentos não valem apena para este sistema. Mas claro: se tiver um bug que prejudique o trabalho eu corro para corrigir.
Em um contra exemplo, que eu também já dei: tenho um sistema que está entrando em produção SCRH. Será utilizado por todos os colaboradores. Qualquer problema, dúvida, mensagem que não esteja clara, fluxo não intuitivo. Qualquer ponto destes pode gerar um custo grade para o período de manutenção: centenas, milhares de chamados pro servicedesk. É claro que eu irei investir mais na qualidade deste sistema. Aqui eu não posso correr riscos
Concluindo a analogia: um campo obrigatório que não está sendo validado como obrigatório é um erro. Deve ser corrigido. Entretanto entre estes dois sistemas, o impacto deste defeito será muito maior no segundo exemplo: SCRH.
Aquele que garante um software livre de erros que atire a primeira pedra.
Quem conseguir garantir em 100% a cobertura dos testes está sendo, no mínimo, inocente.
Existem coisas que apenas os usuários são capazes de realizar.
Comentário típico de quem acha que testar é navegar pelo sistema “clicando” nas telas.
Cobertura é algo muito simples, ou vc tem ou não tem, não existe essa de só o usuário consegue.
Concordo inteiramente. como sempre o pessoal não desenvolvedor não tem a minima ideia de como se produz software hoje em dia.
Alguns estão dizendo que todos os softwares tem bugs e estão dando exemplo de software com bugs e correções posteriores. O que vcs não entenderam é que isso acontece porque o processo de desenvolvimento das companhias que desenvolvem esse software é falho. O sistema tem bugs não porque os desenvolvedores são estupidos ou porque é da natureza do software ter bugs e sim porque a companhia tem um processo falho.
Com o processo correto sim é possivel eliminar 100% dos bugs. Se o seu processo não garante isso, o problema é do seu processo.
Imaginemos uma central nuclear. Se algo dá errado , por minimo que seja, temos um efeito chernobyl. mas como testar os sistemas de segurança ? Não dá para deixar o nucleo explodir e ver no que dá. Ou seja, o usuário não pode sair usando para testar.
Teste é feito independentemente daquilo que o usuário faz e sim é possivel ter cobertura de todas as situações. É por isso que os testes têm que ser automáticos!
Testes são feitos diretamente no codigo, por codigo, para o codigo. Humanos falham, sobretudo em situações repetitivas , não queremos esse fator no teste.
E deixo sublinado mais uma vez :qualidade não é negociável. jamais. Qualquer processo, empresa ou pessoa que coloque a qualidade na mesa de negociação merece ser terminado… exterminado, porque isso sim é um grande bug.
Sim, é uma mudança de cultura. Mas só é necessária porque a cultura dominante atual é baseada em lacunas graves de metodologia, profissionalismo, valores e principalmente qualidade.
Um dos valores do desenvolvimento de software moderno é Respeito. É preciso respeitar o cliente, mas é preciso , principalmente respeitar os colegas de profissão. Caso contrário estamos lidando com mercenários aproveitadores. Esses simplesmente devem ser banidos.
F
fernando.palma
Bom eu já tentei demonstrar que não concordo, mas respeito seu ponto de vista.
Faço a mesmo pergunta: como garantir 100% dos testes para especificação? Como eliminar 100%? Sabemos que grande parte dos erros vêm da especificação.
Em um livro de testes de sofwtare de Leonardo Molinari ele exemplifica: por mais que você realize testes automatizados ou mecânicos, dificilmente cobrirá 100% dos testes de uma simples calculadora.
Pelo que eu entendi você está usando um conceito de qualidade mais moderno e radical que o meu. Qualidade para mim é planejada, mensurada e existem níveis. Nada impede de qu eeu mude de idéia um dia, mas eu preciso comrpeender o novo coceito e acreditar. no momento, acredito fiemlmente que a qualidade tem requisitos, variáveis e são negociáveis a depender do uso do produto/serviço.
Concordo plenamente. Sem tirar nem por. Espero que eu não esteja passando uma imagem contrária aesta sua afirmação.
F
fernando.palma
Quem conseguir garantir em 100% a cobertura dos testes está sendo, no mínimo, inocente.
Existem coisas que apenas os usuários são capazes de realizar.
Concordo com ressalvas.
Existem validações que não são para o usuário fazer. Você tem que garantir o cumprimento dos testes que mitiguem os riscos. Claro que nunca chegará a 100% (inisito).
Imaginem produzir um sistema que controla a temperatura de calderões quimicos de uma industira. Se esse sistema falha, o calderão explode e todos morrem.
Como utilizar pequenas entretas neste caso? Como deixar que o usuário valide? O desenvolvedor deste sistema tem que testar muito e estes testes (neste caso) são caríssimos.
F
fernando.palma
Procurei no google e achei algo sobre este pensamento sobre qualidade.
"Guilherme fala sobre os frameworks com a perspectiva de quem está no mercado de uma empresa referência da web brasileira e fala do que vive no dia-a-dia. Ele não tem motivos políticos para defender Ruby ou Python, ele fala da produtividade e da qualidade que encontra ao usar tais ferramentas. Sua frase mais forte, que nós da Ato gostamos é: ?Qualidade não é negociável?. Não adianta: ?faz qualquer coisa pra terminar mais rápido? ou ?faz qualquer coisa porque sai mais barato?. De novo: ?Qualidade não é negociável?. "
Pelo que eu entendi, a filosofia é contra o fato de entregar mais rapido e entregar a custo mais baixo. Quero deixar mais uma vez claro que não é esta a minha filosofia: manter bugs. Tente observar meus posts. Eu estou falando da balança: eu prevejo o custo no futuro e comparo com valores presente e tomo decissões.
F
fernando.palma
Conta pro Google e pra MS o segredo que você vai ficar rico
Estamos falando com o próximo Bill Gates! O cara que consegue liberar código sem nenhum bug, por maior e mais complexo que seja! Adeus Service Packs, adeus Bug Fixes!! Sergio Taborda rules!!
Pois é, Marcos.
Eu também fico assustado com afirmações deste tipo: “corrigir 100% dos bugs”
Conta pro Google e pra MS o segredo que você vai ficar rico
Estamos falando com o próximo Bill Gates! O cara que consegue liberar código sem nenhum bug, por maior e mais complexo que seja! Adeus Service Packs, adeus Bug Fixes!! Sergio Taborda rules!!
Pois é, Marcos.
Eu também fico assustado com afirmações deste tipo: “corrigir 100% dos bugs”
Vcs ficam assutados porque vcs não tenderam até agora. É normal as pessoas terem medo do futuro e do desconhecido.
Em vez de ficar lendo os dinosauros do teste de software leia sobre práticas ageis e principalmente - ja que é gerente - scrum.
Não faça waterfall, faça integração continua, automatize testes, incluia testes na equipa de desenvolvimento durante o desenvolvimento e terá melhores resultados. Especifique menos e dialogue mais.
O “segredo” não é meu. Não fui eu que inventei agile … .oO(damm! :lol: )
P.S Vc voltou a por sobre-assinaturas.
B
bobmoe
fernando.palma:
Conta pro Google e pra MS o segredo que você vai ficar rico
Estamos falando com o próximo Bill Gates! O cara que consegue liberar código sem nenhum bug, por maior e mais complexo que seja! Adeus Service Packs, adeus Bug Fixes!! Sergio Taborda rules!!
Pois é, Marcos.
Eu também fico assustado com afirmações deste tipo: “corrigir 100% dos bugs”
se foram identificados 10 bugs e corrigiram os 10, então temos 100%!
Não é o fato dele ser imune a defeitos, a questão é o estado em que o software se encontra.
F
fernando.palma
Vcs ficam assutados porque vcs não tenderam até agora. É normal as pessoas terem medo do futuro e do desconhecido.
Em vez de ficar lendo os dinosauros do teste de software leia sobre práticas ageis e principalmente - ja que é gerente - scrum.
Não faça waterfall, faça integração continua, automatize testes, incluia testes na equipa de desenvolvimento durante o desenvolvimento e terá melhores resultados. Especifique menos e dialogue mais.
Eu realmente não osu especialista em métodos de gestão ageis mais conheço sim. Posso afirmar sem falsa modéstia que sou disciplinado com estudos e gosto de estar atento para novas tendências.
O que eu e o Marcos estamos querendo dizer (pelo menos posso falar por mim) é que perfeição não existe independente do métdo. Não existe uma esfera perfeita. Não existem 100% de correção de bugs.
Vou me arriscar a falar um pouco de XP e Scrum mesmo não sendo especialista. Se falhar e algum ponto, por favor, me corijam.
Trazem vantagens para o usuário final, pois facilita mudanças de requisito. Usuário adora mudar requisito;
Traz motivação aos programadores, que não gostam de regras, metodologias e afins (exemplo aqui no fórum), puca documentação;
É agil, como o nome sugere;
Traz integração maior da equipe e menos hierarquia.
O que você precisa notar - acredito eu - é que existem projetos e projetos. Não posso confiar em XP e SCRUm em determinados projetos.
Outro ponto: o principal objetivo de quem está lá em cima e decide pro gestão agil é gastar menos. Este mantra do “qualidade ou existe ou não existe” é um motivador para a equipe. É o gatilho. Quem segue metodos ágeis repete isso como se fosse uma nova tendência, mas existem conceitos que não passam pro tendências, é fato.
Lembre do meu exemplo do inmetro: para diferentes produtos existem diferentes níveis de qualidade exigidos.
Lembro do exemplo do sistema do calderão: o nível de testes é caríssimo. Exige um planejamento de testes “macho”
Eu não uso cascata (waterfal) e tenho testes durante todo ociclo de via V MODEL. Tenho iteratividade om o cliente. Não uso automação no momento, mas já utilizei. No projeto que estou, em específico, ainda não foram implantadas ferramentas de teses, mas pretendo.
Essa sua sugestão não contradiz o facto de que “qualidade não é mensurável”, tão pouco prova que “é possível eliminar 100% de bugs de um sistema”.
F
fernando.palma
se foram identificados 10 bugs e corrigiram os 10, então temos 100%!
Não é o fato dele ser imune a defeitos, a questão é o estado em que o software se encontra.
Agora sim. Isso significa que eu corrigi 100% dos que encontrei. Até ai tudo bem.
S
sergiotaborda
A bem de quem está lendo vou corrigi-lo, mas se vc pensa o que escreveu vc não estudou o suficiente, por isto não é XP/Scrum é completo non sense.
As diferenças entre metodologia moderna e tradicional são :
Respeite valores acima de tudo.
A unica coisa que temos a certeza (absoluta) em relação ao software é que ele evoluirá.
Isto define o termo ágil. Ágil vem do facto do software mudar constantemente , portanto o processo de desenvolvimento tem que acompanhar essa mudança. Um processo Ágil é aquele que funciona mesmo quando o software muda.
A mudança de requisito é a tradução direta do que significa “evolução do software”. Ou seja, o usuário mudar o requisito não é a exceção, é a regra. Ele fará isso , e é bom que você aceite esse fato. Lutar contra ele não traz vantagem.
Portanto, esta não é uma vantagem, é a propria base para a definição do que é ser ágil. É aceitar a alteração de requisitos on-the-fly
completa palhaçada. Agil não significa desleixado ou preguiçoso. Sim ha documentação em processos ageis. Mas é tudo uma questão de saber qual documentação é util e qual não é. A primeira documentação , obrigatória , de um processo ágil é o código.
Código não escrito para funcionar é escrito para ser lido. Para ser lido por outras pessoas. Código limpo, bem programado, enxuto, bem comentado ( bem significa util não extenso)
A segunda é o manual do usuário.
Em scrum vc ainda tem os burndown charts e os backlogs. normalmente estes ficam em software.
Vc pode adicionar mais : modelos UML tb são aceitáveis. Mas podem ficar num quadro branco visivel a todos, não necessáriamente precisam ficar no word ou numa ferramenta case.
documentar não é escrever words! documentar é guardar informação de forma a poder de lida e consultada depois por qualquer um!
(abertura , outra cacaracteristica ágil)
Tautologia.
Ai que entram o valores. Respeito, abertura , comunicação, são os valores que tornam a integração maior naturalmente.
Quando as pessoas se entendem ha consenso. Com consenso não ha necessidade de hierarquia.
Isso é porque vc não sabe o que XP e Scrum são. Se soubesse vc não pensaria assim.
Aliás o seu raciocino é tipo de pessoas no lugar de gerente.
Eu acho que é porque vc acham que XP e Scrum matam a necessidade de gerentes. E vc tem razão.
Só que se a pessoa realmente entender de desenvolvimento ela assume um dos muitos papeis no XP/Scrum e continua trabalhando feliz como antes. Agora se a pessoa é um prevaricador ai sim é para ter medo mesmo porque essas pessosas têm os dias contados.
quem é agil não coloca a qualidade como parametro. Qualidade é para existir e ponto final. Não tem essa de “niveis de qualidade” porque isso - para uma pessoa que segue valores como abertura - é o mesmo que “niveis de falta de qualidade” .
Defender a qualidade não é algo de agile é algo de ser profissional. E apenas quem é profissional consegue seguir agile (porque só uma pessoa profissional consegue seguir valores doe a quem doer). Qualidade é um fim em si mesmo que tem que ser alcançado junto com a entregua do software. é o mesmo tipo de qualidade de que a ISO fala.
Testes são caros se forem mal feitos ou feitos no ponto errado do processo. Porque a metodologia tradicional os faz no lugar errado
eles são caros. Em agile se fazem mais testes,mais depressa,mais barato. E isso acontece porque são feitos testes diferentes em fases diferentes do processo. Um equivalente na linha de produção - para vc entender - seria : no método tradicional o produto é testado no fim da linha de montagem. No método ágil o produto é testado a cada passo da linha de montagem. Além disso cada componente dele é testado da mesma forma. E além disso temos tb o teste no final. Porque já foram feitos muitos testes durante o processo o teste final não precisa ser tão demorado, extenso ou caro como se ele fosse único. É a distribuição dos testes (automáticos) ao longo do processo que barateiam os testes e garantem menos defeitos no final.
O melhor ponto a favor de processos ageis não é a falha dos tradicionais,mas o sucesso dos ageis.
Empresas que falham usando processos ageis, falham porque não os implementam direito.
Ah! sim, isso é outra coisa que vc precisa entender : processos ageis se implementam, não se adoptam.
F
fernando.palma
Gostei dos seus pontos, entretanto existem alguns que eu já vi de perto e tenho lá minhas contra-indicações. Mas tudo bem.
Um equivalente na linha de produção - para vc entender - seria : no método tradicional o produto é testado no fim da linha de montagem. No método ágil o produto é testado a cada passo da linha de montagem.
Eu já te respondi isso lá em cima: não uso cascata. Testes devem ser realizados em todo o ciclo de vida do projeto. Eu falei até do V model.
você não precisa de gestões ágeis para ter esta vantagem. Modeo iterativo já existe há muitos anos na engenharia de software.
O que eu não consigo aceitar é que sistemas como o que eu exemplifiquei sejam tratados sem planejamento de testes e qualidade. Testes são caros sim, mesmo se executados durante todo o ciclo de vida. No exemplo do sistema do caldeirão eu vou pedir pro cliente fazer varias avaliações e ir evoluindo?. Eu tenho que ter um proceso de testes interno bom, sim, não da pra ele avaliar: se falhar todo mundo morre.
M
ManoJava
Concordo que 100% dos bugs na primeira entrega é complicado, mas como o Fernando disse existem bugs que podem ficar pra próxima entrega e tambem acho que as ferramentas case no processo de automação de testes podem auxiliar bastante e conferir mais confiabilidade e estabilidade ao sistema já na primeira entrega.
A discussão esta boa e acho que chegaremos a um ponto em comum.
Metodologia e automação de testes, explore mais essa funcionalidade!!!
Att.
Y
YvGa
Curioso como ninguem mais usa cascata hoje em dia. Alias, nao sei porque se fala tanto de processo em cascata se ninguem usa.
Diga pra nos entao, Fernando, qual processo voce usa.
E Marcos é possivel sim um software 100% livre de bugs, ou voce acha que software para a industria medica tem bugs pra todo lado? Software militares? entre muitos exemplos.
Ora, imaginem se esses pensamentos dos gerentes fosse tambem usado na engenharia.
O bug esta no pensamento arcaico da maioria dos gerentes, esta nesse processo pesado que nao funciona, nem nunca funcionou.
Talvez ainda nao seja, mas é um grande passo nesse caminho. Quem nao conseguiu diminuir sensivelmente o numero de bugs com agile, é porque esta usando de forma errada, ou seja embora pense que é, nao é agile.
F
fernando.palma
E Marcos é possivel sim um software 100% livre de bugs, ou voce acha que software para a industria medica tem bugs pra todo lado? Software militares? entre muitos exemplos.
Modelo Iterativo e Incremental
Estes softwares têm poucos bugs, mas nenhum é 100% confiável. Eles falham e vidas se perdem por conta disso. 100% não é tecnicamente possível, independente da metodologia ou competência profissional.
Veja alguns exemplos de sistemas que falham (sistemas deste nível):
Já respondi também a você que utilizo testes em todo o ciclo de vida de desenvolvimento: desde as verificações de especificação a testes de sistema em homologação interna e externa. Uso iteração e incremento sim. Entrego pequenas partes, buscando algumas vantagens que o modelo cascata não traz. No contrato que estou hoje, nçao vejo vantagem em aplicar gestão ágil e abidicar de documentações tradicionais. Mas isso é ponto de vista meu específico para este contrato, tenho minhas razões.
O que eu conheço de gestões ágeis é interessante, pretendo aprender mais e voltar a usar quando considerar que será viável. Não sou leigo como você classificou, muito menos especialista. Mas a metodologia não tem relação com sistema 100% livres de bugs. Acho que você está usando uma justificativa incoerente, por estar muito satisfeito com ela atualmente e resistente a outros pontos de vista.
Y
YvGa
fernando.palma:
E Marcos é possivel sim um software 100% livre de bugs, ou voce acha que software para a industria medica tem bugs pra todo lado? Software militares? entre muitos exemplos.
Modelo Iterativo e Incremental
Estes softwares têm poucos bugs, mas nenhum é 100% confiável. Eles falham e vidas se perdem por conta disso. 100% não é tecnicamente possível, independente da metodologia ou competência profissional.
Veja alguns exemplos de sistemas que falham (sistemas deste nível):
Exemplos de falhas nesse tipo de sistema nao diz que eles nao sao a prova de bugs, eles tem que ser a prova de bugs.
Isso voce ja disse, nao disse qual, nem como.
Voce consegue enumarar as razoes pra nao utilizar metodologias ageis no seu atual projeto?
É evidente que tem, por favor, essa uma afirmacao sem cabimento. A metodologia que voce usa influencia muito no resultado.
F
fernando.palma
Já respondi também a você que utilizo testes em todo o ciclo de vida de desenvolvimento: desde as verificações de especificação a testes de sistema em homologação interna e externa. Uso iteração e incremento sim.
Isso voce ja disse, nao disse qual, nem como.
Iterativo.
Entrego pequenas partes, buscando algumas vantagens que o modelo cascata não traz. No contrato que estou hoje, nçao vejo vantagem em aplicar gestão ágil e abidicar de documentações tradicionais. Mas isso é ponto de vista meu específico para este contrato, tenho minhas razões.
Voce consegue enumarar as razoes pra nao utilizar metodologias ageis no seu atual projeto?
Quando você toma decisões em certos contratos muitas coisas são levadas em consideração. Não da para sair mudando tudo s´´o porque eu tenho idéias que considero boas. Não estou falando de gestão ágil, estou generalizando.
Mas a metodologia não tem relação com sistema 100% livres de bugs. Acho que você está usando uma justificativa incoerente, por estar muito satisfeito com ela atualmente e resistente a outros pontos de vista.
A diferença do cascata para um iterativo é que em cascata você corrige no final, levando a um custo maior de correção. Mas, em ambas betodologias, a mesma quantidade de erros é corrigida.
O que garante corrigir mais bugs é a automação, competência, expertise no assunto. Não a metodologia: agil ou cascata. Gestão ágil não corrige mais, simplesmente corrige de uma maneira mais eficiente e menos custosa.
S
sergiotaborda
quer ver como isso é mentira ?
Como sua equipa automatiza testes ? Vc tem testes unitários ? Vc usa um servidor de integração ? Qual é a politica de prioridade de correção de testes vs implementações de outra especie ? Quanto demora um ciclo de testes feito na estação do desenvolvedor ? e no servidor de continuidade ? vc usa o maven ou ant para explicitar o empacotamento ? Vc tem servidor de desenvolviemento ? e de homologação ? e de ensaio ? Quantos bugs a sua equipa corrigiu entre o primeiro e vigésimo dia do projeto ?
Humm… isso quer dizer que o seu processo é baseado nele.
:lol: :lol: :lol: só para vc entender o que passa pela nossa cabeça quando um gerente diz isso:
“Eu sei nada de desenvolvimento, então tenho que mostrar trabalho entegando um monte de documentos word que ninguem lê e só enchem linguiça, mas eu sou pago para isso mesmo” - não necessáriamente nestas palavras.
Sinceramente, o que vc conhece é zero, nada.
Não ha o que discutir. É sempre viável. Basta que vc saiba como e tenha vontade de usar!
quantas vezes vc já usou um processo ágil no seus projetos ? nunca ? então como sabe que não funciona melhor ?
10 vezes ? 2 vezes ? então porque vc demonstra não saber nada sobre processos ageis ? Das duas uma. ou vc nunca usou, ou vc não quer nunca usar.
Se é a segunda opção, boa sorte arranjando emprego daqui a 5 anos. Se é a primeira, tente usar nos seus proximos projetos (todos eles). A gente ajuda nas duvidas.
É obvio que tem. Mas exatamente porque não é óbvio para si é que vc é gerente.
Quando o seu superior descobrir o rio de dinheiro que está perdendo , ai vc mudará de opinião…
Y
YvGa
A diferença do cascata para um iterativo é que em cascata você corrige no final, levando a um custo maior de correção. Mas, em ambas betodologias, a mesma quantidade de erros é corrigida.
O que garante corrigir mais bugs é a automação, competência, expertise no assunto. Não a metodologia: agil ou cascata. Gestão ágil não corrige mais, simplesmente corrige de uma maneira mais eficiente e menos custosa.
Nao, com TDD, por exemplo, muitos dos erros que fazem todo mundo ficar estressado, cliente ligando, gerente reclamando, programador pedindo a conta, NAO SAO introduzidos, por que existem testes para eles antes mesmo das funcionalidades deles serem escritas.
E outra, gestao agil é car…, nao existe gestao agil, existe desenvolvimento agil, ou voce participa dele ou nao. O Sergio esta coberto de razao quando diz que os gerentes de hoje estao com os dias contados. Ou se atualizam e acompanham os desenvolvedores ou tao fora.
Infelizmente agile é um processo que só acontece de baixo pra cima, só os desenvolvedores conseguem introduzir agilidade numa empresa. Ela nao vem de cima pra baixo.
Por isso discutir com um gerente sobre isso é pura perda de tempo, a nao ser que seja o seu gerente obviamente (e mesmo nesses casos é muito dificil).
F
fernando.palma
Opa, vamo lá.
Nao, com TDD, por exemplo, muitos dos erros que fazem todo mundo ficar estressado, cliente ligando, gerente reclamando, programador pedindo a conta, NAO SAO introduzidos, por que existem testes para eles antes mesmo das funcionalidades deles serem escritas.
Eu sei que a técnica evita erros, por implementar funções de testes antes do código. No meu tempo de analista de testes eu ja lia sobre Programação orientada a Testes, isso foi em 2006. Mas caso você não aplique TDD, irá ter mais custo para corrigir depois.
Portanto, você ganha na eficiência e não eficácia. Você corta o mal pela raiz, o que o waterfull não faz. Mas o waterfull também chega com um sistema bonitinho, redondinho com poucos erros no final, só que em mais tempo e maior custo.
Gestão Ágil é uma expressão utilizada. Não precisa de tanta resistência ao ler a palavra Gestão. Calma.
Cara, acho que este tipo de afirmação pode soar meio “prepotente” entene?. Parece um desafio entre profissionais: um querendo engolir o outro. Em uma equipe, precisamos com skills diferenciados sim.
Existem pessoas que dizem que os programadores estão com dias contados, porque código cada vez mais é gerado automaticamente. Eu acho bobagem também e tenho contra-argumentos pra este tipo de afirmação. Eu acredito que dificilmente um profissional qualificado está com dia contato, independente de sua área de atuação. Não é impossível, mas é dificil que ele seja eliminado, caso tenha competência e conhecimento constantemente atualizado.
Concordo com você com o fato que devemos estar atualiazados. Eu não estou aqui para perder tempo, estou acompanhando, conversando com profissionais que - talvez - tenham pensamentos parecidos com os das equipes em que trabalho(lharei). Li o material que você me passou, foi legal.
E já que tocou no assunto: acredito também que os profissionais pagos cada vez mais para pensar em vez de operacionalizar.Independente de ser programador ou diretor.
E não, administração não será facilmente anulada, porque é mais complexo de automatizar. Toda atividade precisa ser organizada, medida, para obter informações que comprovem se o processo está sendo eficaz, eficiente, lucrativo.
Toda equipe precisa de um facilitador, que interaja com outras equipes. Até em um prédio existe um síndico. Em uma manifestação, um líder.
Precisamos de um responsável por uma equipe, um setor, etc. Alguém que reprte e responda.
Nas atividades que envolvem processos de construção (TI ou não TI), tais como engenharia, é preciso de um profissional com expertise em medir, controlar, reportar resultados, tomar decisões rapidas e eficazes e chegar à conclusão de se e o quanto a equipe está encontrando resultados. Sim, os indicadores, números e gráficos não vão acabar facilmente. Acredite, por mais absurdo que te pareça, eles têm utilidade! .
Tenho que admitir, este fórum é divertido
A
aleck
Fernando,
sem querer ofender, você deveria ler algum livro sobre Scrum e Lean, lhe ajudariam muito como gerente.
Concordo também com o que foi dito sobre agile vir de baixo para cima, porém já vi gerentes darem o pontapé inicial. Quem sabe você se torna um deles e começa a escrever artigos sobre o assunto voltado para empresários?
Ser ágil é mais do que utilizar uma metodologia ou técnica, é uma mudança de comportamento dos profissionais.
Recomendações:
F
fernando.palma
Concordo também com o que foi dito sobre agile vir de baixo para cima, porém já vi gerentes darem o pontapé inicial. Quem sabe você se torna um deles e começa a escrever artigos sobre o assunto voltado para empresários?
Ser ágil é mais do que utilizar uma metodologia ou técnica, é uma mudança de comportamento dos profissionais.
Ok, sugestão aceita. Estava apenas abordando alguns pontos, mas me interesso sim.
A certificação SCRUM está no meu calendário entre as que almejo. O papo com vocês é ótimo.
Me diga: vocês trabalham em São Paulo?
F
fernando.palma
Ah, claro: obrigado pelos links!
Y
YvGa
fernando.palma:
Opa, vamo lá.
Gestão Ágil é uma expressão utilizada. Não precisa de tanta resistência ao ler a palavra Gestão. Calma.
Nao tenho nada contra gestao, tenho e muito contra a forma burocratica utilizada por muitos que se dizem gestores e nao tem a menor ideia do que estao fazendo.
Nao, nao eh um desafio entre profissionais. Nao é uma questao de “eu sou importante, voce nao é”. Um bom gerente é importante, mas o que é um bom gerente é muito diferente do que se tem hoje por ai. A principal funcao de um gerente é administrar a equipe, nao o produto. Tem que saber cortar as asas de alguns desnvolvedores quando algo comeca a fazer mal a equipe, tem que incentivar o desenvolvedor quando ele precisa. Tem que administrar a briga de ego dentro da equipe. Tem que saber identificar a hora certa de fazer tudo isso.
Tem que saber se impor e dar a palavra final ao cliente quanto aos prazos estipulados pelos desenvolvedores, tem que saber como e o que cobrar da equipe, mas sem forçar demais e fazer a equipe trabalhar sob estress, porque programador sob pressao é bug na certa. É funcao do gerente saber se um desenvolvedor esta sobrecarregado e porque, identificar os que rendem menos, descobrir porque e fazê-lo render mais (sem chicotada, nem ameaca de demissao obviamente).
O que não é função do gerente: Fazer planilhas e graficos pra mostrar a diretoria o andamento do projeto. Se o andamento do projeto nao pode ser visto em funcionamento tem algo errado. Ficar trancado numa sala mandando conversando com a equipe por email ou skipes da vida, o gerente tem que estar proximo a equipe, do contrario nao vai saber se eles precisam de algo, nao vai saber se tem dificuldades, nao vai saber se estao insatisfeitos.
Não é funcao do gerente de modo algum tomar decisoes tecnica, essa é funcao da equipe e somente dela. A nao ser evidentemente que o gerente tenha conhecimento tecnico. Mas conhecimento tecnico profundo, que tenha vivencia na parte tecnica, nao experiencia de artigos aqui e ali. Alias desenvolvimento de software, se nao a unica, é uma das poucas areas em que é frequente pessoas sem o menor conhecimento tecnico tomarem decisoes tecnicas. E isso é invariavelmente desastroso.
Bom isso é uma utopia dos empresarios, mas nao vai acontecer nunca. Nao existe criar software sem conhecer logica e conhecendo logica profundamente voce se torna programador. Entao antes de poder usar as ferramentas dos sonhos, em que pensa software de um lado e sai software do outro, vao precisar aprender a pensar com logica, logo serao programadores. Bom, eu pelo menos sonho com uma ferramenta dessas, mas duvido que va ser tao util a quem a tanto deseja hoje.
Pensar, eu penso até no boteco e nem por isso ninguem me paga por esses pensamentos. Os profissionais sao pagos para fazerem as coisas funcionarem, nao pra pensar. Se voce é criativo e acha boas maneiras de fazer as coisas funcionarem, ótimo. Se nao seus pensamentos nao servem pra nada.
E não, administração não será facilmente anulada, porque é mais complexo de automatizar. Toda atividade precisa ser organizada, medida, para obter informações que comprovem se o processo está sendo eficaz, eficiente, lucrativo.
Toda equipe precisa de um facilitador, que interaja com outras equipes. Até em um prédio existe um síndico. Em uma manifestação, um líder.
Precisamos de um responsável por uma equipe, um setor, etc. Alguém que reprte e responda.
Nas atividades que envolvem processos de construção (TI ou não TI), tais como engenharia, é preciso de um profissional com expertise em medir, controlar, reportar resultados, tomar decisões rapidas e eficazes e chegar à conclusão de se e o quanto a equipe está encontrando resultados. Sim, os indicadores, números e gráficos não vão acabar facilmente. Acredite, por mais absurdo que te pareça, eles têm utilidade! .
Tenho que admitir, este fórum é divertido :)
Pois é, eu concordo que é preciso lideranca, expus acima como acho que deve ser um gerente.
No mais, seu discurso é de muita retorica, clichês, frases feitas e nada de profundidade, nada consistente. Voce nao traz exemplos, nao mostra suas “estatisticas”, nao cita onde baseia suas fontes, em quais experiencias, quais metodologias utiliza. Nao nos da detalhes que tragam clareza a suas ideias.
Tudo retorica, aquele monte de frases que a gente ouve todo dia em propagandas de consultorias administrativas. De pratico, de conclusivo? Nada.
F
fernando.palma
fernando.palma wrote:Opa, vamo lá.
Gestão Ágil é uma expressão utilizada. Não precisa de tanta resistência ao ler a palavra Gestão. Calma.</blockquote>
Nao tenho nada contra gestao, tenho e muito contra a forma burocratica utilizada por muitos que se dizem gestores e nao tem a menor ideia do que estao fazendo.
Blz…
ok, massa. O lider é um facilitador.
Tem que saber se impor e dar a palavra final ao cliente quanto aos prazos estipulados pelos desenvolvedores, tem que saber como e o que cobrar da equipe, mas sem forçar demais e fazer a equipe trabalhar sob estress, porque programador sob pressao é bug na certa. É funcao do gerente saber se um desenvolvedor esta sobrecarregado e porque, identificar os que rendem menos, descobrir porque e fazê-lo render mais (sem chicotada, nem ameaca de demissao obviamente).
Ou seja: solucionador de probelmas. facilitar a vida da equipe e do cliente.
Não concordo com a primeira parte, concordo com a segunda. indicadores são importantes. Se você não mede, você não pode controlar (já sei, vc vai responder que é frase feita, mas é isso)
To contigo também nesse parágrafo. Eu não corrijo nem tomo decisão em cima de uma atividade que eu nunca fiz. Acho incoerente. Eu delego.
Bom isso é uma utopia dos empresarios, mas nao vai acontecer nunca. Nao existe criar software sem conhecer logica e conhecendo logica profundamente voce se torna programador. Entao antes de poder usar as ferramentas dos sonhos, em que pensa software de um lado e sai software do outro, vao precisar aprender a pensar com logica, logo serao programadores. Bom, eu pelo menos sonho com uma ferramenta dessas, mas duvido que va ser tao util a quem a tanto deseja hoje.
Eu digo mais que isso: sempre existirá um gap onde os desenvolvedores deverão interpretar o código. além do facto de que as ferramentas produzidas hoje ainda durarão anos para entrar em extinção. Como eu te disse lá em cima, eu tenho argumentso para discordar também. O qu eeu acho que está mudando é o perfil do desenvolvedor.
Um amigo meu até me disse outro dia: criatividade é coisa de pobre. Você tem que pensar e saber aplicar. Mais que isso: aplicar rápido, antes que seja tarde. Mas nós somos exigidos cada vez mais a pensar em vez de trabalhos mecênicos (já se foi a era industrial)
No mais, seu discurso é de muita retorica, clichês, frases feitas e nada de profundidade, nada consistente. Voce nao traz exemplos, nao mostra suas “estatisticas”, nao cita onde baseia suas fontes, em quais experiencias, quais metodologias utiliza. Nao nos da detalhes que tragam clareza a suas ideias.
cara, fraes feitas tb vejo quando vc defende desenvolvimento ágil (ta vendo, não usei a palavra gestão).
Eu venho aqui no fórum responder rapidamente e olhe que eu não costmo escrever pouco. Se eu não utilizar frases resumidas que já tenho de cabeça, vou ter que parar pra escrever um artigo.
Isso não ficou claro para mim… Há anos atrás quando trabalhei em fabrica usei CMMI. Hoje gerencio projetos com base no PBMBOK, uso praticas de gestão do governo (meu projeto é estadual) e modelo de desenvolvimento bem iterativo. Uso alguns conceitos de A ISO/IEC 12207 no processo que desenvolvemos recentemente de desenvolvimento. Entretanto, no modelo que trabalho hoje, não tenho uma estrutura de desenvolvimento estritamente CMMI ou SCRUM. Não uso um padrão de mercado, uso o meu padrão. Você já trabalhou alcado em cliente do estado? Não se se foi bem essa sua pergunta…
Abraços !
Fernando Palma
F
fernando.palma
As diferenças entre metodologia moderna e tradicional são :
Respeite valores acima de tudo.
A unica coisa que temos a certeza (absoluta) em relação ao software é que ele evoluirá.
Eu gostaria de uma opinião dos membros da comunidade. Vocês acham que outros métodos e padrões vão contra a essas filosofias. Ou seja: não respeitam valores e não reconhecem que o softwrae evoluirá.
Não pergunto para causar polêmica. Apenas quero uma opinião sincera para ter noção do que todos pensam.
Já conhecia estas frases sobre metodologia ágil, sei que existem fundamentos como base para estas afirmações. Mesmo assim, gostaria de que participassem. Considero interessante o tema.
S
sergiotaborda
O problema é que a grande maioria das pessoas que ocupam o cargo de “gerente” não têm nenhum skill na área de desenvolvimento. Têm muitos na área de manter a sua posição e repassar culpa para a equipe de desenvolvedores e acatar os desejos do cliente mesmo contra os interesses do projeto, da companhia ou da equipe. Esse tipo de gerente está em via de extinção.
Ai é que você se engana. Pode ser complexo de automatizar mas é muito simples de eliminar.
Administração de projeto tradicional gera custos e delays (que geram custos) que as empresas espertas estão aprendendo a eliminar. A gordura de um projeto é causada pela existência da figura do gerente. E isto as empresas espertas estão aprendendo a enxugar.
Sim, mas não precisa ser pelo gerente. Equipas auto-gerenciadas é a forma mais barata de alcançar os mesmos resultados e até melhores.
É verdade que a equipa precisa de um facilitador. Mas repare : não precisa que o facilitador seja hierarquicamente superior à equipe. É aqui que a porca torce o rabo. O Gerente pode assumir o papel de facilitator (Scrum Master) ou de Product Owner fácilmente , mas não os dois (como é comum hoje em dia). O problema é que os gerentes não suportam a ideia de serem rebaixados para o mesmo nivel dos desenvolvedores sem terem sobre eles poderes de comando.
Nas metodologias modernas existe cooperação - como numa colmeia - e não comando - como no exercito.
Esta é outra coisa que os gerentes tradicionais não entendem. A equipe é responsável por si mesma. Ela responde em unissono.
Não existe porta-voz. Existe respeito. coisas como codigo partilhado, e pair programing não entram na cabeça dos gerentes tradicionais, mas são a forma de responsabilizar todos os membros da equipe pelo que é produzido. Cada papel da equipe é responsável pela parte que lhe cabe. sem desculpas. Se a pessoa tem algum problema é discutido com o Facilitador e a partir dai a responsabilidade é dele.
Só que produzir software não é um processo de construção. Portanto nada disso se aplica.
Enquanto vc não entender isto, vc não conseguirá entender as metodologias modernas.
é preciso que algum membro deste forum tenha vivido isolado do planeta nos ultimos 10 anos ou não tenha experiencia com desenvolvimento, para acreditar que alguma coisa do que vc está dizendo faze sequer sentido, quanto mais usá-lo para algum fim util. As metodologias tradicionais estão mortas. Quem não enxergar isso morrerá com elas.
Implatar Metologias modernas requer uma mudança de cultura, de paradigma, a aceitação de valores e axiomas diferentes daqueles da metodologia tradicional. Mudar de paradigma é extremanente dificil, portanto utilizar metodologias ageis não é possivel do dia para a noite e não é facíl.
S
sergiotaborda
Essa desculpa de seguir o CMMI não cola. CMMI não diz como vc deve chegar nos niveis,Ele apenas diz quais são os niveis.
por exemplo: se o processo é gerenciado, temos um certo nivel. Mas não difinitivo o que significa "gerenciado’.
Gerenciado não significa ter um Gerente. Isto é um erro grave. Com Scrum vc tb tem um processo gerenciado e com mais e melhores indicativos que qualquer outra estrutura de gerenciameno.
O problema de trabalhar para o governo é outras historia. As pessoas no governo que pedem esses trabalhos têm a mesma visão obtusa que os gerentes tradicionais e por isso eles pedem garantias tradicionais.
quando o mundo do sfotware for agil os governos tb serão (é uma questão de tempo até que esses cargos seja ocupados por pessoas que pensam agil)
F
fernando.palma
“Passar a culpa para desenvolvedores” é algo que deve ser banido. 90% dos casos a culpa é da gestão.
Eu entendo seu ponto, mas não é bem assim. Difícil sobreviver sem este papel. Só esperando para ver.
Sim, mas não precisa ser pelo gerente. Equipas auto-gerenciadas é a forma mais barata de alcançar os mesmos resultados e até melhores.
Ok, temos opiniões diferentes. Eu não sobrevivo sem um superior a quem passar certas decisões. Há não ser que eu seja sócio único da empresa. Eu posso até mudar de opinião um dia, não descarto a possibilidade.
Sim, até ai tudo bem. É como os modelos de gestão japonesas de cooperação, já abordavam menos hierarquia, com esta metáfora da colmeia . Isso já tem anos.
Esta é outra coisa que os gerentes tradicionais não entendem. A equipe é responsável por si mesma. Ela responde em unissono.
Não existe porta-voz. Existe respeito. coisas como codigo partilhado, e pair programing não entram na cabeça dos gerentes tradicionais, mas são a forma de responsabilizar todos os membros da equipe pelo que é produzido. Cada papel da equipe é responsável pela parte que lhe cabe. sem desculpas. Se a pessoa tem algum problema é discutido com o Facilitador e a partir dai a responsabilidade é dele.
Bom, eu tenho que viver mas na prática para entender como funciona. Leio a respeito e vejo estes ponto, mas entendo que certas atividades exigem um repsosável para que funcione.
Única vez que usei métodos ágeis não apliquei com a experiência que você e outros demonstraram ter aqui. tenho que ver de perto para entender melhor como iso dá certo.
Eu acredito que você está com um pouco de entusiasmo com o tema. Práticas novas surgem todos os dias, quando estudamos e praticamos tendemos a não enxergar outros pontos de vista. O entusiasmo.
Me responda uma pergunta: quais são as desvantagens das metodologias ágeis? Em que casos elas terão dificuldades de ser utilizadas?
Ok.
.
F
fernando.palma
Essa desculpa de seguir o CMMI não cola. CMMI não diz como vc deve chegar nos niveis,Ele apenas diz quais são os niveis.
por exemplo: se o processo é gerenciado, temos um certo nivel. Mas não difinitivo o que significa "gerenciado’.
Gerenciado não significa ter um Gerente. Isto é um erro grave. Com Scrum vc tb tem um processo gerenciado e com mais e melhores indicativos que qualquer outra estrutura de gerenciameno.
O problema de trabalhar para o governo é outras historia. As pessoas no governo que pedem esses trabalhos têm a mesma visão obtusa que os gerentes tradicionais e por isso eles pedem garantias tradicionais.
quando o mundo do sfotware for agil os governos tb serão (é uma questão de tempo até que esses cargos seja ocupados por pessoas que pensam agil)
A Fábrica era nível 3. Era um pré-requisito dos softwares. Se o mundo se tornar software ágil, ótimo, trabalharemos assim em projetos de todos os tipos (se eu ainda estiver trabalhando com desenvolvimento de software. Mas como eu disse; cuidado com o entusiasmo (é meu ponto de vista)
S
sergiotaborda
As desvantagem são politicas. Agil não funciona dentro de uma cultura militar. Não funciona quando as pessoas não sabem se responsabilizar perante as outras. Quanto todo o mundo é mestre em “tirar o seu da reta” não funciona. quando a equipe não é realmente uma equipe mas um conjunto de pessoas, não funciona. quando não existe um responsável pelo produto, não funciona.
Quando não existe um facilitador - que seja uma pessoa diferente do responsavel pelo produto - não funciona. Quando os valores não são aceites no coração dos membros não funciona. Quando as pessoas envolvidas não entendem o que estão fazendo nem o pq, não funciona. Quando o cliente tem sempre razão, não funciona. Quando a documentação de ha 6 meses vale mais que a palavra do desenvolvedor, não funciona. Quando a equipa de desenvolvedor não se pode auto-gerenciar, não funciona.
quando alguém teima em cotar as coisas em horas-homem não funciona. Quando não se deixa os desenvolvedores desenvolverem, não funciona. Quando não se entende o que é um Story Point, Velocidade,Fator de Foco e a diferença entre Estoria e Tarefa não funciona.
A desvantagem principal é que existe uma mudança de paradigma que é complexa e difícil se as pessoas não estão preparadas, e o processo de implantação deixa bem claro quem está preparado e quem não está. Isso pode levar a diversos problemas politico-hierarquicos.
“Preparadas” significa podem acatar valores como respeito, abertura, comunicação, etc… Por exemplo, às vezes o cara quer usar Scrum, mas não quer publicar um burndown chart. Ou seja, ele não está sendo aberto, logo está fazendo reserva mental ao não acatar esse valor. Esta pessoa não está preparada para usar Scrum.
Então, quando as pessoas não estão preparadas a implantação de agil não cola e fica a impressão que a culpa é do agil, mas a culpa é na realidade das pessoas que não conseguem seguir valores simples como respeito e abertura, entre outros…
J
JavaLivros
Falando em Técnicas de Test de Software e voltando ao assunto.
P
peczenyj
sergiotaborda:
fernando.palma:
Me responda uma pergunta: quais são as desvantagens das metodologias ágeis? Em que casos elas terão dificuldades de ser utilizadas?
As desvantagem são politicas. Agil não funciona dentro de uma cultura militar. Não funciona quando as pessoas não sabem se responsabilizar perante as outras. Quanto todo o mundo é mestre em “tirar o seu da reta” não funciona. quando a equipe não é realmente uma equipe mas um conjunto de pessoas, não funciona. quando não existe um responsável pelo produto, não funciona.
Quando não existe um facilitador - que seja uma pessoa diferente do responsavel pelo produto - não funciona. Quando os valores não são aceites no coração dos membros não funciona. Quando as pessoas envolvidas não entendem o que estão fazendo nem o pq, não funciona. Quando o cliente tem sempre razão, não funciona. Quando a documentação de ha 6 meses vale mais que a palavra do desenvolvedor, não funciona. Quando a equipa de desenvolvedor não se pode auto-gerenciar, não funciona.
quando alguém teima em cotar as coisas em horas-homem não funciona. Quando não se deixa os desenvolvedores desenvolverem, não funciona. Quando não se entende o que é um Story Point, Velocidade,Fator de Foco e a diferença entre Estoria e Tarefa não funciona.
a
A desvantagem principal é que existe uma mudança de paradigma que é complexa e difícil se as pessoas não estão preparadas, e o processo de implantação deixa bem claro quem está preparado e quem não está. Isso pode levar a diversos problemas politico-hierarquicos.
“Preparadas” significa podem acatar valores como respeito, abertura, comunicação, etc… Por exemplo, às vezes o cara quer usar Scrum, mas não quer publicar um burndown chart. Ou seja, ele não está sendo aberto, logo está fazendo reserva mental ao não acatar esse valor. Esta pessoa não está preparada para usar Scrum.
Então, quando as pessoas não estão preparadas a implantação de agil não cola e fica a impressão que a culpa é do agil, mas a culpa é na realidade das pessoas que não conseguem seguir valores simples como respeito e abertura, entre outros…
Tem mais um ponto ai. Por que motivos vc quer ser agil?
Isso é uma boa pergunta: existem empresas que não querem. Existem empresas que dão MUITO certo sem ser agil e, quando tentam usar algo como Scrum, falha.
Eu vejo o seguinte: vc precisa responder rapido ao cliente? Se sim, agile é uma boa opção.
Imagine que vc esta desenvolvendo um sistema complexo e vc vai lançando releases de tempos em tempos com alguma funcionalidade suficiente e tem tempo de receber feedback do que o cliente usou e achou: é um bom passo para vc evitar de fazer aquela tela pq o cara de terno azul pediu mas que todo mundo sabe que é inutil, pois vc pode jogar com coisas realmente uteis e, quando chegar a hora de fazer o relatorio detalhado do nada ao lugar nenhum simplesmente não vale a pena investir mais no projeto.
Agora imagine um portal que oferece serviços específicos e, um dia, a concorrência lança um produto ANIMAL e INOVADOR: vc acha que vai fazer frente a isso tendo uma fase de levantamento de requisitos, uma fase de … , uma fase de desenvolvimento, uma fase de teste (e uma fase de demissões pq demorou mais do que o previsto)? Nesse caso a empresa tem que reagir rapido.
Mas como ela reage? Tem muitas formas, uma delas é lançar algo O MAIS RAPIDO POSSIVEL. Ah mas ai alguem diz ‘puxa, mas o css ta feio, tem um dropbox no lugar de um [buzzword da web 2.0], ta incompleto, não tem toda a experiência imersiva, etc’. Ok, nesse meio tempo alguem mais vai lançar alguma coisa e, quando vc perceber, só vc não seguiu o bonde e vc perdeu audiência. Numa situação dessas Agile é interessante, mas Agile intrincado na estratégia empresarial. Se eu preciso responder e trabalhar sem ficar preenchendo planilha que não serve pra nada ou juntar buzzwords para manter o meu trabalho, então eu preciso do anti-agile.
Agora se eu só quero trabalhar e, de repente, melhorar o meu processo, eu posso ver que caracteristicas do Agile me servem. De repente um Kamban para certas atividades pode ajudar, ou simplesmente trabalhar com iterações curtas e retrospectivas.
Em mais de um ano trabalhando com Scrumm eu aprendi muita coisa, principalmente comportamental: eu questiono e sou questionado pelas minhas decisões. Geralmente isso é benefico para o time e todos colaboram no trabalho de uma forma mais ativa. No fim do dia vc sente orgulho do que fez, até. E olha q antes eu trabalhava numa coisa q tentava aplicar esses conceitos bonitinhos de teste de software que, no fim das contas, só me deixava ocioso em varios momentos - não que isso seja ruim.
S
sergiotaborda
peczenyj:
Em mais de um ano trabalhando com Scrumm eu aprendi muita coisa, principalmente comportamental: eu questiono e sou questionado pelas minhas decisões. Geralmente isso é benefico para o time e todos colaboram no trabalho de uma forma mais ativa. No fim do dia vc sente orgulho do que fez, até.
Infelizmente muito poucas pessoas que se intitulam “desenvolvedor” ou “programador” ou algo equivalente não sabem o que é sentir orgulho pelo trabalho bem feito. É dificil que alguem sinta isso num ambiente onde valores não são bem vindos. O unico jeito de sentir orgulho pelo trabalho é trabalhar com uma metodolgia que valorize o seu trabalho tanto quanto vc.
Muitos acham que agil significa “codificar o que quero, quando quero do jeito que quero”. É exatamente o contrário.
P
Paulo_Silveira
sergiotaborda:
Muitos acham que agil significa “codificar o que quero, quando quero do jeito que quero”. É exatamente o contrário.
acho que nao muitos… bem poucos alias. pessoal ja deu uma boooa esclarecida. é como a frase “agil é aquela metodologia que nao precisa de documentacao!”. (quase) ninguem mais fala isso.
S
sergiotaborda
Paulo Silveira:
sergiotaborda:
Muitos acham que agil significa “codificar o que quero, quando quero do jeito que quero”. É exatamente o contrário.
acho que nao muitos… bem poucos alias. pessoal ja deu uma boooa esclarecida. é como a frase “agil é aquela metodologia que nao precisa de documentacao!”. (quase) ninguem mais fala isso.
LoL se vc se refere a pessoas que sabem o que é agil , ou pelo menos usam, então sim.
Agora se vc se refere a todos os desenvolvedores ,não concordo. Especialmente os novatos e aqueles que foram bitolados em metodologias tradicionais acham que agil é a maneira de fazerem menos coisas burucráticas pela simples forma de não fazer nada. Muitos nem sabem o que é escrever codigo bem, quando mais saber que isso é uma forma de documentação.
V
ViniGodoy
Realmente, muita gente usa ágil como desculpa. Mas isso é uma atitude irresponsável, não algo que deva ser usado contra a metologia ágil séria, que de fato existe.
P
Paulo_Silveira
sergiotaborda:
LoL se vc se refere a pessoas que sabem o que é agil , ou pelo menos usam, então sim.
Agora se vc se refere a todos os desenvolvedores ,não concordo. Especialmente os novatos e aqueles que foram bitolados em metodologias tradicionais acham que agil é a maneira de fazerem menos coisas burucráticas …
é, talvez eu esteja meio viciado as empresas que estamos dando consultoria e aos alunos que passam por aqui… mas é bom ter pensamento positivo!! :).
V
ViniGodoy
O pior é que já vi más consultorias queimarem o filme do ágil, e depois, ser difícil sequer conversar com um gestor de uma empresa, traumatizado, sobre usar uma metodologia assim.
L
luistiagos
Isso é uma piada? :lol: 200000 por mes? ta doido???
sou arquiteto, desenvolvedor, testador e ganho miseros 2k por mes fio…
acorda marcio… isto e vida e não ficção… nunca que vc vai ganhar 20k neste pais a menos que vc seja um deputado…
ou tenha um papai com bastante $$$ que monte uma empresa pra vc… senão esqueça…
agora voltando ao topico… ja vi empresas que agil significa hora extra…
F
fernando.palma
Tem mais um ponto ai. Por que motivos vc quer ser agil?
Isso é uma boa pergunta: existem empresas que não querem. Existem empresas que dão MUITO certo sem ser agil e, quando tentam usar algo como Scrum, falha.
Eu vejo o seguinte: vc precisa responder rapido ao cliente? Se sim, agile é uma boa opção.
Imagine que vc esta desenvolvendo um sistema complexo e vc vai lançando releases de tempos em tempos com alguma funcionalidade suficiente e tem tempo de receber feedback do que o cliente usou e achou: é um bom passo para vc evitar de fazer aquela tela pq o cara de terno azul pediu mas que todo mundo sabe que é inutil, pois vc pode jogar com coisas realmente uteis e, quando chegar a hora de fazer o relatorio detalhado do nada ao lugar nenhum simplesmente não vale a pena investir mais no projeto.
Agora imagine um portal que oferece serviços específicos e, um dia, a concorrência lança um produto ANIMAL e INOVADOR: vc acha que vai fazer frente a isso tendo uma fase de levantamento de requisitos, uma fase de … , uma fase de desenvolvimento, uma fase de teste (e uma fase de demissões pq demorou mais do que o previsto)? Nesse caso a empresa tem que reagir rapido.
Mas como ela reage? Tem muitas formas, uma delas é lançar algo O MAIS RAPIDO POSSIVEL. Ah mas ai alguem diz ‘puxa, mas o css ta feio, tem um dropbox no lugar de um [buzzword da web 2.0], ta incompleto, não tem toda a experiência imersiva, etc’. Ok, nesse meio tempo alguem mais vai lançar alguma coisa e, quando vc perceber, só vc não seguiu o bonde e vc perdeu audiência. Numa situação dessas Agile é interessante, mas Agile intrincado na estratégia empresarial. Se eu preciso responder e trabalhar sem ficar preenchendo planilha que não serve pra nada ou juntar buzzwords para manter o meu trabalho, então eu preciso do anti-agile.
Agora se eu só quero trabalhar e, de repente, melhorar o meu processo, eu posso ver que caracteristicas do Agile me servem. De repente um Kamban para certas atividades pode ajudar, ou simplesmente trabalhar com iterações curtas e retrospectivas.
Em mais de um ano trabalhando com Scrumm eu aprendi muita coisa, principalmente comportamental: eu questiono e sou questionado pelas minhas decisões. Geralmente isso é benefico para o time e todos colaboram no trabalho de uma forma mais ativa. No fim do dia vc sente orgulho do que fez, até. E olha q antes eu trabalhava numa coisa q tentava aplicar esses conceitos bonitinhos de teste de software que, no fim das contas, só me deixava ocioso em varios momentos - não que isso seja ruim.
Eu esperava justamente uma resposta dessas como desvantagem. estava tentando demonstrar que tudo tem desvantagens e o mundo não vira uma metodologia só, como foi dito aqui.
Imagem criar um software para medir e controlar a temperatura do bico dos foguetes de ônibus espaciais. Você usaria método ágil???
Tudo depende do objetivo.
M
mochuara
fernando.palma:
Ok, temos opiniões diferentes. Eu não sobrevivo sem um superior a quem passar certas decisões. Há não ser que eu seja sócio único da empresa. Eu posso até mudar de opinião um dia, não descarto a possibilidade.
Sim, até ai tudo bem. É como os modelos de gestão japonesas de cooperação, já abordavam menos hierarquia, com esta metáfora da colmeia . Isso já tem anos.
O que não significa de forma alguma que desenvolvimento de software seja uma atividade que não se beneficie dos líderes. Líderes são fundamentais sendo difícil acreditar num projeto de sucesso sem um papel de líder. Todas empresas, projetos open source, e até projetos de final de semana tem seus líderes. Mas o que as metodologias ageis são boas mesmo é em ressaltar as habilidades de cada um para o melhor aproveitamento da equipe. Neste caso, mesmo que o papel de gerente não tenha vez, existe sempre alguma coisa que se pode contribuir. Não são líderes que são desnecessários aqui, mas os gerentes. Pra ser um líder este alguém precisa ter o modelo do software a ser desenvolvido sobre o seu domínio para não parecer um idiota quando lhe forem exigir que tome uma decisão de projeto.
Menos hierarquia não significa ausência de líder, e metodologias ageis não são pela sua exterminação. Mas não sei como é no Japão.
M
mochuara
peczenyj:
sergiotaborda:
fernando.palma:
Me responda uma pergunta: quais são as desvantagens das metodologias ágeis? Em que casos elas terão dificuldades de ser utilizadas?
As desvantagem são politicas. Agil não funciona dentro de uma cultura militar. Não funciona quando as pessoas não sabem se responsabilizar perante as outras. Quanto todo o mundo é mestre em “tirar o seu da reta” não funciona. quando a equipe não é realmente uma equipe mas um conjunto de pessoas, não funciona. quando não existe um responsável pelo produto, não funciona.
Quando não existe um facilitador - que seja uma pessoa diferente do responsavel pelo produto - não funciona. Quando os valores não são aceites no coração dos membros não funciona. Quando as pessoas envolvidas não entendem o que estão fazendo nem o pq, não funciona. Quando o cliente tem sempre razão, não funciona. Quando a documentação de ha 6 meses vale mais que a palavra do desenvolvedor, não funciona. Quando a equipa de desenvolvedor não se pode auto-gerenciar, não funciona.
quando alguém teima em cotar as coisas em horas-homem não funciona. Quando não se deixa os desenvolvedores desenvolverem, não funciona. Quando não se entende o que é um Story Point, Velocidade,Fator de Foco e a diferença entre Estoria e Tarefa não funciona.
a
A desvantagem principal é que existe uma mudança de paradigma que é complexa e difícil se as pessoas não estão preparadas, e o processo de implantação deixa bem claro quem está preparado e quem não está. Isso pode levar a diversos problemas politico-hierarquicos.
“Preparadas” significa podem acatar valores como respeito, abertura, comunicação, etc… Por exemplo, às vezes o cara quer usar Scrum, mas não quer publicar um burndown chart. Ou seja, ele não está sendo aberto, logo está fazendo reserva mental ao não acatar esse valor. Esta pessoa não está preparada para usar Scrum.
Então, quando as pessoas não estão preparadas a implantação de agil não cola e fica a impressão que a culpa é do agil, mas a culpa é na realidade das pessoas que não conseguem seguir valores simples como respeito e abertura, entre outros…
Tem mais um ponto ai. Por que motivos vc quer ser agil?
Isso é uma boa pergunta: existem empresas que não querem. Existem empresas que dão MUITO certo sem ser agil e, quando tentam usar algo como Scrum, falha.
Eu vejo o seguinte: vc precisa responder rapido ao cliente? Se sim, agile é uma boa opção.
Imagine que vc esta desenvolvendo um sistema complexo e vc vai lançando releases de tempos em tempos com alguma funcionalidade suficiente e tem tempo de receber feedback do que o cliente usou e achou: é um bom passo para vc evitar de fazer aquela tela pq o cara de terno azul pediu mas que todo mundo sabe que é inutil, pois vc pode jogar com coisas realmente uteis e, quando chegar a hora de fazer o relatorio detalhado do nada ao lugar nenhum simplesmente não vale a pena investir mais no projeto.
Agora imagine um portal que oferece serviços específicos e, um dia, a concorrência lança um produto ANIMAL e INOVADOR: vc acha que vai fazer frente a isso tendo uma fase de levantamento de requisitos, uma fase de … , uma fase de desenvolvimento, uma fase de teste (e uma fase de demissões pq demorou mais do que o previsto)? Nesse caso a empresa tem que reagir rapido.
Mas como ela reage? Tem muitas formas, uma delas é lançar algo O MAIS RAPIDO POSSIVEL. Ah mas ai alguem diz ‘puxa, mas o css ta feio, tem um dropbox no lugar de um [buzzword da web 2.0], ta incompleto, não tem toda a experiência imersiva, etc’. Ok, nesse meio tempo alguem mais vai lançar alguma coisa e, quando vc perceber, só vc não seguiu o bonde e vc perdeu audiência. Numa situação dessas Agile é interessante, mas Agile intrincado na estratégia empresarial. Se eu preciso responder e trabalhar sem ficar preenchendo planilha que não serve pra nada ou juntar buzzwords para manter o meu trabalho, então eu preciso do anti-agile.
Agora se eu só quero trabalhar e, de repente, melhorar o meu processo, eu posso ver que caracteristicas do Agile me servem. De repente um Kamban para certas atividades pode ajudar, ou simplesmente trabalhar com iterações curtas e retrospectivas.
Em mais de um ano trabalhando com Scrumm eu aprendi muita coisa, principalmente comportamental: eu questiono e sou questionado pelas minhas decisões. Geralmente isso é benefico para o time e todos colaboram no trabalho de uma forma mais ativa. No fim do dia vc sente orgulho do que fez, até. E olha q antes eu trabalhava numa coisa q tentava aplicar esses conceitos bonitinhos de teste de software que, no fim das contas, só me deixava ocioso em varios momentos - não que isso seja ruim.
Compartilho da opinião sobre o prazer de entregar software funcionando e tal, mas discordo da visão de metodologias ageis como ferramenta pra clonar sensações web da noite pro dia. Se não me engano essa já é a motivação do Rails. :lol:
M
mochuara
fernando.palma:
Me responda uma pergunta: quais são as desvantagens das metodologias ágeis? Em que casos elas terão dificuldades de ser utilizadas?
.
Voce sabe, existem varias metodologias ágeis, existem diferentes sabores para diferentes tipos de projeto, desde projetos distribuidos não.
Existe alguma característica além de colocação que dificultaria o processo. Não estou lembrado. Hardware é baratos, pizzas tb.
V
ViniGodoy
As metodologias ágeis se baseiam numa premissa: é barato modificar software.
Em todos os locais onde essa premissão não é verdadeira, será difícil aplicar um método muito iterativo:
Em software que irá embarcado em hardware;
Em software que exige extrema performance e testes;
Em software que será distribuído em larga escala, muitas vezes para clientes sem internet.
Em software produzido através de equipes externas;
M
mochuara
ViniGodoy:
As metodologias ágeis se baseiam numa premissa: é barato modificar software.
Em todos os locais onde essa premissão não é verdadeira, será difícil aplicar um método muito iterativo:
Em software que irá embarcado em hardware;
Em software que exige extrema performance e testes;
Em software que será distribuído em larga escala, muitas vezes para clientes sem internet.
Em software produzido através de equipes externas;
Esta dizendo que nesses tipos de software o programador não escreve código de forma iterativa?
Eu discordo. O software ser barato pra criar/modificar é uma constante. O que muda em cada caso é o custo elevado do código mal especificado.
V
ViniGodoy
mochuara:
Esta dizendo que nesses tipos de software o programador não escreve código de forma iterativa?
Eu discordo. O software ser barato pra criar/modificar é uma constante. O que muda em cada caso é o custo elevado do código mal especificado.
Ele pode escrever de forma iterativa até a distribuição. Depois disso, o custo do software torna-se astronomicamente caro. Estou falando em:
Equipes de campo para ter que fazer update no cliente;
Equipamentos de hardware que terão que ser recolhidos, e atualizados manualmente;
Sistemas onde a falha do software pode causar processos, destruição, mortes ou outras coisas catastróficas.
Nem todo software é barato de se modificar.
As metodologias ágeis se baseiam no princípio de estar preparado para o erro, e para a mudança. Em deixar o cliente especificar mal, ver o resultado, e modifica-lo cedo, dentro do ciclo de desenvolvimento dinâmico. E isso efetivamente acontece, pois nossos clientes não entendem nada de informática.
Entretanto, alguns casos a metodologia torna-se de difícil aplicação, justamente porque o fator “barato de se modificar” deixa de se verificar. E é aí que a metodologia ágil torna-se cada vez mais difícil de ser vantajosa. Veja, não é o caso da maior parte dos sistemas hoje, especialmente os sistemas web, ou os sistemas onde enviar patches via internet é possível.
P
peczenyj
Eu usaria agile num programa desses da NASA amarradão. Entretanto só imagino gente absurdamente animal programando essa parada e eu fazendo cafezinho.
F
fernando.palma
O que não significa de forma alguma que desenvolvimento de software seja uma atividade que não se beneficie dos líderes. Líderes são fundamentais sendo difícil acreditar num projeto de sucesso sem um papel de líder. Todas empresas, projetos open source, e até projetos de final de semana tem seus líderes. Mas o que as metodologias ageis são boas mesmo é em ressaltar as habilidades de cada um para o melhor aproveitamento da equipe. Neste caso, mesmo que o papel de gerente não tenha vez, existe sempre alguma coisa que se pode contribuir. Não são líderes que são desnecessários aqui, mas os gerentes. Pra ser um líder este alguém precisa ter o modelo do software a ser desenvolvido sobre o seu domínio para não parecer um idiota quando lhe forem exigir que tome uma decisão de projeto.
Menos hierarquia não significa ausência de líder, e metodologias ageis não são pela sua exterminação. Mas não sei como é no Japão.
Ok, legal. Algumas coisas eu vou obtendo explicação com o tempo.
É parecido sim com um modelo de amdministração Japonesa. Não me refiro a administração Japonesa como um todo.
F
fernando.palma
Mas seria posível? Este projeto exige um planejamento macho. O projeto dura muito mais do que o ciclo de desenvolvimento.
Outrs pontos:
Este é um tipo de software que não evului muito, quando for entregue é aquilo mesmo.
O fator agilidade aqui não conta muito, a variável de sucesso aqui é 99% eficácia (cumprir o objetivo, senão a nave explode)
Não da pra fazer pequenas entregas pro cliente testar, da?
A especificação será revisada mil vezes. Não é só desenvolvimento de código. O TDD não resolve tudo.
P
peczenyj
Mas pq não haveria de ser possivel?
Com agile posso produzir todos os artefatos necessários em ciclos iterativos…
F
fernando.palma
Aqui em Salador conheci uma empresa que trabalhou em um projeto para software de controle de calderões em usinas. Se o sftware falhar, explode o calderão.
O software quando é entregue é uma vez só e tem que estar 100%. O que eu fico em dúvida (não tenho certeza) é de como realizar iteratividade neste caso?
Em ambos os exemplos, os produtores do software deverão planejar e garantir que o software funcione. A iteratividade pode não ser justificada, porque o “cliente” desse projeto não vai saber avaliar o artefato, você tem que ser o especialista em produzir o sistema confiável e entregá-lo. Entede?
No caso desta empresa que eu descrevi, se ela fizesse uma pequena entrega e pedisse uma avaliação, o cliente - a usina - provavelmente iria dizer: quem vai me dizer se está avaliado é você.
Nestes casos também a agilidade não e fator crítico e não existem funcionalidades, requisitos de usabilidade, etc, para serem avaliados. O software tem apenas uma fncionalidade: manter a temperatura.
F
fernando.palma
A linha de evolução de software como estes exemplificados é baixa. Ao contrário de ferramentas web que estamos acostumados a entregar: linha de evoluçao quase exponencial.
P
peczenyj
Isso só acontece se o Product Owner entender que deve ser feito assim.
Como se alguem fosse dar o aceite de um produto que não responde com a rapidez que lhe é cabida. Basta ver como a Lockheed Martin usou o Scrum.
F
fernando.palma
Isso só acontece se o Product Owner entender que deve ser feito assim.
Como se alguem fosse dar o aceite de um produto que não responde com a rapidez que lhe é cabida. Basta ver como a Lockheed Martin usou o Scrum.
Ok, legal. Vou dar uma olhada.
Se alguém mais do fórum quiser opinar sobre o assunto…
A
aleck
fernando.palma:
Aqui em Salador conheci uma empresa que trabalhou em um projeto para software de controle de calderões em usinas. Se o sftware falhar, explode o calderão.
O software quando é entregue é uma vez só e tem que estar 100%. O que eu fico em dúvida (não tenho certeza) é de como realizar iteratividade neste caso?
Em ambos os exemplos, os produtores do software deverão planejar e garantir que o software funcione. A iteratividade pode não ser justificada, porque o “cliente” desse projeto não vai saber avaliar o artefato, você tem que ser o especialista em produzir o sistema confiável e entregá-lo. Entede?
No caso desta empresa que eu descrevi, se ela fizesse uma pequena entrega e pedisse uma avaliação, o cliente - a usina - provavelmente iria dizer: quem vai me dizer se está avaliado é você.
Nestes casos também a agilidade não e fator crítico e não existem funcionalidades, requisitos de usabilidade, etc, para serem avaliados. O software tem apenas uma fncionalidade: manter a temperatura.
Independente da complexidade do sistema, este possui módulos que podem ser entregues iterativamente.
Gosto de ressaltar que ser ágil não é utilizar xp ou scrum e sim a forma de pensar da equipe, sempre primando pela qualidade e possuindo acima de tudo o comprometimento e sinergia com o cliente, que em muitos casos não é possível, pois o cliente não está aberto a tal colaboração necessária.
Basicamente é seguir o manifesto ágil, independente da metodologia escolhida.
F
fernando.palma
Gosto de ressaltar que ser ágil não é utilizar xp ou scrum e sim a forma de pensar da equipe, sempre primando pela qualidade e possuindo acima de tudo o comprometimento e sinergia com o cliente, que em muitos casos não é possível, pois o cliente não está aberto a tal colaboração necessária.
Realmente essas colaborações para o tema estão mais coerentes para mim, fazem mais sentido. Começo a entender melhro o ponto de vista.
V
ViniGodoy
Eu acho que é simplificar um problema. A partir do momento que o custo da release torna-se extremamente caro, o ágil começa a perder o sentido.
Já vou deixando claro que sou completamente à favor do desenvolvimento ágil. Mas já trabalhei na indústria de hardware, e sei que alguns sistemas tem custos de manutenção astronômica. Mesmo sendo software só usado por pessoal de campo. E, nesses casos, justificava sim um ciclo mais pesado, com mais documentações e fases mais longas e burocráticas.
V
ViniGodoy
Só para complementar. Não significa que o desenvolvimento “não ágil” seja totalmente em cascata. Waterfall completo é algo que não existe há muitos anos, embora a literatura ágil dê a entender o contrário (vide o livro de UML e padrões do Craig Larmann).
Muitas técnicas que surgiram no ágil também são aplicadas à outros ciclos de desenvolvimento. Não creio que hoje exista uma empresa séria em desenvolvimento não-ágil que abra mão de testes unitários, por exemplo. Ou faça ciclos de desenvolvimento maiores que do dois meses (sendo que dois meses é um ciclo já considerado longo, mesmo por elas mesmas).
As scrums, que surgiram no processo de fabricação automobilistica (e que está bem longe de ser ágil como o software) foram primeiro aplicadas no RUP, por exemplo.
Só não concordo quando começam a defender qualquer tipo de desenvolvimento como a única alternativa. Como ressaltei num post em que defendi o singleton, construir software é, como todo projeto de qualquer coisa, escolher entre diversos trade-offs. Para tudo, ganha-se de um lado, perde-se de outro.
O importante para o desenvolvedor é saber reconhecer em cada processo ou técnica de programação utilizado seus pontos fortes e fracos. A partir do momento que você torna evangelista “demais” de uma técnica, corre-se o risco de estar também se tornando míope, um cuidado que todos nós devemos evitar.
F
fernando.palma
è, é isso ai. Eu gostei do tópico para conhecer mais discursos de quem trabalhou na pratica mais vezes com desenvolvimento ágil. Achei ótimo.
Eu tenho minha área de especilização também, mas sei que o tema qual sou especializado também não é perfeito e não se adpata em qualquer caso (não é desenvolvimento), quem quiser conhecer: http://gsti.blogspot.com
Como Marcos disse, para tudo que fazemos, devemos mensurar quais são os objetivos e sermos sensatos.
Obrigado pela colaboração de todos!
S
sergiotaborda
Mas seria posível? Este projeto exige um planejamento macho. O projeto dura muito mais do que o ciclo de desenvolvimento.
Outrs pontos:
Este é um tipo de software que não evului muito, quando for entregue é aquilo mesmo.
O fator agilidade aqui não conta muito, a variável de sucesso aqui é 99% eficácia (cumprir o objetivo, senão a nave explode)
Não da pra fazer pequenas entregas pro cliente testar, da?
A especificação será revisada mil vezes. Não é só desenvolvimento de código. O TDD não resolve tudo.
fernando.palma:
Aqui em Salador conheci uma empresa que trabalhou em um projeto para software de controle de calderões em usinas. Se o sftware falhar, explode o calderão.
O software quando é entregue é uma vez só e tem que estar 100%. O que eu fico em dúvida (não tenho certeza) é de como realizar iteratividade neste caso?
Acho que vcs não entenderam. Agil se aplica ao desenvolvimento. Ou seja, enquanto o software está sendo feito.
O software está sendo feito até à entrega do ultimo release! O numero de releases é planejado com antecedência.
O projeto pode ter apenas um release como nesse seu exemplo, nos da NASA, de hardware,firmware , etc…
Nada disto impossibilita o processo agil porque ele não se preocupa com a forma /uso do software e sim com o processo de como chegar na entrega final.
O processo agil sugere (o scrum exige) que no meio tempo demos sejam apresentadas. Isso é independente do meio final onde o software irá rodar.
Em um release podem haver quantos sprints vc quiser (ou forem matemáticamente possiveis). Por exemplo,um software de controle de caldeirão deve ter alguma parte que é o controlador (critico) e uma parte de apoio (telas, cadastros etc) VC pode serparar os dois e ter dois releases facilmente.
Quando vc pensa agil sempre existe uma forma e não depende do tipo de projeto. Lembre-se que agil foi introduzido no mundo dos fabricantes de automoveis.
Isso é simplesmente errado. A iteratividade é ainda mais importante quanto mais o projeto tem riscos. O risco do caldeirão explodir é muito grande para ser deixado num processo não iterativo (aka waterfall).
Isto é inaceitável. O Cliente sempre tem que se responsabilizar pela qualidade do que recebe. quando vc compra um carro um uma casa vc não faz vistoria ? confia no vendedor ? Não. software não é diferente.
Se o cliente não sabe, não pode ou não quer ter essa responsabilidade contrate uma terceira empresa. É mais caro ? É. Problema dele por não querer trabalhar.
Lol, isso o termostato tb faz. Concerteza tem mais coisa nessa salada.
Vc está dando uma versão minimalista dos requisitos. Mas mesmo que o sistema tenha apenas 1 requisito ele rápidamente se desdobra em um monte de coisas que os desenvolvedores têm que fazer e é ai que entra a agilidade. Não no levantamento de requisitos
Aquele ciclo que vemos por ai de Levante Requisitos -> produz -> entrega -> Levanta Requisitos - produz -> entrega não é correto. Isso não é agil. Isso é amador. E dá a falsa ideia que ser agil é levantar requisitos aos soluços. Nada disso.
O levantamento de requisitos sempre é levantado no inicio antes do desenvolvimento começar. É dai que são gerados back ogs, estimativas, prazos, custos, etc… é dai que o projeto é planejado. Depois começa o desenvolvimento. A diferença é que em agil é sabido, entendido e está previsto que esses requisitos mudem. O fato deles mudarem não altera o projeto! É esta a grande diferença , o pulo do gato, que permite tem um projeto fixo em um mundo de requisitos voláteis.
F
fernando.palma
Acho que vcs não entenderam. Agil se aplica ao desenvolvimento. Ou seja, enquanto o software está sendo feito.
O software está sendo feito até à entrega do ultimo release! O numero de releases é planejado com antecedência.
O projeto pode ter apenas um release como nesse seu exemplo, nos da NASA, de hardware,firmware , etc…
Nada disto impossibilita o processo agil porque ele não se preocupa com a forma /uso do software e sim com o processo de como chegar na entrega final.
O processo agil sugere (o scrum exige) que no meio tempo demos sejam apresentadas. Isso é independente do meio final onde o software irá rodar.
Em um release podem haver quantos sprints vc quiser (ou forem matemáticamente possiveis). Por exemplo,um software de controle de caldeirão deve ter alguma parte que é o controlador (critico) e uma parte de apoio (telas, cadastros etc) VC pode serparar os dois e ter dois releases facilmente.
Quando vc pensa agil sempre existe uma forma e não depende do tipo de projeto. Lembre-se que agil foi introduzido no mundo dos fabricantes de automoveis.
Ok! Valeu.
F
fernando.palma
Lol, isso o termostato tb faz. Concerteza tem mais coisa nessa salada.
Vc está dando uma versão minimalista dos requisitos. Mas mesmo que o sistema tenha apenas 1 requisito ele rápidamente se desdobra em um monte de coisas que os desenvolvedores têm que fazer e é ai que entra a agilidade. Não no levantamento de requisitos
É, ode ser, eunão participei só conheci os cara. Mas o sistema por mais que tenha alguns requisitos se desdobrando, será de funcionalidade minimista, usabilidade que tente a zero. Os requesitos não funcionais são: é segugarnça, confiabilidade, sustentabilidade e resiliência. A evolução pode existir mais será bem menor que os software que nós costumamos produzir (evolução quase exponencial).
S
sergiotaborda
Concordo com tudo. Muita coisa pregada no Manifesto Ágil não é novidade, mas uma boa prática conhecida. E tem muita gente que fica babando ovo pro Agil como e defendendo Scrum como a bala de prata pra todos os problemas.
Como você disse, até parece que quem não usa agil é 100% waterfall e quem usa é 100% eficiência.
Como todo processo empírico, o melhor é conhecer várias práticas e saber quando aplicá-las. Senão a discussão nunca vai terminar e pra cada exemplo de sucesso/fracasso alguém vai achar um contra-exemplo de fracasso/sucesso.
A discussão não vai acabar enquanto as pessoas não entenderem o que significa Agilidade. E isso implica em desmistificar várias miss-conceptions comuns e populares que levam as pessoas a não consideram agil nos seus projetos.
Quem não usa agil pode até não ser waterfall ( não acredito nisso , mas ok…) mas concerteza não é tão eficiente como com agil.
Coloque uma equipa RUP tradicional e uma agil fazendo o mesmo software. Enquanto a primeira está fazendo um monte de boneco a segunda já tem algo que corre e pode ser demonstrado, avaliado pelo cliente : aka feedback. Com o feedback começando mais cedo, ha menos “erros de especificação” e com isso mais eficiente porque o desenvolvedor não fica enchendo linguiça enquanto outros fazem bonecos. Meça o fator de foco dos membros das equipas nos dois modelos. Asseguro-lhe que o de agil será maior. Isto significa que o software são logo e sem enrolação. Sem aquele papo de estimar 60 hora um trabalho de 10 para ficar 50 na boa vida. Se colocar pair-programing a diferença é maior ainda.
Agil de adqua a todos os projetos de software independente de localização, tamanho ou objetivos do projeto. a razão é simples :
Agil não é uma metodologia, é uma forma de pensar. Uma melhor forma de pensar que respeita os intervenientes é sim uma bala de prata para matar os mercenários parasitas que existem por ai construindo software ruim e cobrando caro: verdadeiros charalães vendedores da banha-da-cobra. Pode haver uma melhor no futuro, mas agora, esta é a que temos para nos defender.
J
JavaLivros
Se é uma forma de pensar eu acredito, aliás acho que é sim uma forma de compartilhar o conhecimento sem a governança de uma gerencia de Marketing aliada à PMI, CMMI 1, 2, 3, 4, 5, 6 etc… PMBOK´s e vendor lo lo lo, "é sim todos na responsabilidade do sucesso "
F
fernando.palma
Eu costumo ter o mesmo ponto de vista de Marcos. Falei sobre entusiasmo algumas vezes aqui. Estou achando ótimo conhecer pessoas que trabalham na prática com SRCUm e XP. Mas nada é maravilhoso e vai mudar o mundo.
Trabalho com implantação de processos baseado em práticas da ITIL. Me especializei, fui para mais alta das certificações, ensino e faço consultoria no assunto. Muitas pessoas me procuram por conta desta especialização. Mesmo assim, não sou radical ou entusiasta, si bem ponderar, saber quando usar ou não as práticas e quais das práticas no momento certo.
J
JavaLivros
fernando.palma:
Trabalho com implantação de processos baseado em práticas da ITIL. Me especializei, fui para mais alta das certificações, ensino e faço consultoria no assunto. Muitas pessoas me procuram por conta desta especialização. Mesmo assim, não sou radical ou entusiasta, si bem ponderar, saber quando usar ou não as práticas e quais das práticas no momento certo.
Existe uma ciência que entende-se hoje como produção de software, algo que está ao domínio de linguagens de programação e dela e você faz o deployment soluções de frameWorks e extrair documentação.Os requisitos de sistemas são interações por uma colaboração de equipe gerenciadas por pequenas historias junto ao cliente que assina os contratos e aprovações, trabalhar com Ágil é uma cultura orientada a mudanças e inovações.
S
sergiotaborda
marcosalex:
sergiotaborda:
Coloque uma equipa RUP tradicional e uma agil fazendo o mesmo software. Enquanto a primeira está fazendo um monte de boneco a segunda já tem algo que corre e pode ser demonstrado, avaliado pelo cliente : aka feedback. Com o feedback começando mais cedo, ha menos “erros de especificação” e com isso mais eficiente porque o desenvolvedor não fica enchendo linguiça enquanto outros fazem bonecos. …
Não foi o Manifesto ágil que inventou entregas parcias e planejamento em ondas sucessivas, nem a coleta de feedback.
Ninguem está dizendo que foi. Isso é totalmente irrelevante. Processos iterativos até o RUP tem. A questão é que ninguém segue! Na maioria dos casos RUP é usado como desculpa para um processo waterfall.
Como disse, agilidade é uma forma de pensar. Se vc pensa agil vc pode ser agil até com RUP.
Fala sério - quem acha que os métodos tradicionais - que comprovadamente são uma merda - têm alguma change contra os ágeis ?
Veja o exemplo da microsoft e do google : qual vc vê conduzir agil ? e qual vale mais no mercado ?
É uma questão de tempo (pouco) que os empresário se atenham ao fato que emrpesas ageis rendem mais. Simple economics. É o dinheiro que move o mundo e não a filosofia. Ágil tem simplesmente melhor custo/beneficio sem truques.
Além disso , programadores profissionais que estão cansados de ser tratados como peões num sistema feudal de gerencia estão procurando ambientes melhores e esses ambientes na grande maioria daz vezes seguem agil.
Agíl não é moda. É o padrão de fato. Já que em 50 anos de dev de software nada conseguiu ser tão consistente.
Y
YvGa
Pois é, eu tenho o mesmo ponto de vista, aparentemente radical, que o Sergio.
Nao sei quanto aos casos que postou o Vinigodoy sobre softwares embarcados e tal, porque nunca trabalhei com esse tipo de desenvolvimento. Mas, exceto pelo release incremental, nao vejo porque nao se pode usar ageis. Mas enfim, como nunca vivenciei…
Quanto ao entusiasmo, digo que nao é entusiasmo, é a diferenca entre funcionar e nao funcionar. Quantas vezes voces usaram as metodologias tradicionais e entregaram o projeto com atraso? Se todo mundo responder sinceramente, é mais facil contar as vezes em que entregaram dentro do prazo, se é que alguma vez entregaram no prazo.
Falar em pros e contras dos metodos tradicionais? Eu nao consigo ver pros, nao os encontro. Existem sim, ponto que ainda estao fracos nas ageis, pelo menos pontos em que tivemos dificuldade (como integracao dos trabalhos de mais de uma equipe, determinar as fronteiras). Com certeza existem outros pontos fracos, mas os pontos fortes sao muitos.
Em pouco tempo as empresas irao perceber o quanto de dinheiro estao perdendo com esse blablabla, e terao que se tornar ageis.
J
JavaLivros
sergiotaborda:
Agíl não é moda. É o padrão de fato. Já que em 50 anos de dev de software nada conseguiu ser tão consistente.
O Problema é que hoje Ágil é visto sim como as tecnologias que já são tendências algo como Rails que já é alvo do desenvolvimento orientado ao domínio, com técnicas avançadas de TDD, BDD , FDD e assim por diante, todavia não estão localizando o que é a essência ao Manifesto Ágil não estão se colocando de forma mais exata como você se colocou, uma nova forma de pensar,e ai fica essa desvirtualização entre a tecnologia e as boas pratica ao desenvolvimento.
A
Andre_Fonseca
YvGa:
Pois é, eu tenho o mesmo ponto de vista, aparentemente radical, que o Sergio.
Nao sei quanto aos casos que postou o Vinigodoy sobre softwares embarcados e tal, porque nunca trabalhei com esse tipo de desenvolvimento. Mas, exceto pelo release incremental, nao vejo porque nao se pode usar ageis. Mas enfim, como nunca vivenciei…
Quanto ao entusiasmo, digo que nao é entusiasmo, é a diferenca entre funcionar e nao funcionar. Quantas vezes voces usaram as metodologias tradicionais e entregaram o projeto com atraso? Se todo mundo responder sinceramente, é mais facil contar as vezes em que entregaram dentro do prazo, se é que alguma vez entregaram no prazo.
Falar em pros e contras dos metodos tradicionais? Eu nao consigo ver pros, nao os encontro. Existem sim, ponto que ainda estao fracos nas ageis, pelo menos pontos em que tivemos dificuldade (como integracao dos trabalhos de mais de uma equipe, determinar as fronteiras). Com certeza existem outros pontos fracos, mas os pontos fortes sao muitos.
Em pouco tempo as empresas irao perceber o quanto de dinheiro estao perdendo com esse blablabla, e terao que se tornar ageis.
se as empresas perdem dinheiro e continuam fazendo isso a muito tempo então tem duas alternativas, ou não aprenderam até hoje ou então alguém está ganhando dinheiro - consultorias, novos projetos, manutenções, etc, etc
S
sergiotaborda
JavaLivros:
sergiotaborda:
Agíl não é moda. É o padrão de fato. Já que em 50 anos de dev de software nada conseguiu ser tão consistente.
O Problema é que hoje Ágil é visto sim como as tecnologias que já são tendências algo como Rails que já é alvo do desenvolvimento orientado ao domínio, com técnicas avançadas de TDD, BDD , FDD e assim por diante, todavia não estão localizando o que é a essência ao Manifesto Ágil não estão se colocando de forma mais exata como você se colocou, uma nova forma de pensar,e ai fica essa desvirtualização entre a tecnologia e as boas pratica ao desenvolvimento.
Quando eu comecei a ouvir falar de agil os autores passavam muito a ideia de que o processo agil é feito aos pedaços em que vc pega requisitos somente depois de ter implementados os anteriores e vai refatorando milhares de vezes entre iterações. Hoje, depois de ter lido livro e acompanhado o pensamento sobre agil por ai isso é claramente longe da verdade. O que quero dizer com isto é que tem muito “pregador” que não tem noção que as sua palavras , mal empregadas, podem detonar todo o futuro de um novo paradigma.
Evangelistas de verdade têm mais cuidado, mas tb são mais bitolados. Não enxergam as coisas além daquilo que leram na “biblia”.
É preciso na realidade se informar bem. Como em tudo na vida, antes de dizer que X é ruim.
E é preciso ter muito cuidado com pregadores de primeira maré que ficam bradando a 7 ventos coisas que não são totalmente reais.
S
sergiotaborda
André Fonseca:
se as empresas perdem dinheiro e continuam fazendo isso a muito tempo então tem duas alternativas, ou não aprenderam até hoje ou então alguém está ganhando dinheiro - consultorias, novos projetos, manutenções, etc, etc
Repare, temos as empresas produtoras. Estas não estão perdendo dinheiro já que estão chupando ele das empresas “clientes”.
São as empresas clientes que têm que acordar e ver que estão levando um boa noite cinderela desde do principio do anos 90.
J
JavaLivros
Sergio,
Bota primeira maré nisso, ainda acho que são escoteiros sem bússola.
M
mochuara
Será que ser radical hoje em software é considerado crítica ou elogio? :lol:
Mas falando sério, pra mim radical é quem fala que agile não é 100% eficiente e tem seu pontos fracos (e pior, não sabe apontar qual, demonstrando ainda que é ignorante).
Qual é, entusiasmo é bem vindo em todas metodologias. Só que em processos arcaicos como RUP o mais divertido acaba sendo as reuniões onde os gerentes tentam te fazer acreditar que o produto é um sucesso mesmo ele não tendo sido lançado ainda! Alias, gerentes são entusiastas em querer adquirir cada vez mais entusiastas para sua mais nova grande idéia que ira continuar entusiasmando o mundo. Mas eu desconfiaria de processos que tem reuniões como único motivador de equipes.
Mas para o estado do agile eu penso que é bom esse tido de gente pois ela costuma ser mais vocal. A verdade é que a grande maioria de nós que produz software e portanto se beneficia de agile de verdade não esta preocupado com o que seria uma imagem do agile (!) para o resto do mundo.
A
Andre_Fonseca
sergiotaborda:
André Fonseca:
se as empresas perdem dinheiro e continuam fazendo isso a muito tempo então tem duas alternativas, ou não aprenderam até hoje ou então alguém está ganhando dinheiro - consultorias, novos projetos, manutenções, etc, etc
Repare, temos as empresas produtoras. Estas não estão perdendo dinheiro já que estão chupando ele das empresas “clientes”.
São as empresas clientes que têm que acordar e ver que estão levando um boa noite cinderela desde do principio do anos 90.
concordo
M
mochuara
Acho que isso resume tudo.
M
mochuara
sergiotaborda:
André Fonseca:
se as empresas perdem dinheiro e continuam fazendo isso a muito tempo então tem duas alternativas, ou não aprenderam até hoje ou então alguém está ganhando dinheiro - consultorias, novos projetos, manutenções, etc, etc
Repare, temos as empresas produtoras. Estas não estão perdendo dinheiro já que estão chupando ele das empresas “clientes”.
São as empresas clientes que têm que acordar e ver que estão levando um boa noite cinderela desde do principio do anos 90.
Acho que é mais um longo casamento de interesses onde um provavelmente estaria pior sem o outro.
Alexandre Magno b[/b] - [color=red]O palestrante teve problemas pessoais e infelizmente não poderá comparecer. Lamentamos o inconveniente.[/color]
A morte do Scrum começa a ser anunciada pela comunidade. Não são poucos os artigos e posts que falam que Scrum não o tornará ágil, e pior, que o Scrum o fará achar ser ágil sem o ser de fato. Mas afinal, se ao usar Extreme Programming eu já uso Scrum, por que Scrum existe? E ao usar Scrum + XP, serei ágil de fato? Nesta apresentação o palestrante questionará o papel que Scrum tem exercido dentro do mundo ágil e avaliará o lado positivo e negativo dos fatos.
Vejam as coisas mudam e mudam muito rápido mesmo, é o que só vem a afirmar “Ágil é uma maneira de Pensar”
S
sergiotaborda
Scrum é voltado para gerenciamento e funciona mesmo fora do mundo de software (basta referir que foi inventado na industria automovel). XP é voltado para desenvolvimento.
Sendo que as duas são ageis as duas aplicam a permissa : a unica coisa que temos a certeza é que software evolui e o respeito a valores. Valores são quase os mesmos, mas os de XP são voltados para o desenvolvimento. Por exemplo, a partilha de codigo.
O codigo é de todos, não apenas de um. todos têm direito a mudar qualquer código a qualquer momento. São valores que só fazem sentido em desenvolvimento.
Como ja foi dito as bases das práticas agil vêm de antes. Por isso tanto xp como scrum beberam das mesmas fontes.
Só que scrum foca em gerenciar o projeto, não o codigo. Ele tenta estimar tamanho, custo,prazo, etc… tudo de forma agil.
XP apenas foca em executar o projeto. Os dois casam bem porque partem da mesma base.
XP se sobrepoe um pouco a scrum porque tenta colmatar os problemas gerencias das metodologias gerenciais tradicionais que não são compativeis com XP.
Na prática se vc usar os dois , cada um na sua área, não tem espaço para falha.
O legal do scrum é que pode ser usado em qq nivel da empresa,em qq tipo de time (marketing, vendas, sei lá…) e por isso se fala do scrum of scrums que seria a resposta agil a quem quer “hierarquia”
Y
YvGa
mochuara:
Mas para o estado do agile eu penso que é bom esse tido de gente pois ela costuma ser mais vocal. A verdade é que a grande maioria de nós que produz software e portanto se beneficia de agile de verdade não esta preocupado com o que seria uma imagem do agile (!) para o resto do mundo.
Eu tbm pensava assim quando trabalhava com agile. Mudei para uma empresa que dizia ser agil, vi que nao era e pensei que podia ajuda-la a se tornar. Triste engano.
Mas nós temos a mania de atirar pedras nos gerentes e diretores, culpando-os por nao quererem agilidade e ficarem amarrados em processos atrasados que nao levam a lugar nenhum. Mas a grande culpa da metodologia ainda nao ter engrenado é dos desenvolvedores mesmo.
Um exemplo simples, que provavelmente ocorre na maioria das empresas de desenvolvimento, grande, medias ou pequenas: aqui onde trabalho, a primeira vez que a maioria dos programadores ouviu falar em TDD foi da minha boca, ha no maximo seis meses atras, e mesmo assim ainda nao consegui introduzir o conceito como regra para o desenvolvimento. E dizem que usam Scrum.
Ora, aí se perguntam por que uns dizem que Scrum tem que morrer.
M
mario.fts
Tenho acompanhado o tópico, mas não entendi esse seu ultimo comentário marcos.
O que vc quer dizer? que os desenvolvedores não devem procurar melhores ambientes de trabalho, já que é sempre a mesma música que toca, independente do lugar ou que vc não acredita que ambientes ágeis são melhores para se trabalhar?
[]'s
M
mochuara
O problema de RUP, CMMI, PUK, PMBOX, é que elas são muito lentas para responder ao mercado competitivo de TI. As grandes empresas sem duvida podem se beneficiar de praticas ageis no seu processo mas dificilmente o fazem por que vai contra todo o status quo já estabelecido que é de parar pra estabelecer objetivos, discutir taticas para cumprir esses objetivos, o problema disso é que geralmente são estimativas construidas sobre base tão sólida como gelatina. No final, havendo caixa, é mais facil comprar o concorrente, uma startup que usa metodologias ageis.
E o ciclo se repete…
S
sergiotaborda
marcosalex:
sergiotaborda:
A questão é que ninguém segue!
Como disse, agilidade é uma forma de pensar. Se vc pensa agil vc pode ser agil até com RUP.
Se ninguém segue, nem agile resolve. :lol: :lol:
Ai é que está. Se vc é agil, vc segue, e ai resolve. Agil é seguir valores. Que é exactamente o que falta
no desenvolvimento de software.
Ora exactamente porque elas usam é que são chamadas assim. Essa sua frase é um tautologia.
Só dá para entender agil vs tradicional se falarmos do tradicional. Chama-se argumentação por contra-posição.
Não, escolhi certo. Exactamente porque a MS tem problemas que ela vale menos. Eu disse “vale” e não “lucra”. Quem quer comprar a microsoft ? e quem quer comprar o google ?
Primeiro o chrome é feito com TDD ?
Segundo o chrome é um beta , ou seja, oficialmente ainda não está pronto. Esse é exactamente o conceito. Ele só está pronto e oficialmente entregue quando tiver zero bugs.
Não é a palavra. É o que ela representa. Não são todos os problemas do mundo. São todos os problemas do mundo do desenvolvimento de software.
As suas frases são tautologias. É claro que é obvio e que scrum , xp e lean (que são tudo metodologias ageis) se baseiam nisso.
Quem não se baseia nisso são as metodologias burucráticas que se usam na prática nestes 50 anos.
Se nestes 50 anos em que é obvio que se deve ser agil não se usou isso, nem se tirou partido disso, e pelo contrário se instituicionalizou um mecanismo burucrático que nada tem a ver com nada e que só enche o saco dos desenvolvedores e dos clientes algo está muito errado. O que está muito errado é clientes e desenvolvedores deixarem isso ser assim. Existe uma razão porque a palavra manifesto é usada em “manifesto agil”. Não é apenas uma afirmação , é um pedido de mudança.
F
fernando.palma
Complementando a resposta do Marcos, aqui foi muito comparado o modelo ágil ao cascata. Entretanto, existem diversos modelos de desenvolvimento, entre eles:
Modelo em Cascata;
Modelo Ad-Hoc;
Modelo em Cascata Revisto;
Modelo em V;
Modelo de Prototipagem;
Modelo de Especificação Operacional;
modelo de Transformação Formal;
Modelo em Espiral; etc?
Y
YvGa
Eis que agora existe entao processos semi-ageis?
Voce pode por um resumo pra gente de como voces trabalham ai na sua empresa, Marcos, como funciona o processo desde a coleta dos requisitos ate o ultimo release? Como voce divide as tarefas? como integra o processo? Como faz a integracao do trabalho dos desenvolvedores? de que forma os testes unitarios sao realizados, com quais frameworks? Qual o tipo de documentacao que gera? Como reage as alteracoes de ultima hora do cliente? Como define as prioridades do projeto, do que vai ser entregue?
Essa conversa de “Nao, nao somos waterfall, somos ‘quase’ Scrum, eu escuto sempre” e embora ninguem aceite esse termo, é o que se ve na maioria do casos, por mais que os gerentes tentem negar. Sempre a mesma historia e quando vao argumentar é sempre com os mesmos velhos argumentos.
Ai é que está. Se vc é agil, vc segue, e ai resolve.
Ué, toda metologia é assim.
Não. Primeiro que Agil não é uma metodologia, e segundo que nenhuma metodologia tem como pilar fundamental valores.
Por outro lado, se por alguma razão obscura vc acha que as metodologias tradicionais são baseadas em valores como Abertura, Comprometimento, Foco e principalmente Respeito e Coragem então elas falharam redondamente porque na prática ninguem pratica esses valores. Se chamadas fábricas de software, em que o software é tratado como imutável e que pode ser planejado até o ultimo detalhes em UML antes de um desenvolvedor sequer ser consultado, são o resultado dessas metodologias pré-agil que defendiam esses valores então ou essas metodologias são um lixo, ou a sua implementação é um lixo, ou ambos.
O ponto da conversa é o que o ágil traz a mais. O que traz a mais é o seguimento de valores que não são seguido no dia a dia da maioria das produtoras de software internas e externas. E isto, pasme-se,é um fenomeno mundial. Não é só no Brasil que se está fazendo software de forma ruim, é em todo o lugar.
Vc insiste em mostrar números. Valor não é numérico.
Saber a diferença é fundamental. Porque quando se fala em agregar valor, não se está falando em aumentar o preço.
O Google tem mais valor porque é um player que dá cartas. Ele não fica simplesmente assistindo e copiando como a MS.
O Google mandou o mobile para a estratosfera com o android , disponibilizou mapas para o mundo inteiro , do mundo inteiro e até da lua. Quer digitalizar todos os livros do planeta e até se meteu a construir carros ecologicamente corretos. Além das ferramentas , API e serviços que todos conhecem… e a MS ? Corre atraz do prejuizo do windows vista , da rede .NET (não o framework), lançou um tal de blink e vai lançar um tal de windows 7. O zune é uma copia ruim do ipod que não deu certo. Resumindo, a MS pode faturar mais (pq cobra mais caro!!), mas ela parou no tempo. A visibilidade é menor. Ninguem mais tem medo ou respeito pela MS como antes e tem até gente falando que ela será comprada.
Se o que vc diz é verdade, então temos que concluir que a Google é uma empresa meia-boca. O que é verdade de qualquer jeito e mesmo se o chrome não tivesse bugs. O ponto não são os bugs do chorme. O ponto é entregar sistemas com bugs conhecidos.
quanto dos bugs do chrome eram conhecidos e não resolvidos na entrega da versão 1?
Quando vc entrega um software vc o testou ? Testou mesmo ? para valer ? até o osso ? Se sim, vc resolveu todos os bugs ? então vc está de consciencia tranquila. quem faz o que pode, a mais não é obrigado.
Se um bug acontece depois (alguns acontecem por diferenças do ecosistema onde o sistema é instalado ) é uma falha honesta. Vc fez tudo ao seu alcance para detectar o bug, mas não pegou esse… et lasse.
Agora a outra situação é vc ter descoberto o bug e não o resolver antes da entrega. É isso que não é honesto.
Encontre o bug como quiser, TDD ou sem TDD , mas encontre.
Depois de encontrado, resolva-o. Resolver é tão importante como encontrar.
Se o seu sistema tem 1000 bugs, 3000 bugs , 10000 bugs na lista, abertos, num dado momento, algo está errado na sua equipa de desenvolvimento ou na sua metodologia, ou ambos. Se vc tem 30000 bugs na lista, mas todos estão fechados, vc está funcionado perfeitamente.
Isso não faz nenhum sentido. como é que o passado pode usar o futuro ?
Se vc está falando de ferramentas como planning poker ou kanban, ok, isso é usado em várias metodologias ageis ou não.
Agora , dizer que a metodologia em si é usada antes não faz sentido. Mas sinta-se livre de dar exemplos.
Por exemplo, que metodologia usava Scrum ? Qual usava XP ?
Se até a IBM mudou o seu RUP para o OpenUP porque quer ser agil , não faz muito sentido dizer que RUP é ágil. (embora como eu já disse agil não seja uma metodologia em si)
O que lhe posso dizer é que se alguem já trabalhou assim , e não trabalha mais, então essa forma de trabalhar não era agil. Pela simples razão que se fosse, as pessoas teriam coragem para não deixar mudar as coisas.
O gerente burrocratas que tomaram conta das 'fábricas de software" só pegaram esse lugar porque alguem deixou.Se deixou é pq não tinha coragem para enfrentar essa burrocracia. E se não tinha coragem, se isso não era valorizado, se a pessoa não podia se expressar livremente e colocar em causa essas más práticas, então não existia agil para começo de conversa. Onde existe agil, ha coragem e abertura para mandar esses burrocratas catarem coquinho…
Se os desenvolvedores do seculo passado - a velha guarda - se deixou enganar shame on them. Mas quem desenvolve agora tem que aguentar um sistema que esses desenvolvedores ajudaram a construir. Foram coniventes com a burrocracia e o foram por falta de coragem e repeito para com a profissão e os outros profissionais e até para com os clientes. Quer que eu acredite que existia um paraiso antigamente ? então alguem tem que ser culpado por ele não existir mais ! e quem vão ser esses culpados a não ser quem desenvolvia nessa epoca e deixou as coisas chegararem no nivel que estão hoje ?
Vc quer passar a ideia de que agil não é novidade e que não é bala de prata. Tlv para um culpado pelo sistema atual isso seja a forma de amenizar o problema,porque ele sabe que a bala é para ele. A bala sim é para ele. Todos aqueles que ainda desenvolvem no métodos burrocráticos e imbecis que totalmente violam o profissionalismo e assediam as pessoas moralmente diáriamente sim têm que ser eliminados.
Se agil não é essa bala de prata que matará estes monstruoso sugadores de recursos algo melhor virá. Mas virá. E virá rapidamente porque os desenvolvedores deste século já perceberam que estão sendo enganados.
Quem aqui conhece um gerente que foi despedido porque o projeto atrazou ? E quem aqui conhece projetos que não atrazaram ?
ah!, detalhe, o projeto atrazou assim que alguem sugerir que se façam horas extra.
Vai-nos fazer acreditar que tudo está bem no mundo do desenvolvimento de software ? Ora! ninguem aqui acredita nisso.
Isso é simplesmente mentira. Ninguem que eu conheça trabalha com essa hipotese, muito menos sempre. Logo, nem todo o mundo trabalha com ela sempre.
E muitas outras pessoas que eu conheço tb não conhecem ninguem. Aliás , alguem conhece alguém que sempre trabalha com essa hipotese?
Mesmo que alguns trabalham assim, esses alguns não são a maioria e não têm representatividade para podermos dizer que essa é a norma em desenvolvimento de software. A norma é o gerente não planejar, prometer o que o cliente perguntou e esfolar os desenvolvedores. Vai dizer que é mentira ? Vai dizer que agil não é diferente disso ? Que tautologia vc vai inventar agora para dizer que não devemos seguir agil ?
Y
YvGa
Nao, nao entendi. Leia o texto do Rodrigo Yoshima, para o qual eu pus o link no meu ultimo post e voce vai entender porque eu nao entendi.
Nao conheco uma empresa que utilize, de fato, qualquer metodologia agil e se denomine fabrica de software. Algumas gostam do termo e o anunciam em algum lugar, mas nem sabem o que significa. É assim em absolutamente TODAS as que conheci, por mim mesmo ou por descricao de amigos. O termo fabrica de software nos remete, e é o que essas empresas pregam, a linhas de montagem de software, ou seja, é furada.
Isso é absurdo. As empresas vem ha anos tentando lutar contra a mudanca, buscando formas de neutralizar essas mudancas, tentando pregar que o problema esta na coleta dos requisitos, que os “analistas” precisam saber “tirar” do cliente a informacao precisa. Pregando que os cliente sao responsaveis por um requisito mal formulado, fazendo-os inclusive assinar, registrar, lavrar em cartorio, um termo dizendo, olha esse é o requisito, se precisar mudar a culpa é minha.
E voce vem me dizer que todo mundo sempre trabalhou com essa hipotese? Se isso fosse verdade provavelmente nao estariamos discutindo aqui.
S
sergiotaborda
Não, já disse nos outros posts que não estou defendendo as metodologias tradicionais. Vide respostas anteriores que você deve ter pulado.
E “ninguém pratica” da mesma forma que “todo mundo faz” são termos vazios. Quem generaliza é porque falta argumentos. Será seu caso?
Não. o meu caso é falta de paciência mesmo… vc não entendeu , ou finge que não entendeu, distorce o que eu disse, responde a algo que eu não perguntei e fica nesse ciclo idiota.
Mostre-me os numeros.
O que acontece é que muitas dizem usar e publicitam que usam, mas na realidade é só uma mascara para a mesma burrocracia de sempre. Como não ha nenhuma entidade que certifique que é verdade cada um pode dizer o que quiser…
Concordo que ha muitos que dizem ser e usar, mas o problema é que é mentira que sejam e usem.
Fábrica de software não é toda a empresa que produz software. É um termo prejorativo mesmo. O termo normal é Software House que pode traduzir para Produtora de Software ou Casa de Software. Fábrica de Software designa um tipo especifico de processo de criação de software e não se restringe a empresas que produzem ondemand. Empresas que produzem software internamente tb têm fábricas de software ( aliás quanto mais CLT mais fábrica é).
Diga-me o nome de uma ou duas empresas nacionais que produzem software on demand (para clientes) usando Scrum. E me mostre o depoimento de pessoas que trabalham lá e atestam que é verdade. Curiosidade…
O ponto não é , mais uma vez para ver se vc entende - se existe ou não existe, se já era usado ou não era usado.
O ponto é que enquanto existirem empresas que seguem politicas abjetas, imorais e não profissionais para a criação de software, temos um problema grave. Enquanto existirem empresas que xulam os seus desenvolvedores, teremos problemas. Enquanto a qualidade for negociável, teremos problema. enquanto os desenvolvedores forem tratados como peoes teremos problema.
Existem muitos problemas no desenvolvimento de software que eu e muitos vivemos no dia a dia. Isso é a realidade. sim existem gerentes malvados. E se vc nunca encontrou um, sorte sua. Não é mito. É real. Existe imbecis mentecaptos interferindo com a profissão e a vida de desenvolvedore pelo mundo inteiro pela simples razão que eles nunca são responsabilizados por coisa alguma.
É impossivel usar agil e não ser responsabilizado. É por isso que agil é a esperança para acabar com essa raça de fraudadores.
Quando um cara se passa por médico é preso por falsidade ideologia. Mas quando se passa por gerente de projeto de software nunca lhe acontece nada. É isto que tem que mudar. E agil é uma a solução. É a que temos agora.
Se o seu ponto não é contra agil , nem a favor das metologias tradicionais, afinal o que vc está defendendo ?
Que agil já existe ha 50 anos ? Essa tem até graça pelo anacronismo. Mas sinta-se à vontade de mostrar como agil existe e é prática comum em todas as produtoras de software ha 50 anos.
Y
YvGa
Estou me perguntando a mesma coisa.
M
mochuara
marcosalex:
Eu disse que não devemos seguir agil? Só disse que ele não é novidade. Se você está mudando o que eu disse, acho que o problema não está comigo, ou está?
E essa sua “norma do gerente de software” é que está 50 anos defasada. Se existe algum que faz assim, é minoria faz anos. Fala a verdade, seja sincero: você sabe disso mas não quer dar o braço a torcer.
Discordo. Fabrica de software continua sendo uma aberração bastante comum. Pra piorar agile ta na moda e ganha cada vez mais novos especialistas dizendo que agile tb tem analista, que é tudo a mesma coisa, etc. Acho que não é questão de dar o braço a torcer, até porque sem números pra basear sua afirmação que enterprise software no brasil é agil só pode ser piada.
M
mochuara
Sim. É isso que estamos dizendo faz algumas paginas.
S
sergiotaborda
bom, então - finalmente - descobrimos que o seu ponto é que agil já existia antes.
E depois eu que imagino coisas… mas blz… just for the sake of the argument … explique-nos como é isso. Porque,como viu, ninguem comprou essa…
Eu já expliquei porque acho que isso é falso. O argumento é simples : nunca na historia alguma metodologia ou recomendação foi baseada em valores. Esta é a grande diferença que nunca ninguem introdoziu antes.
Mas, por favor, explique o seu ponto de vista.
S
sergiotaborda
Só para entender pq isso é introduzido na conversa sempre
Moral da historia, Agil é a bala de prata contra Gerentes Malvados.
Y
YvGa
De onde eu disse isso?
Daqui
Aponte, qual empresa, poste um link pro site e se possivel a opiniao de algum desenvolvedor que trabalhe la.
Voce esta se perdendo cada vez mais, Marcos, porque ja estao faltando argumentos, na verdade voce nao sabe nem o que esta defendendo.
Eu insisto, se voce usa XP, como diz que usa, descreva um pouco desse uso no seu dia-a-dia.
S
sergiotaborda
marcosalex:
sergiotaborda:
Eu já expliquei porque acho que isso é falso. O argumento é simples : nunca na historia alguma metodologia ou recomendação foi baseada em valores. Esta é a grande diferença que nunca ninguem introdoziu antes.
Cara, então aproveita a apresentação do Fred Brooks, porque ele já tinha esse valores séculos atrás. hehehe
Já todo o mundo percebeu que vc está enrolando. Mas deixem-me só dizer o seguinte : Fred Brooks não é uma metodologia, é uma pessoa.
Muitas pessoas ao longo dos tempos têm valores compatíveis com ágil. Eu mesmo tinha esses valores antes de ouvir falar de agil.
A questão não é que as pessoas tenham esses valores e sim que as metodologia se baseiem nesses valores. Não adianta muito você ter Foco e Coragem num processo burocrático. Mas essa mesma pessoa numa metodologia agil é mais produtiva e ela se sente melhor.
O resumo da ópera é que agilidade veio para ficar, que sabe o que é agilidade sabe disso. Quem não sabe, não sabe o que é agilidade. Existem muitas pessoas que não sabem e não sabem porque não estudam, não se informam. O mesmo comodismo intelectual de sempre.
Todo aquele que é desenvolvedor sabe o que acontece na sua empresa no dia a dia. E sabe dos defeitos do processos. Sabe que os mérito são sempre de outra pessoa que não a equipa, sabe que às vezes a equipe é hostil . enfim, sabe que o ambiente profissional de desenvolvimento de software tem muitos problemas.
Quem é desenvolvedor profissional sabe o que é qualidade, sabe que ela se consegue com disciplina, com comunicação, com partilha de conhecimento e principalmente com respeito. E sabe que o problema todo é que a qualidade é relegada a ultimo plano nos projetos. Inaceitável profissionalmente, mas comum diáriamente.
Agilidade pode não ser a ultima arma contra esta corja que dá mau nome à profissão e ao nosso trabalho, mas é o melhor que temos por agora. Quem é, ou quer ser, realmente profissional seguirá esse caminho naturalmente. Quem não é, vai descobrir que é melhor procurar outra profissão.
Y
YvGa
marcosalex:
YvGa:
Evidente que eu nao acho que o produto final seja exatamente o reflexo do que foi recolhido nos primeiros requisitos.
Ué, isso que eu quis dizer com software evolui. Se você concordou , porque discordou?
E não, não acho que a a maioria pensa diferente disso. Até porque se pensassem já teriam quebrado.
Voce DISSE que as empresas no Brasil trabalham com esse pensamento faz tempo,o que é uma mentira, elas estao sempre buscando uma forma de eliminar esse problema ao inves de lidar com ele. Nao tente deturpar.
Enquanto existirem clientes pagando a conta absurda elas nao vao quebrar, nao se preocupe.
Sao, sao poucas. Me aponte quais sao as tais muitas que voce tanto conhece.
marcosalex:
Eu conheco apenas uma, em que trabalhei por um tempo e fui eu um dos entusiastas a implantar o processo. Eu acabei saindo de la por achar que valia mais do que me pagavam, mas o processo continua la e minha boa convivencia com a diretoria e desenvolvedores tambem. Eles estao satisfeitos, tanto a direcao como a equipe com os resultados, que sao cada vez melhores a medida que vao adquirindo experiencia. Fora essas, conheco de ouvir falar da Globo.com, da Objective Solutions e da OnCast, mas essas so de ouvir falar, como disse, nao conheco ninguem pessoalmente que possa atestar que realmente sao ageis.
O que eu queria saber sobre o seu dia-a-dia era como voces adotam os valores do XP na pratica, mas esta cada vez mais evidente que voce nao faz a menor ideia desse como.
Sim, Marcos, conheco Srcum e XP na pratica e na teoria, mas conheco muito muito muito menos do que gostaria de conhecer.
P.S. Eu sou a favor dessa defesa aparentemente xiita que alguns adotam das metodologias ageis que é pra que justamente nao acabemos caindo no mesmo mal que caiu o RUP, que foi deturpado a tal ponto que virou a metodologia tradicional sem nunca ter sido. Enquanto mantivermos esse pensamento de “ou faz certo ou nao fala que é agil” talvez as estaremos defendendo dos gerentes sanguessugas que ha tanto tempo defendem os seus gordos salarios somente com blablabla.
Só agil funciona, o resto é conversa fiada pra enganar trouxa.
S
sergiotaborda
marcosalex:
sergiotaborda:
Já todo o mundo percebeu que vc está enrolando. Mas deixem-me só dizer o seguinte : Fred Brooks não é uma metodologia, é uma pessoa.
Sou eu, né? :lol: :lol:
Vc é o Fred Brooks ?! :shock:
O resto não vou responder porque já é palhaçada.
Vc não tem nada coerente a dizer, está só gastando nosso tempo e paciência.
Se vc acredita mesmo no que escreveu, o problema é seu. Se não, é desonestidade moral.
Seja como for não merece mais resposta.
M
mochuara
Ultimamente todo mundo diz que fez projeto Scrum aqui, XP acola, mas quando olha o processo de perto tem iterações que duram 2 3 meses, ou até mais!
Uma vantagem do agil é que existe pouca margem pra enrolação. Ou vc é ou não é. Basta perguntar: ha entregas a cada 1 ou 2 semanas? Então é agil, não importa a metodologia utilizada.
Y
YvGa
marcosalex:
YvGa:
Voce DISSE que as empresas no Brasil trabalham com esse pensamento faz tempo,o que é uma mentira, elas estao sempre buscando uma forma de eliminar esse problema ao inves de lidar com ele. Nao tente deturpar.
Ué, você não acabou dizer que agil está na moda? Não está mais não? Puxa, cara, mudando de opinião desse jeito não estou conseguindo saber se concorda ou não comigo :lol: :lol:
Ou será que as empresas durante o post estão mudando a metodologia e voltando atrás?
Onde eu disse que agil esta na moda? Quem esta dizendo isso é voce. Alias, nem voce sabe mais o que esta dizendo.
É como o Sergio disse, ja ficou claro que voce se enrolou completamento, nem vale a pena mais levar a discussao adiante.
Pois afinal voce é a favor e contra o agil ao mesmo tempo. A favor e contra as metodologias tradicionais ao mesmo tempo.
Y
YvGa
mochuara:
Ultimamente todo mundo diz que fez projeto Scrum aqui, XP acola, mas quando olha o processo de perto tem iterações que duram 2 3 meses, ou até mais!
Uma vantagem do agil é que existe pouca margem pra enrolação. Ou vc é ou não é. Basta perguntar: ha entregas a cada 1 ou 2 semanas? Então é agil, não importa a metodologia utilizada.
Nem assim.
Aqui tambem se prega isso, a cada uma ou duas semanas, algumas telinhas de cadastro tem que estar pronta, sendo que os principais processos da aplicacao ficam por ultimo. Ora se estao fazendo essa entrega a cada duas semanas estao fazendo Scrum, ao que se comprova pelas reunioes diarias, pra saber o que os desenvolvedores estao fazendo. E nao tem Cristo que tire da cabeca deles que isso é Scrum.
Atacar as funcionalidade principais já no comeco é uma coisa que nao entra na cabeca deles nem com reza brava, afinal “como voce vai fazer o processo X se ainda nao cadastrou os itens A, B e C?”
Eu uso testes unitarios sempre, exceto em pequenas alteracoes de codigos legados, mas é uma pratica que nao pega aqui. Alguns desenvolvedores até gostaram da ideia, mas acabam fazendo testes capengas e com pouca cobertura porque nao conseguem desacoplar os objetos, têm muitas falhas nos conceitos basicos OO, o que dificulta bastante a construcao de testes. E pair programming nao preciso nem falar que é motivo de piada. Como eles nao sao meus subordinados fica complicado tentar “corrigi-los” toda hora. Até porque alguns deles tem mais tempo de programacao e muito mais tempo de empresa que eu.
Y
YvGa
Marcos, eu sei que em linguagem escrita nao temos o recurso de entonacao e gesticulacao pra deixar claro nossa intencao. Eu vou tentar te ajudar a compreender o que o mochuara quis dizer.
mochuara:
marcosalex:
Eu disse que não devemos seguir agil? Só disse que ele não é novidade. Se você está mudando o que eu disse, acho que o problema não está comigo, ou está?
E essa sua “norma do gerente de software” é que está 50 anos defasada. Se existe algum que faz assim, é minoria faz anos. Fala a verdade, seja sincero: você sabe disso mas não quer dar o braço a torcer.
Discordo. Fabrica de software continua sendo uma aberração bastante comum. Pra piorar agile ta na moda e ganha cada vez mais novos especialistas dizendo que agile tb tem analista, que é tudo a mesma coisa, etc. Acho que não é questão de dar o braço a torcer, até porque sem números pra basear sua afirmação que enterprise software no brasil é agil só pode ser piada.
Essa foi uma afirmação pura e simples.
Ele diz aqui, e claramente, em forma de ironia, que tem muita gente se dizendo agile sem ser de fato agil, claramente sem mudar velhos conceitos, como no exemplo dado, “que agile tambem tem analista”. A intenção é nítida (e eu estranho a sua interpretacao erronea): Segundo mochuara, e eu concordo, “dizer” que é agil está na moda, mesmo sem conhecer sequer superficialmente o que é agil.
Qualquer semelhanca com o topico é mera coincidencia.
Essa foi uma critica a sua afirmacao de que o que mais existe por ai sao empresas que seguem metodologias ageis (veja, que seguem, nao que dizem seguir), afirmação esta que, de duas ou uma, ou é piada ou é falta de conhecimento sobre o que agil.
S
sergiotaborda
marcosalex:
sergiotaborda:
marcosalex:
sergiotaborda:
Já todo o mundo percebeu que vc está enrolando. Mas deixem-me só dizer o seguinte : Fred Brooks não é uma metodologia, é uma pessoa.
Sou eu, né? :lol: :lol:
Vc é o Fred Brooks ?! :shock:
Me referi à parte do “enrolando”. hehehe
Bom, de qualquer forma, você foi mudando de opinião até concordar comigo.
Só para deixar claro : Eu não concordo, nem concordei, com o marcosalex.
C
ccaneta
mochuara:
Ultimamente todo mundo diz que fez projeto Scrum aqui, XP acola, mas quando olha o processo de perto tem iterações que duram 2 3 meses, ou até mais!
Uma vantagem do agil é que existe pouca margem pra enrolação. Ou vc é ou não é. Basta perguntar: ha entregas a cada 1 ou 2 semanas? Então é agil, não importa a metodologia utilizada.
Mas o que é ser Ágil nesse ponto de vista, como você quer deduzir que cenários são melhores praticados na corporação ???
S
sergiotaborda
ccaneta:
mochuara:
Ultimamente todo mundo diz que fez projeto Scrum aqui, XP acola, mas quando olha o processo de perto tem iterações que duram 2 3 meses, ou até mais!
Uma vantagem do agil é que existe pouca margem pra enrolação. Ou vc é ou não é. Basta perguntar: ha entregas a cada 1 ou 2 semanas? Então é agil, não importa a metodologia utilizada.
Mas o que é ser Ágil nesse ponto de vista, como você quer deduzir que cenários são melhores praticados na corporação ???
O problema está na palavra “agil”. As empresas acham que “agil” é tudo o que
-não tem documentação
-é iterativo
-não precisa planejamento
vai fazendo e depois se vê
Ágil, o real ágil, não é isso. Levar a palavra ao pé da letra leva a esses absurdos ridiculos. As empresas estão, mais uma vez , enganando os trouxas, dizendo que estão seguindo a prática da moda. Só que a prática da moda não é isso.
Ágil é implementado. É uma mudança cultural. Sim existe o praticado certo , o praticado errado e a embromação.
M
mochuara
YvGa:
mochuara:
Ultimamente todo mundo diz que fez projeto Scrum aqui, XP acola, mas quando olha o processo de perto tem iterações que duram 2 3 meses, ou até mais!
Uma vantagem do agil é que existe pouca margem pra enrolação. Ou vc é ou não é. Basta perguntar: ha entregas a cada 1 ou 2 semanas? Então é agil, não importa a metodologia utilizada.
Nem assim.
Aqui tambem se prega isso, a cada uma ou duas semanas, algumas telinhas de cadastro tem que estar pronta, sendo que os principais processos da aplicacao ficam por ultimo. Ora se estao fazendo essa entrega a cada duas semanas estao fazendo Scrum, ao que se comprova pelas reunioes diarias, pra saber o que os desenvolvedores estao fazendo. E nao tem Cristo que tire da cabeca deles que isso é Scrum.
Atacar as funcionalidade principais já no comeco é uma coisa que nao entra na cabeca deles nem com reza brava, afinal “como voce vai fazer o processo X se ainda nao cadastrou os itens A, B e C?”
Eu uso testes unitarios sempre, exceto em pequenas alteracoes de codigos legados, mas é uma pratica que nao pega aqui. Alguns desenvolvedores até gostaram da ideia, mas acabam fazendo testes capengas e com pouca cobertura porque nao conseguem desacoplar os objetos, têm muitas falhas nos conceitos basicos OO, o que dificulta bastante a construcao de testes. E pair programming nao preciso nem falar que é motivo de piada. Como eles nao sao meus subordinados fica complicado tentar “corrigi-los” toda hora. Até porque alguns deles tem mais tempo de programacao e muito mais tempo de empresa que eu.
Este processo que vc descreve é conhecido por Scrud e costuma ser ágil enquanto durarem as telas de cadastro. :lol:
Y
YvGa
:lol: Perfeito.
C
ccaneta
O problema está na palavra “agil”. As empresas acham que “agil” é tudo o que
-não tem documentação
-é iterativo
-não precisa planejamento
vai fazendo e depois se vê
Ágil, o real ágil, não é isso. Levar a palavra ao pé da letra leva a esses absurdos ridiculos. As empresas estão, mais uma vez , enganando os trouxas, dizendo que estão seguindo a prática da moda. Só que a prática da moda não é isso.
Ágil é implementado. É uma mudança cultural. Sim existe o praticado certo , o praticado errado e a embromação.
Sérgio sabe o que é mais triste nisso tudo, é que ninguém tem como fazer alguma coisa, isso é uma verdade eu só não posso afirmar em outras nações se é assim também mas é certo que estão vendendo um monte de ilusionismo sem fundamento, mas eu acredito que isso ocorre, por que ainda não se tem o conceito de consultor independente ainda no Brasil, o profissional que consegui levar a informação com uma expertise ao cliente de forma mais atuante a se ligar ao time de desenvolvimento fazendo o que lhe cabe e com profissionalismo, essa mentalidade não existe ainda.
S
sergiotaborda
Eu sei. Mas eu quero crer que a mentalidade existe sim. Alguns conhecem e sabem essas coisas. O problema é de apoio.
Essas pessoas não recebem o apoio e o respeito necessário tanto dos desenvolvedores, dos clientes, e dos “manda chuvas” das empresas.
Os clientes e os “manda chuva” é até normal. O que é triste e, sinceramente, abjeto, é que os desenvolvedores não tenham ética.
Quando vc vê um colega fazer merda vc vai lá e passa um sermão ? A maioria não faz isso. Leva na boa , ou na brincadeira, e segue em frente. Os desenvolvedores profissionais não exigem profissionalismo dos novatos. E os novatos nem sabem o que isso é. Esse é o problema, a partir dai o resto é mais fácil. Os profissionais não vêem que deixar barato lhes vai sair caro, que é um ciclo.
As pessoas ainda se escandalizam quando é exigido profissionalismo em desenvolvimento de software, como isso não fosse uma profissão de respeito. Não é a Ordem dos Analistas que vai salvar, é a exigencia permanente de profissionalismo e qualidade.
Eu prefiro trabalhar com pessoas de confiança que não sabem nada de java do que com gurus vira-casaca.
C
ccaneta
sergiotaborda:
Eu sei. Mas eu quero crer que a mentalidade existe sim. Alguns conhecem e sabem essas coisas. O problema é de apoio.
Essas pessoas não recebem o apoio e o respeito necessário tanto dos desenvolvedores, dos clientes, e dos “manda chuvas” das empresas.
É aquela coisa eles querem rodar os profissionais e consorciar o projeto, ou seja quem chega para o desenvolvimento já leva um golpe.
Os clientes e os “manda chuva” é até normal. O que é triste e, sinceramente, abjeto, é que os desenvolvedores não tenham ética.
Quando vc vê um colega fazer merda vc vai lá e passa um sermão ? A maioria não faz isso. Leva na boa , ou na brincadeira, e segue em frente. Os desenvolvedores profissionais não exigem profissionalismo dos novatos. E os novatos nem sabem o que isso é. Esse é o problema, a partir dai o resto é mais fácil. Os profissionais não vêem que deixar barato lhes vai sair caro, que é um ciclo.
O que importante é vender a publicidade e vender, o que vai rolar é puritanismos e ninguém se interessa em qualificar ninguém.
Quem vai querer ir contra essa Máfia que já esta ai, ganhando rios de dinheiro ? é complexo.
S
sergiotaborda
Só existe um jeito : criar empresas que produzem software de um jeito saudável e que desbancam as outras por serem mais competitivas. Em algum lugar eu ouvi que a thoughtworks viria para o brasil. Ela tem fama de ser meio dura por impor um esquema de trabalho agil. Se isso for verdade , e ela se conseguir implantar aqui, o mercado vai dar uma guinada. A seguir outras virão seguindo os seus passos.
Y
YvGa
Isso é verdade, enquanto nao acontecer a guinada, enquanto as empresas que utilizam metodologias ageis nao comecarem a incomodar as grandes, nada vai mudar.
As empresas so irao adotar outras metodologias quando sentirem no caixa que estao ficando pra tras. Mas o problema é: será que a maioria delas é capaz de praticar a mudanca fundamental, que é a de valores? Deixar de ver o funcionario como um recurso e passar a tratá-lo como parte integrante da equipe, como um individuo diferente de todos os outros?
Isso eu ja acho mais dificil.
C
ccaneta
sergiotaborda:
Só existe um jeito : criar empresas que produzem software de um jeito saudável e que desbancam as outras por serem mais competitivas. Em algum lugar eu ouvi que a thoughtworks viria para o brasil. Ela tem fama de ser meio dura por impor um esquema de trabalho agil. Se isso for verdade , e ela se conseguir implantar aqui, o mercado vai dar uma guinada. A seguir outras virão seguindo os seus passos.
Agora vem a situação, a Thoughtworks esta preparada para entender a cultura do mercado Brasileiro ?, outra questão que tipo de concorrência vai se desencadear perante as consultorias menores, para exigir um padrão de mão de obra vai ter que pagar equivalente, será que as consultorias estão preparadas para reciclar os seus profissionais, só ai vai ter um competição bem injusta.
Existem profissionais de todos os níveis culturais e já atuando como consultores, a Thoughtworks vai ter um escritório ou pretende ser uma base de desenvolvimento em Software no Brasil, o problema ai é as carteiras de clientes que estão sendo mira para absorver a questão de planejamento e contratação, pode ocorrer uma injustiça para aqueles consultores que vão perder suas oportunidade, por uma mare de profissionais altamente qualificados que podem ser mesmo das consultorias que estão baseados na Inglaterra e vão garimpar projetos aqui.
A filosofia de contratação para brasileiros pode nem ocorrer por a escassez de mão de obra , e essas oportunidades são mesmo para profissionais da Thoughtworks.
C
cv1
Nao so ja esta preparada, como ja temos um cliente brasileiro (onde eu estou trabalhando no momento). Tem alguns truques e macetes, mas nao tem uma diferenca taaaaaaaao grande quanto se imagina dos outros mercados pelo mundo.
Se a concorrencia vier de consultorias menores que prezam por seu trabalho e dedicam seus recursos a formar as melhores equipes de desenvolvimento de software existentes, ficaremos honrados. Nao eh bem o que estamos esperando, no entanto: nossa maior competicao vai ser com consultorias de 3 letras e “alocadores de recursos”, que sao uma praga tao grande no Brasil quanto nos EUA e Australia, e precisam acabar.
Parte da missao da ThoughtWorks eh tambem reeducar os clientes e organizacaoes com quem interagimos; grande parte disso aqui no Brasil vai ser demonstrar que quantidade nao eh qualidade, pelo contrario.
Realmente nao entendi suas afirmacoes neste paragrafo. Elabore um pouco mais, por favor?
Escassez de profissionais qualificados e culturalmente alinhados aos propositos da ThoughtWorks eh um problema global, e a gente tem se virado bem. O Brasil nao eh unico nesse aspecto, e imagino que so teremos as dificuldades serias para achar talento que temos na Inglaterra em alguns anos. Era melhor nao ter falado isso, pq agora eu agourei a coisa toda
C
cv1
So confirmando: sim, a ThoughtWorks vai abrir um escritorio aqui no Brasil, e ja estamos contratando e passando o pessoal pelo processo seletivo (que vai demorar um pouquinho mais do que de costume, talvez algumas semanas).
Vou publicar um FAQ com mais informações daqui alguns dias, mas se alguém já quiser adiantando, envie a carta de apresentação e currículo (ambos em inglês) para [email removido].
C
ccaneta
cv:
Realmente nao entendi suas afirmacoes neste paragrafo. Elabore um pouco mais, por favor?
Vou resumir a Thoughtworks vai demolir as consultorias pequenas, sem dizer que traz de bagagem cenários com case de sucesso em projetos Ágil, em vista que no Brasil as consultorias se encontram mesmo na esfera dos tradicionais processo de desenvolvimento, na oportunidade a mesma vai promover seu marketing que já é liderado por Martin Fowler, o que vai tornar ainda mais arrasador um verdadeiro massacre.
Y
YvGa
ccaneta:
cv:
Realmente nao entendi suas afirmacoes neste paragrafo. Elabore um pouco mais, por favor?
Vou resumir a Thoughtworks vai demolir as consultorias pequenas, sem dizer que traz de bagagem cenários com case de sucesso em projetos Ágil, em vista que no Brasil as consultorias se encontram mesmo na esfera dos tradicionais processo de desenvolvimento, na oportunidade a mesma vai promover seu marketing que já é liderado por Martin Fowler, o que vai tornar ainda mais arrasador um verdadeiro massacre.
Mas isso tudo vai ter um custo. Talvez por ai as consultarias pequenas continuem com seu espaco. Apesar de que qualquer coisa que venha pra implodir a forma como se faz software aqui é bem vinda. Ou as empresas acordam e se tornam menos burocraticas ou vao ter prejuizo.
C
ccaneta
Mas isso tudo vai ter um custo. Talvez por ai as consultarias pequenas continuem com seu espaco. Apesar de que qualquer coisa que venha pra implodir a forma como se faz software aqui é bem vinda. Ou as empresas acordam e se tornam menos burocraticas ou vao ter prejuizo.
Infelizmente as coisas não são tão simples assim, consultoria pequena tem parceira com outras consultorias é como se fossem países menores aliados com outros maiores, pode esperar sim uma guerra entre uma mudança por uma tecnologia melhor sendo liderada por consultoria de renome, algo como se você é um profissional que trabalha com X tecnologia e não estiver atuante com X metodologia pode ser alvo de eliminação em projetos já desejados por corporações, que querem mudanças rapidas e atingir melhores economias, o bicho vai pegar.
Y
YvGa
ccaneta:
Mas isso tudo vai ter um custo. Talvez por ai as consultarias pequenas continuem com seu espaco. Apesar de que qualquer coisa que venha pra implodir a forma como se faz software aqui é bem vinda. Ou as empresas acordam e se tornam menos burocraticas ou vao ter prejuizo.
Infelizmente as coisas não são tão simples assim, consultoria pequena tem parceira com outras consultorias é como se fossem países menores aliados com outros maiores, pode esperar sim uma guerra entre uma mudança por uma tecnologia melhor sendo liderada por consultoria de renome, algo como se você é um profissional que trabalha com X tecnologia e não estiver atuante com X metodologia pode ser alvo de eliminação em projetos já desejados por corporações, que querem mudanças rapidas e atingir melhores economias, o bicho vai pegar.
Nao acho que a coisa vai ser tao radical assim, até porque a Thoughtworks tem renome somente entre os desenvolvedores, pelo menos no Brasil, e mesmo assim, entre um grupo de desenvolvedores apenas. E como todo mundo sabe, na imensa maioria das empresas nós nao apitamos nada.
Logico que basta um pouco de marketing pra que ela se torne mais conhecida, mas mesmo assim as coisas nao vao mudar tao rapidamente assim como voce imagina.
Infelizmente…
C
cv1
ccaneta:
cv:
Realmente nao entendi suas afirmacoes neste paragrafo. Elabore um pouco mais, por favor?
Vou resumir a Thoughtworks vai demolir as consultorias pequenas, sem dizer que traz de bagagem cenários com case de sucesso em projetos Ágil, em vista que no Brasil as consultorias se encontram mesmo na esfera dos tradicionais processo de desenvolvimento, na oportunidade a mesma vai promover seu marketing que já é liderado por Martin Fowler, o que vai tornar ainda mais arrasador um verdadeiro massacre.
E desde quando demolir consultorias que nao fazem um trabalho melhor que o nosso eh uma coisa ruim?
Juro que eu nao consigo entender o seu ponto de vista ate agora…
C
ccaneta
cv:
E desde quando demolir consultorias que nao fazem um trabalho melhor que o nosso eh uma coisa ruim?
Juro que eu nao consigo entender o seu ponto de vista ate agora…
É como se as evoluções das coisas acontecessem no mesmo nível de projeto e experiência, como se todo o acesso a informação e conhecimento tivesse a mesma equivalência.
Faria melhor sentindo se a Thoughtworks absorvem-se essas consultorias e remodelá-se as dando-as condições de produtividade em seus projetos, entretanto vai ser mesmo algo como colonias de exploração ou sem qualquer participação em seus projetos de maior relevância.
C
cv1
E a sua evidencia para suportar este argumento esta baseada em que?
R
rubensdemelo
Tem muito analista de mercado aqui no GUJ.
C
ccaneta
E a sua evidencia para suportar este argumento esta baseada em que?
Para se modelar um perfil profissional de uma empresa como a Thoughtworks, que jornada de estudos e risco e investimentos você não teve que passar , estamos falando de especializações até ainda nem atingida por muitos profissionais.Você voltaria a trabalhar no Brasil como consultor ? Claro que não, seria um retrocesso da própria carreira e na certa não iria atingir a mesma rede de clientes, onde sua empresa vem implementando cases a tempos, e com muitos clientes já endinheirados. “software de sucesso é mesma coisa que aplicação em bolsa de valores”
Dizer a Thoughtworks, que esta no Brasil e falar que esta com as portas abertas, isso é pura groselha, mas dizer que tem uma proposta em redesenhar o mercado de desenvolvimento de software como apoio ao software livre, entre melhores praticas ao Open Source e outras questões à alavancar situações econômicas, transferência de conhecimento sobre as metodologias que são tradicionais utilizando uma nova concepção onde mante-las, ou como fazer a implementação com metodologias Ágil aplicáveis sobre uma transparecia da tecnologia utlizada, ninguém tocou no assunto e nem se quer eu ouvi falar.
E ai aparece o Encontro Ágil como se tudo isso já fosse algo mais praticado e dominado por muitas consultorias, essa natureza de fazer informação e de proposta para contemplar a todos um novo movimento ou uma nova passagem geração só vem aumentar o nível contra-senso de nunca te-las praticado em cases de empresas nacional, é algo pra se dizer, seja Ágil para se alocar em quem esta com os melhores clientes, porque informação não é pra todos.
A
aleck
Existem muitas consultorias de qualidade no país, se os clientes preferem consultorias piores é algo político e não está relacionado com qualidade.
A Thoughtworks vai ser mais uma opção que os clientes que buscam qualidade irão buscar, como já acontece atualmente.
C
cv1
Sim, e eu ja voltei para o Brasil como consultor… pela ThoughtWorks. Nao entendo onde esta o problema nisso.
Err… vou tentar explicar de novo, com frases menores e de forma mais facil de entender. Voce me parece estar muito confuso.
Eu sou um dos 1200+ consultores da ThoughtWorks.
Eu estou no Brasil.
Pela ThoughtWorks.
Que abriu no Brasil ha poucas semanas.
Eu estou trabalhando num projeto como coach.
Pela ThoughtWorks.
No Brasil.
Mas, como eu nao dou conta sozinho de toda a demanda que a gente tem, a ThoughtWorks esta contratando mais profissionais no Brasil.
A ThoughtWorks Brasil fara as mesmas coisas que os outros escritorios da ThoughtWorks pelo mundo fazem. Isto inclui:
Desenvolver software customizado para clientes de qualquer porte usando praticas e metodologias ageis
Transformacao organizacional
Criar e participar de projetos OpenSource
Coaching e mentoring em praticas do XP
Gerencia de qualidade de projetos
Definicao de metricas de acompanhamento e gerencia de projetos
etc, etc, etc, e nao necessariamente em uma ordem qualquer.
Ficou mais claro?
N
neofito
cv:
Eu sou um dos 1200+ consultores da ThoughtWorks.
Eu estou no Brasil.
Pela ThoughtWorks.
Que abriu no Brasil ha poucas semanas.
Eu estou trabalhando num projeto como coach.
Pela ThoughtWorks.
No Brasil.
Mas, como eu nao dou conta sozinho de toda a demanda que a gente tem, a ThoughtWorks esta contratando mais profissionais no Brasil.
CV, esse projeto é em São Paulo?
N
Nykolas_Lima
CV, a ThoughtWorks está contratando par ao escritório do Brasil somente profissionais com grande experiência ou júnior e estágio também?
C
cv1
Sim, esse projeto em que eu estou eh em Sao Paulo.
A sede da TW Brasil vai ser em Porto Alegre, inicialmente.
Por enquanto, estamos contratando desenvolvedores com ao menos 2 anos de experiencia. Idealmente, 5 ou mais.
T
tnaires
CV, caso ainda não tenha reparado, você está falando com “o cara cujos pelos do peito se parecem com duas hello kitties se beijando”, segundo você mesmo… :lol:
C
ccaneta
A ThougthWorks seria hoje a empresa ideal para se atuar a agregar valor em mão de obra, principalmente em uma empresa onde seu principal gestor é o Martin Fowler, uma projeção profissional da melhor possível.
Testar todas as combinações existentes dos campos para garantir que a tela funciona. Para uma busca com ?a? campos, existirão 2ª combinações.
