Gerenciamento de requisitos (OFF-TOPIC)

[Paulo Larini]

Pessoal, para quem está trabalhando com softwares grandes, o que estão usando para gerenciar os requisitos do software? Algo que fosse sendo alterado para refletir as alterações feitas no código.

[Alex Takitani]

Não entendi, pode ser mais claro?

2013/5/22 Paulo Larini <pfla...@gmail.com>

Pessoal, para quem está trabalhando com softwares grandes, o que estão usando para gerenciar os requisitos do software? Algo que fosse sendo alterado para refletir as alterações feitas no código.

--
--
Você recebeu essa mensagem porquê está inscrito no Google
Groups "rails-br".
Para enviar uma mensagem para o grupo, mande um email para rail...@googlegroups.com
Para se descadastrar, mande um e-mail para
rails-br+u...@googlegroups.com
Visite o grupo em http://groups.google.com/group/rails-br?hl=pt-BR
Leia nossa política de uso: http://goo.gl/YGgt7
 
---
Você está recebendo esta mensagem porque se inscreveu no grupo "rails-br" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para rails-br+u...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

[Everaldo Gomes]

Use Cucumber.

2013/5/22 Alex Takitani <atp...@gmail.com>

[Paulo Larini]

Por exemplo, tenho uma funcionalidade no sistema. Tenho que documentá-la.

Na verdade posso até usar um editor de texto e criar um diretório cheio de arquivos representando meus requisitos.

Mas queria saber se alguém já usa alguma ferramenta ou padrão para isso.

[Pedro Mamede]

Documentar no caso seria um User Case? aqui na empresa a nossa "Documentação" é o output dos testes do Rspec

2013/5/22 Paulo Larini <pfla...@gmail.com>

--
Pedro Mamede

msn: pedro....@hotmail.com
gmail: pedro....@gmail.com

www.pmamede.com

[Everaldo Gomes]

http://cukes.info/

2013/5/22 Pedro Mamede <pedro....@gmail.com>

[Alex Takitani]

Ah sim..  Faço como o Pedro, Rspec.

2013/5/22 Everaldo Gomes <everald...@gmail.com>

[Pedro Mamede]

Acho que pro Paulo Larini o problema seria o fato dele querer documentar uma funcionalidade, que normalmente é composta/envolve uma ou mais entidade e métodos, o Rspec no entanto traria um "output" mais modularizado, que não representaria a funcionalidade em sua totalidade.

Se conseguir algo diferente do Cucumber mostra pra gente Paulo.

2013/5/22 Alex Takitani <atp...@gmail.com>

[Alex Takitani]

Mas vc não acha q as feature specs resolvem isso Pedro?

2013/5/22 Pedro Mamede <pedro....@gmail.com>

[Everaldo Gomes]

Gambiarra...

2013/5/22 Alex Takitani <atp...@gmail.com>

[Alex Takitani]

O que é gambiarra?

2013/5/22 Everaldo Gomes <everald...@gmail.com>

[Everaldo Gomes]

Usar Rspec para documentar os requisitos de um software, principalmente um software grande.

2013/5/22 Alex Takitani <atp...@gmail.com>

[Alex Takitani]

E vc diz isso com base em que? 

2013/5/22 Everaldo Gomes <everald...@gmail.com>

[Luiz Augusto B. Florentino Filho]

