Olá Habitantes! Qualquer empresa deseja obter maior eficiência no desenvolvimento de software, pois isso afeta diretamente os lucros. Grande parte da literatura Agile é voltada para empresas grandes e de alto crescimento, mas e se sua empresa não estiver na vanguarda da TI? A boa notícia é que toda organização pode melhorar o desempenho, e este livro o ajudará a encontrar caminhos e soluções específicos para obter o máximo do Agile. “Não sou um evangelista ágil. Sou adepto do que funciona e adversário do que muito promete mas não traz resultados. Neste livro, a metodologia Ágil é apresentada não como um movimento que requer consciência elevada, mas como um conjunto de métodos administrativos e técnicos especiais, cujo efeito e interação são compreensíveis para qualquer empresário ou especialista em TI.Os entusiastas do Agile podem criticar este livro por não promover as melhores práticas do Agile. Mas esse é o ponto - uma ênfase em métodos práticos que se mostraram eficazes. A história do Agile está repleta de ideias que foram implementadas com sucesso por alguns entusiastas em algumas organizações, mas que não podem ser usadas por todos ”, diz Steve McConnell. O novo livro de Steve McConnell, autor dos lendários livros Code Complete e Software Estimation, reúne a experiência da vida real de centenas de empresas. Use um guia simples e direto para as práticas Agile modernas e mais eficazes.que foram implementados com sucesso por alguns entusiastas em algumas organizações, mas que não são usados por todos ”, diz Steve McConnell. O novo livro de Steve McConnell, autor dos lendários livros Code Complete e Software Estimation, reúne a experiência da vida real de centenas de empresas. Use um guia simples e direto para as práticas Agile mais modernas e eficazes.que foram implementados com sucesso por alguns entusiastas em algumas organizações, mas que não são usados por todos ”, disse Steve McConnell. O novo livro de Steve McConnell, autor dos lendários livros Code Complete e Software Estimation, reúne a experiência da vida real de centenas de empresas. Use um guia simples e direto para as práticas Agile modernas e mais eficazes.
Execução de projetos ainda mais eficiente
No capítulo anterior, vimos como organizar e oferecer suporte aos desenvolvedores ao trabalhar no Agile. Este capítulo discute como organizar e manter adequadamente o processo de desenvolvimento ao trabalhar no Agile.
A maior parte do desenvolvimento de software é organizada em projetos. As organizações usam uma variedade de termos para se referir a conceitos relacionados a um projeto, incluindo produto, programa, release, ciclo de release, função, fluxo de valor, fluxo de trabalho e muito mais. ...
A terminologia varia consideravelmente. Algumas empresas acreditam que lançamento é sinônimo de projeto. Outros pensam que o lançamento se refere ao desenvolvimento progressivo, então pararam de usá-lo. Outros ainda definem o conceito de "função" como a quantidade de trabalho projetada para 3-9 pessoas e 1-2 anos. Neste capítulo, pela palavra "projeto", quero dizer qualquer um dos tipos de trabalho listados, ou seja, o trabalho de um certo número de funcionários por um longo tempo.
Princípio chave: projetos pequenos
Nos últimos 20 anos, os casos mais famosos de aplicação de Agile com sucesso em pequenos projetos. Durante os primeiros 10 anos de sua existência, o Agile prestou grande atenção em manter os projetos pequenos, ou seja, 5 a 10 pessoas em uma equipe (por exemplo, 3 a 9 desenvolvedores, um product owner e um scrum master). A ênfase no tamanho de projeto pequeno é muito importante porque projetos pequenos são mais fáceis de manusear do que grandes, como mostrado na Fig. 9,1
Capers Jones postulou por 20 anos que pequenos projetos são mais bem-sucedidos do que grandes [Jones, 1991; 2012]. Eu resumi a maioria das pesquisas sobre sucesso de projetos versus tamanho em meus livros Code Perfect [McConnell, 2004; SPb.: Peter, 2007] e Software Estimation: Demystifying the Black Art [McConnell, 2006].
Projetos menores são mais seguros por vários motivos. Grandes projetos requerem o envolvimento de mais especialistas, e o número de relacionamentos entre as pessoas nas equipes e entre as próprias equipes aumenta em uma progressão não linear. E quanto mais complexo o relacionamento se torna, mais erros são cometidos na interação. Erros de interoperabilidade levam a erros nos requisitos, projeto, codificação - em geral, outros erros.
Conseqüentemente, quanto maior se torna o projeto, mais erros são cometidos (Figura 9.2). Isso significa não apenas que o número total de erros está crescendo, mas que há muito mais erros em projetos grandes!
Quanto mais alta a taxa de erro, menor a eficácia das estratégias de detecção de falhas. Isso significa que o número de defeitos no produto acabado aumenta desproporcionalmente.
Também é necessário mais esforço para eliminar erros. Portanto, como mostrado na Fig. 9.3, projetos menores têm maior produtividade por pessoa, mas quanto maior o tamanho do projeto, mais produtividade cai. Esse fenômeno é conhecido como custo de escala.
Essa relação inversa entre tamanho e desempenho foi exaustivamente pesquisada e testada por mais de 40 anos. Fred Brooks discutiu o custo de escala no desenvolvimento de software na primeira edição de seu livro The Mythical Man-Month [Brooks, 1975; SPb .: Peter, 2021]. O trabalho de Larry Putnam na estimativa dos custos de desenvolvimento de software confirmou as observações de Brooks [Putnam, 1992]. O estudo do modelo de custo de desenvolvimento (Cocomo) confirmou empiricamente a existência de custos de escala duas vezes - em um estudo do final dos anos 1970 e em um estudo atualizado do final dos anos 1990 [Boehm, 1981; 2000].
A conclusão é que, para maximizar a probabilidade de um projeto Agile bem-sucedido, tente manter o projeto (e a equipe) pequenos.
Claro, é impossível tornar cada projeto pequeno. O Capítulo 10, “Executando grandes projetos com ainda mais eficácia”, descreve abordagens para grandes projetos, incluindo sugestões sobre como reduzi-los.
Princípio-chave: Sprints curtos
A conclusão natural de que projetos pequenos são preferíveis é que os sprints não devem durar muito. Você pode pensar que um pequeno projeto já é uma receita para o sucesso. Mas sprints curtos de 1-3 semanas contribuem para um gerenciamento de projeto bem-sucedido em todas as áreas. Isso é descrito nas próximas seções.
Sprints mais curtos reduzem o número de requisitos intermediários e melhoram a capacidade de resposta a novos requisitos
No Scrum, novos requisitos podem ser adicionados entre os sprints. Mas, uma vez que o sprint começou, você não pode adicionar requisitos até o próximo sprint. Isso faz sentido se o sprint durar de 1 a 3 semanas.
Se os ciclos de desenvolvimento demorarem mais, os stakeholders estarão cada vez mais insistentemente pedindo para adicionar requisitos ao longo do caminho, de modo que as solicitações para adiar a adição de requisitos não são mais justificadas. Se o ciclo com um modelo de desenvolvimento sequencial durar seis meses, pedir ao stakeholder para adiar a implementação do novo requisito até o próximo ciclo significa que o trabalho no requisito começará apenas no próximo ciclo - ou seja, no início do ciclo, esse requisito será apenas adicionado e, então, você precisará aguardar a entrega do produto no final deste ciclo. Em média, leva 1,5 ciclo, ou seja, 9 meses.
Em contraste, sprints normais de Scrum duram duas semanas. Isso significa que uma parte interessada que deseja adicionar um novo requisito terá que esperar em média três semanas.
Pedir a uma parte interessada que espere 9 meses para que um requisito seja implementado é frequentemente inadequado. E três semanas quase sempre é apropriado. Isso significa que o time Scrum trabalha silenciosamente, sem medo de novos requisitos no meio do sprint.
Sprints curtos fornecem maior capacidade de resposta ao trabalhar com clientes e partes interessadas
Cada sprint apresenta uma nova oportunidade para mostrar software funcional, validar requisitos e gerar feedback das partes interessadas. Com sprints padrão de duas semanas, as equipes têm a oportunidade de ser mais rápidas 26 vezes por ano! Com um ciclo de desenvolvimento de três meses, essa oportunidade é apresentada apenas quatro vezes por ano. Quinze anos atrás, um projeto de três meses era considerado curto. Hoje, tal programação significa que você não será capaz de responder rapidamente ao feedback das partes interessadas, clientes e do mercado.
Sprints curtos
aumentam a confiança das partes interessadas À medida que as equipes entregam resultados com mais frequência, o progresso se torna mais transparente, de forma que o progresso seja visível para as partes interessadas, o que aumenta a confiança entre eles e a equipe.
Sprints curtos ajudam a acelerar o desenvolvimento por meio de ciclos de aprendizagem e adaptação.
Quanto maior a taxa de iteração, mais oportunidades para a equipe refletir sobre as lições aprendidas, tirar conclusões e aplicar os resultados a métodos práticos de trabalho. A justificativa para essa área é a mesma para a capacidade de resposta do cliente: é melhor deixar suas equipes aprenderem e se adaptarem 26 vezes por ano, ou apenas quatro? Sprints curtos ajudam sua equipe a melhorar mais rápido.
Sprints curtos ajudam a reduzir o tempo de experimentação
No contexto dos Problemas emaranhados de Cynefin, os problemas devem primeiro ser investigados antes que todo o escopo do trabalho possa ser compreendido. Tal pesquisa deve ser caracterizada da seguinte forma: "Para obter uma resposta a esta ou aquela pergunta, faça o mínimo de trabalho necessário." Infelizmente, a Lei de Parkinson diz que o trabalho ocupa todo o tempo disponível. E até que a equipe desenvolva disciplina de ferro, a solução do problema, se for alocado um mês para isso, levará exatamente um mês. Mas, se houver apenas duas semanas, geralmente a solução do problema leva duas semanas.
Sprints curtos permitem a detecção oportuna de custos e riscos
Sprints curtos permitem que você acompanhe o progresso com mais frequência. Depois de apenas alguns sprints, ao trabalhar em uma nova tarefa, a "velocidade" da equipe ou o ritmo de progresso serão determinados. A capacidade de monitorar o andamento do trabalho torna mais fácil prever o momento do lançamento do produto. Se o trabalho estiver demorando mais do que o planejado originalmente, isso ficará claro como cristal em apenas algumas semanas. Sprints curtos são uma ferramenta poderosa para se manter informado. O Capítulo 20, "Previsibilidade ainda melhor", dá mais detalhes sobre isso.
Sprints curtos promovem a responsabilidade da equipe
Se uma equipe é responsável por entregar funcionalidade de trabalho a cada duas semanas, eles não têm a oportunidade de trabalhar no escuro por muito tempo. Ela mostra os resultados de seu trabalho em reuniões de revisão de sprint e relatórios para as partes interessadas a cada duas semanas.
O product owner vê os frutos do trabalho com ainda mais frequência.
O product owner aceita ou rejeita o trabalho, o andamento do trabalho é claramente visível. Assim, as equipes são mais responsáveis por seu trabalho.
Sprints curtos promovem responsabilidade
Por gerações, as equipes de desenvolvimento sofreram com "estrelas" trancadas em uma sala escura por meses, e não estava completamente claro se o trabalho estava progredindo. No caso do Scrum, esse problema não existe mais. Todos trabalham em prol dos objetivos da equipe no sprint, além disso, há a necessidade de vir ao stand-up todos os dias e conversar sobre o trabalho que foi feito ontem - você não vai conseguir mais se trancar. Ou o desenvolvedor passa a cooperar, que resolve o problema de uma forma, ou não aguenta as condições e sai da equipe, que ainda resolve o problema, embora de outra forma. Por experiência própria, posso dizer que qualquer um dos resultados é mais favorável do que no caso em que alguém trabalha sem nenhum relatório por semanas ou meses e, no final, descobre-se que nada foi realmente feito.
Sprints curtos promovem a automação
Como as equipes costumam realizar a reconciliação, os sprints curtos podem automatizar tarefas que, de outra forma, seriam repetitivas e demoradas. A automação é amplamente difundida na montagem, integração, teste e análise estática de código.
Sprints mais curtos têm maior probabilidade de proporcionar uma sensação de satisfação. Uma
equipe que entrega software funcional a cada duas semanas tem mais probabilidade de ficar satisfeita com seu trabalho e também de ter a oportunidade de comemorar suas realizações. Isso contribui para um senso de profissionalismo que estimula a motivação.
Sprints curtos. Resumo
Em geral, os benefícios dos sprints curtos podem ser resumidos da seguinte forma: "A velocidade de entrega em todos os aspectos ajuda a lidar com o volume de trabalho." A entrega de funcionalidade em pequenos lotes e cadências curtas traz um grande número de vantagens em relação à entrega de funcionalidade em grandes lotes e cadências longas.
Planeje com base na velocidade das tarefas
As unidades de dificuldade da história são uma medida do tamanho e da complexidade de uma tarefa. Velocidade é uma medida de progresso com base na frequência com que as tarefas são concluídas e medidas em unidades de dificuldade da história. A programação baseada na velocidade é o planejamento e rastreamento do trabalho com base nas unidades de dificuldade do histórico e na velocidade de trabalho.
Agendamento de velocidade e rastreamento não fazem parte do tutorial Scrum, mas na minha experiência, acho que seria uma boa ideia incluí-los. A seguir, falarei sobre como as unidades de dificuldade da história e as estimativas de velocidade são aplicadas.
Estimando o tamanho do backlog do produto
A pontuação de dificuldade é usada para determinar o tamanho do backlog do produto. Os tamanhos dos problemas no backlog do produto são geralmente estimados em termos de unidades de dificuldade das histórias e, em seguida, as unidades de complexidade das histórias são adicionadas para calcular o tamanho total do backlog do produto. Isso deve ser feito no início do ciclo de lançamento e conforme o trabalho é adicionado ou removido do backlog. Isso é feito na medida em que a equipe precisa ser previsível. Mais sobre isso no Capítulo 20, "Previsibilidade ainda melhor."
Cálculo de velocidade
A quantidade de trabalho concluído pela equipe em cada sprint é calculada em unidades de dificuldade da história. O número de unidades de dificuldade de história alcançadas em cada Sprint representa a velocidade da equipe. A velocidade é calculada com base nos resultados de cada sprint calculando a média.
Planejamento de Sprint
A equipe planeja o escopo de trabalho por sprint, também medido em unidades de dificuldade da história, com base nas observações da velocidade da equipe.
Se a equipe completou 20 unidades de dificuldade de história por sprint em média e, no sprint seguinte, estabeleceu para si mesma a meta de completar 40 unidades de história, então eles precisam cortar seus planos. Se um membro da equipe está saindo de férias ou vários membros da equipe estão participando de eventos de treinamento, a equipe deve planejar menos Dificuldades de História por sprint do que em média. Se a equipe conseguiu atingir as 20 unidades de dificuldade das histórias graças às noites sem dormir e ao trabalho nos finais de semana, a barra também deve ser rebaixada. Se sua equipe atinge as metas de sprint de maneira consistente e sem esforço, tente programar mais dificuldade de história do que a média. Em qualquer caso, a equipe está planejando com base em sua velocidade real.
Rastreamento de liberação
Com base na velocidade média, você pode calcular ou prever a quantidade de tempo que levará para concluir as tarefas na lista de pendências do produto. Se a lista de pendências do produto tiver 200 unidades de dificuldade de história e a velocidade média da equipe for de 20 unidades de dificuldade de história por sprint, a equipe precisará de 10 sprints para concluir todas as tarefas na lista de pendências. Explicarei mais sobre como isso funciona no Capítulo 20, "Previsibilidade ainda melhor".
Contabilizando o impacto das mudanças no processo, composição da equipe e outras mudanças
Com base na velocidade, você pode acompanhar o impacto das mudanças no processo, composição da equipe e outras mudanças. Os detalhes disso são discutidos no Capítulo 19, Melhorando ainda mais o processo.
Princípio fundamental: entrega do produto em fatias verticais
Para que os sprints sejam eficazes, a equipe precisa desenvolver a capacidade de entregar pequenos lotes de funcionalidade funcional com frequência. A abordagem de design que facilita isso é chamada de "uso de fatias verticais", o que significa fazer alterações em cada camada arquitetônica para obter incremento ou valor.
A fatia vertical representa a funcionalidade completa da pilha, como adicionar um campo a um extrato bancário ou tornar a confirmação da transação do usuário um segundo mais rápida. Cada um desses exemplos geralmente requer que toda a pilha de tecnologia seja executada, conforme mostrado na Figura 1. 9,4.
Fatias verticais tendem a ajudar as partes interessadas não técnicas a compreender, observar e medir melhor o valor do negócio. Eles dão à equipe a capacidade de lançar lançamentos mais rapidamente e perceber o valor real do produto para os negócios e obter feedback real dos usuários.
As equipes que usam fatias horizontais correm o risco de mergulhar na selva por vários sprints seguidos, trabalhando em histórias que refletem algum progresso, mas não trazem valor de negócio visível.
Às vezes, as equipes relutam em usar fatias verticais, geralmente por causa da menor eficiência. Eles argumentarão, por exemplo, que é mais eficiente fazer mais trabalho na camada de lógica de negócios e depois passar para a camada de interface. Essa abordagem é chamada de fatias horizontais.
Em alguns casos, do ponto de vista técnico, pode ser mais eficiente trabalhar em camadas horizontais, mas essa eficiência técnica, via de regra, leva à otimização de partes individuais do produto, o que não é tão importante quanto a obtenção de funcionalidades valiosas. Ao contrário das afirmações de que o uso de fatias horizontais leva a uma maior eficiência, nossa empresa descobriu que, ao usar fatias horizontais, muitas equipes se deparam com a necessidade de fazer correções significativas.
Fatias verticais fornecem feedback mais
preciso As fatias verticais permitem que você entregue funcionalidade rapidamente aos usuários de negócios, o que ajuda a obter feedback rápido sobre como a funcionalidade está funcionando corretamente.
Como as fatias verticais requerem desenvolvimento de ponta a ponta, os membros da equipe são forçados a trabalhar juntos no design e na implementação, o que fornece feedback técnico útil para toda a equipe.
O uso de fatias verticais também promove testes de ponta a ponta, o que ajuda a garantir um feedback preciso.
Fatias verticais fornecem mais valor de negócios
As fatias verticais são mais bem compreendidas pelas partes interessadas que não conhecem os detalhes técnicos, e isso leva a decisões de melhor qualidade que a empresa toma sobre a prioridade e a ordem de implementação de funcionalidades novas e revisadas.
Como as fatias verticais fornecem um incremento funcional completo, elas geralmente fornecem uma oportunidade de apresentar a funcionalidade de trabalho aos usuários, o que aumenta o valor comercial.
O uso de fatias horizontais leva ao fato de os desenvolvedores começarem a perceber a arquitetura como um produto. E isso pode levar a atividades gratificantes que são completamente desnecessárias para a entrega de funcionalidade e a outros métodos que levam a uma diminuição no valor.
O que uma equipe precisa para usar fatias verticais A
entrega da funcionalidade com fatias verticais pode ser difícil. Depende da composição da equipe, seus negócios, habilidades de desenvolvimento e teste, que incluem habilidades em toda a pilha de tecnologia.
As equipes também podem precisar alterar seu design e pensamento de implementação para trabalhar com fatias verticais, o que será diferente de trabalhar por componentes ou camadas horizontais. Algumas equipes não possuem habilidades de design para fazer isso e precisarão desenvolver (e manter o desenvolvimento) habilidades para lidar com isso.
Finalmente, as equipes precisam realizar seu trabalho em fatias verticais. O product owner e a equipe de desenvolvimento devem encontrar uma abordagem para refinar o backlog de forma que o resultado seja fatias verticais.
Princípio fundamental: Gerenciar dívidas de tecnologia
"Dívida de tecnologia" refere-se ao acúmulo de trabalho de baixa qualidade no passado, que retarda o ritmo de trabalho no presente. O exemplo clássico é uma base de código frágil em que cada tentativa de corrigir um bug gera um ou mais novos. Mesmo consertar um erro simples consome tempo e consertar erros adicionais.
A dívida técnica pode incluir código de baixa qualidade, design de baixa qualidade, um conjunto de testes fraco, uma abordagem de design difícil, um ambiente de construção pesado, processos manuais lentos e outras maneiras de uma equipe sacrificar o desempenho de longo prazo em favor de ganhos de curto prazo.
Consequências da dívida técnica
A dívida geralmente aumenta como resultado da pressão para priorizar liberações de curto prazo em vez de qualidade. Uma visão holística dos recursos investidos e dos retornos obtidos inclui a contabilização do impacto da dívida técnica ao longo do tempo.
As equipes técnicas e de negócios podem ter motivos convincentes para acumular essa dívida. Algumas versões são sensíveis ao tempo o suficiente para justificar trabalho adicional mais tarde devido ao desejo de fazer o trabalho mais rápido no presente.
No entanto, um modelo que permite que o débito técnico se acumule ao longo do tempo sem um plano para resolvê-lo acabará por reduzir a velocidade da equipe. A equipe precisa desenvolver um plano de gestão da dívida para manter ou aumentar sua velocidade.
Kruchten, Nord e Ozkaya desenvolveram um diagrama excelente de como surge a dívida técnica, qual (provável) valor de negócio ela tem e como ela acaba se tornando mais um passivo do que um ativo (Figura 9.5).
Ao trabalhar do zero, as equipes podem evitar o acúmulo de dívidas técnicas em primeiro lugar. Ao realizar um trabalho já iniciado, muitas vezes as equipes não têm escolha a não ser trabalhar com o débito técnico já acumulado. Em todos os tipos de trabalho, se a equipe não vai bem com o débito técnico, a velocidade vai diminuindo com o tempo.
Pagando dívidas técnicas
Diferentes equipes têm abordagens diferentes para pagar dívidas técnicas . Algumas equipes, para saldar a dívida, distribuem em compartilhamentos a cada ciclo de desenvolvimento (sprint ou release). Outras equipes adicionam dívidas à carteira de produtos ou lista de lacunas e priorizam a dívida e o resto do trabalho. Em qualquer caso, a principal característica é que a dívida técnica é administrada abertamente.
Tipos de dívida e como lidar
Nem todas as dívidas técnicas são iguais e existem classificações diferentes. Acho essas categorias úteis:
- Dívida intencional (curto prazo). Dívida derivada de considerações táticas ou estratégicas, como a liberação pontual de uma liberação urgente.
- Dívida intencional (longo prazo). A dívida derivou de considerações estratégicas, como inicialmente o suporte a uma única plataforma em vez de suporte a plataformas cruzadas.
- Dívida não intencional (má-fé). Dívida que acontece por acaso devido a métodos de desenvolvimento de baixa qualidade. Esse tipo de dívida retarda o trabalho tanto no presente quanto no futuro, por isso deve ser evitado.
- Dívida não intencional (boa fé). Dívida que surge acidentalmente devido a erros naturais no desenvolvimento de software (“Nossa abordagem de design não funcionou tão bem quanto planejamos” ou “A nova versão da plataforma apresentou sérias falhas de design”).
- Dívida herdada. Dívida herdada pela nova equipe da antiga base de código.
A Tabela 9.1 mostra quais abordagens são recomendadas para responder a esses tipos de dívida.
Benefícios de discutir dívida técnica
Em minha experiência, a metáfora “dívida técnica” tem sido útil para facilitar as discussões entre profissionais de tecnologia e negócios. Os profissionais de negócios geralmente não sabem quais são os custos de saldar dívidas técnicas e os técnicos geralmente não conhecem os interesses do negócio. Em alguns casos, é uma boa ideia permitir deliberadamente o aumento da dívida técnica, e em outros não. A dívida facilita a troca de opiniões sobre considerações técnicas e comerciais, tornando-a mais significativa, o que melhora a qualidade das decisões sobre quando e por que contrair dívidas e quando e como pagá-las.
Construa sua estrutura de trabalho para evitar esgotamento
A visão purista do Agile assume a mesma duração de sprint (conhecida como “cadência compartilhada”). Se a equipe tolera bem a cadência geral, não adianta fazer mudanças. Cadências compartilhadas tornam mais fácil calcular a velocidade e outros fatores ao planejar um sprint.
Uma reclamação comum ao implementar Scrum é que uma sequência interminável de sprints leva à fadiga e à sensação de estar correndo na roda. Com um desenvolvimento consistente, ocorrem falhas naturais no desempenho, principalmente entre as disciplinas, assim como no equilíbrio durante os períodos de alta intensidade.
Sprints constantes não deixam tempo para descanso se cada sprint realmente correr em um ritmo de sprint.
Um dos antídotos para a fadiga após os sprints é alterar a duração dos sprints conforme necessário. A maneira sistemática de fazer isso é usar um padrão 6x2x1, seis sprints de duas semanas mais um sprint com duração de uma semana, para um total de 13 semanas, que é exatamente um quarto.
Uma alternativa para isso seria usar sprints encurtados após grandes lançamentos, em feriados e em outros momentos quando a velocidade da equipe ainda não será estável. Durante um sprint de uma semana, uma equipe pode estar trabalhando em infraestrutura ou ferramentas, participando de eventos de preparação ou de equipe, hackathons, trabalhando em dívidas técnicas, trabalhando em melhorias que são grandes demais para serem concluídas em um sprint ou algo mais.
Os diferentes comprimentos de cadência de sprint correspondem ao conceito de ritmo sustentável usado no Agile. Muitas pesquisas Agile equivalem a um ritmo constante com a falta de noites e fins de semana livres. Mas eu acho que esta é uma simplificação exagerada e irritante que ignora as diferenças nas preferências de condições de trabalho de pessoas diferentes. Alguns sugerem uma semana de trabalho de 40 horas como um ritmo constante, mas para outros é um caminho para o tédio. Pessoalmente, fiz a maior parte do meu melhor trabalho em modo explosivo - 55 horas em duas semanas e 30 horas nas duas semanas seguintes. Em média, pode chegar a cerca de 40 horas de trabalho por semana, mas equipes diferentes nem sempre têm 40 horas de trabalho. A compreensão de um ritmo constante é diferente para cada pessoa.
Outras considerações
Desenvolvimento de software fora do projeto
Nem todo desenvolvimento de software é organizado em projetos, mesmo com as muitas definições no início deste capítulo. Às vezes, há situações em que uma pessoa geralmente trabalha, por exemplo, é comum lidar com chamadas de suporte técnico, resolver problemas de lançamento, criar patches e assim por diante.
Esse trabalho, obviamente, está relacionado ao desenvolvimento de software e também se presta a práticas Agile. Eles podem ser realizados de forma mais eficiente, qualitativa e metodicamente por meio da implementação de métodos ágeis práticos como Manufatura Enxuta e Kanban. Mas, em minha experiência, as empresas tendem a ter muito menos problemas com esse tipo de trabalho do que com o desenvolvimento de software em todo o projeto, portanto, este livro se concentra em trabalhar em projetos em vez de em um trabalho ad-hoc.
Estudo de recomendações :
- Reveja o histórico dos totais do projeto. A experiência da sua empresa é consistente com o consenso geral de que pequenos projetos têm mais chance de sucesso do que grandes?
- Navegue em seu portfólio de projetos. Qual de seus grandes projetos pode ser dividido em vários projetos menores?
- , . ? ?
- , .
- , .
- . ?
- .
- , , .
- .
- [ , 1975]. -. , , .
- [ , 2019]. Understanding Software Projects Lecture Series. Construx OnDemand. (2019 ). ondemand.construx.com. .
- [ , 2012]. Essential Scrum: A Practical Guide to the Most Popular Agile Process. , .
- [ ., 2019]. Managing Technical Debt. .
»Mais detalhes sobre o livro podem ser encontrados no site da Editora
» Índice
» Trecho
Para Habitantes desconto de 25% no cupom - Agile No
ato do pagamento da versão em papel do livro, é enviado um e-book para o e-mail.