Blog: ederson

Você Conhece o Framework Scrum?

No entendimento literal, #Scrum é inspirado em uma jogada de rugby e representa a importância de trabalhar em equipe, de forma estratégica e bem integrada, para resolver problemas complexos.

Scrum é um dos métodos ágeis mais difundidos do mercado, juntamento com os #Métodos #Lean e #Kanban.

O Scrum serve para organizar e orientar o processo rumo ao entregável.

É utilizado por equipes de desenvolvimento de software em todo o mundo e é a metodologia ágil mais popular entre todas.

Scrum também é utilizado por outros setores além da TI, onde há projetos que devem avançar na presença de cenários complexos.

3 pilares principais do #Scrum

Transparência, para ter certeza de que a equipe esteja na mesma página sobre os conceitos da metodologia e os resultados esperados;

Inspeção, para revisar constantemente a metodologia e a evolução dos projetos e da equipe;

Adaptação, para adequar e corrigir aspectos do processo que não estão acontecendo da forma como deveriam.

Os Personagens do Framework Scrum

Product owner É a pessoa que gerencia os projetos da equipe, gerando as demandas, definindo metas, entregas e prazos. O Product owner também é responsável por garantir que o trabalho do time esteja alinhado às necessidades do cliente e aos objetivos da empresa.

Scrum master O Scrum master é quem coordena o dia a dia da equipe, delegando papéis e acompanhando de perto a execução das tarefas. Ele garante que as regras, processos e cronograma sejam seguidos, além de ajudar o time a solucionar as dificuldades no caminho.

Dev team Dev Team são todas as pessoas da equipe envolvidas com determinada entrega, responsáveis por executar o que foi planejado. Nas empresas mais inovadoras, o Dev team é um time multidisciplinar - composto de pessoas com perfis e habilidades diferentes e complementares.

Os produtos do Framework Scrum

Product backlog É a lista produzida pelo Product owner, contendo todas as entregas de valor relacionadas a determinado produto/serviço e tudo o que deve ser realizado pela equipe para garantir essas entregas. Ela deve estar organizada por prioridades para que os próximos passos aconteçam.

Sprint backlog São as tarefas que serão realizadas durante o Sprint (ciclo) atual, somadas a um plano de ação para garantir que os objetivos finais sejam cumpridos. O Sprint backlog é alimentado com as prioridades que estão no topo do Product backlog.

Increment

É o objetivo ou entrega final esperada ao final de cada Sprint (ciclo).

Os Eventos Framework Scrum

🏃Sprint

O Sprint é um ciclo de trabalho com um período de tempo definido. Pode ser uma semana, quinze dias, um mês, mas depende da complexidade das entregas e da forma como a equipe ou a empresa escolhem se organizar.

Essa organização deve considerar um objetivo a ser atingido ou uma entrega a ser realizada ao final do Sprint.

📚 Sprint Planning

É uma reunião de planejamento que antecede o início de um novo Sprint. Ela envolve todo o time: o Product Owner, o Scrum Master e o Dev team. Essa reunião serve para responder às seguintes perguntas:

🟢 Que objetivo deveremos cumprir até o final desse Sprint?

🟢 De que forma esse objetivo será atingido?

📅 Daily Scrum

A Daily Scrum, ou só “Daily”, é uma reunião diária do time para avaliar o progresso das tarefas, solucionar dificuldades e planejar o dia de trabalho. O ideal é que essa reunião não ultrapasse 15 minutos de duração. Durante a Daily, cada pessoa deve responder objetivamente:

🔵 O que eu fiz ontem para contribuir com o objetivo do ciclo atual?

🔵 O que vou fazer hoje?

🔵 Existe algum impedimento para atingir esse objetivo?

📢 Sprint review

Chegou a hora de revisar aquilo que foi feito do início ao fim de um ciclo. A equipe verifica se o objetivo foi atingido, avalia as entregas, dificuldades e aprendizados do Sprint. O Sprint review também é o momento para atualizar o Product backlog.

🔎 Sprint retrospective

Podemos dizer que é uma reunião de revisão, mas olhando especificamente para a dinâmica do time ao invés de olhar para os resultados. O objetivo da Sprint retrospective é avaliar como se comportaram as pessoas, processos e ferramentas. Com essa visão é possível identificar o que deu certo e o que precisa ser melhorado e quem sabe sair com um plano de ação para esses pontos.

Os Valores do Scrum

Segundo a Agile Alliance, uma organização global sem fins lucrativos comprometida em apoiar pessoas que exploram e aplicam os valores, princípios e práticas Agile, espera-se que as equipes estudem e dominem os valores:

🔴 Comprometimento Os membros da equipe se comprometem pessoalmente a atingir as metas da equipe.

🟢 Coragem Os membros da equipe fazem a coisa certa e trabalham em problemas difíceis.

🔵 Foco Deve-se concentrar no trabalho identificado para o Sprint e nos objetivos da equipe.

🟡 Abertura Os membros da equipe e as partes interessadas estão abertos sobre todo o trabalho e os desafios que a equipe encontra.

🟠 Respeito Os membros da equipe se respeitam para serem capazes e independentes.

Sistema kanban

Um Sistema #Kanban é muito mais que anotações em uma parede. Para entender o #Kanban é preciso aceitar sua filosofia e aplicá-lo no seu trabalho diário. Se você lê, entende e se identifica com seus 4 princípios básico, a transição prática será lógica.

Image without description

Os 4 Princípios Fundamentais do #Kanban: 1º-Começar Com O Que Você Já Faz; 2º-Aceitar a Busca por uma Mudança Evolutiva e Incremental; 3º-Respeitar os Processos, as Funções & Responsabilidades Atuais; 4º-Encorajar Atos de #Liderança em Todos os Níveis;

1º Princípio do #Kanban: Começar Com O Que Você Já Faz

A flexibilidade do Kanban faz com que ele funcione com os processos, sistemas e fluxos de trabalho existentes, introduzido incrementalmente. Fácil de ser implementado já que não há necessidade de grandes mudanças.

2º Princípio do #Kanban: Aceitar a Busca por uma Mudança Evolutiva e Incremental

O #métodoKanban foi projetado para criar mínima resistência, encorajar pequenas mudanças incrementais e evolutivas ao processo atual.

3º Princípio do #Kanban: Respeitar os Processos, as Funções & Responsabilidades Atuais

Processos, funções, responsabilidades e títulos existentes possuem valor e, geralmente, valem a pena ser preservados.

4º Princípio do #Kanban: Encorajar Atos de Liderança em Todos os Níveis

