Nesta última terça-feira, 12 de Abril, tivemos mais um Codigo Dojo na AdaptWorks. Claro, a chuva que caiu no final da tarde atrapalhou um pouco, mas mesmo assim tivemos uma boa quantidade de participantes.

Desta vez resolvemos mudar o condutor do Dojo e o escolhido foi o Juliano Alves (obrigado, Juliano).

Jonas e Juliano, apresentando as opções para o problema

Apesar de algumas pessoas reclamarem, parece que Java continua sendo o “common ground” para a maioria dos participantes. Não que seja um problema, mas alguns gostariam de uma pequena mudança, conhecer uma outra linguagem.

Platéia atenta, mas participativa

Algumas pessoas talvez se sintam constrangidas em participar de um Coding Dojo – algumas por não se acharem com conhecimento suficiente ou por acharem que isso é para um nível mais alto de programação. E para estas situações, é importante lembrar que um Coding Dojo não é criado para mensurar o seu “traquejo” na linguagem, e sim mostrar (e usar) boas práticas em programação.

"Pair Programming", uma das práticas mais usadas

Inclusive, na Retrospectiva feita ao final da sessão, um dos comentários positivos foi a diferença positiva sentida quando praticando “pair programming”. E é por aí que as coisas se encaminham.

Uma nova metodologia ágil para desenvolvimento de software? Um conjunto de boas práticas? O nome do quadro do Scrum? Uma evolução do Scrum? Uma versão simplificada do Scrum? Nenhuma das anteriores? Todas as anteriores?

Kanban é uma palavra de origem japonesa, cujo significado é “cartão visual”. Sua popularidade vem do Sistema Toyota de Produção, cujo mecanismo básico de operação consiste justamente nos cartões visuais.

O que vem ganhando muita popularidade no mercado de desenvolvimento de software, na verdade, é o “Sistema Kanban para Desenvolvimento de Software”, o qual muitas vezes é abreviado para “Kanban” e cujo nome completo deixa tudo mais claro: trata-se de um conjunto de princípios, conceitos e práticas cujo principal objetivo é minimizar o tempo necessário para uma idéia se transformar em um ativo de software em produção.

Sendo assim, podemos dizer que o Kanban é uma metodologia ágil para desenvolvimento de software? Sim, podemos, porém ele é mais abrangente, pois nos possibilita gerenciar uma cadeia de valor inteira: “from concept to cash”.

Não perca nossos próximos posts sobre Kanban, nos quais explicaremos mais detalhes sobre esta fascinante maneira de trabalhar!

Em ambientes de projetos ágeis é comum sermos questionados se o resultado de uma Sprint deve automaticamente se tranformar em uma entrega – algo que vai entrar em produção – ou se podemos aguardar um momento mais apropriado para fazê-lo. A resposta padrão é: uma Sprint gera algo potencialmente entregável, algo que está Done, mas se isso vai entrar em produção ou não, vai depender de como você pretende trabalhar com seus Releases. Neste post pretendo explorar um pouco mais esse tema e deixar minha opinião sobre quando e como trabalhar com Releases.

O que é um Release?
Um Release é a representação de uma entrega de produto em produção. Ele é comumente planejado através de um cerimônia chamada Release Planning. Releases são planejados principalmente em ambientes onde estas entregas precisam ter uma data fixa, seja por obrigações contratuais, necessidades de mercado, eventos (conferências, product lauch, etc.) ou – principalmente em ambientes largos – para seguir um roadmap de releases corporativos.

Preciso planejar Releases?
As duas mais comuns situações em que o planejamento de Relase não será necessário:

• Um (ou vários) Release(s) por dia: dependendo do tipo de produto que você desenvolve e de quão maduro seu time é em boas práticas ágeis de engenharia de software, você pode conseguir este estado de nirvana. Release diários ocorrem através de uma boa estrutura de build e deploy para que estes possam ser feitor frequentemente. Aqui a sua definição de Done teria a instrução “Release it!” (ou algo do gênero). Além disso seu time precisaria de um Product Owner trabalhando MUITO próximo a eles e  um Product Backlog com itens realmente pequenos.
  Um case com esta característica que ficou bem popular nos eventos de Agile foi o do Flickr, que publicou conseguir uma média de 10 deploys diários através da coperação entre Dev e Ops.
