Categoria: Frameworks

Publicado em

Cristal – Simplificando o Controle de Projetos

Cristal - Simplificando o Controle de Projetos

Este framework foi criado por Alistair Cockburn em 1988 com o objetivo de proporcionar um controle simplificado para projetos de softwares, que se tornaram cada vez mais complexos com a evolução da tecnologia. A metodologia Cristal possui uma característica única onde são divididos em cores os níveis de criticidade de um projeto e tamanho da equipe responsável pela execução.

Seguindo a filosofia Cristal, projetos menores e menos críticos são classificados com cores mais claras, como por exemplo Clear e Yellow, envolvendo menos desenvolvedores e possuindo baixo risco e projetos maiores são classificados com cores escuras caracterizando um alto nível de importância e relação risco/retorno maior.

Segundo Cockburn o framework Cristal, embora possua diferentes níveis de controle, em todos é procurado ter uma comunicação clara e um forte trabalho em equipe, a qual possui sete princípios chaves para sua implementação, que são:

Feedback constante: Todo time se reúne com frequência com o time de desenvolvimento para discutir o andamento do projeto e com o cliente, para garantir que está sendo desenvolvido o que é esperado.

Comunicação constante: Os responsáveis por definir os requisitos do projeto devem ser acessíveis a todo momento.

Entrega frequente: São esperados resultados a cada 2 meses e as partes interessadas podem acessar versões intermediárias das entregas para poder fornecer feedback.

Foco: Cada membro do time possui sua lista de prioridades e deve trabalhar dentro do timebox para concluir as tarefas sem ser interrompido.

Acesso para usuários: É esperado que o time de desenvolvimento tenha acesso a uma pequena parcela de usuários finais do projeto.

Testes automatizados e integração: Devem ser inseridos controles de testes automatizados para uma frequente integração com o sistema final.

Segurança: Aqui tem-se dois vieses onde o time de projeto deve ser livre para comunicar seus pontos de vista e deve ser garantida a segurança do usuário ao utilizar o produto.

O método Cristal também utiliza uma codificação por letras para representar o nível crítico do projeto conforme figura 1.

Figura 1 – Nível de criticidade do projeto Cristal.

Fonte: Elaborada pelo autor (2021).

Sendo:

 C – Confort (conforto): Caso o produto não funcione em sua totalidade inicialmente, deve haver um backup para que o usuário possa dar continuidade em seu trabalho.

D – Discretionary Money (dinheiro disponibilizado para uso sob autorização): Casos onde a falha do sistema causa perda de dinheiro, porém o valor da perda não é expressivo.

E – Essencial Money (dinheiro necessário para os custos do projeto): Casos onde a falha do sistema causa grandes perdas financeiras.

L – Life (vida): Casos onde a falha do sistema pode causar a perda de vidas.

Segundo Fowler o framework cristal tem como prioridade as pessoas envolvidas, estando o processo em segundo plano. Assim como em outros frameworks ágeis, o Cristal possui seu próprio framework conforme figura 2, com um conjunto de práticas a serem abordadas dentro de cada ciclo e possuindo determinado grau de importância dependendo do nível crítico do projeto.

Figura 2 – Framework Cristal.

Fonte: Elaborada pelo autor (2021).

Staging: É o planejamento do próximo incremento do projeto, nesta etapa o time seleciona os requisitos e prazo para a entrega da iteração.

Edição e Revisão: É onde é construído, demonstrado e revisado os objetivos do incremento a ser feito.

Monitoramento: O progresso e a performance da equipe são monitorados e são medidos os estágios de estabilidade de entregas.

Paralelismo e fluxo: As equipes operam de modo sincronizado.

Inspeções de usuário: São realizadas de 2 a 3 inspeções por incremento.

Workshops refletivos: Antes e depois de cada iteração são realizadas reuniões para analisar o progresso do time.

Assuntos locais: Dependendo do tipo do projeto são aplicados diferentes procedimentos e ferramentas.

Produtos de trabalho: São documentos de requisitos, com lançamentos frequentes, manuais, modelos comuns.

Padrões: São padrões de qualidade, notação e formatação.

Ferramentas: São as ferramentas mínimas necessárias para a execução do projeto, como por exemplo compiladores, programas, desenhos, métricas e comunicação.

O framework cristal possui alguns papeis importantes para a sua aplicação, sendo:

Patrocinador: Responsável por financiar o projeto.

Usuário: Responsável por utilizar o produto.

