| Autor |
Mensagem |
Xeper
Veterano |
# abr/14
· votar
^
^
^
NOT SAFE FOR WORK
|
Xeper
Veterano |
# abr/14
· votar
^
^
^
#sdds fail
|
st.efferding
Membro |
# abr/14
· votar
ualáa
fiz um exemplo bem sucedido no VS2010 C# + TDD + NUnit
não sou mais noob \o/
|
john s mill
Membro |
# abr/14
· votar
TDD
*-*
|
st.efferding
Membro |
# abr/14
· votar
john s mill
legal pra caralho, tô usando TDD desde o ano passado nos meus projetos e vale a pena o investimento.
é muito legal ver as partes do projeto conectadas (requisitos -> testes -> características = win) por uma ferramenta ágil
|
Xeper
Veterano |
# abr/14
· votar
TDD
Parece ser bem legal, mas no ambiente go horse daqui nem rola.
é muito legal ver as partes do projeto conectadas (requisitos -> testes -> características = win) por uma ferramenta ágil
Deve ser lindo
|
Drowned Man
Veterano |
# abr/14
· votar
Tão falando grego pra mim.
|
Mary Lennox
Pitéu OT 2012 |
# abr/14
· votar
ooooooooooooooooopaaaaaaaaaaaaaaaaaa
|
john s mill
Membro |
# abr/14
· votar
TDD e bem legal, mas nunca vi funcionando de verdade em um projeto grande
|
john s mill
Membro |
# abr/14
· votar
Mary Lennox
oi moça bonita
|
st.efferding
Membro |
# abr/14
· votar
Xeper
Deve ser lindo
sim, eu sou
ah, você quis dizer a ferramenta? ^^
no que tange especificamente às tarefas de projeto (escrever os testes e escrever o código para fazer o respectivo teste passar), o meu workflow diário é povoado de tarefas de no máx. 15 minutos, coisa linda de se ver (e fazer)
john s mill
TDD e bem legal, mas nunca vi funcionando de verdade em um projeto grande
grande = mais do que 20 pessoas?
|
Mary Lennox
Pitéu OT 2012 |
# abr/14
· votar
john s mill
Oi moço bonito
O assunto ta muito avançado pra mim
|
st.efferding
Membro |
# abr/14
· votar
Mary Lennox
Oi
O Arthur não te assaltou?
|
Xeper
Veterano |
# abr/14
· votar
st.efferding
Deve ser lindo
sim, eu sou
ah, você quis dizer a ferramenta? ^^
Os dois
nhoim
|
st.efferding
Membro |
# abr/14
· votar
Xeper
nhoim ahuehuaheueaah
atualizando: vs2012 express ftw /o/
|
Drowned Man
Veterano |
# abr/14
· votar
Quanta viadeza...
|
john s mill
Membro |
# abr/14
· votar
st.efferding
bem mais, umas 10x
|
john s mill
Membro |
# abr/14
· votar
Mary Lennox
mudando de assunto, você tá tocando alguma coisa ou cantando?
|
st.efferding
Membro |
# abr/14
· votar
john s mill
em uma equipe com mais de 200 colaboradores, é go horse ou nada, na prática?
|
john s mill
Membro |
# abr/14
· votar
st.efferding
vira meio que uma putaria que é um quebra-cabeça com várias coisas, mas como a empresa tinha uns 35 anos já tinha uma metodologia mais ou menos bem definida.
a definição de requisitos e a própria estimativa eram feitos de forma tradicional com RUP/pontos de função, assim como as atividades administrativas, de apoio, implementação e suporte.
o desenvolvimento em si era feito com base no SCRUM, sempre tentei implantar um TDD ou algo parecido para dar agilidade, porque o tempo corrigindo bugs era superior ao tempo de desenvolvimento em si, mas nunca deu muito certo, você trabalha muito atrás do mercado com tecnologia de segurança pública, não há muito prazo para conseguir um bom foco em qualidade, aí no fim sempre fica tendo que apagar incêndio em um lado ou outro.
mas pelo menos do período que eu entrei até o que eu saí, conseguimos ter um nível legal de documentação de software, boa parte do pessoal até gostava de engenharia de software.
|
st.efferding
Membro |
# abr/14
· votar
porque o tempo corrigindo bugs era superior ao tempo de desenvolvimento em si,
john s mill
da tua experiência, consegue estimar uma relação aproximada entre esses períodos?
|
john s mill
Membro |
# abr/14
· votar
a implantação do TDD é um investimento promissor, que tornando o desenvolvimento mais ágil e com menor incidência de erros, mas é difícil arrumar uma janela pra implantar, foi feito consultoria, treinamento, apoio da diretoria de desenvolvimento, mas no fim sempre chegava solicitações de clientes importantes que eram prioritárias em relação a isso, fora o índice de rotação dos profissionais deste tipo de mercado.
|
john s mill
Membro |
# abr/14
· votar
st.efferding
nem precisa pela experiência, eu tinha os números.
a correção de bugs gastava 30% a mais que o desenvolvimento e representava pouco mais que metade do tempo total da construção do software.
|
Xeper
Veterano |
# abr/14
· votar
documentação de software
É incrivel como toda a empresa que passei caga completamente para isso... é novo no projeto? Troca uma ideia com aquele carinha lá que está a mais tempo e panz
|
john s mill
Membro |
# abr/14
· votar
Xeper
pelo mesmo motivo que dificilmente tu ve uma empresa que funcione bem TDD, pair programming, refactoring de manutenção e outras medidas para melhoria da qualidade, nego acha que todo tempo que não é gasto digitando código novo é puro desperdício.
|
sallqantay
Veterano |
# abr/14
· votar
sopa de letrinhas FTW
|
st.efferding
Membro |
# abr/14
· votar
nego acha que todo tempo que não é gasto digitando código novo é puro desperdício.
isso resume a atitude de 99% dos programêros ou envolvidos em atividades de desenvolvimento similares que conheço. galera (e equipes) não sabe organizar minimamente um projeto antes de começar (requisitos é motivo de piada, negócio é fazer e depois ir cortando as pontas)
|
st.efferding
Membro |
# abr/14
· votar
john s mill
considerando o scrum, o que você acha do daily meeting para equipes com número de colaboradores igual ou inferior a 3 pessoas?
|
john s mill
Membro |
# abr/14
· votar
st.efferding
por essas e outras que quando tu sai de gerenciamento de projetos de TI pra construção civil, consegue fazer com as mãos amarradas nas costas, nem o pessoal que trabalha por empreitada levanta um metro de muro sem ao menos os documentos de alteração de projeto e memorial descritivo.
de 3 a 5 é o ideal, adoro equipes assim, fica mais fácil de trabalhar e a comunicação é bem eficaz.
com 2 acho que acaba ocorrendo informalmente de um jeito ou de outro, mas ainda assim sempre é válido tirar um tempo pra isso, só pela prática.
|
Xeper
Veterano |
# abr/14 · Editado por: Xeper
· votar
requisitos é motivo de piada
Isso é problema sério aqui. Ai vai atrasando e tudo tem que virar código do dia para a noite.
Ai fica aquele sistema lindo de se ver... todo bugado e com sérios problemas de performance. Isso quando acertamos o que o cliente quer...
Editado pq tava tenço
|