Scrum: A Gestão Ágil de Projectos
Agilidade é a capacidade de equilibrar flexibilidade e estabilidade (Highsmith 2002 p 29)
Ser ágil é ser flexível, o que permite, por sua vez, ser adaptável à mudança
O desenvolvimento ágil de software baseia-se no planeamento adaptativo, no desenvolvimento evolutivo, na entrega antecipada de valor e na melhoria contínua, Uma abordagem agile é iterativa, limitada no tempo e permite construir/fornecer um produto passo e passo, entregando-o em pequenas partes (incrementos). Um dos principais benefícios é a capacidade de esta se adaptar e mudar a qualquer momento – de acordo com feedback, condições de mercado, obstáculos corporativos – fornecendo, deste modo, apenas o produto relevante para o cliente, ou seja, aquilo que este efetivamente quer e valoriza.
Highsmith recorre a analogias com o montanhismo para explicar estes conceitos-chave. Um alpinista inicia o seu percurso na base da montanha, mas, à medida que vai escalando e subindo, as condições inicialmente previstas mudam. A saliência que parecia escalável, quando avistada a partir da base da montanha é, na realidade, intransitável. A rota inicialmente traçada precisa de ser adaptada. Manter a rota prevista e tentar escalar a saliência poderia ser mortal. Ser adaptável é fundamental no alpinismo, tal como em qualquer empresa ou organização.
Para alcançar resultados é necessário, entre várias coisas, reforçar o desempenho através da quantificação dos resultados e a partilha de responsabilidades.
Enquanto os métodos waterfall se centram no âmbito do projeto e, em função deste, determinam os custos e desenham o cronograma, os métodos ágeis focalizam-se na noção de “valor” para o cliente
Os métodos ágeis são mais adequados quando as mudanças são frequentes, uma vez que são considerados métodos “caórdicos” (caos + ordem)
Os métodos ágeis mais populares, além do Scrum, são Crystal, Dynamic Systems Development Method (DSDM), Extreme Programming (XP), Kanban, Feature Driven Development (FDD), Adaptative Software Development (ASD), Lean Product Development (LPD)
Existem obstáculos à adoção de métodos ágeis, nomeadamente uma compreensão pouco clara do impacto paa as metas gerais do negócio. Executar projetos usando simplesmente uma metodologia ágil não é suficiente para colher os benefícios desejados. Os projetos até podem ser bem executados sem que tal resulte num crescimento sustentável do negócio. O alinhamento estratégico é crítico.
A gestão ágil apresenta uma estrutura simples que promove a comunicação e a reflexão sobre os projetos/trabalhos anteriores entre os membros da equipa. Na era da transformação digital, com muitas empresas a migrar para um ambiente de trabalho digital, a agilidade é a opção perfeita para organizações que procuram transformar a forma como gerem os projetos e atuam como um todo. A agilidade garante o alinhamento metodológico de toda a empresa.
Embora estes métodos tenham nascido na indústria do desenvolvimento de software, é de salientar que a estrutura Scrum pode ser aplicada a outros domínios.
Os três pilares do Scrum são transparência (todos reconhecem o quanto é importante um projeto que tudo seja claro e todos possam saber o que se está a passar); inspeção (garante que existe algum meio de controlo ou verificação que valida o trabalho realizado e o compare com o esperado); adaptação.
Tudo está sujeito a mudança, é inevitável. Um método que se quer ágil tem de saber adaptar-se de forma fácil e rápida. O cliente pode mudar de ideias, o mercado pode mudar, os governos e as orientações políticas também. Os produtos (outputs de um projeto) podem sofrer inúmeras alterações ao longo do projeto (algumas com origem interna, mas a maioria devido a fatores externos).
A estrutura Scrum apoia-se em seis princípios: controlo empírico do processo (a tomada de decisões é feita com base na observação e experimentação); auto-organização; colaboração (trabalhar em conjunto para alcançar um objetivo em comum); priorização baseada em valor; timeboxing (o Scrum considera o tempo como principal restrição); desenvolvimento interativo.
As user stories podem ter de ser constantemente restritas ao longo do período de duração do projeto.
Um dos princípios-chave do Scrum é perceber que as necessidades exatas de longo prazo a respeito de qualquer projeto podem não ser plenamente compreendidas ou definidas logo no início deste, especialmente nos mercados voláteis, em rápida mudança.
Os processos Scrum são 19 processos agrupados em cinco fases.
Os quatros grandes eventos (reuniões) do método Scrum são: planemaento do sprint, reunião diária em pé, revisão do sprint, retrospectiva do Sprint
Artefactos são ferramentas a usar no método Scrum. São o Project Vision Statement; Prioritized Product Backlog, Release Planning Schedule
Vantagens do Scrum:
O Product Owner representa as parte interessadas e é responsável por garantir que o Scrum Team entrega valor ao cliente. O PO passa uma boa parte do tempo a conhecer o produto ou serviço a entrega, pois ele é responsável pela entrega do produto / serviço ao cliente de acordo com os requisitos/funcionalidades requeridos.
O PO é quem decide que funcionalidades e/ou características serão elaboradas em casa sprint (ciclo) do Scrum. O PO escreve os requisitos do projeto, sob a forma de user stories (US), com a contribuição da ST e gere o Prioritized Product Backlog.
O Scrum Master é um líder informal, preocupado com o que se passa no interior da estrutura Scrum, garantindo que o método é corretamente aplicado e que a Scrum team tem todo o suporte de que precisa. O Scrum Master é a pessoa responsável por garantir que a execução do projeto decorre sem problemas e que os membros da Scrum Team têm todos os meios e ferramentas necessários apara realizar o trabalho. Atua como coach, orientando, ajudando e liderando a Scrum Team.
A Scrum Team é composta por vários tipos de funções, como programador, designer e administrador de base de dados. A estrutura Scrum define o papel da equipa de desenvolvimento como um conjunto multifuncional e diverso de pessoas responsáveis pela conceção (design), pela criação e pelo teste do produto/serviço desejado.
A Scrum Team é auto-organizada e autosuficiente e segue uma estrutura cross-functional; promove a comunicação presencial; é orientada ao valor, e fomenta a entrega interativa de produtos.
OS 19 PROCESSOS
INICIAR
P01 Create Project Vision
P02 Identify Scrum Master & Stakeholders
P03 Form the Scrum Team
P04 Develop Epic(s)
P05 Create Prioritized Product Backlog
P06 Conduct Release Planning
PLANEAR E ESTIMAR
P07 Create User Stories (US)
P08 Approve, estimate and Commit US
P09 Create Tasks
P10 Estimate Tasks
P11 Create Sprint Backlog
IMPLEMENTAR
P12 Create Deliverables
P13 Conduct Daily Standup Meetings
P14 Groom Prioritized Product Backlog
REVISÕES E RETROSPETIVA
P15 Convene Scrum of Scrums (SoS)
P16 Demonstrate and Validate Sprint
P17 Retrospect Sprint
Ser ágil é ser flexível, o que permite, por sua vez, ser adaptável à mudança
O desenvolvimento ágil de software baseia-se no planeamento adaptativo, no desenvolvimento evolutivo, na entrega antecipada de valor e na melhoria contínua, Uma abordagem agile é iterativa, limitada no tempo e permite construir/fornecer um produto passo e passo, entregando-o em pequenas partes (incrementos). Um dos principais benefícios é a capacidade de esta se adaptar e mudar a qualquer momento – de acordo com feedback, condições de mercado, obstáculos corporativos – fornecendo, deste modo, apenas o produto relevante para o cliente, ou seja, aquilo que este efetivamente quer e valoriza.
Highsmith recorre a analogias com o montanhismo para explicar estes conceitos-chave. Um alpinista inicia o seu percurso na base da montanha, mas, à medida que vai escalando e subindo, as condições inicialmente previstas mudam. A saliência que parecia escalável, quando avistada a partir da base da montanha é, na realidade, intransitável. A rota inicialmente traçada precisa de ser adaptada. Manter a rota prevista e tentar escalar a saliência poderia ser mortal. Ser adaptável é fundamental no alpinismo, tal como em qualquer empresa ou organização.
Para alcançar resultados é necessário, entre várias coisas, reforçar o desempenho através da quantificação dos resultados e a partilha de responsabilidades.
Enquanto os métodos waterfall se centram no âmbito do projeto e, em função deste, determinam os custos e desenham o cronograma, os métodos ágeis focalizam-se na noção de “valor” para o cliente
Os métodos ágeis são mais adequados quando as mudanças são frequentes, uma vez que são considerados métodos “caórdicos” (caos + ordem)
Os métodos ágeis mais populares, além do Scrum, são Crystal, Dynamic Systems Development Method (DSDM), Extreme Programming (XP), Kanban, Feature Driven Development (FDD), Adaptative Software Development (ASD), Lean Product Development (LPD)
Existem obstáculos à adoção de métodos ágeis, nomeadamente uma compreensão pouco clara do impacto paa as metas gerais do negócio. Executar projetos usando simplesmente uma metodologia ágil não é suficiente para colher os benefícios desejados. Os projetos até podem ser bem executados sem que tal resulte num crescimento sustentável do negócio. O alinhamento estratégico é crítico.
A gestão ágil apresenta uma estrutura simples que promove a comunicação e a reflexão sobre os projetos/trabalhos anteriores entre os membros da equipa. Na era da transformação digital, com muitas empresas a migrar para um ambiente de trabalho digital, a agilidade é a opção perfeita para organizações que procuram transformar a forma como gerem os projetos e atuam como um todo. A agilidade garante o alinhamento metodológico de toda a empresa.
Embora estes métodos tenham nascido na indústria do desenvolvimento de software, é de salientar que a estrutura Scrum pode ser aplicada a outros domínios.
Os três pilares do Scrum são transparência (todos reconhecem o quanto é importante um projeto que tudo seja claro e todos possam saber o que se está a passar); inspeção (garante que existe algum meio de controlo ou verificação que valida o trabalho realizado e o compare com o esperado); adaptação.
Tudo está sujeito a mudança, é inevitável. Um método que se quer ágil tem de saber adaptar-se de forma fácil e rápida. O cliente pode mudar de ideias, o mercado pode mudar, os governos e as orientações políticas também. Os produtos (outputs de um projeto) podem sofrer inúmeras alterações ao longo do projeto (algumas com origem interna, mas a maioria devido a fatores externos).
A estrutura Scrum apoia-se em seis princípios: controlo empírico do processo (a tomada de decisões é feita com base na observação e experimentação); auto-organização; colaboração (trabalhar em conjunto para alcançar um objetivo em comum); priorização baseada em valor; timeboxing (o Scrum considera o tempo como principal restrição); desenvolvimento interativo.
As user stories podem ter de ser constantemente restritas ao longo do período de duração do projeto.
Um dos princípios-chave do Scrum é perceber que as necessidades exatas de longo prazo a respeito de qualquer projeto podem não ser plenamente compreendidas ou definidas logo no início deste, especialmente nos mercados voláteis, em rápida mudança.
Os processos Scrum são 19 processos agrupados em cinco fases.
Os quatros grandes eventos (reuniões) do método Scrum são: planemaento do sprint, reunião diária em pé, revisão do sprint, retrospectiva do Sprint
Artefactos são ferramentas a usar no método Scrum. São o Project Vision Statement; Prioritized Product Backlog, Release Planning Schedule
Vantagens do Scrum:
- Adaptabilidade
- Transparência
- Feedback Contínuo
- Melhoria Contínua
- Entrega contínua de valor
- Ritmo sustentável
- Entrega antecipada de elevado valor
- Processo de desenvolvimento eficiente
- Motivação
- Resolução mais rápida de problemas
- Entregas efetivas
- Foco no cliente
- Ambiente de elevada confiança
- Pertença coletiva
- Velocidade
- Ambiente inovador
O Product Owner representa as parte interessadas e é responsável por garantir que o Scrum Team entrega valor ao cliente. O PO passa uma boa parte do tempo a conhecer o produto ou serviço a entrega, pois ele é responsável pela entrega do produto / serviço ao cliente de acordo com os requisitos/funcionalidades requeridos.
O PO é quem decide que funcionalidades e/ou características serão elaboradas em casa sprint (ciclo) do Scrum. O PO escreve os requisitos do projeto, sob a forma de user stories (US), com a contribuição da ST e gere o Prioritized Product Backlog.
O Scrum Master é um líder informal, preocupado com o que se passa no interior da estrutura Scrum, garantindo que o método é corretamente aplicado e que a Scrum team tem todo o suporte de que precisa. O Scrum Master é a pessoa responsável por garantir que a execução do projeto decorre sem problemas e que os membros da Scrum Team têm todos os meios e ferramentas necessários apara realizar o trabalho. Atua como coach, orientando, ajudando e liderando a Scrum Team.
A Scrum Team é composta por vários tipos de funções, como programador, designer e administrador de base de dados. A estrutura Scrum define o papel da equipa de desenvolvimento como um conjunto multifuncional e diverso de pessoas responsáveis pela conceção (design), pela criação e pelo teste do produto/serviço desejado.
A Scrum Team é auto-organizada e autosuficiente e segue uma estrutura cross-functional; promove a comunicação presencial; é orientada ao valor, e fomenta a entrega interativa de produtos.
OS 19 PROCESSOS
INICIAR
P01 Create Project Vision
P02 Identify Scrum Master & Stakeholders
P03 Form the Scrum Team
P04 Develop Epic(s)
P05 Create Prioritized Product Backlog
P06 Conduct Release Planning
PLANEAR E ESTIMAR
P07 Create User Stories (US)
P08 Approve, estimate and Commit US
P09 Create Tasks
P10 Estimate Tasks
P11 Create Sprint Backlog
IMPLEMENTAR
P12 Create Deliverables
P13 Conduct Daily Standup Meetings
P14 Groom Prioritized Product Backlog
REVISÕES E RETROSPETIVA
P15 Convene Scrum of Scrums (SoS)
P16 Demonstrate and Validate Sprint
P17 Retrospect Sprint
ENTREGAR
P18 Ship deliverables
P19 Retrospect Project
As equipas Scrum são concebidas para estarem próximas do cliente, promovendo a comunicação presencial entre todos os seus membros, de forma a adaptarem-se rapidamente aos pedidos de mudança. Quando corretamente implementado, o Scrum resulta em significativos aumentos de produtividade e moral dos participantes, reduzindo tempo de desenvolvimento, melhor qualidade e menores riscos, quando comparados com os modelos tradicionais de gestão de projetos.
Estruturas de escalabilidades, como SAFe, LeSS ou NEXUS, são muito pouplares no domínio do desenvolvimento de software e dos sistemas de informação.
Qualidade é muitas vezes entendida como conformidade com os requisitos. Um aspeto importante da qualidade é a melhoria contínua, o que se traduz em ciclos consistentes de inspeção e adaptação.
Na estrutura Scrum existem quatro momentos de inspeção e adaptação: planeamento do sprint, conduzir as reuniões diárias em pé, demonstrar e validar o sprint, retrospectivar o sprint.
Em Scrum a qualidade é definida como a “capacidade dos produtos ou entregas concluídas em cumprir com os critérios de aceitação e em alcançar o valor de negócio esperado pelo cliente” (ScrumStudy, 2017).
Como o trabalho em Scrum é feito através do desenvolvimento de incrementos ao longo dos sprints, isso faz com que os erros ou os defeitos possam ser identificados mais cedo, através de repetidos testes de qualidade e validação junto dos stakeholders.
Os requisitos de âmbito e qualidade são determinados considerando se o projeto vai dar resposta às necessidades do negócio, as necessidades atuais e futuras do público-alvo, capacidade de a organização dar resposta às necessidades identificadas.
A US só poderá ser classificada como done se der resposta a todos os critérios de aceitação. Todas as condições devem ser satisfeitas para que a US seja considerada done. Uma definição clara de done é fundamental pois ajuda a eliminar a ambiguidade.
O cliente é o stakeholder mais importante para qualquer projeto. A Gestão da Qualidade em Scrum permite que os clientes estejam cientes de quaisquer problemas no início do projeto e ajuda-os a reconhecer se um projeto será útil ou não. O processo é facilidade por três atividades que se encontram inter-relacionadas: planeamento da qualidade, controlo da qualidade, garantia da qualidade.
A Gestão da mudança é a forma de encarar e gerir a mudança em Scrum: aceitá-la, incorporá-la, ajustá-la a ela, ao contrário de lhe resistir, de a ela se opor e de forçar o planeamento inicial.
O método Scrum permite que as organizações se tornem mais flexíveis e abertas à mudança. Também é importante perceber a necessidade de manter a estabilidade durante todo o processo de mudança. A chave é encontrar o equilíbrio certo entre flexibilidade e estabilidade (“caórdico”).
Os projetos de desenvolvimento e inovação são tipicamente complexos e sujeitos a inúmeras falhas. Um das razões de falha dos projetos é a ausência de procedimentos de gestão de risco.
O risco é um aspeto inerente a qualquer atividade e os projetos não são exceção. Podem ser risco financeiro, risco do negocio, risco técnico. A gestão de risco é fundamental em qualquer área de negócio, de modo a assegurar a sua viabilidade e a reduzir a probabilidade de insucessos. A gestão ágil do risco aborda a identificação, a análise, a priorização, o tratamento e a monitorização de riscos em sintonia com os princípios das práticas do manifesto ágil. Fundamentalmente é o equilibro entre o risco e a recomenda.
A gestão ágil baseia-se nos princípios de transparência, equilibro e fluxo. O risco é uma incerteza que importa e que ameaça o sucesso de um projeto. Tem potencial positivo ou negativo. Quando é positivo, são designados por oportunidades.
Lean thinking: eliminar o desperdício, ampliar a aprendizagem, decidir o mais tarde possível, entregar o mais rápido possível, dar poder à equipa, criar integridade, ver o “todo”.
Filosofia Lean startup: o empreendorismo está em toda a parte, o empreendedorismo é gestão, há uma validação da aprendizagem, há contabilidade da inovação, aplicar o loop de feedback build-measure-learn.
Sistema Kanban é diferente do Scrum, mas também tem o propósito ágil e lean. Uma diferença fundamental entre os dois é que o Kanban é um sistema contínuo e o Scrum um método interativo.
O sistema Kanban é mais adequado a equipas que têm muito trabalho não planeado durante o sprint.
O espírito de uma gestão lean e agile pode ser resumido na busca incessante pela adaptação dos produtos/serviços ao mercado; construir, medir e aprender; entender o cliente e perceber o que pretende é um desafio de todos, não apenas dos departamentos de Vendas ou de Marketing ou da equipa de gestão.
Num ambiente lean and agile, ninguém é culpado. Se acontecer um erro, não devemos procurar alguém para culpar. Em vez disso, devemos examinar o sistema que o produziu e procurar corrigi-lo.
O desenvolvimento de software, como muitos outros negócios assentes no conhecimento, requer muito mais do que pessoas para realizar tarefas. Requer “seres pensantes”, motivados e com um elevado propósito.
P18 Ship deliverables
P19 Retrospect Project
As equipas Scrum são concebidas para estarem próximas do cliente, promovendo a comunicação presencial entre todos os seus membros, de forma a adaptarem-se rapidamente aos pedidos de mudança. Quando corretamente implementado, o Scrum resulta em significativos aumentos de produtividade e moral dos participantes, reduzindo tempo de desenvolvimento, melhor qualidade e menores riscos, quando comparados com os modelos tradicionais de gestão de projetos.
Estruturas de escalabilidades, como SAFe, LeSS ou NEXUS, são muito pouplares no domínio do desenvolvimento de software e dos sistemas de informação.
Qualidade é muitas vezes entendida como conformidade com os requisitos. Um aspeto importante da qualidade é a melhoria contínua, o que se traduz em ciclos consistentes de inspeção e adaptação.
Na estrutura Scrum existem quatro momentos de inspeção e adaptação: planeamento do sprint, conduzir as reuniões diárias em pé, demonstrar e validar o sprint, retrospectivar o sprint.
Em Scrum a qualidade é definida como a “capacidade dos produtos ou entregas concluídas em cumprir com os critérios de aceitação e em alcançar o valor de negócio esperado pelo cliente” (ScrumStudy, 2017).
Como o trabalho em Scrum é feito através do desenvolvimento de incrementos ao longo dos sprints, isso faz com que os erros ou os defeitos possam ser identificados mais cedo, através de repetidos testes de qualidade e validação junto dos stakeholders.
Os requisitos de âmbito e qualidade são determinados considerando se o projeto vai dar resposta às necessidades do negócio, as necessidades atuais e futuras do público-alvo, capacidade de a organização dar resposta às necessidades identificadas.
A US só poderá ser classificada como done se der resposta a todos os critérios de aceitação. Todas as condições devem ser satisfeitas para que a US seja considerada done. Uma definição clara de done é fundamental pois ajuda a eliminar a ambiguidade.
O cliente é o stakeholder mais importante para qualquer projeto. A Gestão da Qualidade em Scrum permite que os clientes estejam cientes de quaisquer problemas no início do projeto e ajuda-os a reconhecer se um projeto será útil ou não. O processo é facilidade por três atividades que se encontram inter-relacionadas: planeamento da qualidade, controlo da qualidade, garantia da qualidade.
A Gestão da mudança é a forma de encarar e gerir a mudança em Scrum: aceitá-la, incorporá-la, ajustá-la a ela, ao contrário de lhe resistir, de a ela se opor e de forçar o planeamento inicial.
O método Scrum permite que as organizações se tornem mais flexíveis e abertas à mudança. Também é importante perceber a necessidade de manter a estabilidade durante todo o processo de mudança. A chave é encontrar o equilíbrio certo entre flexibilidade e estabilidade (“caórdico”).
Os projetos de desenvolvimento e inovação são tipicamente complexos e sujeitos a inúmeras falhas. Um das razões de falha dos projetos é a ausência de procedimentos de gestão de risco.
O risco é um aspeto inerente a qualquer atividade e os projetos não são exceção. Podem ser risco financeiro, risco do negocio, risco técnico. A gestão de risco é fundamental em qualquer área de negócio, de modo a assegurar a sua viabilidade e a reduzir a probabilidade de insucessos. A gestão ágil do risco aborda a identificação, a análise, a priorização, o tratamento e a monitorização de riscos em sintonia com os princípios das práticas do manifesto ágil. Fundamentalmente é o equilibro entre o risco e a recomenda.
A gestão ágil baseia-se nos princípios de transparência, equilibro e fluxo. O risco é uma incerteza que importa e que ameaça o sucesso de um projeto. Tem potencial positivo ou negativo. Quando é positivo, são designados por oportunidades.
Lean thinking: eliminar o desperdício, ampliar a aprendizagem, decidir o mais tarde possível, entregar o mais rápido possível, dar poder à equipa, criar integridade, ver o “todo”.
Filosofia Lean startup: o empreendorismo está em toda a parte, o empreendedorismo é gestão, há uma validação da aprendizagem, há contabilidade da inovação, aplicar o loop de feedback build-measure-learn.
Sistema Kanban é diferente do Scrum, mas também tem o propósito ágil e lean. Uma diferença fundamental entre os dois é que o Kanban é um sistema contínuo e o Scrum um método interativo.
O sistema Kanban é mais adequado a equipas que têm muito trabalho não planeado durante o sprint.
O espírito de uma gestão lean e agile pode ser resumido na busca incessante pela adaptação dos produtos/serviços ao mercado; construir, medir e aprender; entender o cliente e perceber o que pretende é um desafio de todos, não apenas dos departamentos de Vendas ou de Marketing ou da equipa de gestão.
Num ambiente lean and agile, ninguém é culpado. Se acontecer um erro, não devemos procurar alguém para culpar. Em vez disso, devemos examinar o sistema que o produziu e procurar corrigi-lo.
O desenvolvimento de software, como muitos outros negócios assentes no conhecimento, requer muito mais do que pessoas para realizar tarefas. Requer “seres pensantes”, motivados e com um elevado propósito.
Comments
Post a Comment