• Um Release a cada Sprint: este cenário é bastante comum, o time trabalha para que o resultado final da Sprint, aquele que será apresentado no Review, já esteja em produção. Empresas que, por exemplo, liberam uma “nova versão” do produto aos seus clientes a cada mês/quinzena provavelmente trabalharão desta forma. Neste caso a Sprint Planning já será suficiente para enxergar o que o cliente receberá em produção e quando, não precisando assim de um Release Planning.

Planejando Release curtos e frequentes
Se o seu cenário não é semelhante aos dois que eu apresentei acima, provavelmente você precisará planejar Release para poder enxergar além de uma Sprint (mesmo que de forma embaçada) e, assim, planejar entregas em produção para seus clientes. Tenha em mente  que, mesmo planejando além de uma Sprint, trabalhar com Releases curtos e frequentes é mais que uma boa prática em Agile, é quase uma obrigação. Releases curtos e frequentes contam com um tempo de resposta menor para colher feedback do cliente, evitando assim o desenvolvimento de funcionalidades desnecessárias ou com um comportamento diferente do esperado pelo cliente. Além disso o retorno sobre o investimento do cliente é acelerado, já que na maioria das vezes o ROI real só será recebido pelo cliente com o produto em produção.

Lembro que quando comecei a trabalhar com Agile alguém me falou que o tamanho ideal de um Release seria 06 meses, lembro que no mesmo momento pensei “Isso é loucura, acho quase impossível isso acontecer!”. Hoje quando escuto falar em Release deste tamanho penso “6 meses? Não, isto é muito tempo!”. Na verdade o tamanho “ideal” de um Release vai depender diretamente do ambiente corporativo que você está inserido. Se a empresa possui uma política de Releases corporativos onde n produtos precisam “entrar” juntos, bem, você pode precisar de Release de 06 meses, ou até mais. O que sugiro nestes cenários é evitar Release BIG-BANG, ao invés disso lance Releases menores para uma base selecionada de usuários (field-beta testers, por exemplo).

Release Planning Meeting – Agenda
Abaixo segue uma sugestão de algumas práticas comuns que procuro utilizar em reuniões para planejamento de um release. Muito provavelmente parte destas práticas não servirão para você, remova-as e adapte a agenda para que esta gere o resultado e visibilidade que seu ambiente precisa para um Release.

1. Abertura: ScrumMaster revisita o propósito da reunião, sua estrutura, agenda, etc.
2. Visão do Produto e Roadmap: Product Owner revista a Visão do Produto com o propósito de trazer todos novamente para o foco e alinhar expectativas.
3. Status atual do projeto: Product Owner apresenta gráficos e Status Reports onde possam ser visualizados resultado das últimas Sprints e momento atual do projeto.
4. Meta/tema da Release: Product Owner propõe a meta para o Release. Normalmente esta meta é expressa em objetivo de negócio alinhado à data de entrega.
5. Estimativa de velocidade: Time estima sua velocidade para esta Release baseando-se no resultado de Sprints anteriores. Caso esta seja a primeira Sprint de um primeiro Release, sugiro que execute duas ou três Sprints antes de planejar um Release.
6. Agenda da Release e número de Sprints: ScrumMaster facilita um trabalho colaborativo entre Time e Product Owner para enxergar Milestones, definir tamanho de Sprints, etc.
7. Estimativa de itens do Product Backlog: Time estima itens do Product Backlog caso estes não estejam estimados. Só deverão ser estimados uma quantidade de itens suficiente para planejar o Release e, talvez, para deixar uma “sobra”.
8. Mapear itens nas Sprints do Release: seguindo a priorização do Product Owner o Time irá mapear quais itens “cabem” em quais Sprints. Como o Plano de Release será revisto ao fim de cada Sprint, não aconselho tentar encaixar item a item em cada Sprint. Se você está planejando, por exemplo, um Release de 05 Sprints, mapeie itens para as 02 primeiras Sprints apenas, e deixe o restante selecionado sem posicionar na Sprint 03, 04 ou 05.
9. Riscos, dependência e preocupações: de forma colaborativa Time, ScrumMaster e Product Owner trabalham com práticas para identificar riscos, dependências, impedimentos arquiteturais, desafios, etc. Caso necessário será elaborado um plano de riscos, impediments backlog e/ou um simples plano de ação.
10. Comprometimento: ScrumMaster provoca Time e Product Owner para que haja um comprometimento com esta Meta. É importante todos estarem confiantes e entusiasmados com a Meta.
11. Plano de comunicação e logística da Sprint: principalmente em ambientes largos, a comunicação do Release (e consequentemente do projeto) perante a organização não podem falhar. Se necessário montar plano de ação para este trabalho.
12. Montar gráfico(s): montar Release Burndows e/ou Parking Lot e/ou qualquer gráfico que ajude a comunicar o andamento do Release.
13. Retrospectiva: Por fim, como de costume em qualquer cerimônia do Scrum, considero uma boa prática ser feita uma Retrospectiva para avaliar pontos positivos e de melhoria desta reunião.

