 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. |
Categorias
Tudo
Histórico
Novembro 2024
|