Programador sênior: Membro responsável por passar experiência ao time.

Programador: Membro responsável pela estruturação da programação.

Testador: Membro responsável por testar o produto desenvolvido.

Escritor: Responsável pela elaboração da documentação.

Analista de negócios: Responsável por se comunicar com o usuário e negociar requisitos.

Publicado em

XP – Extreme Programming: Onde Boas Práticas Maximizam Resultados

XP - Extreme Programming: Onde Boas Práticas Maximizam Resultados

O XP – Extreme Programming foi criado por Kent Beck em 1997 em um projeto para a Chrysler com o objetivo de auxiliar em projetos pequenos e médios de 2 a 12 pessoas envolvidas, com boas práticas para assegurar que o cliente tenha o melhor retorno possível.

Nesta metodologia tem-se como objetivo descrever a meta de longo prazo para atender a todos requisitos da necessidade do cliente seguindo os valores:

Feedback: Ao ser analisado o sistema pelo cliente, o mesmo é avaliado e gera insights importantes que norteiam o time de desenvolvimento, dizendo o que é necessário melhorar ou acrescentar, o que deu certo e o que não é necessário.

Comunicação: Com isso é possível que sejam analisados os detalhes importantes do projeto e que seja dispendida a atenção necessária no desenvolvimento.

Simplicidade: Toda informação trocada entre cliente e time de projeto deve ser claramente compreendida e deve ser desenvolvido somente aquilo que é necessário, direcionando totalmente o foco no problema.

Coragem: O time deve ter a confiança de que partindo com os valores do XP poderá evoluir o desenvolvimento com segurança e agilidade.

Respeito: Todos os integrantes do time devem ter abertura para apresentar seus pontos de vista.

O XP possui 12 práticas diretamente relacionadas aos seus valores e que tem como missão garantir a satisfação do cliente e proporcionar um ambiente de trabalho agradável a todos, conforme demonstrado na figura 1. As 12 práticas da metodologia XP devem ser aplicadas em conjunto dentro dos projetos para que se tenha consistência nos resultados.


Figura 1 – Práticas Extreme Programming.

Fonte: Elaborada pelo autor (2021).

Test driven development (Desenvolvimento orientado a teste): O time de desenvolvimento define testes para cada funcionalidade que será desenvolvida, antes de iniciar a estruturação do código, com isso torna-se possível validar rapidamente o item desenvolvido.

Refactoring (Refatoração): Esta prática consiste em reestruturar o código de um projeto para facilitar seu entendimento e evitar duplicidade seguindo a filosofia DRY (don´t repeat yourself).

Simple design (Design simples): O projeto desenvolvido deve ser simples atendendo a real necessidade do cliente naquele momento. Caso existam necessidades futuras elas podem ser incrementadas ao projeto quando realmente se tornarem necessárias.

Pair Programming (Programação em par): Todo o código do projeto é feito em dupla, onde um desenvolvedor escreve o código e outro monitora o raciocínio fornecendo insights e em determinado momento ambos invertem os papeis, dando dinamismo ao desenvolvimento.

Collective Code Ownership (Propriedade coletiva): Todos os membros do time de desenvolvimento são responsáveis pelo código que está sendo desenvolvido, ou seja, mesmo que um membro deixe o time/empresa no decorrer do projeto, todo o restante sabe o ponto que está o desenvolvimento e pode dar continuidade rapidamente.

Code standards (Padronização de código): São estabelecidos padrões de estruturação do código para que todos os desenvolvedores tenham uma leitura rápida do que está sendo construído.

Sustainable pace (Ritmo sustentável): Nesta metodologia é recomendado que a jornada de trabalho de 8 horas seja respeitada, entendendo o limite físico de cada desenvolvedor.

Metaphor (Metáfora): É uma boa prática da metodologia XP realizar associações de termos técnicos a uma linguagem que seja compreensível por todos criando metáforas para facilitar o entendimento.

Continuous integration (Integração contínua): Ao final do desenvolvimento de cada incremento, após serem realizados todos os testes possíveis, a nova funcionalidade é incorporada ao código principal.

Planning games (Jogos de planejamento): O cliente é incumbido de descrever claramente as funcionalidades desejadas estruturando as user stories para que o time de projeto possa definir o tempo necessário para realizar o incremento e o custo, desse modo o cliente decide a ordem a qual serão desenvolvidos os itens.

Small releases (Entregas curtas): Como cada história de usuário representa o menor incremento utilizável de um projeto é utilizada esta prática para realizar entregas rápidas ao cliente.