Muitos me perguntam sobre o tempo que normalmente leva uma Release Planning Meeting. Minha resposta é: não mais que dois dias. Talvez você diga “Dois dias trancados em uma sala fazendo planejamento? Isso é desperdício, um tédio, rg$5sfga!” Bem, tudo depende do quão bom facilitador seu ScrumMaster for. Faço uma analogia destas cerimônias ágeis a um treinamento…dependendo da dinâmica aplicada, do conteúdo e do instrutor, 02 horas podem ser uma tortura – ou 32 horas podem ser extremamente proveitosas e você nem sentir o tempo passar.

Atualizando e revisando o Plano de Release
Por fim é importante ficar claro que o Plano de Release é um artefato vivo e que a cada Review deve ser atualizado, revisado e comunicado pela organização. O Product Owner é o responsável por fazer esta comunicação e, caso tenha sido elaborado uma plano de comunicação, este deverá ser seguido.

[img:images.jpeg,thumb,alinhar_dir_caixa]Após o retorno de Chicago, onde estive participando da Agile Conference, entrei em uma sequência bem grande de viagens que me impediram de escrever aqui minhas impressões sobre o evento. Como agora estou tendo um “tempinho livre”, vamos ao meu relato:

- Hoje, na minha opinião, o que diferencia claramente os eventos gringos de Agile e os eventos realizados aqui no Brasil não é tanto o nível das palestras, mas sim o público! Enquanto aqui encontramos sempre as mesmas “figuras de sempre” nesses eventos, lá fora os organizadores estão focando em trazer clientes e novos usuários para os eventos. Fiquei muito, muito contente em ter na minha palestra pessoas que tinham escutado sobre Agile pela primeira vez fazia 1 ou 2 meses! Não adianta falar sobre Agile para aqueles que já estão convencidos…temos que ter “sangue novo” nesses eventos. Portanto se você é praticante de Agile, convide seus amigos iniciantes para o próximo evento! E para nós palestrantes, o que penso é que temos que sempre revisitar temas básicos em nossas palestras, para tornar os eventos atraentes para os iniciantes no assunto;

- Pelo que vi por lá, Feature-teams é algo que vem sendo bastante utilizado em projetos ágeis largos. O Jim Highsmith apresentou uma idéia destes times bem semelhante ao que é proposta pela FDD (Feature-Driven Development). Já o Bas Vodde, que fez para mim duas das melhores apresentações do evento, tem uma proposta um pouco diferente para estes times, como uma evolução dos já conhecidos times de componentes.

- Falando em FDD, vi por lá umas 3 palestras utilizando estratégias “em cores” no estilo Peter Coad, em técnicas para usabilidade, modelagem de negócio e identificação de itens para um Product Backlog. E pensar que o “em cores” já foi tratado como piada em um evento local…mas vamos em frente;

- A TDD Clinic em C++ apresentada pelo Bas Vode e James Grenning foi fantástica! Nossa…como eu estava com saudade de mexer em um código C++, aqui rolou para mim um profundo momento nostálgico…rs

- A sessão “Product Vision and the Glass Wall” do Matt Roadnight da Conchango foi, como eu poderia dizer, FANTÁSICA! Eu já conhecia um pouco sobre como a Conchango trabalha com a questão de usabilidade na elaboração de produtos, mas a dinâmica, que envolveu quase os 90 minutos inteiros da apresentação, nos mostrou tudo isso na prática. A Conchango é realmente a companhia que inspira o em-fase-de-crescimento estúdio de projetos da AdaptWorks.

- A utilização de Scrum e/ou Lean na gestão de portfólios e programas está crescendo bastante. Além da minha palestra vi o tema ser abordado em várias outras apresentações, destaque para a Barelly Suficient Portfolio Management, apresentada pelo Todd Little da Landmark Graphics.

