Um livro básico e incrível sobre gestão de projetos. Útil para qualquer pessoa que quer melhorar a sua gestão e para qualquer profissional da área de tecnologias e do digital.
Este foi um presente dado pelos colegas antes de sair da empresa onde estava. Sabendo que eu iria adoptar uma lógica de gestão de projetos, este foi um mimo muito especial e mais do que valorizado. Quando recebi folheei e sabia que iria ser bastante útil. E é mesmo um livro muito completo.
Foi também o primeiro livro que comecei a sublinhar a lápis, fruto de uma reflexão que fiz no LinkedIn.
Questionei se as pessoas sublinhavam livros e percebi que muitas delas diziam que sim. Também fui inspirada pelo sistema de Note Taking do Ryan Holiday. Este é assim o primeiro livro que vai receber mais notas nesta book review, passando a ser tanto uma review como um sumário.
Ficha técnica
Título: Scrum – A Gestão Ágil de Projetos
Autor: João Paulo Pinto e Christiane Tscharf
Ano: 2019
Editora: FCA – Editora de Informática, Lda
Resumo
Sendo um livro técnico por excelência, este livro é uma introdução e resumo à gestão de projetos, com foco no Scrum.
Uma metodologia ágil nasceu para dar resposta a um contexto atual de mudança e evolução constantes. A forma de atuar tradicional demorava muito tempo e contava demasiados riscos, em que empresas investiam recursos a planear projetos, e chegando ao fim, não era nada daquilo que o cliente tinha imaginado.
Com as rápidas mudanças, uma nova forma de gestão de projetos nasce, mostrando conceitos, métodos e ferramentas que permitem dar resposta às solicitações dos clientes e mercados cada vez mais exigentes e competitivos – a metodologia ágil.
O livro foca-se na estrutura Scrum como metodologia ágil para a gestão de projetos. Tem 5 fases e 19 processos que meticulosamente seguidos dão imensas vantagens a equipas e empresas.
Os principais temas abordados são:
- Introdução à Metodolodia Ágil
- Papéis, fases e processos Scrum
- Escalabilidade
- Qualidade
- Gestão de Mudança
- Gestão do Risco
- Gestão Lean e Agile
Estes são também os grandes temas dos 10 capítulos, com ainda casos de estudo no final, bem como anexos para se usar no dia-a-dia.
Podes ler mais reviews de livros aqui.
Porque é relevante este livro?
Já deves ter ouvido as palavras “Agile”, “Lean”, Scrum”, “Kanban”, “Sprint”. Este é um excelente livro para clarificar esses conceitos e perceberes como se relacionam entre si. O que gostei mais é o seu conhecimento prático, pois acabei por usar na minha empresa e é mesmo um guia passo-a-passo desta prática que é aplicada todos os dias por diversas equipas em todo o mundo.
É assim um livro base para qualquer profissional de gestão de projetos, como se fosse uma bíblia. É também útil para gestores que querem começar a gerir de uma forma mais ágil, perceber do que se trata e quais as vantagens deste processo, em detrimento de outros procedimentos mais tradicionais (chamado waterfall – cascata – em que uma tarefa é feita e só passa para a seguinte quando estiver concluída).
Por fim, qualquer profissional da área de IT pode perceber melhor como funciona a metodologia ágil e como rapidamente integrar uma equipa de desenvolvimento com este livro na cabeceira, para tirar todas as dúvidas.
Notas a guardar
Este foi o livro em que tirei mais notas. Assim, tens acesso a notas mais extensas, que fui fazendo ao longo da leitura. É também uma boa forma de consultar esta informação mais tarde sobre gestão de projetos, quando precisar. Seguem as notas:
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.
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 para 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.
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
Existem papéis centrais e não centrais no Scrum. Os centrais são o Product Owner, o Scrum Master e a Scrum Team. Os não centrais são os stakeholders, fornecedores, scrum guidance body
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
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.
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
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.
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.
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.