Customer Tests (Testes de usuário): São as definições do cliente dos testes necessários para a validação do projeto.

Whole team (Equipe inteira): Nesta metodologia é buscado unir diversas áreas do time para atuarem em conjunto no mesmo ambiente para o desenvolvimento do projeto.

           Como ao analisar os valores da metodologia XP pontualmente podem haver avaliações vagas dependendo da óptica utilizada entre duas pessoas, procura-se transformar os valores em princípios (feedback, simplicidade, mudanças incrementais, aceitação de mudanças e qualidade) que irão nortear o time para agregar valor. Apesar da metodologia XP possuir práticas e valores que possibilitam simplificar projetos complexos, existem ambientes onde o XP não é recomendado, em processos de produção em massa onde tem-se etapas conhecidas e é claro desde o início o que necessita ser feito para atingir certo fim ou até mesmo quando um dos focos do projeto seja a documentação, nestes ambientes culturalmente são utilizadas metodologias estruturadas pelo modelo cascata.

Publicado em

Less – Aplicando o Scrum em Larga Escala

Less - Aplicando o Scrum em Larga Escala

Desde 2005, o framework LeSS (Large scaled Scrum) “Scrum em larga escala” criado por Craig Larman e Bas Vodde tem sido desenvolvido com o objetivo de auxiliar no andamento de grandes projetos em grandes grupos de trabalho. O framework LeSS é estruturado com base em princípios, técnicas de adoção, estrutura organizacional, excelência técnica, simplicidade e gerenciamento estratégico conforme figura 1, onde têm-se boas práticas que auxiliam todos os membros da organização a direcionar esforços na execução dos projetos.

Figura 1 – Framework Less.

Fonte: Disponível em https://less.works

O framework LeSS possui regras minimalistas que apenas fornecem a base para auxiliar na tomada de decisão. Este framework possui alguns princípios que são descritos abaixo:

Queue Theory (Teoria da fila): Nesta teoria é relatado que filas com lotes menores de atividades possuem melhor tempo de ciclo quando comparado a lotes maiores e que embora o tempo de ciclo possa ser melhorado aumentando o uso de recursos, um caminho interessante para que não se tenha sobrecarga de processos (WIP – work in progress) são os lotes menores de atividades.

Empirical process control (Controle empírico de processo): Este princípio é aplicado em projetos onde não se tem etapas predefinidas devido sua alta complexidade, nestes projetos é necessário que o time inspecione e adapte continuamente os processos.

System Thinking (Pensamento sistêmico): Esta é a prática a qual todo o time de projeto analisa os impactos que o projeto pode causar em diferentes áreas e segmentos.

Lean Thinking (Pensamento enxuto): Nesta prática procura-se focar apenas em atividades que agregam valor, melhorando continuamente o tempo de ciclo.

Continous Improvement (Melhoria contínua): Dentro do LeSS não existe um “grupo de mudança”, a mudança é feita de modo contínuo por meio da experimentação.

Customer Centric (Foco no cliente): Todo projeto, processo e produto construído é pensado para atender aos requisitos solicitados pelo cliente.

Whole Product Focus (Foco no produto inteiro): Nesta prática tem-se o pensamento de que o cliente não compra o incremento e sim o produto como um todo, devido a isso os incrementos de um produto só tem valor quando integrados ao produto.

More with LeSS (Mais com menos): Este princípio defende a remoção da complexidade organizacional, tornando simples os processos sempre que possível.

Transparência: Esta prática apoia os ciclos curtos de feedback baseado nos princípios do Scrum onde a transparência possibilita a inspeção e adaptação.

Dentro do framework LeSS apresentado na figura 1 também se têm as respectivas análises para a sua adoção, sendo:

Three Principles (Os três princípios): Concentrando o esforço de adoção do framework em um único produto, dando suporte e tendo foco no aprendizado, permitindo o autogerenciamento do time, dando suporte na remoção dos impedimentos sempre que necessário e identificando voluntários para aprender o mindset ágil.

Coaching: Responsável por atuar a nível organizacional sendo um facilitador, identificando melhorias a serem implementadas nos projetos e na empresa.

Continuous Improvement (Melhoria contínua): Criando na organização a capacidade de responder as mudanças, mudando de direção o negócio sempre que necessário.

Feature team adoption map (Mapa de adoção da equipe de recursos): Tendo como objetivo a co-criação do produto junto com os usuários reais, o mapa parte desde a implementação do ágil com o crescimento da maturidade do ágil na empresa.

Getting started (Começando): Iniciando com a preparação técnica e estruturação do time, entendendo o produto a ser entregue e de onde virá o trabalho.

As estruturas organizacionais tradicionais buscam continuamente a otimização da produção individual tendo como elemento estrutural hierarquias, funções e políticas.  

Segundo a quarta lei de comportamento organizacional de Larman “A cultura segue a estrutura” o framework LeSS propõe uma estrutura organizacional com mais foco no produto conforme figura 1, sendo estruturada em:

Teams (Times): Com responsabilidades compartilhadas, sendo auto gerenciados e multifuncionais, podendo atuar em diversos projetos da empresa.

Scrum master: Ensinando o Scrum a todo o time e removendo impedimentos nos projetos.

Communities (Comunidades): Dentro das empresas podem surgir comunidades de prática (CoP – communities of practice) onde são compartilhados conhecimentos e experiências adquiridas pelo time por membros voluntários.

Organizational structure (Estrutura organizacional): Diferentemente das estruturas padrões das organizações, dentro LeSS tem-se pessoas de habilidades diferentes trabalhando lado a lado, aprendendo umas com as outras.

Feature teams (Equipes de recursos): São equipes multifuncionais de alta performance que trabalham juntas a muito tempo e que maximizam o valor entregue ao cliente.

Organizing by customer value (Organização por valor ao cliente): Dentro do framework LeSS procura-se ter equipes multifuncionais que trabalham juntas a muito tempo e com isso é procurado se especializar no segmento do cliente que a empresa procura resolver o problema.

Publicado em

Scrum: A Arte de Criar Valor

Scrum: A Arte de Criar Valor

Este framework foi desenvolvido em 1990 por Jeff Sutherland e Ken Schwaber e teve suas raízes em um ambiente de extrema incerteza e desperdício num projeto de desenvolvimento de sistema para o FBI, onde milhões de dólares haviam sido dispendidos ao projeto, porém não havia sido entregue o que realmente era necessário com a estrutura gestão de projetos utilizada na época, conforme citado no livro (Scrum, 2019). O objetivo do Scrum é ajudar pessoas a solucionar problemas complexos por meio de soluções adaptativas, tendo como foco pessoas, ambiente frequentado pelo time e busca da satisfação do cliente.

Segundo Schwaber (2020), neste framework somente são fornecidas recomendações sobre relacionamentos e interações, podendo ser empregado em diferentes times ferramentas e técnicas que complementem a filosofia ágil e ajudem no desenvolvimento do projeto.

O Scrum tem como base o empirismo (o conhecimento dos membros do time surge com base em suas experiências) e o lean thinking (redução de desperdícios e foco na real necessidade do projeto) e em seus quatro eventos dentro de seu framework emprega seus pilares de (transparência, inspeção e adaptação). (SCHWABER, 2020). Em cada evento do Scrum tem-se como prática possibilitar que o projeto seja o mais transparente possível fazendo com que todos do time e o cliente saibam onde o projeto se encontra, quais são suas barreiras e descobertas que foram feitas, também se tem como prática a inspeção do trabalho que vem sendo mostrado, para que seja possível identificar potenciais pontos de melhoria e assim adaptar métodos e processos utilizados.

A estrutura de operação do Scrum bem como um exemplo de seus time boxes pode ser analisada na figura 1.

Figura 1 – Framework Scrum.

Fonte: Elaborada pelo autor (2021).

Conforme apresentado na figura 1, o Scrum possui 4 eventos formais, que são:

Sprint planning: Este é o evento de início da sprint, onde são definidas as tarefas que serão realizadas e é entendido o objetivo, definindo qual será a meta da sprint. Neste evento podem ser convidados apoiadores de fora do projeto para compartilharem suas experiências e aconselhar o time de desenvolvimento. Na sprint planning é procurado entender o motivo das entregas gerarem valor ao cliente, o que e como pode ser feito o trabalho para tornar a meta real, dentro do timebox definido para este evento, durando no máximo 8 horas para sprints de 4 semanas.

Daily Scrum: Este é o evento mais rápido da sprint, porém é executado todos os dias de trabalho, tendo um timebox máximo de 15 minutos. Na daily Scrum tem-se o propósito de inspecionar o progresso para atingir a meta da sprint, neste encontro é desenvolvido um plano de ação para o próximo dia de trabalho e são identificados os impedimentos para o dia de trabalho atual, criando foco e incentivando o autogerenciamento do time de projetos.