- As palestras de games para o ensino de práticas ágeis, como eu poderia dizer…causaram um certo enjoo (não apenas em mim). O problema é que eram muitas, e quase todas falavam a mesma coisa, trocando apenas o “brinquedo” a ser utilizado. Uma das exceções neste quesito foi a apresentação dos brazucas Luiz Paulo Parzianello e Rafael Prikladnicki, com a famosa apresentação sobre os jogos estatísticos, que já havia feito bastante sucesso no Brazil Scrum Gathering;

E por falar em Brasil, fiquei muito contente em ver vários brasileiros por lá…fiquei mais contente ainda em ver que a palestra de muitos de nós obteve destaque! Tem muita gente mandando bem de verdade com Agile aqui no Brasil, tem muita empresa – que nem imaginamos – fazendo isso bem. Isso me motiva! Penso que o Brasil vive um momento bastante especial em vários aspectos, mas isso é assunto para um próximo post!

Por fim, gostei bastante de participar da Agile Conference, é um evento bem grande, e que consegue nos passar a dimensão que Agile está tomando. Foi maravilhoso conhecer Chicago, uma cidade belíssima que um dia pretendo voltar realmente de férias, e reencontrar por lá uma grande referência na minha carreira, Renato Quedas, que hoje é Domain Specialist para a Borland/Microfocus no escritório de Chicago.

Para mim, o grande diferencial entre as metodologias ágeis e qualquer outra abordagem tradicional de desenvolvimento de software está no uso inteligente da comunicação humana. Enquanto os agilistas procuram estimular a comunicação não-verbal com todos os canais sensoriais do ser humano, a maioria dos profissionais de software investe horas e horas de esforço na construção de mecanismos de comunicação escrita responsáveis por somente 7% da eficácia da transmissão da informação a seus usuários. Para evidenciar essa fragilidade das técnicas de comunicação em ambientes de software, podemos encontrar pesquisas que apontam 64% das funcionalidades como sendo raramente ou nunca utilizadas por seus usuários (quem as pediu?), bem como 63% dos problemas de projeto tendo como origem os requisitos de software (que tipos de problema você imagina?). Desenvolver competências na área da comunicação humana tornou-se imperativo para todo e qualquer profissional demandado por resultados imediatos e altos índices de qualidade em seus produtos de trabalho, pois, do contrário, continuaremos por mais algumas décadas vendo os mesmos índices diante somente de mais complexidade e tecnologia.

Pois bem, quanto mais eu me dedico a capacitar profissionais e a orientar equipes em melhoria de processos, mais me dou conta de que a maioria de nossos gestores está remando contra a correnteza … Explico: ao invés de desenvolverem suas equipes para exercerem toda a competência necessária na entrada do processo de software (comunicação com o cliente e identificação de seus requisitos), investem fortunas em sua saída a fim de comprovar que a qualidade de seus produtos e a eficiência de seus processos realmente são precárias. A comunidade ágil propõe que assuntos como processos de negócio, objetivos estratégicos, retorno de investimento, fluxo de informação, etc. sejam do conhecimento do time e não uma exclusividade de gerentes e analistas de negócios. Com base nessas informações, podemos desenvolver produtos em prazos nunca antes imaginados, com altos níveis de qualidade desacreditados pelo mercado, e com uma constante satisfação do cliente e da equipe de software. Para tanto, precisamos trazer para nosso ambiente técnicas de comunicação que a área de vendas já utiliza há décadas, tornando nossos analistas profissionais altamente eficazes no tratamento dos requisitos de software.

No workshop entitulado “Requisitos de Software: Conceitos e Práticas para Equipes Ágeis” ensino meus alunos a pensarem na natureza dos requisitos e não apenas a escreverem especificações e documentos. Procuro desafiar suas tradicionais crenças sobre o que é um processo de software apresentando conceitos e práticas não difundidos em nossa área, como por exemplo: percepção e comunicação humana, estratégias de pensamento e mudança, análise de negócios e produção enxuta (Lean Thinking), planejamento e controle de projetos baseados na gestão da produção, entre outros. O resultado, após trabalhar durante dois dias (duração do workshop) com grupos de mentes tipicamente analíticas e pragmáticas, tem sido o despertar para um novo mundo de possibilidades. Um mundo ainda pouco conhecido mas com uma vasta quantidade de recursos que podem aumentar consideravelmente nossa produtividade.

Se você é um profissional que trabalha com metodologias ágeis ou que deseja aprimorar suas habilidades na área de requisitos de software, venha aprender como a mente, a comunicação e a logística podem aumentar consideravelmente a capacidade produtiva de sua equipe nos dias 30 e 31/07/2009, datas do próximo workshop a ser realizado em São Paulo. Para informações e inscrição, contate a Adaptworks pelo email contato@adaptworks.com.br ou pelo telefone (11) 5585-7738.

