Divisão de Responsabilidades

Quando eu falei sobre divisão de responsabilidades no post anterior eu não quis dizer uma pessoa fazer o trabalho de todos, muito pelo contrário! E para uma equipe maior que umas 9 pessoas pode ser impraticável algumas técnicas do Scrum, por exemplo o Daily Scrum que tem o objetivo de ser rápido. Mas quando ocorre um time tão grande assim? Não é impossível ter muitas pessoas num projeto. Eu particularmente já participei de um time de 11 desenvolvedores. Nesse caso talvez algumas técnicas do Scrum me ajudasse, mas não todas! Porém a maioria das vezes a equipe não é tão grande, então quanto mais técnicas usar, melhor!

Mas vamos pensar um pouco. Um problema que acontece muito nos projetos atuais é o software final não sair da maneira que o cliente esperava, e aí ocorrem os retrabalhos. Por que isso acontece tanto? Não quero generalizar, só vou dar um exemplo. Ocorre porque no levantamento do projeto os analistas de negócio fazem toda a documentação e passam para uma fábrica de software implementar. Os desenvolvedores são cobrados por prazos e muitas vezes não lêem todas as 50 páginas do documento e fazem da forma que entenderam podem interpretar de maneira erronea, a não ser que exista um documento de Visão que não permita esse mal entendimento. Eles não participaram das reuniões com o cliente não sabem o escopo do projeto o que facilitaria o entendimento e possibilitaria ter uma visão macro do projeto. Mesmo se o conhecimento for passado do analista de requisitos para o desenvolvedor por meio de uma conversa, não será tão bom como o próprio cliente passar o conhecimento, pois esse último é o que realmente entende do negócio. As vezes um intermediário pode causar o problema de telefone sem fio. Daí quando o projeto está quase acabando já é tarde demais. Comentei sobre isso nesse post.

Uma metodologia ágil deve dizer que o cliente tem que estar sempre próximo do time, e quanto mais desenvolvedores participarem das reuniões, sobre os requisitos por exemplo, é melhor. No scrum existe os papéis de Product Owner (pode pensar no cliente do exemplo citado), o Time, e o Scrum Master. Isso muitas vezes é o suficiente.

Devemos ter testers? Sim, mas se o time trabalhar com TDD do Extreme Programming pode ser que não precise.

Podemos ter analistas de negócios? Sim, desde que não seja um intermediário.

