Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Caso Prático Voice Technology
Similaire à Caso Prático Voice Technology (20)
Caso Prático Voice Technology
- 1. Caso Prático
- 2. @andre_pantaliao Desenvolvimento de software Métodos Ágeis Surdos Jogos de tabuleiro
- 3. @antonioams @fabricioffc Rodrigo Ribeiro ensinar.wordpress.com
- 4. Não é o melhor caso
- 5. HARD SOFT
- 7. CASO PRÁTICO EM UM PROJETO
- 10. Não é o melhor caso
- 14. Scrum, pero no mucho
- 15. Desconfiança do Scrum Divisão em fases Perfil inadequado Muita gente nova em um projeto desconhecido Muito teste manual
- 17. Definição do que vai ser feito em conjunto Entregas completas Testes de aceitação automatizados
- 18. Backlog com poucos itens Pessoas inexperientes Cliente ainda não "enxergou" o valor
- 20. Clientes gostaram do esquema de sprint Conseguimos demonstrar valor Testes de aceitação utilizados em outras áreas Retrospectivas mais eficientes
- 21. Não temos testes unitários Em dois meses, diversas atividades sem muito código envolvido... difícil de achar a velocidade. Time ainda grande
- 22. FALTOU Todos os membros estarem manjando bem de métodos ágeis. Uma palestra com alguém de fora da empresa, um consultor... para "desafiar" as pessoas.
- 25. Testes de Aceitação Automatizados
- 28. App Customização Media Hardware
- 32. "Não queríamos acertar um cronograma com todas as features que o cliente precisariam em 6 meses, mas sim, as mais importantes para o próximo mês."
- 33. Velocidade
- 34. É mais difícil determinar a velocidade em sprints de pesquisa mais intensa, ou comemos bola?
- 35. Experiência
- 37. Scrum?
- 38. Tamanho
- 39. Obrigado
Notes de l'éditeur
- A idéia deste tipo de encontro surgiu na lista do Happy Hour Ágil, criada pelo Luiz Faias da Bluesoft. A idéia é criar o hábito de reuniões com uma periodicidade fixa para as pessoas conversarem sobre problemas que estão tendo em suas equipes e como resolvê-los. Junto a este problema colocaríamos algumas apresentações de conteúdo que o grupo achasse pertinente. Havia pensado em algo como 10 ou 15 pessoas, mas o negócio tomou proporções maiores. Acabou virando um grande evento, tomando proporções maiores e dificultando um pouco o bate-papo.
- Na lista, o Rodrigo Yoshima e o Rubem Azenha levantaram a discussão muito bem observada sobre se a conversa seria sobre assuntos mais gerenciais ou mais genéricos. Acredito ter espaço para os dois. Fazer palestra sobre conceitos básicos de scrum não agrega muito para quem já tem alguma experiência. Podem ser criados grupos de discussão focados em algum assunto mais específico. Criar focos de estudo, de troca de idéias. Sugestões de assuntos?
- mas a moral da história e acho que temos que fazer mais... é juntar um grupo... Dojo... Bate-papo Open Source Empreendedorismo Porque aqui temos um bom universo de pessoas que podem ser seu cliente, fornecedor, concorrente ou funcionário. e diversas empresas podem ajudar cedendo algum espaço como a Caelum, Globalcode, a Voice... Blue Soft, Locaweb
- Mas... isto foi só para dar uma visão geral como começou... e agora vou começar a explicar o caso prático de forma mais objetiva possível, para não deixar o pessoal dormindo...
- o projeto que vou mostrar agora é da Voice Technology. Lá na Voice trabalhamos com sistemas que integrem telefonia e computador, desde 1993. Por falar em tempo, estou na Voice há 13 anos. é.. vai um tempo...
- Basicamente, o backlog da equipe que vou mostrar agora tem três origens distintas, todas relacionadas com o desenvolvimento de uim produto... o Tangram, que é uma plataforma para aplicações de atendimento eletrônico. Um item do backlog pode vir de: - um projeto de pesquisa financiado pelo FINEP que esta equipe faz parte. - requisições para evolução do produto. - serviços para complementar a necessidade do cliente. Cada uma destas solicitações vem de um responsável e estas solicitações são priorizadas e negociadas por um fantástico PO, que sou eu.
- O que estou mostrando aqui não é o melhor caso de implementação de Agile... é uma equipe que ainda está em seu caminho por algo melhor E tivemos alguns problemas estruturais. Esta apresentação veio parar aqui porque precisamos de uma primeira para apresentar o modelo de caso prático. Se durante esta apresentação você olhar e falar… pô .. Tenho um caso que despertaria muito mais perguntas… demorou… apresenta para todos.
- Nosso processo é Scrum But total... ao fazer o Nokia test que nem é extremamente detalhado tiramos cinco... por isso... digo que ainda a muito espaço para melhora.
- O começo do uso de Scrum nesta equipe aconteceu porque uma outra equipe nossa vinha usando o Scrum com sucesso em outro projeto com um cliente nosso no Japão. Ali a equipe cresceu muito, melhorando qualidade, descobrindo o seu ritmo e criando uma equipe realmente multi-disciplinar.
- 16 pessoas 4 experientes 5 + ou - 7 novos E estes novos foram contratados no início do projeto. Este foi o principal erro deste início... contratar mais gente para um projeto que ainda nem estava bem definido o que seria. Começamos grande quando não precisava... Podíamos montar esta equipe grande depois, caso fosse necessário.
- entao.. como já era de se imaginar tínhamos um Scrum que parecia com o Scrum mas não chegava nem perto....
- As consequências disso é que o pessoal começou a falar que este tal de Scrum era muito ruim... não adiantou nada... E o pior que o pessoal estava fazendo tudo em fases... chegando ao ponto de um especificar em uma sprint... para na outra o cara codificar e outro fazer os planos de teste e só na outra testar. A equipe tinha um perfil inadequado para um projeto de pesquisa e desenvolvimento, com muitas pessoas de teste / suporte que não mexia no código. Na outra equipe que trabalhei sentia falta de uma pessoa de qualidade... para ajudar em alguns testes.... nesta era o contrário. Em uma equipe de desenvolvimento, sentindo falta de desenvolvedores. A equipe confiava fortemente em testes manuais... gastando um bom tempo fazendo casos de teste e depois executando.
- 2 meses se passaram, eu me juntei a equipe com a saída do antigo responsável pelo projeto. A equipe foi reduzida para 12 pessoas. Começamos a definir melhor uma meta para sprint, que fizesse sentido comemorar o seu cumprimento. Nosso backlog ainda estava um pouco confuso, porque os clientes não tinham o mesmo entendimento da equipe sobre o que era de valor.
- o planejamento começou a ser feito em conjunto, com as 11 pessoas. Começaram a ser feitas entregas completas, sem a criação de fases entre as sprints. E os testes de aceitação foram automatizados... Só seriam escritos casos de teste para itens que não possam ser automatizados.
- O backlog estava ainda confuso, porque não havia um acordo sobre o que era mais importante para o produto entre PO, clientes e time. As pessoas inexperientes ou com pouco conhecimento dificultaram a sua utilização em outras posições como teste automatizado, codificação. Quando falamos para o cliente que iríamos parar de executar um teste manual que estava sendo feita em uma interface que era só utilizada por nossa equipe... parecia que estávamos largando qualidade. Quando ele pediu um cronograma detalhado dos próximos 6 meses e não fornecemos... parecíamos irresponsáveis. Mas queríamos acertar não um cronograma com todas as features que ele queria, mas sim, as mais importantes no próximo mês.
- Depois de trabalhar por uns 3 meses assim... os nossos clientes internos começaram a achar legal este esquema de sprint e já se programavam para pensar certinho o que iriam pedir para a próxima.
- o cliente começou a pedir este planejamento de outras equipes nossas. E assim que começamos a entregar valor mais cedo e do que era mais importante para o cliente... suas requisições na verdade diminuiram. os testes de aceitação que desenvolvemos começaram a ser utilizados por quem instalava a solução no campo... customizando estes testes para a solução que era instalada no cliente. E só agora as pessoas estão realmente falando nas retrospectivas. Se sentindo a vontade para tocar em um assunto sem serem cutucadas.
- Não temos testes unitários e pouco melhoramos em relação a isto. Estes últimos dois meses ficamos em diversas atividades de pesquisa com novos produtos, softwares e soluções É difícil achar uma velocidade. 11 pessoas é muita gente. Mas não conseguimos ainda dividir de forma eficiente em dois times. Tentamos com 6 pessoas nas equipes, mas não conseguimos manter esta divisão por duas sprints...
- Acho que os problemas que tivemos para definir o backlog atrasaram um pouco a evolução da equipe... mas agora acho que o time está unido e indo em busca de um bom resultado
- Eu hoje fraquejei e não fiz teste unitário. Na verdade, nos últimos 6 meses eu não fiz. Produto já é antigo, é difícil. É, nas novas features não fizemos não. Fizemos ua vez ou outra, mas não fizemos sempre. Temos uma equipe de teste que faz a validação. Rede de segurança acaba sendo as pessoas.... Para resolver um problema temos que estar ciente dele. A equipe ainda não está realmente convencida por completo da importância dos testes automatizados. Mas já sabe que é preciso melhorar.
- Toda recuperação tem que ter um começo. O começo da mudança foi automatizar os testes de aceitção. E a definição é feita em conjunto entre desenvoledores e testadores. Cria um stub que simula a funcionalidade
- Este produto que desenvolvemos é a evolução de uma plataforma que tínhamos anteriormente. Muitas vezes, ela tem mais valor do que para o cliente. Ela atende chamadas de forma customizada... o jeito de fazer aplicação é muito melhor... mas não entrega valor para o cliente.
- Todo mundo dá seu pitaco... e acaba formando a opinião em assuntos mais técnicos. Dois casos foram exemplares: - Toda a equipe estava construindo casos de teste unitários de um software windows enorme... - Este software já está estável há alguns anos e atualmente só é utilizado por nossa equipe. - Enquanto isto não fazíamos teste de carga nem implementávamos melhoria para diminuir o tempo de projeto em cliente. Não focamos em valor.
- Vendendo produto. Nossa empresa vem do conceito de vender produto... alguns de sucesso vendendo como caixinha. Assim... tudo que vende as pessoas querem transformar em produto... Adicionando features que não são necessárias... homologando em todos os sistemas operacionais... o cliente queria uma bola de futebol... mas que tal homologar ela também como bola de sinuca... temos 2 grandes clientes utilizando a solução... porque não atender bem eles e esquecer do produto.
- O backlog estava ainda confuso, porque não havia um acordo sobre o que era mais importante para o produto entre PO, clientes e time. As pessoas inexperientes ou com pouco conhecimento dificultaram a sua utilização em outras posições como teste automatizado, codificação. Quando falamos para o cliente que iríamos parar de executar um teste manual que estava sendo feita em uma interface que era só utilizada por nossa equipe... parecia que estávamos largando qualidade. Quando ele pediu um cronograma detalhado dos próximos 6 meses e não fornecemos... parecíamos irresponsáveis. Mas queríamos acertar não um cronograma com todas as features que ele queria, mas sim, as mais importantes no próximo mês.
- Nas nossas outras equipes... conseguimos descobrir nossa velocidade e ir tomando atitudes para aumentá-la
- Nesta equipe, demoramos para encontrar nossa velocidade principalmente por dois motivos: - Pessoas muito inexperientes, que não agregariam muito às atividades... estavam ainda aprendendo... e o problema aqui foi a concetração destas pessoas. - Diversas tarefas de pesquisa. estamos numa fase de analisar 4 soluções (3 open source e 1 de vídeo) e analisando outros softwares que seriam utilizados em conjunto. Pesquisamos sobre vídeo chamada e afins. Pessoas tinham dificuldades em estimar o tamanho das histórias.
- Na Voice temos o costume de formar as pessoas desde o início. Entram, ensinamos a programar, ensinamos telefonia... Aumenta o comprometimento, a história da empresa.
- MAs algumas vezes exageramos e colocamos diversas pessoas novatas no mesmo projeto. Para montar uma equipe eficiente e realmente multi-disciplinar... porque a pessoa tem menos conhecimento adquirido... Hoje... gostamos de ter 1 ou 2 novatos na equipe... não muito mais que isso.
- Nossa equipe participa de um projeto com subvenção econômica da Finep. TEmos um cronograma de entregáveis. Um cronograma bem cascata.... mas optamos por ir desenvolvendo sempre entregando pedaços de software. REcebemos também demanda de um cliente para um produto da empresa e com algumas customizações. As sprints não são sempre parte do Release Planning... Qual a melhor abordagem?
- Nossa equipe tem 12 pessoas. É difícil fazer uma reunião diária eficiente e um planejamento que realmente discuta todos os itens. Tentamos dividir em 2 equipes de 6, mas não deu muito certo... - Não conseguimos manter os 6 após cada sprint. Acredito que muito devido a problemas de conhecimento em uma só pessoa. - Agora somente algumas APIs que lidam com hardware estão dependendo de uma pessoa só... Não vejo muita vantagem trabalhando com um grupo grande de pessoas... alguém trabalha e acha uma boa...