Quando falamos sobre qualidade em software, surgem diversas dúvidas quanto ao que significa ter qualidade em um software: ter um código bem escrito? Código que não apresente falhas? Boa performance no que se propõe a fazer?

De acordo com a NBR 13596 (ISO/IEC 9126), existem algumas características que um software deve apresentar para ser considerado como um software de qualidade. Estas características são listadas na tabela a seguir:

A maioria das características que determinam um software com qualidade referem-se mais a boas práticas de engenharia de software ou eficiência da plataforma tecnológica. Entretanto, Scrum, como framework para gerenciamento de projetos, também é capaz de oferecer qualidade no processo de desenvolvimento.

Em Scrum, conseguimos uma melhora na qualidade através de diversos pontos. Entretanto, obter esta melhora na qualidade depende muito se Scrum está sendo bem implementado ou não.

Dentre estes pontos, podemos destacar:

• Iterações
• Remoção de impedimentos
• Inspeção e adaptação
• Autonomia
• Times multi-funcionais

Iterações

Qualidade em software também significa entregar para o cliente algo que lhe seja realmente útil, de acordo com suas necessidades.

Por ser uma framework ágil, Scrum trabalha com iterações, onde a cada iteração entregamos software, ou incrementos de software, potencialmente usável e de acordo com a necessidade do cliente. E a cada nova iteração, temos “feedback” do que foi entregue e que utilizamos para melhorar o produto (sempre de acordo com a prioridade do cliente).

O “feedback” do cliente haveria de qualquer forma, seja apresentando o produto ao final de uma iteração, seja ao final de todo o ciclo de desenvolvimento, o que normalmente acarreta em alterações no código. Entretanto, se estas alterações forem feitas no final do projeto, isto também pode acarretar efeitos colaterais indesejados, ao passo quefazê-las de forma antecipada impede este tipo de problemas.

Através das Sprints, times Scrum estão sempre desenvolvendo algo que realmente tenha valor para o cliente.

Remoção de impedimentos

Remover qualquer tipo de impedimento durante a execução de um projeto é essencial não importa qual metodologia seja utilizada. Em Scrum é esperado que estes problemas apareçam. Mas o que é feito após resolver este impedimento determina se um time está utilizando Scrum corretamente ou não.

Durante a execução de uma Sprint, é recomendável que a execução das tarefas seja feita item a item ao invés de cada membro executar tarefas de itens diferentes. Isso tem duas razões: a primeira é relacionada ao valor para o cliente. Para um cliente, um item somente tem valor caso tenha sido entregue completamente — uma funcionalidade que esteja funcionando 80% não lhe trará vantagem alguma. Além disso, executar um item completamente ajuda a manter o foco da equipe na meta e no item em específico. Desenvolvedores em geral tendem a ser mais orientados a tarefas ao invés de orientados a valor. Manter o foco na meta ajuda a aumentar a qualidade do item sendo desenvolvido.

A outra razão é em relação à forma como os problemas são resolvidos e suas correspondentes soluções são utilizadas. A execução completa de um item representa um fluxo completo de execução e faz parte do processo utilizado no desenvolvimento. Neste caso, problemas que poderiam se tornar recorrentes podem ser solucionados imediatamente, permitindo que isso não se repita na execução dos próximos itens. Desta forma estamos aprimorando o processo, o que também reflete na qualidade do produto.

Inspeção e adaptação

Ao final da execução de uma Sprint há a Sprint Retrospective, uma das cerimônias de Scrum. Nela, revisamos a Sprint (inspeção) e determinamos o que foi bom e o que precisa ser melhorado (adaptação). As adaptações podem ser individuais ou coletivas, mas de qualquer forma são uma forma de garantir a melhora do processo e consequente otimização, o que traz diversos benefícios.

Com um processo mais enxuto e mais eficiente, podemos ter um software com mais qualidade.

Autonomia

Times em Scrum são auto-gerenciados, o que significa uma menor pressão sobre eles. Desta forma, cada um dos membros pode selecionar o que fará e terá o tempo necessário parafazê-lo com qualidade. Estudos mostram que, sob pressão de prazos exíguos, a primeira coisa a ser deixada de lado pelos desenvolvedores é a qualidade.

Além disso, através desta autonomia, os membros do time passam a ter uma melhor qualidade de vida, o que reflete em uma melhoria na qualidade como um todo. Isso porque passam a ter mais tempo e disposição para pesquisar uma melhor forma de abordar e executar uma tarefa. Em um ambiente onde Scrum tenha sido bem implantado, este aprimoramento pessoal é compartilhado com os outros membros, o que traz mais incremento na qualidade.

Times multifuncionais

Quando montamos os times, procuramos sempre montá-los com membros que tenham diferentes características ou atribuições. Por exemplo, ao invés de um time formado só por desenvolvedores ou só de analistas de requisitos, procuramosmisturá-los e formar diversos times Scrum.

Isto porque a experiência de cada um é extremamente útil no planejamento das tarefas a serem executadas na Sprint. Entretanto, existe um conceito maior escondido por trás disto: qualidade desde o início.

Pude presenciar em diversas ocasiões a seguinte situação: empresas utilizando o modelo em cascata, faziam o levantamento de requisitos no início do projeto. Em seguida, arquitetos de sistema e especialistas no negócio modelavam as classes para atender a todos os requisitos levantados na etapa anterior. Depois (bem depois, por sinal), estes modelos eram passados para a equipe de desenvolvimento e o resultado era testado pela equipe de Q&A e homologação. No final do processo, isto era entregue à equipe de implantação.

Invariavelmente, o contato com o cliente era feito no início do projeto, onde este apresentava todos os requisitos possíveis e imagináveis para o produto. Embora saibamos que o cliente saiba o que precisa mas tenha somente uma vaga idéia do que quer, ele era obrigado a informar o que desejava que fosse desenvolvido, e por isso a quantidade de requisitos, algumas vezes desnecessários, era imensa.

Durante a modelagem, os analistas modelavam o que era necessário para a aplicação, muitas vezes deixando de lado alguns detalhes que poderiam facilitar o desenvolvimento ou ignorando outros detalhes que pudessem melhorar o acesso aos dados.

Os desenvolvedores, por sua vez, simplesmente executavam o que foi determinado pelos arquitetos e no prazo determinado pelo gerente de projeto.

Depois de devidamente codificado, o resultado era passado para a equipe de Q&A, que testava o que tinha sido produzido e retornava o resultado dos testes à equipe de desenvolvimento. Infelizmente, isto era feito invariavelmente aos lotes — os testadores eram obrigados a testarem diversos recursos de uma vez, muitas vezes impossibilitando testes com aspectos mais amplos.

Como tudo isso feito às pressas, em algumas situações, a equipe de implantação era informada com poucos dias de antecedência (e em uma situação, a equipe foi informada que tinha até o final da tarde para implantar um sistema). Com tão pouco prazo, muitas vezes a implantação era feita sem qualquer teste, simplesmente esperando que a sorte sorrisse para eles.

Note que os cinco parágrafos anteriores descreveram cada um dos estágios no desenvolvimento. E isto reflete como o desenvolvimento era feito — sem qualquer comunicação adicional entre cada uma das etapas que não fosse a documentação do sistema. É fácil descobrir o resultado disso.

Através de times multifuncionais, a cada Sprint temos a opinião de especialistas em diferentes áreas definindo o que será feito naquela Sprint. Enquanto não sabemos o que o cliente realmente quer como produto, sabemos o que é mais importante para ele, com estes especialistas definindo a melhor abordagem possível, levando em consideração os aspectos nos quais cada um é melhor. Assim, arquitetos podem começar definindo as classes levando em consideração a opinião de um especialista em banco de dados, de domínio, etc.

Utilizando o princípio de qualidade desde o início, o código tende a ser mais enxuto, mais adaptável, a ter mais performance. Como a interação com o usuário é constante, o produto estará sempre de acordo com a necessidade do usuário. E com a presença de um especialista em testes, cada tarefa executada já pode ser testada e eventualmente corrigida rapidamente.

E finalmente, um especialista em implantação já sabe antecipadamente o que deve testar e providenciar como ambiente de produção.

Conclusões

Existe uma beleza singular na simplicidade apresentada por Scrum. Entretanto, por trás desta simplicidade, existem conceitos que não devem ser ignorados, sob pena de obter somente parte dos benefícios de Scrum.

Um ScrumMaster deve estar sempre atento aos diversos sinais que o time apresenta, bem como motiva-los e desafia-los, sempre em busca constante do aprimoramento individual como seres humanos e o time como um todo. Além disso, buscar a melhoria contínua do processo permite que a qualidade passe a ser uma constante em futuros projetos de software.