Eu trabalhei numa empresa (CMMI-3) que usava o uma adaptação do Mantis (http://www.mantisbt.org/)

Mas confesso que o Cucumber é mais interessante e ainda serve de teste de aceitação.

[Everaldo Gomes]

Eu digo com base em experiência própria.

Eu não disse que não funciona. Mas quando utilizamos uma ferramenta ou técnica para resolver um problema, e essa ferramenta ou técnica não foi criada para isso, denominamos essa prática de Gambiarra.

2013/5/22 Luiz Augusto B. Florentino Filho <luizflo...@gmail.com>

[Everaldo Gomes]

Requisitos é uma atividade do "Analista de Requisitos" (pode até ser o programador, mas ele está exercendo outro papel).

Logo, os requisitos devem ser escritos/expressos em linguagem apropriada, não em código de programação.

Cucumber foi projetado para isso....RSpec não. Dá pra fazer com RSpec? Dá, porque já vi muito disso...mas é gambiarra.

2013/5/22 Everaldo Gomes <everald...@gmail.com>

[daniel carli]

Everaldo,

Na moral, você te falar uma coisa, mas como um toque mesmo.

Você é um cara que já veio aqui na comunidade cobrar respeito pelos profissionais, que devemos ser vistos como engenheiros de software e afins. Mas no contraponto, você é o primeiro a criticar de maneira ríspida tudo que saia do seu "bom senso"(vide discussão sobre o sistema do banco é um lixo porque é feito em Java). Cara, na moral, você deve respeitar um pouco mais os profissionais da sua categoria, porque um dia pode ser você na berlinda.

Daniel Carli

dcrlz.tumblr.com

[Alex Takitani]

Rspec com Capybara faz a mesma coisa que o cucumber.

Na minha opinião e de uns coitados "desconhecidos"

@carlosbrando I agree. RT @fnando: @georgeguimaraes cucumber is for poets. i prefer writing code.

2013/5/22 Everaldo Gomes <everald...@gmail.com>

[Everaldo Gomes]

Maneira ríspida? Eu disse que é gambiarra....e é.

Eu não disse que não faço gambiarras, de vez em quando, ou que é errado fazê-las ou que quem as faz é menos qualificado.

Acho que algumas pessoas podiam estudar um pouco de psicologia. Tem gente que se ofende por qualquer coisa.

E não foi minha intenção fazê-lo. Isso se chama projeção.

Estou de consciência tranquila @Daniel.

E não pense que eu não presto atenção nos seus posts. Geralmente você se manifesta de maneira muito infantil. Tome mais cuidado com o que fala - pelo menos a maneira como fala.

Note que eu não estou brigando com o Alex, tanto que ele até citou uma opinião bem-humorada:

"cucumber is for poets. i prefer writing code."

Att.

Everaldo

2013/5/22 Alex Takitani <atp...@gmail.com>

[daniel carli]

Como assim me manifesto de maneira infantil? Eu não venho responder nada aqui cheio dos meus achismos ou causar flames por nada.

Daniel Carli

dcrlz.tumblr.com

[Everaldo Gomes]

@Alex e quem está interessado no tópico de documentação de requisitos:

Não consegui achar o artigo original, creio que da Thoughtbot  e/ou do Boston.rb. Mas achei esse aqui:

http://rinaldifonseca.com/testes-de-aceitacao-com-ruby-on-rails-rspec-e-capybara/

Eu lembro que quando li (o artigo original) que advogava Rspec + Capybara até achei a ideia bem interessante.

Mas aí quando eu li o RSpec Book e o Cucumber Book eu pensei comigo mesmo: "puxa, fui bobo de confiar na opinião dos outros.

Agora, lendo o livro, percebo que Cucumber *é mais vantajoso*, porque me ajuda a pensar em termos de requisitos, sem me preocupar com código de programação. Da próxima vez vou averiguar por mim mesmo, não ficar confiando cegamente na opinião dos outros."

Bom, foi essa a lição que eu aprendi.

Sei que há vários perfis de programadores. Por exemplo, o criador do Sinatra, ele costuma fazer várias piadas dizendo que nem gosta de testes...que quando surge um erro, ele corrige etc.

Tem gente que gosta de codificar etc. Outros preferem "a poesia".

Enfim, por isso que não considero ofensivo o termo "gambiarra". Garanto que não pus nenhum sentimento de maldade ali.

E, como boa-vontade, até coloquei o link acima, para quem deseja usar RSpec e Capybara. E também indiquei o livro do Cucumber Book - e detalhe - quem programa com Cucumber costuma utilizar uma técnica chamada "Outside-in Development" (procurem, vale a pena) - e adivinhem? Sim, nós também utilizamos RSpec e Capybara....cada ferramenta ao seu momento.

Att.

Everaldo Gomes

Mestre em Informática pela Universidade Federal do Paraná

Bacharel em Ciência da Computação pela Universidade Federal do Paraná

Rubista há 2 anos - com muitos achismos - mas todos eles baseados em conhecimento técnico, leitura de artigos, muitos e muitos livros etc.

2013/5/22 daniel carli <dansa...@gmail.com>

[Pedro Mamede]

Everaldo,

O Paulo pediu sugestão em uma ferramenta que ajudasse a documentar uma feature. Apesar do Rspec ser uma ferramenta de teste, o output dele acaba sendo uma documentação. É claro que um software grande que usa todo um processo de analise para ser construido (e a documentação é feita antes da implementação dependendo do processo utilizado) utilizar o Rspec para documentar tudo seria gambiarra. Mas para gerar a "documentação" de algo existente, não creio que possa ser chamado de gambiarra.

Cucumber é basicamente uma ferramente para escrever testes automatizados de maneira não tecnica (não vou entrar nos conceitos de BDD), então pelo seu ponto de vista usar o Cucumber para documentar deveria gambiarra também. A diferença é que com o Cucumber você escreve e obtem a sua "documentação" no input dos testes e com o rspec no output.

Abraço.

2013/5/22 daniel carli <dansa...@gmail.com>

[Everaldo Gomes]

Pedro, o que o Paulo pediu foi diferente (no meu entendimento):

"Pessoal, para quem está trabalhando com softwares grandes, o que estão usando para gerenciar os requisitos do software? Algo que fosse sendo alterado para refletir as alterações feitas no código."

Gerenciar requisitos é diferente de documentar uma feature (ao meu ver).

Acho que você simplificou um pouco demais a questão.

Talvez seja necessário integrar o Cucumber com outras ferramentas...para no fim das contas a pessoa ter uma Interface Web com várias informações do projeto.

Até porque "Gerenciar Requisitos" é um termo muito amplo. Concorda?

Abraços,

Everaldo

2013/5/22 Pedro Mamede <pedro....@gmail.com>

[Pedro Mamede]

Depois ele complementou:

"Por exemplo, tenho uma funcionalidade no sistema. Tenho que documentá-la.

Na verdade posso até usar um editor de texto e criar um diretório cheio de arquivos representando meus requisitos.

Mas queria saber se alguém já usa alguma ferramenta ou padrão para isso."

Só queria me expressar quanto ao termo "gambiarra" que apesar de não ter visto nada demais com o que vocẽ falou pro Alex, não concordei =]

