Arquivo Discussoes de Programacao e Tecnologia 
Bom dia Pessoal!
Gostaria que alguém pudesse disponibilizar os templates dos modelos de documentação de um sistema de médio porte. Pode estar em .doc mesmo. Pode ser qualquer tipo que vocês conseguirem, casos de uso, visão, especificação, caso de teste…
Os que achei no google, não me interessaram.
Ficaria muito grato, é simples, basta fazer o upload aqui no post mesmo!
Valeu galera, abraços! 
Dá uma olhada no OpenUP:
Os modelos de documentação agregam muito pouco para definir um processo. As atividades são mais importantes que os artefatos.
Os modelos de documentação agregam muito pouco para definir um processo. As atividades são mais importantes que os artefatos.
No meu caso, o problema é a exigencia do cliente…
Estou baixando por que esse assunto me interessa muito, mas o que contem nesse “zip” do OpenUP?
OpenUp pelo que andei vendo é algo parecido com o RUP certo?
@Rodrigoy: Não acredito que haja algo mais importante (artefato ou atividades do processo). As atividades de cada processo geram artefatos…um tem ligação com o outro e para ter um processo de fato vc tem entradas, processamento e saídas (em linhas gerais) e nisso tudo os artefatos estão presentes…não existe grau de importancia na minha visão não.
ate mais…
Tem o processo… é um site em html com atividades, fluxos de trabalho, guidelines e os modelos de templates que você está procurando.
@Rodrigoy: Não acredito que haja algo mais importante (artefato ou atividades do processo). As atividades de cada processo geram artefatos…um tem ligação com o outro e para ter um processo de fato vc tem entradas, processamento e saídas (em linhas gerais) e nisso tudo os artefatos estão presentes…não existe grau de importancia na minha visão não.
Não necessariamente uma atividade TEM que gerar um artefato (é aquela história do conhecimento tácito, conhecimento explicíto e blá blá blá blá blá blá…). Se você senta com o cliente e conversa sob um determinado assunto do projeto, e sai dessa conversa com conhecimento do negócio, é essa ATIVIDADE que é importante. Se você junta sua equipe para conversar sobre arquitetura, e faz diversos rascunhos em papel usando rabiscos nem um pouco UML 2.0 compliant, é a dinâmica da equipe que é importante, esses rascunhos não são considerados artefatos.
Essa história de “recebo artefatos - executo a tarefa - cuspo artefatos” deve funcionar bem em cartório, linha de produção, banco… Essa visão mecanicista nunca funcionou para desenvolvimento de software. E vou além, essa não é a visão do UP.
Vou falar um pouco sobre isso na minha coluna, mas infelizmente estou escrevendo agora o que só vai ser publicado em janeiro.
Ou seja, se vc tem esse monte de papel rabiscado tá bom? Me perdoe Rodrigo, mas eu não sei trabalhar desta forma não. Um pouco de organização e sistemática não faz mal a ninguem. Vc ir lá, conversar com seu cliente, entender a atividade dele e passar isso em alguns documentos é muito mais organizado e fica mais facil de prosseguir com as coisas. eu sou adepto dos bons processo sim, mas, seguir a sistemática toda tb não é algo que vc precise fazer “religiosamente”, no entanto, se vc não documenta o que seu cliente quer como desenvolve o sistema? Com os rabiscos? Fala sério. :?
ate mais…
Está bom quando temos:
É uma questão de custos… o que o cliente quer de fato é o software e não os documentos. O fato de usar rascunhos (veja, rascunhos, e não rabiscos como vc colocou) não tem relação alguma com organização ou maturidade do processo. Meu rascunho no papel A4 pode ser muito melhor para obter os RESULTADOS que listei acima do que usando ferramentas que custam milhares de dólares.
Tome cuidado com processos que PARECEM organizados com aqueles que SÃO organizados de fato. O que o cliente quer é o software e não os documentos que abstraem o que se espera do software. De fato, meus artefatos de requisitos são rascunhos de Domain Models, rascunhos de casos de uso, rascunhos de protótipos de tela, rascunhos de diagrama de atividades. Tudo em papel A4, desenhados junto com o cliente (e com isso, automaticamente aprovados por ele). Com esses “rabiscos” na mão, volto para casa e transformo isso em software funcionando, seguindo boas práticas de engenharia.
Dentro do processo não se pode gastar muita energia em levantar requisitos antecipadamente. Desenvolvimento de software é uma atividade de codificação.
Na próxima vez que encontro cliente, mostro o software permitindo que o cliente faça as alterações e ajustes necessários (e isso não tem relação com o fato de ter usado papel A4). Então pego mais papel A4 e mais modelagem…
Software funcionando é o melhor artefato para levantamento de requisitos.
e quando vc precisa dar manutenção olha no rabisco no A4? hehe eu entendi o q vc quis dizer tb ja fiz isso… e no cliente pouco me importa o software… é na mao mesmo de forma q eu entenda… e ainda mostro para ele é assim e talz… agora e o rabisco fica para mim… porem para a equipe eu tenho que usar um software ou no mesmo velho word passo exatamente como está no rabisco e mostro a equipe… o motivo é que com minha letra a equipe nao vai entender ou pode entender errado, e digitado e impresso é meio dificil hehhe… mais é isso ai o cliente que o software atendendo a sua necessidade… como vc implementou isso, é um problema seu… pq se amanha quando começar dar pau, ou precisa melhorar o sistema… é importante ter toda documentacao em maos… para ganhar tempo… 
Depende do cliente…e depende muito…
Trabalho a 5 anos na área e nunca vi um cliente querer só o sistema…geralmente, se vc fica responsável pela analise, ele vai querer os UC’s, Diagramas e demais documentos sim…e eles pagam por isso com certeza! Se ele compra seus testes pro sistema…ele vai querer os docs que usou pra testar, evidências dos testes realizados, as vezes até uma analise detalhada dos testes realizados e pelo modelo que vc está me dizendo vc faz a parte de analise tb, ou seja, a fase de analise fica sob sua resp então, neste modelo, não tem como fugir…se fosse só “controi e me entrega”, até poderia ser só entregar o codigo já que a analise vc não poe a mao.
Não sei em que empresa vc trabalha, mas nas que trabalhei nestes meus 5 anos na área JAMAIS vi vc só entregar o código fonte e fazer tudo em rascunho…acho isso um baita absurdo sem cabimento algum.
ate mais…
Não, não depende não… o mercado pede essas besteiras só por adaptação aos padrões. No geral, quem compra (compradores dos clientes) e quem vende (vendedores de fábricas) são mal preparados para a função. Eles acham que com a documentação vão garantir uma melhor qualidade interna do software, mas documentação não garante isso.
Nesses 13 anos na área eu nunca ví um cliente que quer um sistema… o que ele quer na verdade é resolver um problema de negócio… não somos pagos para fazer casos de uso, nem diagramas, nem código… nós somos pagos para resolver um problema de negócio…
Sim, eles jogam dinheiro fora com outras coisas também… como falei, é uma ilusão achar que casos de uso, diagramas e demais documentos colaboram para a qualidade interna do software. CMMI, MPS.BR, ISO não garantem que o cliente terá ROI com o projeto. O mercado está tendo que gastar alguns bilhões para aprender isso. Felizmente isso está mudando.
Cara, você está colocando um cenário da maneira que um cara entra numa fábrica de software e diz: - Quero requisitos, quero desenvolvimento… ahh… hoje eu quero testes também! É a mesma coisa que você chegar numa concessionária de carros e falar: -Hoje está calor… quero só o ar-condicionado do carro por favor…
Ai meu Deus… esses caras de fábrica teimam em separar o desenvolvimento de software entre design e construção. Não existe essa separação, desenvolvimento de software é 100% design. Até testar o software é design. NÃO EXISTE UMA FASE DE ANÁLISE. ALIÁS, NÃO EXISTEM FASES! Meus artefatos de análise são: o próprio código, meus TDDs, os comentários no código e talvez mais um documento de arquitetura. Se por alguma razão achei interessante modelar alguma coisa usando ferramenta (sim, eu uso ferramentas UML, mas sempre focando o código e não o modelo), trato de transformar logo em código.
Richard, trabalhei e presto consultoria em diversas empresas (inclusive, algumas eu ajudo a reduzir a concepção do software de algumas semanas para algumas horas). Eu trabalhei com software antes do mercado ficar maluco, e foi exatamente nesses últimos 5 anos que estamos tendo o ápice da maluquice. Não considere que as empresas que você trabalhou estão certas, pois a maioria delas estão erradas, não é o fato de não usar os rascunhos, mas sim “aonde” estão indo os esforços. Isso vai mudar e vai mudar MUITO em breve. O mercado não aguenta mais pagar o custo desse desenvolvimento pesado, cheio de etapas, cheio de documentos, cheio de pessoas, de departamentos.
Quero que o desenvolvimento de software volte para como era no ínicio dos anos 90 (só que com a tecnologia de hoje!). Nessa época era sentar a bunda na cadeira e fazer o desgraçado do software que resolve o problema do cliente. A última preocupação nessa época era o cronograma. Aí começaram as terceirizações que visavam “economizar”. Hoje um software não sai por menos de R$ 100K quando entra numa fábrica. Tudo é difícil, tudo é demorado, tudo precisa de um monte de coisa que de fato não precisamos.
Rodrigo,
Não vou bater boca com vc a respeito disso…é meu ponto de vista e a thread aqui vai estourar o banco de dados do GUJ e não vou mudar minha visão quanto a isto.
O desenvolvimento de software não vai voltar em como era nos anos 90…tudo isso que acredito, confio e estou dizendo é algo que vejo em grandes empresas e em muitas pequenas, ou seja, se vc quer desenvolver software como nos anos 90 pode ficar pra tras. Não adianta ficar defendendo “pq nos anos 90 era assim” como um revolucionário querendo que seja hj…as coisas mudam, as praticas mudam e não aceita-las é ser ultrapassado.
Pra mim, como lhe disse, essa sua concepção de desenvolvimento de software é absurda…é minha visão, minha opinião, não vou mudar.
ate mais…
Pra mim, como lhe disse, essa sua concepção de desenvolvimento de software é absurda…é minha visão, minha opinião, não vou mudar.
ate mais…
[]'s
Fala sério…
Ninguém aqui tá dizendo pra se usar todos os documentos/processos do CMMx nível 5 por exemplo não…criar documentos como Casos de Uso, Diagramas, etc auxilia o desenvolvimento…tudo bem que estou acostumado mais com esquema de FSW, no entanto, vejo isso como essencial e não consigo entender como uma pessoa desenvolve “uma solução de negócio” com rabiscos e rascunhos.
Me perdoem, mas isso é demais pra mim. Estou me retirando do tópico pq o assunto é absurdo demais para ser discutido. Estamos voltando a idade da pedra mesmo, não é possível.
Nesta comcepção do Rodrigo por ex, não existirá mais analistas, testadores, processos, nada…só o programador e o cliente do lado dizendo o que ele deve fazer?
Realmente, me retiro do tópico.
ate mais…
Bom, daqui a 2 anos não vai reclamar dizendo que eu não avisei… as coisas estão mudando. Estou bem próximo do mercado para afirmar isso. Vou compartilhar aqui o que o Robert Martin vem falando a algum tempo: Ou as fábricas ficam ágeis ou elas morrem.
Essa concepção não é minha, tudo que falei aqui é fundamentado em literaturas (algumas dos anos 90, outras desse milênio), e qualquer desenvolvedor ágil concorda com a minha opinião.
Meu projeto está indo para o mercado até o final do ano. Quando isso acontecer vou fazer questão de mostrar o produto, os artefatos e o tamanho do sorriso dos stakeholders para você. Duvido que qualquer fábrica faria um trabalho melhor.
Não consigo ver um cenário mais maravilhoso do que esse que você pintou. É minha opinião sincera. E vou além, essa divisão do trabalho e especialização não é defendida por nenhuma metodologia. Nem mesmo pelo RUP.
Richard, pelo seu bem e pelo bem da sua carreira (seu bolso), peço que continue no tópico…
Se esse negócio de rascunho em papel de pão e código funciona pra vc, muito bom, mas eu não consigo enxergar isso como algo que de fato seja melhor do que onde tenhamos uma sistemática definida (não necessariamente burocrática) e a geração de alguns artefatos que auxiliem no desenvolvimento do negócio solicitado e documentação do que o cliente pediu/necessita baseado numa metodologia qualquer.
Não, não tem nenhum motivo pra eu continuar neste tópico visto que temos visões diferentes…vc defendeu a sua, eu defendi a minha, pronto.
Não tem mais o que discutir aqui. Espero que vc tenha sucesso neste seu projeto e nos demais em que vc venha a trabalhar.
Obrigado pelo debate.
ate mais…
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.
Ficar agil? Concordo com vc, agilidade será a tendência dos próximos anos. Mas ficar “ágil” não significa anotar o que o cliente quer num papel A4, bota-lo do seu lado e sair programando…pelo amor de Deus, não quero mais discutir isso! Isso foi pra fechar a semana com chave de ouro! ?
ate mais…
Olá
Dúvidas:
Não é mais rápido bater fotos da lousa usada na reunião com o cliente e juntar com a gravação da conversa do que transcrever tudo com palavras que podem ser diferentes das que o cliente usou?
O cliente precisa homologar estes documentos para garantir que contém o que realmente falou ou basta vocês conferirem com a transcriçào das fitas, fotografias e filmes?
Como entram fotos, gravações e fitas no contexto do tipo CMM?
Qual a periodicidade que vocês conseguem nas reuniões com o cliente? Supondo que perdem pelo menos 2 dias na transcrição das conversas em documentos e na aprovação posterior deles, acho difícil haver reuniões semanais.
[]s
Luca
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.
O desenvolvimento de software não vai voltar em como era nos anos 90…
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.
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.
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!
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!
[]'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:
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.
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
eu gostei dessa parte tb:
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!
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.
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
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.
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.
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?! 
Não, as coisas não mudaram:
os burocratas da engenharia continuam fazendo toneladas de papeis e atrasando a entrega de seus produtos, clientes continuam insatisfeitos.
os humildes desenvolvedores ágeis continuam fazendo bom software em tempo recorde e que supre as necessidades dos clientes.
pelo visto as coisas não vão mudar nunca…
os humildes desenvolvedores ágeis continuam fazendo bom software em tempo recorde e que supre as necessidades dos clientes.
Desculpem continuar o tópico de forma desnecessária, mas essa frase ficou engraçada…
No mais, pode fechar a conta e passar a régua nesse tópico.