Sprint review: Neste evento são inspecionados os resultados atingidos dentro da sprint dando visibilidade para o time identificar a necessidade de adaptações futuras. Durante este evento o time Scrum e o cliente analisam o que foi construído e as mudanças que foram realizadas. Este evento tem um timebox de 4 horas para sprints de um mês de duração.

Sprint retrospective: Esta reunião é realizada apenas com os membros do time de projeto, possui um timebox máximo de 3 horas para sprints de 4 semanas e tem como objetivo entender como melhorar a qualidade do produto e a eficiência do trabalho do time. São inspecionadas as iterações, processos e ferramentas utilizadas e é suposto o que pode ter desviado o foco do time, entendido quais melhorias deram certo e que irão continuar sendo aplicadas nas próximas sprints.

Na figura 1 também podem ser analisados os artefatos do Scrum que simbolizam o trabalho/valor agregado ao produto, sendo:

Product backlog: O objetivo do product backlog é atingir a meta da sprint. Este artefato é uma lista ordenada com as atividades que serão executadas dentro da sprint, sendo a única fonte de trabalho. As atividades no topo do product backlog são as que já passaram por um refinamento tornando pequena e precisa cada entrega a ser realizada. O time de desenvolvimento é o responsável pelo dimensionamento do tamanho das atividades e o product owner é incumbido a ajudar e entender os trade-off’s (troca de itens) quando necessário.

Sprint backlog: Este artefato é definido a cada início de sprint no evento sprint planning. Os desenvolvedores analisam o backlog do produto e selecionam quais atividades dentro de uma “história de usuário” serão realizadas dentro da sprint atual. Com o sprint backlog é dada uma imagem do andamento da sprint, servindo como base para implementação de indicadores como gráfico burndown e burnup.

Incremento de produto: São as entregas potencialmente utilizáveis realizadas dentro da sprint. Diversos incrementos são realizados durante a sprint e no evento sprint review são apresentados ao cliente para a obtenção de feedback. Caso um incremento não atinja a definição de pronto o mesmo não é apresentado ao cliente e retorna ao product backlog para que seja retomado em outra sprint.

Segundo Schwaber (2020) o sucesso do Scrum está diretamente relacionado aos seus 5 valores (compromisso, foco, abertura, respeito e coragem). O time de projeto deve se comprometer com estes valores e suportar uns aos outros durante o andamento do projeto para que possam tomar as melhores decisões possíveis sob uma visão holística. No Scrum tem-se 3 papéis conforme apresentado na figura 1, que são:

Time de desenvolvimento: São as pessoas que são responsáveis pela construção do projeto (programação, estruturação, prototipagem). Cada membro do time possui diferentes habilidades e conhecimentos técnicos que se complementam para possibilitar a construção e idealização do projeto.

Product owner: É o responsável por fazer com o que o produto tenha o máximo de valor possível para o cliente e para a empresa, trabalhando com a satisfação de cliente e o retorno financeiro para a empresa, utilizando por exemplo indicadores como o ROI (return on investiment). Este membro do time faz a interface de comunicação entre cliente e time de desenvolvimento, apresentando ao time as necessidades do cliente por meio das histórias de usuário.

Scrum master: É o membro responsável pelo conhecimento técnico do framework Scrum, fazendo com que o time e toda a organização entendam e sigam cada etapa da metodologia. É o responsável pela eficácia do time Scrum, podendo realizar treinamentos ao time, remoção de impedimentos do andamento do projeto e garantindo que os eventos sejam positivos, produtivos e dentro de seus respectivos timeboxes.

Apesar do Scrum possuir eventos predefinidos, este framework procura ser o menos prescritivo possível, para que diferentes times de projeto tenham abertura para adotar práticas e ferramentas que se encaixem ao produto que estão desenvolvendo. (SCHWABER, 2020). O Scrum tem foco total no produto, para atender aos requisitos informados pelo cliente, cada membro tem a liberdade para criar, se auto organizar e auto gerenciar em direção a meta do produto e em suas últimas atualizações do guia Scrum tem sido removida as linguagens técnicas focadas a TI, dando abertura para implementação em diversas áreas de atuação.

Navegue pelo site

Siga-Nos

Youtube Instagram Linkedin-in

Posts recentes

Todos os Direitos Reservados - 2023 - Geração Agile