2013/5/22 Everaldo Gomes <everald...@gmail.com>

[André Rodrigues Pereira]

Putz Everaldo, com todo o respeito que tenho por você, pela sempre prontidão em ajudar aqui, tenho que te dizer: 

Você foi infeliz nessa thread. 

E não foi pela sua opinião técnica e nem por ter usado o termo "gambiarra"...

Atenciosamente,
André Rodrigues Pereira

[Everaldo Gomes]

@Pedro,

em dois lugares onde trabalhei a documentação vinha em Casos de Uso. Eram documentos do Word...a maioria feito com Copy-and-paste - ou seja - ficavam fora de sintonia.

Ao meu ver, o problema do RSpec é a dificuldade em "compilar informações", gerar um relatório técnico etc. Quando é uma equipe pequena, tudo bem...dá pra levar isso na boa.

Mas note que o @Paulo falou em software grande. Implicitamente há Analistas de Requisitos envolvidos etc. (pode não haver, eu que supus).

Não sei se consigo expor meu ponto...mas consegue perceber como algumas soluções que funcionam em pequena escala ou em pequenos nichos já não são tão adequadas em outros contextos?

Olha, pra ser sincero, naquele tweet que o @Alex citou, acho que os autores reconhecem que a técnica adotadas por eles é mais uma preferência pessoal do que "padrão de mercado". Estou supondo, não os conheço pessoalmente.

Att.

Everaldo

[Everaldo Gomes]

@André, sem problemas.

Achei que algumas pessoas estavam abusando, já há algumas threads....posso ser "infeliz", às vezes, mas pelo menos eu posto tentando ajudar, não tumultar. O histórico tá aí pra provar...

2013/5/22 André Rodrigues Pereira <andre...@gmail.com>

--

[Diego Tuchê]

Na empresa que trabalho toda a documentacao e feita no EA (enterprise architect) 

http://www.sparxsystems.com/products/ea/index.html

[Bernardo Amorim]

Independente da forma como o Everaldo disse eu concordo com ele.
Uma coisa é teste de aceitação, outra coisa são requisitos.

O cucumber permite que você use os requisitos escritos numa linguagem própria para requisitos para fazer testes de aceitação também, ele mesmo divide em 2 partes.
As features são os requisitos propriamente ditos, que podem ser escritos por um analista sem saber necessariamente Ruby.
Dai depois os programadores de testes podem apenas escrever os steps, ai sim é teste de aceitação.

O que o RSpec + Capybara faz na verdade, é só a parte de testes de aceitação, aí sim, substitui muito bem o Cucumber, talvez até melhor em alguns pontos (na minha opinião).

Enfim, são duas coisas diferentes, mas nós programadores tendemos a olhar como apenas uma.
Mostre as duas para um analista ou um stakeholder e pergunte se há diferença.

Abraços,
Bernardo Amorim

[Everaldo Gomes]

Bom, já que o @Andre, o @Bernardo, o @Daniel entre outros estão comentando da forma como eu me expressei, só tenho a dizer que vou cuidar mais do que eu digo, a forma de me expressar. Não quero que os outros sintam-se ofendidos. Sei que isso é impossível, mas prometo tomar mais cuidado. Não são poucas as vezes em que eu já escrevi um e-mail precipitado e cliquei em Undo ou em Discard Draft. Só posso dizer que "podia ser pior", porque lá na Rails-Talk e em outras listas, tem gente que é muito mal-educada....no meu caso, acho que foi mais uma "infelicidade" como o André disse. Foi mal gente...(esse tipo de coisa acontece com todo mundo, né?)

Em especial, creio que tenho que pedir desculpas ao @DanielCarli.

Att.

Everaldo

2013/5/22 Bernardo Amorim <bamo...@gmail.com>

[daniel carli]

Cara você não deve nada,

como disse antes, só queria te dar um toque, não queria te ofender e de forma nenhuma queria ser ofendido.

Acredito que você vem aqui na lista só como boas intenções, mas, você tem que se policiar e ler o que você escreve antes de enviar.

no mais, sem ressentimentos 

Daniel Carli

dcrlz.tumblr.com

[Everaldo Gomes]

Obrigado, Daniel.

2013/5/22 daniel carli <dansa...@gmail.com>

[André Rodrigues Pereira]

Fica tranquilo Everaldo, 

Eu falei só por hoje mesmo, sua atitude aqui sempre é muito boa... 

Atenciosamente,
André Rodrigues Pereira

[Bernardo Amorim]

Eu nem achei que você falou de maneira ruim, eu entendi que você foi apenas direto ao ponto, e isso pode parecer "grosseiro".
^^

--

[Marcos Silveira]

Recomendo, EA – Enterprise Architect - é uma ferramenta para isso e muito mais. "Requisitos, Caso de Uso, Diagramas, Modelos de dados..." tudo que é necessário para documentação do projeto.

--

Atenciosamente,

Marcos Silveira
Coordenador de Projetos
tel. 71 8313-2593 / 9959-5695

[Emerson Informática]

Tudo resolvido entre os envolvidos na questão da palavra Gambiarra que pode ser vista de dois ângulos.

Mas como seria e o que se pode encarar um:

Projeto Pequeno

Projeto Médio

Projeto Grande

E para as suas necessidades de documentação qual ferramenta seria apropriada para a documentação?

Emerson da Silva Cardozo
Informática - (11) 9778-8920vivo

[Alex Takitani]

Everaldo sobre os livros, não deixam de ser uma opinião pessoal de quem os escreve.

TI é uma área relativamente nova, então é normal que tenhamos erros e acertos durante o caminho. Cito alguns que vivenciei:

Nos anos 90 e boa parte dos 200x o padrão do mercado era o famoso 3 camadas em VB+COM ou Delphi+CORBA.

Banco de dados era o lugar de se manter regra de negocios.

Controle de versão era coisa rara, o normal era ter uma pasta compartilhada na rede.

Waterfall era O padrão de desenvolvimento. Quantos livros não temos sobre o assunto? Quantas faculdades não ensinaram que o correto era: Levantar, Documentar, Desenvolver , Testar, Homologar e Entregar?

Agora olhando pra trás, parece piada, não?

Quem hoje em sã consciência escreve regra de negócio em procedures? 

Quem topa manter codigo fonte compartilhado em pasta de rede, ou até em controle de versão centralizado (SVN, CVS) ?