O mais novo princípio Kanban. É importante que todo mundo adote a mentalidade de melhoria constante (#Kaizen), para atingir um desempenho ótimo a nível de time/departamento/empresa.

O #Kanban tem 6 Práticas importantes, conforme identificado por David Anderson, que precisam estar presentes para uma implementação bem-sucedida. -Visualizar o Fluxo de Trabalho; -Limitar Trabalho em Progresso; -Gerenciar o Fluxo; - Construir Políticas de Processo Explícitas; - Feedback Loops; - Melhorar a Colaboração (usando modelos & o método científico);

David J. Anderson (pioneiro Lean/Kanban para trabalho de conhecimento) formulou o método #Kanban como uma abordagem para mudanças de sistemas e o processo evolutivo, incremental, para organizações de trabalho de conhecimento.

Kanban é muito mais que anotações em uma parede. A maneira mais fácil de entender Kanban é aplicá-lo no seu trabalho diário. Se você lê, entende e se identifica com seus quatro princípios básico, você vai querer usar.

Agora começo a me aprofundar mais nos pontos fortes dos Quadros #Kanban, limites de #WIP e dos Cartões Kanban.

Esse texto foi um agrupado no mesmo formato que tuitei semana passada sobre #kanban em @edersonmelo.

Microsserviços de Susan J. Fowler - para Desenvolvimento Mobile

Concluído uma atualização sobre os principais Padrões de Arquiteturas para o Desenvolvimento Mobile, a ideia é aprofundar mais nos Microsserviços. E para isso, começo a ler o recém chegado livro da Susan J. Fowler. 

Mas diferente do que o título pode nos levar a interpretar, o livro não tem exemplos de soluções e códigos prontos. Tem uma boa base na vivência da Susan, parte nos serviços da UBER, permitindo que você converta esta experiência para qualquer tecnologia.

Image without description

Arquitetura iOS VIPER

Nos estudos acabei achando uma Arquitetura para iOS chamada VIPER.

Onde pude ter a oportunidade de entender, está Arquitetura tem como base a Experiência de construção de LEGO transferida para o design do aplicativo iOS VIPER.

Diferente do padrão MV(X), VIPER faz outra iteração sobre a ideia de separar responsabilidades com cinco camadas.

Interator - contém lógica de negócios relacionada aos dados ( Entidades ) ou rede, como criar novas instâncias de entidades ou buscá-las no servidor. Para esses propósitos, você usará alguns serviços e gerenciadores que não são considerados parte do módulo VIPER, mas sim uma dependência externa. Apresentador - contém a lógica de negócios relacionada à IU (mas independente do UIKit ), invoca métodos no Interator . Entidades - seus objetos de dados simples, não a camada de acesso a dados, porque isso é responsabilidade do Interator . Roteador - responsável pelos trechos entre os módulos VIPER . Basicamente, o módulo VIPER pode ser uma tela ou toda a história do usuário de seu aplicativo - pense na autenticação, que pode ser uma tela ou várias outras relacionadas. Quão pequenos são os seus blocos de “LEGO”? - Você é quem decide.

Image without description

Se compararmos com o padrão MV(X), veremos algumas diferenças na distribuição de responsabilidades: A lógica do modelo (interação de dados) mudou para o Interator com as Entidades como estruturas de dados burras. Apenas as funções de representação da IU do Controller / Presenter / ViewModel foram movidas para o Presenter, mas não os recursos de alteração de dados.

VIPER é o primeiro padrão que aborda explicitamente a responsabilidade da navegação, que deve ser resolvida pelo Roteador. A maneira adequada de fazer o roteamento é um desafio para os aplicativos iOS, os padrões MV(X) simplesmente não resolvem esse problema.

Distribuição - distribuição de responsabilidades. Testabilidade - sem surpresas aqui, melhor distribuição - melhor testabilidade. Fácil de usar - finalmente, os dois acima têm custo de manutenção, como você já imaginou. Você tem que escrever uma grande quantidade de interface para classes com responsabilidades muito pequenas.

Me parece que adotar o VIPER você tem a liberdade e a percepção de que pode construir um tanque, mas que pode servir para atirar numa mosca. E muito dos padrões do MV(X) consiga nos atender a longo prazo e com um custo menor de manutenção.

Arquitetura iOS MVC, MVP, MVVM

Dando continuidade ao aprendizado sobre Padrões e Arquiteturas, me mantenho nos padrões mais usados para Mobile seja para Android ou iOS.

Fundamentos de MV (X) Existem muitas opções quando se trata de padrões de design de arquitetura: MVC ,MVP, MVVM

Os 3 MV's pressupõem colocar as entidades do aplicativo em uma das 3 categorias:

Modelos - responsáveis ​​pelos dados de domínio ou uma camada de acesso a dados que manipula os dados.

Visualizações - responsável pela camada de apresentação, para o ambiente iOS pense em tudo começando com o prefixo ' UI '. Como o mediador entre o Model e a View, responsável por alterar o Model , reagindo às ações do usuário realizadas na View e atualizando a View com as mudanças do Model.

MVC Tradicional por assim dizer, é um pouco diferente do MVC da Apple.

Image without description

Cacau MVC O Controlador é um mediador entre a Visualização e o Modelo para que eles não se conheçam. O menos reutilizável é o Controlador, já que devemos ter um lugar para toda aquela lógica de negócios complicada que não se encaixa no Modelo .

MVC da Apple

Realistic Cocoa MVC Cocoa MVC incentiva você a escrever controladores de visualização massiva , porque eles estão tão envolvidos no ciclo de vida de visualização que é difícil dizer que são separados. Embora você ainda tenha a capacidade de descarregar parte da lógica de negócios e da transformação de dados para o Modelo, você não tem muita escolha quando se trata de descarregar trabalho para a Visualização, na maioria das vezes, toda a responsabilidade da Visualização é enviar ações para o controlador . O controlador de visualização acaba sendo um delegado e uma fonte de dados de tudo, e você pode deixa-los responsável por despachar e cancelar as solicitações de rede.

Image without description

A View configurada diretamente com o Model , então as diretrizes do MVC são violadas, mas isso acontece o tempo todo, e geralmente as pessoas não acham que está errado. Se você seguir estritamente o MVC, deverá configurar a célula a partir do controlador e não passar o modelo para a visualização , o que aumentará ainda mais o tamanho do seu controlador .

Cocoa MVC não é abreviado como o Controlador Massive View. E podemos ter um problema que pode não ser evidente até que chegue ao Teste de Unidade . Uma vez que seu controlador de visualização está fortemente acoplado com a visualização, torna-se difícil testar porque você tem que ser muito criativo ao simular visualizações e seu ciclo de vida, ao escrever o código do controlador de visualização de tal forma que sua lógica de negócios seja separada tanto quanto possível a partir do código de layout de visualização.

Mas vamos avaliar o Cocoa MVC em termos de características definidas no início do artigo:

Distribution - a View e o Model de fato separados, mas a View e o Controller estão fortemente acoplados.

Testabilidade - devido à má distribuição, você provavelmente só testará seu modelo. Facilidade de uso - a menor quantidade de código entre outros padrões. Além disso, todos estão familiarizados com ele, portanto, é facilmente mantido, mesmo por desenvolvedores inexperientes.

Se Cocoa MVC é o padrão de sua escolha, e você não está pronto para investir mais tempo em sua arquitetura e sente que algo com custo de manutenção mais alto é um exagero para seu projeto de estimação minúsculo.

Mas podemos dizer que o Cocoa MVC é o melhor padrão arquitetônico em termos de velocidade de desenvolvimento.

MVP

No MVP a View está fortemente acoplado ao Controller, enquanto o mediador do MVP, Presenter, não tem nada a ver com o ciclo de vida do view controller, não há código de layout no Presenter , mas ele é responsável por atualizar a View com dados e estado.

Image without description

Se dissermos que o UIViewController é o View, em termos de MVP, as subclasses de UIViewController são, na verdade, as visualizações e não os apresentadores. Essa distinção fornece testabilidade excelente, o que tem o custo da velocidade de desenvolvimento, porque você tem que ter dados manuais e associação de eventos.

Vejamos os recursos do MVP: Distribuição - tem a maior parte das responsabilidades divididas entre o MVP no iOS, excelente testabilidade e muito código.

MVP Com Bindings e Hooters Existe outro ponto do MVP - o MVP do Controlador de Supervisão. Esta variante inclui vinculação direta da Visualização e do Modelo enquanto o Presenter (O Controlador de Supervisão) ainda lida com ações da Visualização e é capaz de alterar a Visualização .

MVVM O mais recente e o melhor dos MV(X)'s, em teoria, o Model-View-ViewModel parece muito bom. A View e o Model já são familiares para nós, mas também o Mediador, representado como o View Model.

MVVM É muito semelhante ao MVP: o MVVM trata o controlador de visualização como o View Não há um acoplamento forte entre a vista e o modelo Além disso, ele faz ligações como a versão de supervisão do MVP; entretanto, desta vez não entre a vista e o modelo , mas entre a vista e o modelo de vista . Então, qual é o modelo de visualização na realidade do iOS? É basicamente uma representação independente do UIKit de sua Visualização e seu estado. O View Model invoca mudanças no Model e se atualiza com o Model atualizado , e uma vez que temos uma ligação entre View e View

Image without description

Model , o primeiro é atualizado de acordo.

Bindings As vinculações vêm prontas para o desenvolvimento do OS X, mas não as temos na caixa de ferramentas do iOS. Claro que temos o KVO e as notificações, mas eles não são tão convenientes quanto as ligações. Portanto, desde que não queiramos escrevê-los nós mesmos, temos duas opções: Uma das bibliotecas de ligação baseadas em KVO, como RZDataBinding ou SwiftBond As bestas de programação reactive funcional em escala real , como ReactiveCocoa , RxSwift ou PromiseKit . Se você ouve “MVVM” - você pensa em ReactiveCocoa, e vice-versa. Embora seja possível construir o MVVM com as ligações simples, ReactiveCocoa permitirá que você obtenha a maior parte do MVVM.

Testabilidade - o View Model não sabe nada sobre a View , isso nos permite testá-la facilmente. O modo de exibição também pode ser testado, mas como é dependente do UIKit, você pode querer ignorá-lo.

Fácil de usar - O MVVM é muito atraente, pois combina os benefícios das abordagens citadas e, além disso, não requer código extra para as atualizações do View devido aos bindings do lado do View. No entanto, a testabilidade ainda está em um bom nível.