Agilidade é exatamente isso!
anotar o que o cliente quer num papel A4 está de acordo com o 1o, 2o, 3o e 4o princípios ágeis.
bota-lo do seu lado está de acordo com o 1o e 3o princípios ágeis.
sair programando está de acordo com o 2o princípio ágil.
[quote=flaleite][quote=richardpeder]
O desenvolvimento de software não vai voltar em como era nos anos 90…
[/quote]
Richard,
Vejo como uma tendencia forte dos anos 90 a utilização de RUP, waterfall, documentação, ciclos de 2 anos de duração,etc…
Agora como tendencia forte dos anos 2000 são as metodologias ágeis, documentação apenas essencial, ciclos curtos, etc…
Já participei de projetos grandes em grandes multinacionais e cheguei em alguns projetos participar da apresentação do projeto para a presidência e na grande maioria das apresentações do projetos a maior parte da apresentação do projeto era mostrar resultados e melhorias.
[/quote]
Concordo plenamente. Inclusive RUP é usado sim (uma parte apenas pois ele todo é doidera). Mas o amigo aí dizer que é tudo no papel rascunhado? Isso não quero nem discutir pois é algo que nao consigo nem imaginar, me perdoem pela franqueza.
ate mais…
Luca,
A confecção de artefatos de analise do projeto não precisa caracterizar a criação de um milhão de artefatos. Concordo com o que o flaleite disse…ciclos curtos, artefatos essenciais…projtos ageis…o negócio aqui é eu nao concordo com o fato de ser em papel de pao as coisas…não tem como conceber uma coisa destas. Os artefatos foram criados para que a “zona” que era antigamente ficasse organizada (ao meu ver). Vamos retroceder então?
ate mais…
Olá
O que não entendo é porque precisam ser refeitos pelo analista em seu escritório se tudo já foi discutido na presença do cliente. Quando falei em fotos da lousa nem quiz me referir a uma coisameio cara que já usei em 2002/2003 que é a lousa eletrônica que captura os desenhos como um scanner.
Fazer um desenho de um diagrama de classes com uma canetinha na lousa é muito mais rápido do que usando qualquer programa gráfico. Exigir do analista ou programador habilidades no uso de programas gráficos é absolutamente desnecessário depois que inventaram a câmara digital.
E muitas câmaras digitais são como a minha que com seus 4Gb é capaz de gravar mais de 2 horas de reunião. Me custou menos de 800 reais e talvez seja mais barato do que a licença de uso do Visio + horas de treinamento.
[]s
Luca (com 62 anos mas já em 2007)
Não o RUP só começou a ser mais utilizado no fim dos anos 90 (o primeiro release foi em 1998). No ínicio dos anos 90 não tinha nada disso, quer saber, nem Waterfall. Era um desenvolvimento iterativo, mas a gente nem sabia o que era isso. Era bem “programar do lado do cliente” mesmo. Isso acontecia em indústrias pequenas e comercio. Bancos creio que tinha uma tendência maior para Waterfall, pois eram os projetos maiores.
As equipes de desenvolvimento eram um grupo coeso de programadores. Não era as mil maravilhas, mas o sentimento a respeito do processo de desenvolvimento era muito melhor do que temos hoje. O que era ruim era a parte de engenharia (garantir coesão, acoplamento). No geral me lembro que os clientes eram mais satisfeitos.
Agilidade é exatamente isso!
anotar o que o cliente quer num papel A4 está de acordo com o 1o, 2o, 3o e 4o princípios ágeis.
bota-lo do seu lado está de acordo com o 1o e 3o princípios ágeis.
sair programando está de acordo com o 2o princípio ágil.
[/quote]
Então trabalhe desta forma…e boa sorte.
ate mais…
como sempre o luca arrebentou… boa opniao… hehe o que vale é a experiencia… concerteza, o que o luca falou vai se ganhar tempo… e realmente tem cliente que vc pode so conseguir 1 ou 2 reunioes no mes… por exemplo se for um diretor de uma empresa de medio/grande porte iai? Você acha que ele tem qualquer dia da semana? qualquer horario? Não.
Agora se seu cliente for uma empresa pequena… é bem capaz de vc tomar café todo dia com o proprietario…
flw!
[quote=LPJava]como sempre o luca arrebentou… boa opniao… hehe o que vale é a experiencia… concerteza, o que o luca falou vai se ganhar tempo… e realmente tem cliente que vc pode so conseguir 1 ou 2 reunioes no mes… por exemplo se for um diretor de uma empresa de medio/grande porte iai? Você acha que ele tem qualquer dia da semana? qualquer horario? Não.
Agora se seu cliente for uma empresa pequena… é bem capaz de vc tomar café todo dia com o proprietario…
flw![/quote]
não é bem assim…
o cliente é o maior interessado no sucesso do projeto.
se ele não tem disponibilidade para trabalhar junto no projeto, é sinal que talves não seja tão importante p/ ele.
por isso se deixa bem claro que ele é parte fundamental no processo, e ele tem que estar SIM disponivel durante o projeto.
[]'s
Olha como ja tenho um bom tempo em analise e desenvolvimento, posso afirmar que o metodo agil veio para ficar inclusive la fora e muitissimo usado, aqui que estamos meio para tras nesse requisito, e tambem concordo que no comeco dos anos 90, o desenvolvimento de sistemas era muito, mas muito parecido mesmo com o metodo agil de hoje em dia, quase nao tinhamos ferramentas case, modelagens, gant, project e essas coisas, e tudo era feito do lado do cliente, e quer saber… os sistemas saiam o que o cliente esperava, e o melhor, ele era a nossa melhor propaganda. Sei tambem que os analistas mais jovens tem muita dificuldade em usar papel e caneta, mas tudo e uma questao de costume, e como pegar um arabe radical que acha q tudo aqui e do sata, mas e pq ele nao conhece. Tudo que chega na cabeca dele e aquilo, e ele cresce acreditando que aquilo e certo.
Quem aqui conseguiu dar manutencao em codigo dos outros somente olhando a documentacao ??? Eu apos mais de 16 anos na area nao conheci ninguem, nem de pequena e nem de empresas enormes como a IBM. A melhor documentacao e um programa bem escrito e ponto final. Logico que alguma documentacao para passar para o time, se este for grande, e importante, mas nao perder muito tempo com isso, o ideal e so o essencial para que eles tenham a ideia para comecar. Acho que voces que nao acreditam que o metodo agil veio para ficar, deveriam sair do Brasil um pouco, e nao so ler em 3 ou 4 foruns, tenho certeza de que irao voltar com uma nova idea. Claro que dependendo da hierarquia da empresa, alguma documentacao vai ser necessaria, mas com o tempo isso tende a diminuir muito.
E tem tambem a dificuldade das pessoas que sempre usaram (uns 60%) do RUP ou PMBOK a terem dificuldades no comeco, isso e normal. E comparada a quando voces sairam das procedurais para o mundo OO, que diga-se de passagem melhorou bem a manutencao de codigo (exeto aqueles feitos por indianos, que sao triste… acreditem). E por fim, se vc nao quer usar o papel para usar como doc, perca tempo depois passando eles para um meio digital.
Nao sei talvez eu hoje esteja errado, mas nao e o que a expereiencia tem me mostrado. Lembrem-se:
Existe dois tipos de pessoas no mundo. Uma que aprende com os proprios erros e outras com a experiencia alheia, agora cabe a voce decidir quem quer ser!
Olá
Gostei das suas observações. Muito bom ler gente com experiência e que chegou a mesma conclusão do que eu: os métodos burocratizadados não deram certo. Serviram apenas para vender… consultorias sobre metodologia burocratizante. A verdade nua e crua é uma só: esta questão de certificação CMM etc. e tal é um produto a venda com muito marketing por trás. Na prática os resultados são pífios.
Plenamente de acordo.
[]s
Luca
Não sei se vocês concordam, mas depois dos projetos Y2K é que o mercado começou a ficar maluco…
Senhores, até pouco tempo atrás achava que os requisitos deviam estar 100% fechados e isto gerava um problema que eu batizei de “corrida do hamster”.
Imaginem aquele ratinho preso em uma roda correndo, correndo, correndo… e nunca chega a lugar algum!
Bem, este é era o problema:
Visitava o cliente e realizava o levantamento de informações com ele ou com a área usuária do sistema, depois voltava para “casa” e produzia durante alguns dias vários casos de uso e agendava uma reunião para aprovação dos casos de uso.
Na aprovação não conseguia aprovar nada! Pois neste momento o cliente econtrava pontos que, na grande maioria das vezes, ele não havia identificado anteriormente. E então neste momento, depois de uma boa discussão, realizava a compilação dos requisitos e voltava para “casa” para atualizar a documentação e realizar uma posterior aprovação.
Sabe quando isto acabava? Nunca!! Ou então consumia muito, mas muito mais do que havia sido planejado!!
E mesmo quando acabava um dia e eu consiga falar: “Fechei todo o escopo do projeto com o cliente e aprovei com ele a definição de todos os requisitos!”; quando realizada a entraga do software para o cliente eu escutava a cérebre frase: “Não era bem isto que eu queria!”.
Para tentar sanar isto comecei a ler e pesquisar sobre métodos ágeis e percebi que se ao invés de aprovar documentação aprovar o software, quando eu chegar ao ponto de dizer: “Fechei todo o escopo do projeto com o cliente e aprovei com ele a definição de todos os requisitos!”, terei software pronto, entregue ao cliente e em alguns casos até indo para produção, ou seja, conseguirei resolver o problema do cliente de forma rápida e com qualidade.
Não estou dizendo que não devemos documentar, muito pelo contrário!
Para vocês terem uma idéia, atualmente utilizo Scrum e gero os seguintes documentos:
- Documento de arquitetura e de definição funcional (caso de uso), feitos em ferramenta Wiki
- Javadoc das classes
- Os protótipos de telas são feitos em rascunhos junto com o cliente, digitalizados através de fotos e publicados no Wiki;
- Modelos UML do domínio de negócio são feitos em um quadro branco com a participação de todos (até do cliente quando necessário) e depois fotografados e adicionados ao Wiki.
Eu também achava que não conseguia produzir software sem antes produzir uma boa quantidade de documentos: documento de visão, caso de uso, diagrama de fronteira, diagrama de domínio, documento de arquitetura, plano de testes, roteiro de testes, etc, etc, etc.
E percebam que continuo fazendo isto, só que de uma forma mais ágil e com o foco no software (na realidade, em resolver o problema do cliente) não no documento.
Ola,
Entao Rodrigo, acho que sim, mas tambem pelo fato de termos muitas MS´s no mercado, que ao meu ver ela sempre acerta no alvo, pq ela atira e depois desenha o alvo em volta rsss. Tipo ela cria o software e depois cria um monte de usos para ele que ninguem nunca imaginou precisar, ou nao precisava mesmo. E ai na corrente vem as faculdades ensinando a ferramenta X e por ai vai. Gerando profissionais cada vez mais dependente dessas ferramentas e criando um circulo vicioso com cada vez mais ferramentas que se completam. Resumindo e tecnicamente falando, com essa enorme parafernalia, acho que em vez de simplificar… complicou e o mais incrivel e que na nossa profissao que vivemos exclusivamente de criar boas ideias e para isso deveriamos ser inteligentes! Ou seja na media devemos ser mais inteligentes que a maioria das outras profissoes certo ? Fizemos o contrario, nos conseguimos complicar!!! Nao precisa nem ir longe… e so ver q a nossa profissao ainda nao e regulamentada!! rsss
Mas como ja disse uma vez, e afirmo… os metodos ageis vieram para ficar.
Abraco
A experiência que tive foi a seguinte (projeto em que trabalhamos há 4 anos):
No início do projeto queríamos fazer uma enorme documentação. Aquilo consumia um tempo terrível isso quando não tínhamos que ficar ajustando documentação onde a análise mudava por causa de um requisito que o cliente “esqueceu” de mencionar. Era um adepto desta documentação excessiva.
Acontece que com o tempo, isto foi ficando inviável e realmente nenhum programador da equipe recorria à documentação para tirar dúvidas. O fonte era a melhor inspiração.
Ainda defendo muito a presença de analistas de sistemas, mas tomamos outros caminhos para a documentação. Ela é mais direta. Criamos um programa para gerenciar isto e vem funcionando muito bem. É bem mais rápido ter uma conversa com o cliente e transcrever pontos importantes no nosso programa interno à nossa maneira do que ficar fazendo meia tonelada de documentação. E estas transcrições normalmente servem para o processo de análise e desenvolvimento. Depois disso, só recorremos à elas se não tiver outra saída.
Eu fiquei meio desiludido com tudo isso e queimei a língua. E vejo empresas por aí com alguns certificados mas na prática o resultado do software (e da empresa) não mudou quase nada.
Posso estar enganado, mas acho que toda essa burocracia pouco auxilia. O que vejo é um cliente me falando: tenho um problema x e y, o que vamos fazer para resolver? Ficar 1 semana montando papel pra jogar na mesa dele não é algo que me vejo fazendo.
Talvez por ironia, toda aquela documentação inicial, hoje inútil, virou rascunho.
[quote=Luca]Olá
Gostei das suas observações. Muito bom ler gente com experiência e que chegou a mesma conclusão do que eu: os métodos burocratizadados não deram certo. Serviram apenas para vender… consultorias sobre metodologia burocratizante. A verdade nua e crua é uma só: esta questão de certificação CMM etc. e tal é um produto a venda com muito marketing por trás. Na prática os resultados são pífios.
Plenamente de acordo.
[]s
Luca[/quote]
eu gostei dessa parte tb:
[quote]Lembrem-se:
Existe dois tipos de pessoas no mundo. Uma que aprende com os proprios erros e outras com a experiencia alheia, agora cabe a voce decidir quem quer ser!
[/quote]
heheh 
Em times trabalhando em localidades diferentes (distribuída às vezes em muitos países) não funciona de outro jeito.
Claro que pra dar manutenção vc precisa do código fonte, afinal: vai dar manutenção em que?
Mas eu já peguei software de outra equipe e sem entender nada comecei a dar manutenção em pouco tempo auxiliado pela documentação.
Bom dia, eu sou um pouco experiente que todos aqui que ja postaram neste topico, sei que nao vou dizer coisa nova, mas acredito eu que a documentação que vai ser feita para um projeto e muito mais importante para nos que estamos participando de todo o ciclo de desenvolvimento, do que para o proprio cliente, que mesmo nao querendo saber inicialmente nada da documentação, depois ele vai querer algo para demonstrar tudo que você fez no projeto. E isso e bom pra nós nos prevernimos de qualquer coisa que aconteca de errado logo apos a implementaçao do projeto, pois quando o cliente perguntar você tem tudo guardado.E se formos uma pessoa “da empresa”, com certeza, quando um dia sairmos de la, temos que deixar algo para que o proximo analista venha e tenha tudo ja certinho para que ele nao tenha que refazer todo o processo.
Onde trabalho, existe alguns softwares um pouco antigos e ja estaveis que possuem documentacao em UML. As vezes precisamos fazer pequenas alteracoes, e quando temos de faze-las, todos nós programadores da empresa, sabe onde procuramos??
Errado se vc pensou na documentacao. Nem sei se ela foi bem escrita ou nao, ninguem sabe. Nós vamos direto no código.
Me responda com toda a sinceridade se voce, por iniciativa propria, ja procurou algo em uma documentacao que nao tenha sido escrita por voce mesmo.
[quote] mesmo nao querendo saber inicialmente nada da documentação, depois ele vai querer algo para demonstrar tudo que você fez no projeto. E isso e bom pra nós nos prevernimos de qualquer coisa que aconteca de errado logo apos a implementaçao do projeto
[/quote]
O que ele vai querer é software que funcione, nao vai querer papel. A unica forma de demonstrar que tudo que voce fez no projeto está implementando é mostrando o software funcionando. E a maneira de nos previrnirmos de algo que aconteça de errado e fazendo testes.
Eu trabalho com desenvolvimento de software ha mais de 10 anos e nunca foi perguntado se tinha documento guardado. Talvez seja uma exigencia de empresas grandes (trabalhei sempre em pequenas e medias), mas é preciso que haja consciencia do custo adicional da documentacao.
[quote]
E se formos uma pessoa “da empresa”, com certeza, quando um dia sairmos de la, temos que deixar algo para que o proximo analista venha e tenha tudo ja certinho para que ele nao tenha que refazer todo o processo.[/quote]
Temos que deixar codigo bem feito.
Tem muita gente que confunde agilidade com baderna, tem gente que pensa que nao fazer milhoes de diagramas é a mesma coisa que nao ter requisito, nao ter norma.
Os processos ageis sao muito mais faceis de controlar, de dimensionar, de saber da evolucao do que os processos tradicionais. Se engana quem pensa que bagunça e anarquia.
Documentacao em excesso, gera burocracia com quase nada em troca.
Nossa… nunca vi (nem ouvi) tamanho absurdo!!!
Fujam… os porcos estão dominando o mundo!!!
Quase 5 (CINCO) anos depois estou revivendo esse tópico! E ai? As coisas mudaram ou não?! 