Waterfall então, é coisa de dinossauro e vc sabe, pela experiência dos anos lutando contra que o Agile é a resposta do mundo real a tudo que estava errado no processo anterior. 

Sendo assim, não dá pra bater o martelo e dizer que daqui a 2, 3 anos alguém vai usar cucumber ou não. Como tudo que falei anteriormente, pode virar piada amanhã.

A minha experiência é: Analista de requisitos e negócios é coisa de waterfall. E esse povo não escreve user story, esse povo escreve email, word, desenha diagrama e geralmente tudo isso está errado. Usuário então, mal sabem o que realmente querem.... 

Sendo assim, se é o desenvolvedor que acaba escrevendo, essa camada do cucumber vira pura burocracia. É um ambiente a mais pra se preocupar, os editores não tem como ajudar muito, já que é texto puro praticamente, é uma coisa a mais pra rodar e deixar o teste lento, é uma coisa a mais pra se configurar no CI. 

O meu "sentido aranha" me diz que isso está errado, da mesma forma que fazer uma procedure, fazer uma dll pra rodar no COM+, fazer uma função pra chamar essa dll e amarrar tudo isso na telinha do VB me fazia sentir.

É muito trabalho por um retorno questionável, mas veja, seria questionável se eu fosse o único a sentir isso, mas não sou. 

Esse povo que eu colei o twit são uns dos caras mais famosos da comunidade Rails BR, estão desde o começo por aqui. Quem não os conhece e não os toma por modelo já tem um sério problema de não estar seguindo os passos de quem passou pelo caminho antes.

É uma questão de medir gasto x retorno. Com cucumber eu me sinto gastando mais do que ganhando, então, retirei-o do meu arsenal, a sua experiência pode ser diferente.

Ruby e Rails me ganharam, pq tudo que encontrei me passa a sensação de naturalidade, de jeito certo de se fazer, muito pq eu concordo com a filosofia do Matz e do DHH.

Recomendo a leitura do Getting Real da 37 signals, especificamente esse capítulo( http://gettingreal.37signals.com/ch06_From_Idea_to_Implementation.php ) . O Rails é resultado desse processo, diagramas de classe ( alguém citou EA e me deu um frio na espinha... era justamente o que usavamos na época do VB + COM+ ), user stories super detalhadas nunca fizeram parte do processo deles. Será que a primeira  e maior aplicação rails está com o processo errado? 

Spree não tem nos sources nada além de Rspec. RefineryCMS também não o mesmo pro Discourse. Cucumber está ai faz um tempão, será que esse povo todo não teria adotado, não seria padrão? 

Importante é saber que TI é dinâmica a ponto do excelente de hoje ser o ridículo de amanhã. É importante não tomar partido de ferramentas e técnicas como se fossem uma religião. Essa lista é indexada pelo google e muita gente aqui é um potencial cliente/empregador seu. 

2013/5/22 Emerson Informática <ecar...@gmail.com>

[Everaldo Gomes]

Sabe, @Alex...eu não me importo tanto com a questão da indexação do Google etc.

Mas eu realmente me preocupo em tentar não ofender e/ou desrespeitar as pessoas.

Confesso que eu gosto de atacar ideias, mas que seja o mais abstrato possível...e acho que vou ter que mudar um pouco isso, porque eu acabo atingindo as pessoas. E isso não é legal. :|

Obrigado pela consideração em escrever um e-mail tão grande. Concordo com você. Mas eu gosto de estudar as coisas antigas por razões históricas.

Por exemplo, Programação Funcional tem quase 60 anos. Programação Orientada à Objetos mais de 30 anos. A própria Arquitetura MVC, também mais de 30 anos (muitas técnicas que utilizamos hoje em dia, em Ruby, derivam do SmallTalk). O criador do MVC (Trygve Reenskaug - que tem uns 80 anos) também criou DCI (Data Context Interaction) que é um dos tópicos que mais me interessam.

Sobre "meus ídolos", não tenho muitos específicos, mas vou citar algumas pessoas que admiro:

- Pessoal do CodeSchool

- Pessoal do Github

- Pessoal do BostonRB

- Ryan Bates - por ser um cara muito esforçado, com muito conhecimento

- Gary Bernhardt - acho que o cara programa muito!!

- Martin Fowler (de livro dele, só li o Refactory, mas sou muito fã dele, Kent Beck, Bob Martin, David Thomas etc.)

- Sandi Metz - o livro dela também é muito bom

- Russ Olsen

- James Edward Grey II - entre outras coisas, pelo trabalho dele no RubyQuiz

Mas quanto a opinião, eu procuro ouvir e meditar sobre todas: sejam estrangeiros, brasileiros, doutores, mestres ou estagiários.

Por exemplo, o DHH é um cara genial. Ele ter criado o Rails etc. foi algo fantástico. Mas ele dá umas "bolas fora" de vez em quando (um exemplo que eu lembro é da "briga" dele com um pessoal de OO - tem lá no RubyRogues). O que não tira os méritos dele, afinal somos todos humanos.

Eu me considero um programador normal. Não tem nada de excepcional no que eu faço. Eu apenas sou um tanto curioso, gosto de saber como as coisas funcionam.

Enfim, agradeço as dicas e opiniões e reitero que me sinto incomodado, porque acho que às vezes não estou colaborando para a pessoa que quer resolver o problema e acabo ofendendo um ou outro. Me senti um chato no tópico nginx vs. apache.

Acho que a lista deve ser mais um "campo neutro". Se eu quiser ser mais incisivo sobre tecnologias etc. o lugar certo é um blog ou um livro.

Valeu pelas dicas e pelo apoio. Agradeço mesmo. Até porque eu concordo com vocês (estudo/uso RSpec, Capybara, TDD, BDD etc.). Acho mesmo que fui infeliz na forma de me expressar.

Att.

Everaldo

2013/5/23 Alex Takitani <atp...@gmail.com>

[Pedro Mamede]

Interessante isso que o Alex falou do Waterfall e afins. 

A nossa area é nova comparando com a medicina e a engenharia. Em um livro da praprog chamado "The developer's code" tem um capítulo chamado "Metafora" que fala justamente sobre isso. 

Recomendo bastante essa leitura, é bem interessante ver como os modelos de processos de software foram influenciados e "sofreram" por tentar copiar modelos ja existentes de outras areas.

Os capitulos "Metafora" e "Orgulho" são muito bons!

http://pragprog.com/book/kcdc/the-developer-s-code

2013/5/23 Everaldo Gomes <everald...@gmail.com>

--

[Alex Takitani]

Até mais que isso Pedro, o corpo e a física não mudam, já os computadores...

2013/5/23 Pedro Mamede <pedro....@gmail.com>

[Paulo Larini]

Requisito aqui na empresa é feito bem antes de se fazer o código. Inclusive é feito até por outro analista, que pode até nem programar.

O requisito vai dizer o que o sistema deve fazer, em linhas gerais, sem usar termos técnicos.

Seria algo como um "Help", mas não é. É uma documentação para ser utilizada pelo programador, para fazer o código dele.

[Ronald Bolsoni Falcão]

Há alguns meses atuo com grandes projetos em análise de sistemas, grandes mesmo. Vou fugir do assunto para depois voltar ao tópico, calma

Acabei nesse caminho por conta de $$$ depois de anos como desenvolvedor, surgiu uma vaga na empresa e eles viram em mim um perfil para isso.

Quando somos desenvolvedores temos uma visão completamente técnica dos problemas, em determinado tópico, analisamos de maneira lógica e codamos. Acontece que analista de requisitos, de negócios, etc, não estão ai por acaso.

Posso dizer com certeza, a grande maioria (e não torçam o nariz pq muitos aqui são assim, a não ser que tenham 20 anos de experiência e tomou muita porrada)  é excelente programador e se acha excelente analista.

Quando trabalhava com portais era muito simples para mim dizer que eu ´fazia o trabalho de um analista e de desenvolvedor, pois além de conhecer bem o submundo dos portais, no fim a complexidade deles para mim já não era tanta. 

E eu sempre me questionava, para que analistas? Foi então que tive contato com sistemas de grandes montadoras e de grandes construtoras. Improvável um desenvolvedor ter conhecimento do sistema, ou conseguir pensar em um novo projeto de grande porte. Para isso senhores, analistas especializados. Não falo isso porque acho bonito, é o que aprendi nesses anos, somado com o que eu estudei. Desenvolvedor pegar requisitos é como pedir para pescador caçar búfalos, ele até sabe, mas não é a onda dele. Infelizmente, esse não é o tópico.

Voltando ao tópico e contando a minha vida atualmente. Quanto aos requisitos, grande parte do trabalho é feito com planilhas, seguindo alguns padrões. Isso foi adotado por ser de fácil manutenção, e fácil compreensão pelos clientes. A maior parte dos clientes não sabe o que quer. Se você mostra o que eles querem de maneira complicada, eles não vão aceitar. Não concordo.

Por isso, tenho tentado criar (não opensource, sorry) um sistema que me ajude no dia-a-dia com isso. Desconheço outras ferramentas, usei o Mantis, gostei, mas não me atendeu. Estou estudando para fazer algo que seja bom e que englobe as boas práticas.

Abraços.

Ronald Bolsoni Falcão

desenvolvedor web

gtalk     ron...@ronalfalcao.com.br

twitter   @ronaldcurtis

site       www.ronaldfalcao.com.br

"Se você eliminar o impossível o que sobrar, mesmo que improvável, dever ser verdade.

Sir Arthur Conan Doyle

[Everaldo Gomes]

@Ronald....lighthouseapp...já ouviu falar? Eu vi ontem, mas fiquei sem saber direito pra que serve:

http://lighthouseapp.com/

Já usei um pouco do Mantis...mas eu também queria algo que fosse atrelado ao controle de versão.

2013/5/23 Ronald Bolsoni Falcão <ron...@ronaldfalcao.com.br>

[Ronald Bolsoni Falcão]

Cara, não conheço, mas estou aceitando sugestões! Obrigado.

Abraços.

Ronald Bolsoni Falcão

desenvolvedor web

gtalk     ron...@ronalfalcao.com.br

twitter   @ronaldcurtis

site       www.ronaldfalcao.com.br

"Se você eliminar o impossível o que sobrar, mesmo que improvável, dever ser verdade.

Sir Arthur Conan Doyle

[Everaldo Gomes]

@Ronald, também me veio a mente o Redmine: http://www.redmine.org/

Mas essas ferramentas só conheço de nome...usar mesmo, nunca usei.

[daniel carli]

o redmine eh muito bom para qa, já utilizei e recomendo

Daniel Carli

dcrlz.tumblr.com

[Ronaldo Possan]

Aqui na empresa utilizamos o Redmine. Possui todo o suporte de gestão de projetos, subprojetos, etc.

Com ele conseguimos atrelar documentos de requisitos (planilhas, word, qq coisa) às issues que são geradas para o desenvolvimento, dando fluxo à demanda.

Utilizamos alguns plugins para controle de horas (substituição do nosso ponto) e Scrum (scrum dashboard), sem contar que atualmente estou trabalhando no desenvolvimento de alguns plugins para relatórios gerenciais detalhados e dashboards (em breve disponível no github ;) ).

A empresa aqui é de telecom e começamos usando o Redmine apenas no P&D, entre nossos 5 colaboradores. E atualmente se expandiu para todas as áreas da empresa (projetos de campo, compras, auditoria, suporte, e também como ferrramenta de issue tracker para nossos clientes abrirem chamados, compartilhamento de arquivos). E a experiência que temos aqui com os usuários são ótimas.

Voltando ao assunto "requisitos", o Redmine nos atende perfeitamente pois conseguimos acompanhar e visualizar todo o processo da transformação de um requisito, até todas as etapas de sua evolução (desenvolvimento, testes, homologação, etc).

O bom do Redmine é que ele é bem customizável ems eu core, além de ser open source e em Rails :)

Ronaldo Possan
Software Engineer
Expertise in Web Development

+55 19 8820-7159

LinkedIn Profile

 @ronaldopossan

 ronaldo.possan

[Ronald Bolsoni Falcão]

Para projetos uso um sistema da empresa, e o dotproject (PHP) customizado. Quando falo de requisitos é realmente uma ferramenta que além de gerar histórico, versões de requisitos, etc, também tenha uma interface para o cliente (stakeholders), avaliação dos requisitos, priorização, e um monte de outros pontos que julgo importante. Isso ainda não achei. Mas vou dar uma olhada nas sugestões.

