 Como nas organizações as equipes de desenvolvimento podem liderar um processo inovador, criar um produto diferenciado nas perspectivas do cliente e ainda entregar no prazo e abaixo do orçamento? Projetos são uma forma popular de financiar e organizar o desenvolvimento de soluções. Eles organizam o trabalho em equipes temporárias, apenas de construção e são financiados com benefícios específicos projetados em um caso de negócios. Em vez disso, o modo de produto usa equipes duráveis e executadas por ideias que trabalham em um problema de negócios persistente. O modo de produto permite que as equipes se reorientem rapidamente, reduz seu tempo de ciclo de ponta a ponta e permite a validação dos benefícios reais usando iterações de ciclo curto enquanto mantém a integridade da arquitetura de seu software para preservar sua eficácia a longo prazo. Metodologias como o Agile (utilizando técnicas como Extreme Programming, Scrum, Kanban) possibilitam as equipes serem mais adaptáveis e chegando a um contato mais próximo com clientes. Atualmente temos múltiplos casos de utilização do Scrum em projetos de software e diversos exemplos de alto impacto em projetos de manufatura (Embraer, SAAB, Ericsson, Magna International, etc.). No entanto, alguns problemas podem não ser plenamente resolvidos permitindo a construção de algo com baixa aceitação pelo mercado. Isso provavelmente se deve ao fato das equipes ficarem focadas em aspectos técnicos e presas em sua própria visão de produto, com soluções construídas que podem não resolver problemas reais. Além disso, observa-se a ausência de estratégia de mercado e a falta de pesquisa competitiva. Por fim, a principal armadilha é a incapacidade das equipes de se colocarem no lugar dos usuários, entendendo verdadeiramente a maneira como pensam e o que precisam, uma preocupação repetida por todos os outros autores. Dois movimentos que se tornaram populares recentemente nos setores de tecnologia e serviços são o Lean Startup e o Design Thinking. Se por um lado, as startups (modelo enxuto e pouca dependência com sistemas legados) tiveram muita facilidade em adotar um modelo experimental e empírico, muitas outras organizações ainda enfrentam dificuldades em alavancar a transformação ágil, em razão da estrutura atual, competências, sistemas fortemente acoplados, aplicabilidade, entre outros. Enquanto o Lean Startup, Lean UX e Lean Enterprise propõem o modelo experimental, baseado em validação de hipóteses e MVPs para lidar em domínios de extrema incerteza, o modelo projetizado enfatiza o processo linear. A tríplice restrição em projetos tradicionais é estruturada com o tempo e custo variáveis, já o escopo fixo (com alterações via change request). O processo empírico derivado das abordagens ágeis e design thinking orientam para a entrega de valor como foco, onde iterativamente o escopo é reavaliado e repriorizado. Não obstante, restrições como custo, capacidade dos recursos entre outras também fazem parte do processo e devem ser gerenciadas apropriadamente. O Design Thinking, popularizado por Tim Brown da IDEO, veicula que a metodologia empregada pelos designers na abordagem de problemas pode ser aplicada em todas as áreas do conhecimento para o alcance da inovação. A verdadeira inovação está em encontrar uma solução criativa que seja desejável para o consumidor, econômica e tecnicamente viável. Design Sprint é um processo de cinco fases, com restrição de tempo, que usa os conceitos e princípios de Design Thinking com o objetivo de reduzir o risco ao trazer um novo produto, serviço ou recurso para o mercado. O processo visa ajudar as equipes a definir metas claramente, validando suposições diretamente com clientes finais e decidindo sobre um roteiro de produto antes de iniciar o desenvolvimento. Ele procura abordar questões estratégicas usando testes interdisciplinares, prototipagem rápida e usabilidade. Este processo de design é semelhante a Sprints em um ciclo de desenvolvimento Agile. Assim, quando consideramos organizações ágeis em escala (Scaled Agile) que possibilitam negócios ágeis (business Agility) exploramos questões muito mais amplas que o crescimento do número de times ágeis. Observamos em algumas organizações que os times ágeis denominados de Squads são definidos como equipes temporárias para atender os objetivos de um projeto, que uma vez encerrado, o time é desfeito. Este time muitas vezes se restringe à equipe de desenvolvimento, portanto não sendo multifuncional. Aplica as cerimônias e os artefatos do Scrum, mas definitivamente poderíamos apelidar esta abordagem de “Cascágil” ou “Scrum-but”. E assim, escalam o ágil na organização crescendo o número de times ágeis, que logo enfrentam os desafios de coordenação das múltiplas equipes, perda de padronização, ausência de cadência produtiva, e de integração entre as iniciativas. Outro gap importante é que a prática de gerenciamento do produto ainda está amadurecendo nas empresas. Papéis e responsabilidades entre Gerente do Produto, Dono do Produto (Product Owner) e o Scrum Master não estão claramente definidos ou mesmo consistentemente entendidos. Segundo a Gartner, em 2021, mais de 60% das disciplinas tradicionais de gerenciamento de projetos serão amplamente suplantadas por métodos modernos e dinâmicos; por exemplo, gerenciamento de produtos, para a maioria dos projetos digitais e de TI. Assim, um caminho que entendemos estratégico para a jornada da agilidade organizacional é adotar um modelo convergente, integrado e único que combina Design Sprint (Design Thinking), Lean Inception (Lean Startup), Scrum (Agile) e DevOps para desenvolvimento de soluções de produtos e serviços. A organização não abandona totalmente suas práticas projetizadas (Project management), mas adaptam as mesmas e abraçam estrategicamente o gerenciamento de ciclo de vida de produtos (Product life cycle management). Cada iniciativa pode iniciar em uma etapa do modelo conforme seu estágio de maturidade, por exemplo:
Caso queira conhecer mais, em particular sobre os papéis e responsabilidades do Gerente do produto, Dono do Produto (Product Owner), Gerente de Projetos, Scrum Master, Release Train Engineer (RTE), nos procure. A DC-DinsmoreCompass oferece treinamentos e assessoria para implementar este processo nas empresas. Fontes e referências: Leonardo Matsumota, Martin Fowler, scrumguides.org, 
0 Comentários
 DevOps é um conjunto de práticas que combina desenvolvimento de software (Dev) e operações de TI (Ops). Tem como objetivo encurtar o ciclo de vida de desenvolvimento de sistemas e fornecer entrega contínua com alta qualidade de software. DevOps é complementar ao desenvolvimento de software Agile. Vários aspectos do DevOps derivaram da metodologia Agile. Os princípios DevOps Usar a metodologia DevOps dentro na equipe de desenvolvimento de software muda radicalmente a organização. A maneira como a equipe de desenvolvedores codifica e implanta versões é baseada em 6 princípios fundamentais:
A automação permite que desenvolvedores e operações simplifiquem o processo e permite que as equipes sejam mais produtivas. Visto que a automação reduz o número de ações manuais, ela melhora a qualidade do desenvolvimento e a segurança do software. Enquanto a iteração acelera o processo de desenvolvimento graças ao feedback mais rápido dos usuários finais. O autoatendimento também acelera os lançamentos, permitindo que os desenvolvedores implantem aplicativos sob demanda por conta própria. A melhoria contínua existe para tornar o processo mais fluido. Na verdade, após cada incidente, faz parte do processo de DevOps fazer uma retrospectiva. Uma retrospectiva registra cada incidente, seu impacto, as ações tomadas para corrigi-lo, a causa do problema e as ações que foram tomadas para evitar que aconteça novamente. O teste contínuo permite lançamentos mais rápidos e maior qualidade ao mesmo tempo. E, finalmente, mas não menos importante, a colaboração entre desenvolvedores e operações é a chave para combinar esforços e alcançar o sucesso mais rápido. O processo DevOps O processo DevOps consiste em uma série de etapas. Aqui está um diagrama para ajudá-lo a visualizar: As etapas do processo DevOps são:
Como o DevOps visa aumentar significativamente a satisfação de seus clientes, naturalmente suas equipes reiniciam as etapas com um novo recurso para seu software ou aplicativo. É por isso que sempre desenhamos o DevOps como um loop infinito. Caso queira conhecer mais. A DC-DinsmoreCompass oferece treinamentos e assessoria para implementar este processo nas empresas.  Texto extraído e adaptado do scrumguides.org Scrum é um framework ágil dentro da qual as pessoas podem resolver problemas adaptativos complexos, ao mesmo tempo que entregam produtos de maior valor possível de forma produtiva e criativa. Scrum é:
Scrum é um framework de processo que tem sido usado para gerenciar o trabalho em produtos complexos desde o início dos anos 1990. Scrum não é um processo, técnica ou método definitivo. Em vez disso, é uma estrutura dentro da qual você pode empregar vários processos e técnicas, de onde deriva a sua complexidade para dominar e para implementar, particularmente em escala na organização. Scrum deixa clara a eficácia relativa de seu gerenciamento de produto e técnicas de trabalho para que você possa melhorar continuamente o produto, a equipe e o ambiente de trabalho. O framework Scrum consiste em equipes Scrum e suas funções, eventos, artefatos e regras associados. Cada componente dentro do framework serve a um propósito específico e é essencial para o sucesso e uso do Scrum. As regras do Scrum unem as funções, eventos e artefatos, governando os relacionamentos e a interação entre eles. Usos do Scrum Scrum foi inicialmente desenvolvido para gerenciar e desenvolver produtos. Desde o início de 1990, Scrum tem sido usado extensivamente, em todo o mundo, para:
Scrum tem sido usado para desenvolver software, hardware, software embarcado, redes de função de interação, veículos autônomos, escolas, governo, marketing, gerenciamento de funcionamento de organizações e quase tudo que usamos em nosso dia a dia, como indivíduos e sociedades. Como a tecnologia, o mercado e as complexidades ambientais e suas interações aumentaram rapidamente, a utilidade do Scrum em lidar com a complexidade é comprovada diariamente. Scrum provou ser especialmente eficaz na transferência de conhecimento iterativa e incremental. Scrum agora é amplamente usado para produtos, serviços e gerenciamento da organização. A essência do Scrum é uma pequena equipe de pessoas. A equipe individual é altamente flexível e adaptável. Essas forças continuam operando em uma, várias, muitas e redes de equipes que desenvolvem, liberam, operam e sustentam o trabalho e os produtos de trabalho de milhares de pessoas. Eles colaboram e interoperam por meio de arquiteturas de desenvolvimento sofisticadas e ambientes de lançamento de destino. Quando as palavras "desenvolver" e "desenvolvimento" são usadas no Guia do Scrum, elas se referem a trabalhos complexos, como os tipos identificados acima. Teoria Scrum Scrum é baseado na teoria empírica de controle de processos, ou empirismo. O empirismo afirma que o conhecimento vem da experiência e da tomada de decisões com base no que é conhecido. Scrum emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar o risco. Três pilares sustentam toda implementação de controle de processo empírico: transparência, inspeção e adaptação. Transparência Os aspectos significativos do processo devem ser visíveis aos responsáveis pelo resultado. A transparência requer que esses aspectos sejam definidos por um padrão comum para que os observadores compartilhem um entendimento comum do que está sendo visto. Por exemplo:
Inspeção Os usuários do Scrum devem inspecionar frequentemente os artefatos do Scrum e o progresso em direção a uma Meta do Sprint para detectar variações indesejáveis. Sua inspeção não deve ser tão frequente que atrapalhe o trabalho. As inspeções são mais benéficas quando realizadas de forma diligente por inspetores qualificados no local de trabalho. Adaptação Se um inspetor determinar que um ou mais aspectos de um processo desviam-se dos limites aceitáveis e que o produto resultante será inaceitável, o processo ou o material sendo processado deve ser ajustado. Um ajuste deve ser feito o mais rápido possível para minimizar novos desvios. Scrum prescreve quatro eventos formais para inspeção e adaptação:
Valores Scrum Quando os valores de compromisso, coragem, foco, abertura e respeito são incorporados e vividos pelo Time Scrum, os pilares Scrum de transparência, inspeção e adaptação ganham vida e constroem confiança para todos. Os membros do Time Scrum aprendem e exploram esses valores enquanto trabalham com os eventos, funções e artefatos do Scrum. O uso bem-sucedido do Scrum depende das pessoas se tornarem mais proficientes em viver esses cinco valores. As pessoas se comprometem pessoalmente em alcançar os objetivos do Time Scrum. Os membros da equipe Scrum têm coragem de fazer o que é certo. O número de empresas que vem adotando métodos ágeis e, em especial Scrum, cresce a cada dia. Segundo o 14th State of Agile Report, 81% das empresas entrevistadas no mundo possuem times ágeis. Contudo, 84% reportam estarem em estágio inicial de maturidade. Caso queira conhecer mais e ouvir sobre casos práticos nos procure. A DC-DinsmoreCompass oferece treinamentos e assessoria para implementar este processo nas empresas.  A Lean Inception consiste em uma série de workshops que ajudam as equipes a chegar rapidamente a um entendimento compartilhado. Para que seja bem-sucedida, é muito importante que haja um facilitador neutro presente, que atue como moderador da conversa, sem tentar influenciar a tomada de decisão da equipe. Os workshops utilizam técnicas de Design Thinking com uma abordagem de Lean* Startup: o workshop de Lean Inception. Segundo Paulo Caroli, o nome Inception vem do RUP (Rational Unified Process), um processo de engenharia de software criado pela Rational nos anos 90 para o desenvolvimento orientado a objetos, baseado no UML (Unified Modeling Language). Os projetos ágeis enfatizam a entrega antecipada e contínua de software valioso, cujo valor vem dos objetivos de negócios e das necessidades dos clientes. A criação do produto segue os conceitos e princípios do Lean StartUp, ajudando a promover o lançamento incremental de um MVP (Produto Mínimo Viável) - uma versão simples de um produto que é fornecida aos usuários para validar as principais premissas de negócios. (Fonte: Martin Fowler). Assim, o termo Lean do Lean Inception é derivado da abordagem Lean Startup. Particularmente quando um novo produto ou conjunto de recursos está sendo introduzido, pode ser um desafio garantir que a equipe e as partes interessadas tenham um entendimento compartilhado do que precisa ser construído. Questões críticas na concepção do projeto:
Principais resultados desejados
Uma Lean Inception é particularmente útil quando a equipe precisa desenvolver um MVP de forma iterativa. Embora o termo seja frequentemente mal interpretado, a propriedade central de um MVP é que ele é algo que construímos para saber se vale a pena continuar construindo um produto. Portanto, escolhemos os recursos com base no teste de nossas suposições sobre o que é valioso para nossos usuários. Para isso, precisamos entender quem são nossos usuários, que atividade eles fazem que o produto oferece suporte e como medir se eles acham o produto útil. Lean Inception é valioso em duas circunstâncias principais mas aplicável em diversas outras:
Lean Inception não substitui sessões de ideação, pesquisa de cliente, entre outros exercícios observados no Design Sprint. É uma técnica específica que faz parte da compreensão do que é necessário para construir um produto de sucesso. Exatamente como ele se encaixa nessas outras atividades depende muito do contexto específico de sua organização e do esforço de desenvolvimento no qual você está trabalhando. Caso queira conhecer mais e ouvir sobre casos práticos nos procure. A DC-DinsmoreCompass oferece treinamentos e assessoria para implementar este processo nas empresas.  Design Sprint é um processo de cinco fases, com restrição de tempo, que usa os conceitos e princípios de Design Thinking com o objetivo de reduzir o risco ao trazer um novo produto, serviço ou recurso para o mercado. O processo visa ajudar as equipes a definir metas claramente, validando suposições diretamente com clientes finais e decidindo sobre um roteiro de produto antes de iniciar o desenvolvimento. Ele procura abordar questões estratégicas usando testes interdisciplinares, prototipagem rápida e usabilidade. Este processo de design é semelhante a Sprints em um ciclo de desenvolvimento Agile. (fonte: Wikipédia) Design Sprint foi criado na Google Ventures por Jake Knapp, cujo livro SPRINT é um best seller e o processo se mostrou bem-sucedido em centenas de startups e vem sendo utilizado por muitas organizações de diversos tamanhos e mercados, tanto para o desenho de produtos, serviços, estratégia, etc. Trabalhando colaborativamente em um design sprint, times multidisciplinares podem reduzir o ciclo de debates intermináveis e compactar meses de tempo em uma única semana. Em vez de esperar para lançar um produto mínimo para entender se uma ideia é boa, você obterá dados claros de um protótipo realista. O design sprint tem um benefício marcante: avançar no futuro para ver o produto e as possíveis reações do cliente, antes de fazer qualquer compromisso caro com o seu desenvolvimento. Fases
Video de 90 segundos do autor Jake Knapp apresenta o processo, um pouco da história de como tudo começou e mais detalhes podem ser encontrados na fonte SPRINT BOOK. Caso queira conhecer mais e ouvir sobre casos práticos nos procure. A DC-DinsmoreCompass oferece treinamentos e assessoria para implementar este processo nas empresas. |
Categorias
Todos
Histórico
Novembro 2021
|