Esse é um FAQ (Frequently Asked Questions – Perguntas Frequentes) sobre Agilidade. As perguntas foram enviadas por alguns leitores do nosso blog, que fazem parte da nossa lista Vip.
Neste post temos perguntas sobre:
- Métricas Ágeis
- Pontos de Função e Agilidade
- Currículo e Empregabilidade em grandes empresas ágeis
- Gestão de entregas em ambientes ágeis
- DevOps e equipes ágeis
Boa leitura e fique à vontade para participar nos comentários. 😉
Leitor(a): Cacilda Andrade
Bom dia
minha duvida: como fazer estimativas de custo de software no modelo ágil?APF realmente não caberia ? mesmo se fosse gradativo ?
Olá Cacilda!
Imagino que esteja se referindo a prestação de serviços, e não sobre equipes de funcionários da própria empresa alocados.
Partirei dessa premissa, se for diferente disso sinalize nos comentários que eu complemento, ok?
No modelo ágil existe uma diferença significativa que é não termos escopo fechado.
Portanto, medidas de tamanho funcional não costumam ser utilizadas para fins de faturamento (para fins de planejamento e gestão algumas empresas adotam).
Existem casos onde o fornecedor vende capacidade produtiva (homem/hora) que é traduzida em tamanho funcional e assim, cobra-se um valor fixo por sprint (considerando o timebox de cada sprint).
Exemplo:
Uma empresa tem sprints quinzenais (10 dias úteis), onde a cada sprint temos três desenvolvedores com 7h produtivas/dia, logo, 21h produtivas por semana, 42 horas por sprint no total (total por desenvolvedor).
Temos então 42h x 3 desenvolvedores, totalizando 126h alocadas por sprint.
Se a produtividade é 4,2h por ponto de função por exemplo, então no sprint de duas semanas (10 dias úteis) teremos 30 pontos (126h/4,2h). Se cada ponto = R$ 1.200,00, então o valor a ser cobrado pelo o sprint será de R$ 36.000,00.
Mas isso é “vender ponto”.
Acho pouco usual e neste tipo de contexto vejo mais uma aplicação de modelo “body shop”, onde com a alocação, cobra-se o valor da alocação mensal do profissional.
Como mostrar no currículo que você está preparado pra trabalhar com agilidade em grandes empresas?
Olá Daniela!
Para ambos os cenários uma mesma sugestão se aplica: cuide do seu perfil no Linkedin, como se fosse um jardim de inverno público de Paris, que recebe muitos visitantes por dia! 🙂
As grandes empresas focam muito no Linkedin.
Estas empresas inclusive possuem sistemas que fazem buscas automáticas lá para filtrar potenciais candidatos; investem em soluções que vão de simples buscadores por palavras chave até mesmo máquinas de aprendizado e robôs que fazem isso a todo momento.
No cenário 1 (com experiência e capacitação):
- Evidencie em detalhes sua experiência profissional com agilidade (para cada empresa que passou), descrevendo os principais desafios (de pessoas, produtos e processos) no contexto de agilidade. Deixe claro os frameworks ágeis com os quais trabalhou, resultados que ajudou a produzir etc.
- Coloque sempre palavras chave nestes textos que aumentarão sua “encontrabilidade”. Palavras como Scrum, Kanban, Lean, XP, Story Points, Sprints, Squads e coisas do tipo. Não se preocupe em ser redundante, pois os RHs vão bater o olho no perfil/currículo e se não verem estas palavras excluem fácil o candidato na “primeira peneira”.
- Dê destaque às certificações que possui. Muitas certificações são “protocolo” apenas, não somam quase nada em termos de conhecimento “de fato”, mas mostram que o profissional está se envolvendo com agilidade, estudando sobre. Algumas são robustas e agregam real valor. Mas independente das certificações, é importante destacá-las na “parte de cima” do currículo, perfil do Linkedin e nas assinaturas de e-mail.
No cenário 2 (sem experiência e capacitação):
- Procure cursos e certificações, é necessário e importante conhecer bem a teoria. Certificações (e cursos), como citado anteriormente, não “fazem” o profissional, mas demonstra conhecimento e vontade aprender, além de mostrar foco na especialização técnica.
- Empresas grandes são mais exigentes, mas devido à escassez de profissionais de tecnologia que temos no Brasil, com muita frequência elas diminuem “a régua” para conseguir formar suas equipes. Não deixe de procurar oportunidades por ainda não ter experiência, mas prepare o “cartão de visitas” (Linkedin, currículo) da melhor forma e deixe bem claro qual o seu objetivo de carreira.
Para ambos os cenários também sugiro muito se envolver com a comunidade ágil. Participe de Meetups, eventos regionais e nacionais, comunidades em Facebook, Linkedin etc.
É uma excelente forma de se antenar no que está ocorrendo e conhecer profissionais da área (network), lembrando que as empresas prezam muito mais indicações de funcionários internos do que candidaturas desconhecidas.
Abaixo alguns links que podem ajudar:
Resumindo: cuide muito bem do seu perfil do Linkedin, esteja no meio das pessoas que podem lhe ajudar, ajude as pessoas também, certifique-se, estude muito e mostre tudo isso para o mercado! 😉
Leitor: Marcos Vinícius Figueira
Olá , tudo bem?
Segue a minha dúvida: qual é a melhor abordagem gerencial para entregar um projeto com as exigências complexas dos clientes sem perda de qualidade na entrega?Abraços
Olá Marcos!
Sua pergunta é muito ampla, mas tenho uma dica que pode se aplicar em qualquer cenário, ágil ou tradicional, mas que na agilidade é um Mindset muito bem vindo e que contribui muito para a eficácia e eficiência.
Penso que a melhor abordagem de gestão das entregas é uma gestão orientada a dados!
Contra os números não há argumentos, e o uso dos dados (me refiro a medir, ter indicadores etc.) contribui muito para uma boa gestão de pessoas também, uma vez que havendo os números para “traduzirem a realidade”, os conflitos gerados por opiniões divergentes diminuem muito.
Busque ter indicadores que façam sentido, que deem transparência ao contexto, que são compreendidos pelo cliente e pelo time e que ajudem a guiar a gestão na melhor direção possível, do ponto de vista de eficiência e eficácia.
Abaixo dois posts aqui do blog que podem ajudar:
Resumindo: gerencie sempre amparado por indicadores e métricas, contra números não há argumentos, e isso muda o jogo. E o principal de tudo, pessoas. Foque sempre na melhor gestão de pessoas possível! 😉
Leitor: Carlos Eduardo
Bom dia,eu gostaria de saber mais sobre formas de medir a velocidade do time scrum, gostaria saber mais sobre lead time e velocityDesde já agradeço
Olá Carlos!
Abaixo vou abordar as medidas em separado, para explicar um pouco sobre elas:
Velocidade (Velocity)
É uma medida utilizada por algumas equipes que rodam Scrum (mas não é uma medida/métrica “original” do Scrum – não é prescrito pelo Scrum Guide).
Trata-se da quantidade total de trabalho que um time estrega por Sprint, podendo ser: Story Points por Sprint, Tarefas por Sprint, Horas por Sprint etc.
É um indicador que temos que ter muito cuidado em usar.
Na minha opinião não aplica-se de forma alguma o uso de Velocidade com Story Points, prática que talvez a maioria dos times Scrum aplica.
Story Point não é medida de tamanho, é medida de complexidade.
Uma mesma User Story pode ter 1, 2, 3, 5 ou 8 Story Points para um mesmo desenvolvedor em diferentes momentos no tempo, conforme ele vai amadurecendo na equipe/produto/processo do time.
Como considerar histórico de produtividade, velocidade, onde a complexidade é relativa?
Lead time
É uma medida muito utilizada por equipes Scrum mais maduras, ou equipes que rodam Kanban.
Não é necessariamente uma medida de Velocidade mas de tempo em que um item de trabalho leva para ser entregue (a seguir falo sobre Throughput).
Trata-se do tempo consumido entre “o pedido e a entrega”.
No contexto de produção de software é o tempo entre o requisito nascer e ser implantado em produção.
Também é uma medida que carrega um pouco de relatividade porque os itens de trabalho não possuem “tamanho”.
Diferente de velocidade medida usando Story Point, Lead time considera o histórico de entregas do time, geralmente calculando a media de tempo por item de trabalho.
Além de medir a performance do processo na totalidade, é uma métrica de previsibilidade, que mostra a performance do ponto de vista de eficiência.
Por exemplo: no Sprint 1 o tempo médio para entre o pedido e a entrega do item de trabalho foram 3 dias, no Sprint 2 foram 6 dias e no Sprint 3 foram 7 dias. Logo, para o Sprint 4, haverá uma expectativa de Lead time de 5,3 dias.
Throughput
É uma métrica usada por equipes que usam um pouco (ou total) Kanban no dia a dia, e tem a ver diretamente com velocidade (mas existem os que defendem que não).
O objetivo é medir a quantidade de itens de trabalho entregues em um intervalo de tempo.
Em equipes que rodam Scrum calculamos o Throughput por Sprints, podendo ser algo como a quantidade de User Stories entregues por Sprint.
Por exemplo: no Sprint 1 foram entregues 7 Histórias, no Sprint 2 foram 11 e no Sprint 3 foram 9. Logo, o Throughput médio do time é 9 dias.
Lembrando que Kanban não é apenas o quadro “clássico” (To Do/Doing/Done). Trata-se de um modelo de sistema de trabalho, uma filosofia inclusive.
Pontos de Função
É uma medida de tamanho (diferente de Story Points, que é de complexidade).
É uma métrica que tem perdido espaço nas empresas que estão adotando agilidade.
Muito útil em alguns ambientes, por ser muito menos subjetiva que métricas de complexidade, que são altamente relativas.
O Ponto de Função é apenas uma unidade de medida. O seu uso para dar tamanho à entrega de times é que aplica-se no contexto da velocidade.
Cada item de trabalho do Sprint (ou outro ciclo) é mensurado em Pontos de Função (User Story X = 12 pontos, User Story Y = 16 pontos, User Story Z = 10 pontos), e a cada Sprint (ou outro tipo de ciclo) ocorre a apuração para saber quantos Pontos de Função foram entregues no total.
Obs.: é como se fosse uma derivação do Throughput.
Por exemplo: no Sprint 1 foram entregues 35 Pontos de Função, no Sprint 2 foram 36 e no Sprint 3 foram 42. Logo, a vazão média de Pontos de Função por Sprint é de 37,6 pontos.
Um ponto crucial nisso tudo é avaliar o paradoxo Entrega x Valor (Outbound x Outcome). Agilidade tem mais foco em produzir Valor do que Entrega (e muita entrega de valor pode nem ser software, necessariamente). Então não significa que boa performance de entrega = boa performance de geração de valor.
Resumindo: existem diversas formas de se apurar velocidade, e apurar velocidade é fundamental para a melhoria contínua de times ágeis (ou tradicionais, também). É importante entender o contexto e observar qual forma de medir faz mais sentido! 😉
Leitor: Adriana
Bom dia Plinio! Encaminho as perguntas por ordem de prioridade:– Num time ágil todos fazem tudo?
– Quais são os novos papéis dos profissionais em equipes ágeis?
– O que estudar, quais as oportunidades?– O time tem 100% de autonomia?– O que é DevOps?
– Com agilidade não precisamos mais documentar nada?Obrigada pela oportunidade!
Olá Adriana!
Num time ágil todos fazem tudo?
Existe uma falsa ideia de que em times ágeis todos fazem tudo.
Isso é um grande equívoco, que se não for bem equalizado gera grandes prejuízos em termos de processos, produto e pessoas.
O Scrum fala sobre “times multidisciplinares” e não “indivíduos multidisciplinares”.
Quer dizer que, um time Scrum por exemplo precisa ter, além do Product Owner e Scrum Master, o “Time de Desenvolvimento”. Porém, cada um especializado no “seu quadrado”.
Imagine uma equipe com Cientistas de Dados, Desenvolvedor Java, .Net, Analista de QA etc.
Imagine um único profissional fazendo tudo isso! ;(
Mas é importante destacar que a meta sempre é o valor a ser gerado, e a depender do momento, todos podem se voltar a uma atividade semelhante para garantir o resultado.
Por exemplo, os desenvolvedores eventualmente podem em validar itens já construídos e estocados junto com o Quality Assurance para diminuir a fila do time.
Quais são os novos papéis dos profissionais em equipes ágeis?
Depende da empresa, do contexto, da necessidade.
Mas se olharmos para o Scrum, temos o Product Owner, o Scrum Master e os Time de Desenvolvimento (onde ficam todos os profissionais que não são o PO e o SM, podendo ter os desenvolvedores, Tester/QA, Usuário Chave etc.).
PO + SM + Dev Team = Scrum Team.
O que estudar, quais as oportunidades?
As oportunidades são muitas, o mercado está indo na direção da agilidade e trata-se de um caminho sem volta.
Penso que antes de tudo, estudar o Mindset Ágil é premissa.
Não adianta entender frameworks como Scrum, Kanban, Extreme Programming sem entender o porque existem, porque devem ser aplicados, porque não devem, quando customizá-los etc.
Veja a imagem abaixo, para compreender melhor o contexto.
O time tem 100% de autonomia?
Essa pergunta demanda uma resposta muito extensa, rs.
Mas pense que, no nível estratégico não se aplica, no nível tático se aplica parcialmente e no nível operacional, o time deve ter 99% de autonomia. 🙂
O que é DevOps?
DevOps é um Mindset, uma Filosofia.
Defende a união dos esforços de Desenvolvimento e Operações, focando em Integração Contínua e Entrega Contínua para criar condições de entregar software e ativar valor, no menor espaço de tempo possível, com um ambiente sustentável para o time e com a máxima qualidade.
Neste link você pode ver um pouco mais sobre.
Com agilidade não precisamos mais documentar nada?
Este é outro mito, popularmente difundido e super perigoso.
O ponto é: documentar o que faz sentido, na medida necessária apenas.
Muitas coisas não precisam ser documentadas, mas no passado a área de software pensava diferente e isso é desperdício garantido.
Mas aquilo que precisa ser, deve ser sim documentado.
O Manifesto Ágil não fala que não devemos mais documentar. No segundo Valor do Manifesto temos:
“Software em funcionamento mais que documentação abrangente“
E ao final da citação dos valores do manifesto, temos:
“Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”
Então, quando é necessário documentar, sim. Quando não é necessário, não.
Resumindo: como dizia o filósofo Aristóteles, “o bom senso é a melhor medida para todas as coisas”. 😉
Grande abraço!