14 Respostas to “Divisão de Responsabilidades”

  1. Fábio Queiroz Says:

    “Os desenvolvedores são cobrados por prazos e muitas vezes não lêem todas as 50 páginas do documento e fazem da forma que entenderam.”

    Se isso acontecer, demite o cara.

    “Eles não participaram das reuniões e não sabem o escopo do projeto.”

    Se for feito um documento de Visão, que define o escopo, isso não acontece.

  2. Ricardo Almeida Says:

    Atualizado, thanks!

  3. Felipe Regalgo Says:

    Sou totalmente contra esse negocio de ficar tendo que ler requisitos de 50 paginas (ou mais) para entender o software. Até mesmo porque ao decorrer do projeto os requisitos se modificam e o documento se torna desatualizado, e é um saco ficar tendo que sincronizar tudo que se faz no codigo com o documento. Além de que em alguns pontos do documento, cada programador tem sua propria interpretação do que esta escrito! afinal de contas não existe comparação entre a comunicação face-a-face e a comunicação escrita..

    Já que a intensão do documento é ajudar o desenvolvedor a desenvolver o software nada melhor do que o mesmo participar das reuniões e depois ainda ter o Product Owner do seu lado sempre que tiver alguma duvida. Levando em conta que cada iteração do software dura de 2 semanas a 1 mes, não tem como os requisitos serem tantos a ponto do desenvolvedor se perder nas ideias e não conseguir entender tudo….
    e desenvolvendo aos poucos e tendo o cliente (Product Owner) ao seu lado, além de não precisar documentar o software pra ajudar o desenvolvedor e validar com o cliente os requisitos, o fato do cliente estar ao lado, já vai garantir que o software atenda aos requisitos do cliente e não precise ser validado antes!

    Por isso vejo que documentação em excesso…. montar um documento com 50 folhas e dar pro seu programador ler é conceito ultrapassado.

    Na minha opinião se vc quiser documentar, então documente o que já foi feito.. Documentar antes de fazer pra mim é besteira e perda de tempo.. dado o fato de que o desenvolvedor participará da reunião, o cliente estará do lado para sanar duvidas, e a iteração será de 3 semanas com um numero reduzido de requisitos…

    abraços

  4. Fabio Queiroz Says:

    Como estimar um projeto para ganhar uma licitação/edital? Através de uma documentação. Você ganhando essa licitação/edital, com valor fechado, como garantir implementar funcionalidades dentro do escopo? Através de documentação prévia, contrato, etc.

    Se o cliente pede uma funcionalidade nova, como estimar para seu Comecial cobrar? Através de uma documentação do que o Cliente pediu.

    Se implementações são feitas sem prévia documentação, como você garante que o que foi implementado é o que foi acordado Comercialmente? Como podem garantir que o Cliente diga “eu não pedi para fazer A, pedi para fazer B” se não há uma documentação prévia do negócio?

    Pensem a respeito.

  5. Ricardo Almeida Says:

    Oi Fábio,

    Esse assunto é realmente polêmico!🙂 Metodologia ágil é muito mais fácil de implementar em empresas pequenas, pois nas grandes envolve governança. E é isso que a IBM está querendo resolver! Existe também caso de sucesso com a Globo.com, leia os links que coloquei no primeiro post e verá como fazer para implantar e fazer estiamtivas.

    Com certeza essa metodologia é um quebra de paradigma, algo que muitas empresas do mercado ainda não estão preparadas. E para entender bem um novo paradigma as vezes é preciso que esvaziemos alguns conceitos de nossa cabeça para poder absorver outros. Mas isso não quer dizer que todos devem gostar de metodologia ágil! Porém vejo que o mercado está mudando e direcionando para isso. A melhor maneira sanar as suas dúvidas é realmente estudar a metodologia, pois o assunto é muito rico e não seria possível detalhar em um post. Após entendé-la bem aí sim poderemos saber se é bom ou não. Eu aconselharia começar estudos com Scrum. Existem muitos cursos excelentes de Scrum no mercado, como o da Aspercom, da Caelum e Fratec. Por se tratar de cursos mais extensos suas dúvidas serão esclarecidas. Existe muito material na internet também.

  6. Rafael Terra Says:

    Seu blog é muito bom! Visitarei mais vezes🙂

  7. Wallace Says:

    já passei por uns perrengues foda por o pessoal do TI não ter entendido o que nós queríamos…

  8. Felipe Says:

    Fábio Queiroz,

    Quanto à questão do Edital, isso é problema cultural em empresas do governo ou similares. Mas é possível, com algumas pequenas alterações no edital resoler tudo isso.

    Porém to realmente estranhando sua resistência à essa proposta. Pra mim tá parecendo que você é um cara muito sortudo e todos os seus projetos foram salvos por documentos gigantes. Faça uma pesquisa interna em seu projeto perguntando quais são os desenvolvedores que leram toda a especificação do sistema. Melhor faça a pesquisa no mercado de trabalho. Coloque uma enquete em algum fórum.
    Rapidamente vai perceber que documentação não salva projeto, é apenas um detalhe burocrático na maioria dos casos. A documentação boa é aquela que é estritamente necessária. O resto é resto. =)

  9. Fábio Queiroz Says:

    Como diz o Ricardo, realmente esse post gerou boas discussões.

    Quando mencionei edital/licitação, poderia ter mencionado RFP, que são documentos comumente publicados por instituições privadas como bancos, seguradoras, corretoras, etc.

    Até o presente momento, em nenhum dos documentos que vi dessas grandes instituições, nenhuma delas aborda Metodologias Ágeis. Realmente, questões culturais.

    Concordo que quanto mais simples, menos burocrático, melhor. Não tenho aversão à metodologias ágeis. Apenas expresso o que vejo nos Clientes que já atendi.

    “Kiss = Keep it simple, stupid”

    Se as grandes forcedoras de softwares conseguirem conquistar seus clientes a incorporar metodologias ágeis como Scrum ao invés de RUP, com certificações CMMi e Mps.BR, conseguirem validar metologias ágeis na SOX (http://en.wikipedia.org/wiki/Sarbanes-Oxley_Act), conseguirem validar junto com sócios (já que muitos Cliente são empresas listadas em Bolsas de Valores mundo afora), MARAVILHA.

  10. Resistência à Mudanças « Blog Visão Ágil Says:

    […] Esse post causou uma boa polêmica e levantou vários pontos que o mercado utiliza para não adotar agilidade (Vejam os comentários aqui). […]

  11. Jamw - Qualidade de Software e Teste Funcional Says:

    Fico assustado quando dizem que ao usar TDD nao se faz necessario os Testers. Acho que quem pensa dessa forma deveria ler mais e entender o papel que um Arquiteto ou Analista de Teste tem dentro de um time ou equipe Agil. A metodologia Agil e o TDD em momento nenhum diz que os Testers sao dispensaveis, caso contrario peco que me enviem o trecho ou documento que prove o contrario. Recomendo que leiam um pouco mais sobre Agile , TDD e Qualidade de Software.

    Desculpem a falta de acentos!

  12. André Leite Says:

    “Devemos ter testers? Sim, mas se o time trabalhar com TDD do Extreme Programming pode ser que não precise.”

    Discordo. Em todas as metodologias a qualidade é o ponto FUNDAMENTAL e no caso do scrum que é a metodologia pela qual utilizamos em nossa empresa, todos estão muito ligados a qualidade.

    TDD é muito bacana e útil, só que nem sempre um desenvolvedor saberá quais tipos de testes eles podem implementar. Um ex, bem simples vc pode verificar no site: http://www.improveit.com.br/xp/praticas/tdd

    da uma lida no ex. dos caras: Um programa para gerar números primos. Criaram diversos testes!!!! Ao ler tudo, me perguntei no final: Se eu colocar no txt uma “LETRA – simples “A” o que ocorre? tcham tcham tcham tcham: BUG.

    Ou seja: Sempre haverá TESTERS!

    Ps.: Ricardo, acho que seria bacana você dar uma lida nos tópicos do criador do scrum Jeff Sutherland ou até mesmo o do Henrik Kniberg (autor do livro Scrum and XP from the Trenches) e você entenderá muitas coisas novas. Inclusive no capítulo 14 “How we do testing?” do livro do Henrik você terá a resposta da suas dúvidas.

    abraço a todos.

  13. Ricardo Almeida Says:

    Antes de mais nada obrigado pelos comentários!

    @Jamw,

    Quero esclarecer um pouco meu ponto de vista fazendo uma analogia.

    Muitas pessoas tem um mal entendimento dos valores de Agile:

    Individuals and interactions over processes and tools
    Working software over comprehensive documentation
    Customer collaboration over contract negotiation
    Responding to change over following a plan

    Vamos pegar apenas o segundo valor. Reparem que não foi dito que não deve haver documentação, e sim que Software funcionando é mais importante que uma documentação muito abrangente.

    Fazendo uma analogia a minha frase, eu não disse que não devemos ter Testers em um time com TDD, e sim que “pode ser que não precise”. É claro que se tiver equipe de Teste é melhor ainda. Principalmente se os Testers puderem trabalhar em par com os desenvolvedores em algum momento. O próprio livro do Vinícius Teles, que li e recomento muito para todos, diz quais são as responsabilidades dos Testers.

    Conheço projetos que além de não trabalharem com metodologia ágil, também não tem Testers. Tudo bem se se alguém não quer usar metodologia ágil se achar que cascata é melhor. Porém nesse cenário o papel de um Tester é fundamental para que o projeto tenha qualidade!

  14. Ricardo Almeida Says:

    @André Leite,

    Muito bom o link que você passou sobre o TDD. Eu já conhecia e é muito legal para quem ainda não entendeu a vantagem do TDD. Tem outro exemplo muito interessante no Livro do Vinícius Teles.

    O livro Scrum and XP from the Trenches eu também li e recomendo para todo mundo. Inclusive colocamos a tradução desse livro no site InfoqBr:
    http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches

    Eu não discordo de você, inclusive acho que pensamos da mesma forma pois QUALIDADE e VALOR é o que buscamos nos nossos projetos. Por isso usamos o Scrum.

    No seu exemplo, esse bug poderia ser capturado pelo teste de integração, por exemplo o Selenium.😉

    Recomendo também que leiam um artigo do Danilo Sato que diz:

    “Quando falo que a Toyota eliminou o departamento de qualidade e teve ganhos incríveis de produtividade, geralmente recebo olhares espantados e desconfiados, principalmente da equipe de testes. “Você está dizendo que devo ser demitido?”. Calma, não é bem assim. A Toyota não eliminou sua preocupação com qualidade. Pelo contrário, ela valoriza tanto esse aspecto que compartilhou essa responsabilidade com TODOS os envolvidos no processo. Não quero que os testadores sejam mandados embora. Pelo contrário, suas habilidades devem ser espalhadas e aproveitadas por todo o processo de desenvolvimento. Devem trabalhar muito mais próximos e não no final da cadeia. Shigueo Shingo já dizia: “Inspecionar para procurar defeitos é desperdício. Inspecionar para previnir defeitos é essencial”.

    O papel do testador numa equipe ágil é tão importante quanto o do programador. Ele ajuda a equipe e o cliente a aprimorar suas estratégias de teste (principalmente de aceitação). Eles fazem parte da equipe e também são responsáveis pela entrega! Lembrem-se: a história não está pronta enquanto não estiver testada!”

    O link é:

    http://www.dtsato.com/blog/2007/09/24/voce-automatiza-seus-testes-de-aceitacao/

    Thanks,


Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: