O framework de desenvolvimento ágil Scrum tem obtido um grande crescimento nas empresas de desenvolvimento de software. Descubra alguns motivos do crescimento desta nova forma de gerir projetos de software.
Scrum não é um termo novo, mas no Brasil, algumas empresas de TI tem adotado este framework para tornar mais ágil o processo de desenvolvimento de seus produtos. Porém o Scrum já vem desde a década de 90, quando Ken Schwaber e Jeff Sutherland decidiram formalizar a maneira como gerenciavam seus projetos de desenvolvimento de software.
Não é de hoje que muitos profissionais de TI têm procurado novas formas de desenvolver softwares mais rapidamente e com maior qualidade. O framework de desenvolvimento ágil Scrum traz consigo de uma forma simples, porém consistente, uma gama de boas práticas ágeis que contribuem para esse desenvolvimento mais ágil.
O primeiro ponto a ressaltar é que o Scrum, diferente do que muitos pensam, não é uma metodologia, mas sim um framework. A grande diferença está na prescrição, ou seja, metodologias são prescritivas, detalhando tudo o que deve ser feito muitas vezes de forma detalhada, o que não ocorre no Scrum.
É comum adeptos do Scrum utilizarem com proveito técnicas de outras metodologias ágeis, como o Taskboard(Kanban), Pair Programming(XP) entre outras. Por ser um framework, isso é perfeitamente natural.
Os ciclos de desenvolvimento são curtos, de no máximo 30 dias, e por este motivo, o feedback do cliente se torna mais constante já durante a fase de desenvolvimento do produto, tornando seu desenvolvimento mais assertivo e alinhado com as necessidades do negócios do cliente.
Ausência de micro gestão: no Scrum, os times são auto-organizados podendo assim trazer mais agilidade ao processo de desenvolvimento, o que por sua vez requer um time entrosado e conhecedor de suas qualidades e limitações. Não há a figura do Gerente de Projetos, mas nem por isso, deixa de ser rganizado. O time se organiza da maneira que julgar ser a mais produtiva, sempre com o auxílio do Scrum Master, papel este que é responsável por garantir a produtividade do time, removendo impedimentos e auxiliando o time a se tornar mais produtivo.
O Product Owner por sua vez, é o responsável por gerenciar o Backlog, definir quais funcionalidades são mais importantes de acordo com o valor que elas agregam para o produto. Este papel deve ser de preferencia do próprio cliente, ou alguém ligado a ele. O Scrum tem como suas cerimonias a Sprint Planning, ou planejamento da Sprint, momento em que o time se reúne e define qual sua meta e quais itens do Product Backlog irá realizar para chegar à meta. Sprint Review, onde o time revisa o trabalho que foi realizado e o PO aprova ou não o que foi feito, refina se o Product Backlog e colhe se o feedback das pessoas envolvidas no projeto. Todos os dias ocorre a Daily Meeting, reunião do time de desenvolvimento, de no máximo 15 minutos, onde o time sincroniza o trabalho que está sendo realizado e avalia se a meta ainda está alcançável. Após a Sprint Review vem a Sprint Retrospective, momento onde o time Scrum todo se reúne para avaliar o que foi bom, o que pode melhorar e quais as ações que serão tomadas para que na próxima Sprint o que deve melhorar efetivamente melhore.
Adotar Scrum requer conhecimento das limitações e entendimento que os pilares básicos da transparência, inspeção e adaptação devem ser respeitados, pois assim se constrói softwares melhores. Sempre atentar-se aos princípios do manifesto ágil, pois ele é base de qualquer metodologia ágil. Manter as boas práticas de engenharia de software é o mesmo que construir um ambiente saudável e longe dos vícios que outrora atormentavam os desenvolvedores de software. Sempre procurar a melhora no processo e adaptá-lo de forma a ser aceito e efetivo em sua organização. Por ser um framework, Scrum pode ser estendido, desde os devidos cuidados sejam tomados para não burocratizar o processo e torná-lo um anti-pattern ágil.