Abraços.

Ronald Bolsoni Falcão

desenvolvedor web

gtalk     ron...@ronalfalcao.com.br

twitter   @ronaldcurtis

site       www.ronaldfalcao.com.br

"Se você eliminar o impossível o que sobrar, mesmo que improvável, dever ser verdade.

Sir Arthur Conan Doyle

[Ronaldo Possan]

Ah, me esqueci ... o Redmine tem integração com repositório (svn, git) e referências de commits no repositório que afetam os status das issues, que também pode ser customizáveis. Ex:

This commit refs #1, #2 and fixes #3

Onde uma referência pode ser um requisito, e uma parte detalhada (técnica) de sua implementação.

Ronaldo Possan
Software Engineer
Expertise in Web Development

+55 19 8820-7159

LinkedIn Profile

 @ronaldopossan

 ronaldo.possan

Em 23 de maio de 2013 16:09, Ronaldo Possan <ronaldo...@gmail.com> escreveu:

[Everaldo Gomes]

Legal, @Ronaldo.

2013/5/23 Ronaldo Possan <ronaldo...@gmail.com>

[Germano Teixeira]

Algum de vocês já usou o GitLab(http://gitlab.org/)?

Atualmente eu uso o Redmine e o Gitolite, mas estava pensando em instalar o GitLab para ter uma interface melhor para gerencia dos repositórios, chaves de acesso, etc...

Não pretendo abandonar o Redmine porque gosto da forma como gerencio os projetos nele. Meu plano é usar o Redmine e o GitLab juntos.

Algum de vocês já fez isso?
 

[Alex Takitani]

Usamos o gitlab mas não está integrado com o redmine ( que também usamos)

2013/5/23 Germano Teixeira <germ...@gmail.com>

[Germano Teixeira]

@Alex,

Mas como vc faz para atribuir atividades as tarefas(issues). Fica divido nos dois?

Por exemplo o desenvolvedor passa a ter que entrar nos dois sistemas para ver suas tarefas? 
Na hora em que eu quiser ver as atividades pendentes em um projeto tem que olhar no GitLab e no Redmine.

Estou com o um pouco de medo do GitLab facilitar a vida na hora de gerenciar repositórios e complicar o processo de desenvolvimento inteiro porque agora tem informação em mais de um lugar, tarefas duplicadas, etc.

Funciona bem ai usar os dois mesmo sem integrar?

[Alex Takitani]

A gente não controla issues no gitlab, ele serve simplesmente como repositorio.

2013/5/23 Germano Teixeira <germ...@gmail.com>

[Everaldo Gomes]

Estava vendo os screencasts da CodeSchool e havia um sobre Testes, acho que o do Jasmine com CoffeeScript, que apontava para um artigo de BDD do Dan North. Achei que tem muito a ver com o tópico (quando a equipe é formada apenas por programadores BDD e TDD são muito parecidos...):

http://dannorth.net/2012/05/31/bdd-is-like-tdd-if/

2013/5/23 Alex Takitani <atp...@gmail.com>

[Luis Vasconcellos]

"But in the kind of organisations and teams that gave rise to and shaped BDD we have to solve the more complex communication problems that are (by definition) beyond the scope of TDD. "

Gostei desse post!

Luis Vasconcellos, Web Developer

twitter: @vasconcelloslf

skype:  vasconcelloslf
mobile: 55 21 95100576

DTM | Simplifying Ideas

http://dtmtec.com.br

@dtmtec

2013/5/25 Everaldo Gomes <everald...@gmail.com>

[Everaldo Gomes]

Hoje eu comecei a ler este livro: "Specification by Example" - http://my.safaribooksonline.com/9781617290084

para quem se interessar.

Acho que não tem nada de código. Li o Chapter One e é só Use Cases...

Tô gostando. (diferenças entre construir the right product (BDD, Specification by example) e the product right (Xp, Agile).

O certo é fazer os dois...

2013/5/25 Luis Vasconcellos <vasconc...@gmail.com>

[Everaldo Gomes]

RelishApp, alguém já conhece/usou?

https://www.relishapp.com/

2013/5/25 Everaldo Gomes <everald...@gmail.com>