Extreme Programming: práticas.

Extreme Programming possui um conjunto de cinco valores: comunicação, simplicidade, feedback, coragem e respeito, partindo desses valores, apresentados anteriormente. Eles servem como base para criação das doze práticas. Essas práticas já são utilizadas na indústria de software a décadas em seus projetos, e com eficiência. Essas práticas foram desenvolvidas para que sua utilização e avaliação fosse coletiva, afim de reduzir possíveis inconsistências, caso fossem aplicadas de forma individual.

• Jogo do Planejamento: Seu objetivo é determinar rapidamente o escopo da próxima Release, combinando prioridades do negócio e estimativas técnicas. Portanto no XP planejamos o tempo todo, diferente do que alguns pensam. Com um cliente presente ele define o escopo para a próxima Release. Dessa forma, define-se as features, prioridades e o escopo da release.
  Os desenvolvedores irão definir estimativas, consequências técnicas de adotar determinadas plataformas ou componentes (por exemplo, os programadores podem dizer que determinado componente dá muito problema e seria mais adequado utilizar um componente pago que economizará muito tempo), e por fim os desenvolvedores também ajudam no detalhamento de prazos para as atividades. Por fim, mantemos o plano atualizado sempre que houver um novo “toque de realidade” no projeto como algum imprevisto ou algo desejável que não contava-se que iria acontecer, ou qualquer outra coisa que possa afetar o plano atual.
• Teste: é uma pratica bastante técnica, e envolve a presença do cliente no desenvolvimento e na validação de testes. Cada componente do sistema deve possuir testes de unidades, afim de se ter confiança no comportamento do sistema, fazendo com que seja parte do próprio sistema. Existem também casos em que os testes de unidades são desenvolvidos antes mesmo do próprio código do trabalho real, também chamado de Test-Driven.
  Teste automatizado é a prática que sustenta e viabiliza muitas outras práticas como Integração contínua, Projeto Simples, Versão Pequena, Refatoração, e Propriedade Coletiva.
• Programação em pares: há literalmente uma programação em dupla, dois desenvolvedores utilizando-se de uma mesma máquina, ela tende a melhorar a qualidade do código produzido, mas sem afetar em sua velocidade de desenvolvimento. Outro fator, é que está prática tende a melhorar também a comunicação entre todos os membros da equipe, principalmente quando estes pares se alteram com frequência, ou todos os dias. Um dos critérios para definir os pares, não é só a sua disponibilidade, mas também deve ser levado em consideração a experiência de cada pessoa. Por exemplo, quando se necessita desenvolver algo que necessite da utilização de duas tecnologias, como interface Web e banco de dados, haverá dois integrantes, cada um experiente em uma área necessária.
• Projeto Simples: Projetos flexíveis são considerados uma defesa contra mudanças imprevistas no software, porém, projetos flexíveis também têm custos, tempo para desenvolvimento e manutenção, além de um código mais complexo e que muitas vezes nunca será utilizado.
  O XP preconiza que a mudança é barata, pois ele utiliza ciclos curtos, projetos simples, refatorações, por isso mantém-se o projeto o mais simples possível, modificando-o quando for necessário suportar mais funcionalidade. Portanto, o XP diz que o melhor e mais simples projeto é aquele que passa em todos os testes, não contém duplicação de funcionalidade, salienta as decisões de projeto importantes e tem o menor número possível de classes e métodos.
• Refatoração: significa melhorar o código sem alterar sua funcionalidade. Antes de uma mudança sempre refatoramos o código para facilitar a realização de mudanças. Ou seja, se após a refatoração o código continua funcionando como anteriormente, incluímos as novas mudanças. A refatoração contínua possibilita manter um bom projeto, apesar das mudanças frequentes. O Projeto é uma atividade diária, de responsabilidade de todos. A refatoração provê um aumento contínuo de qualidade do código.
• Propriedade Coletiva: Todos podem modificar o código a qualquer momento. Códigos não pertencem a apenas uma pessoa. A melhor forma de evitarmos problemas como trocas de pessoas da equipe e com isso a perda de conhecimento é a propriedade coletiva, onde todos mexem em todas as partes do programa e conhecem de tudo um pouco.
• Integração Contínua: Todo código deve ser integrado diariamente e todos testes devem passar antes e depois da integração. Se algum problema é encontra do ele deve ser corrigido imediatamente.
• Cliente presente: Clientes devem estar presentes para escrevem testes de aceitação, definirem prioridades e histórias para as futuras iterações. Estando sempre disponível afim de responder possíveis perguntas. Não importando o que venha a ocorrer com o projeto, nunca haverá para o cliente uma grande surpresa, se o mesmo estiver presente no desenvolvimento diariamente.
• Semana de 40 horas, é uma prática muito importante, pois deve-se respeitar o ritmo de trabalho que se pode sustentar, sem prejudicar os integrantes, no caso, 40 horas semanais. Uma equipe desgastada fisicamente e intelectualmente, possui grandes chances de produzir um software de baixa qualidade. Caso seja necessário fazer horas extras, essa condição é aceitável, contanto que não se torne uma rotina. Este pode ser um sinal de que pode haver algo errado com o projeto.
• Padrões de Codificação: Todos mexem em todos os códigos, todos refatoram e todos trabalham em pares. Assim é interessante mantermos um padrão para termos algo solidificado. Por isso a melhor forma é a equipe definir um padrão de codificação sempre no início dos projetos. Tendo em vista esta questão, todos os integrantes possuirão a mesma visão diante do código. Isto permite que grupos de vários desenvolvedores, possam produzir um código consistente, e também facilita a sua devida comunicação.
• Metáfora: a sua função é melhorar a comunicação, tanto dentro da equipe, como para com o cliente. Uma linguagem comum que todos devem possuir. Por exemplo, ao invés de descrevermos como uma certa arquitetura funciona apenas comunicamos o seu nome e todos entendem o que um programador quis dizer.
• Reunião diária: é uma prática vinda do SCRUM em que todos fazem uma rápida reunião de pé para discutir o que foi feito no dia anterior, o que será feito no dia atual e se existe algum impedimento.

Tais práticas tendem a funcionar bem quando utilizadas em conjunto. Quando utilizadas uma de cada vez é perceptível os seus benefícios. Mas quando elas começam a ser usadas em conjunto, as melhorias são drásticas. Ainda mais quando existe uma interação entre as práticas.

Fontes: http://www.desenvolvimentoagil.com.br/xp/praticas/

http://blog.locaweb.com.br/artigos/metodologias-ageis/programacao-extrema-extreme-programming-ou-simplesmente-xp/

https://www.devmedia.com.br/introducao-ao-extreme-programming-xp/29249

https://www.devmedia.com.br/praticas-em-xp-extreme-programming/29330

http://www.redspark.io/metodologias-parte-2-xp-extreme-programming/

Como a técnica Pomodoro pode ajudar as metodologias ágeis

Figura 1 - Relógio de cozinheiro

     Muitas vezes estamos prestes a iniciar um projeto que aparentemente mostra-se complexo e trabalhoso, isto acaba nos desmotivando de uma tal forma a ponto de procrastinarmos quanto ao início daquele projeto. Projetos de software são exemplos de projetos que tendem a ter várias tarefas a serem concluídas, mas devido a quantidade de tarefas obrigatórias, interrupções e complexidade de algumas tarefas, os prazos nunca são cumpridos, e como consequência, os seus desenvolvedores ficam desmotivados, infelizes e a produtividade cai. 

   

     Técnica Pomodoro busca solucionar estes problemas. Criada por Francesco Cirillo em 1992, esta técnica busca aumentar a concentração e o foco em tarefas importantes, tarefas que,  quando concluídas, trarão uma recompensa de valor. Seu principal simbolo é o relógio de cozinha em forma de tomate (como este da Figura 1), tomate em italiano chama-se Pomodoro, daí o nome da técnica. Esta técnica é bem simples de ser implementada, basta ter em mãos uma caneta, uma folha de papel e um relógio de cozinheiro. 

Figura 2 -  Fluxo de trabalho do Pomodoro - Ilustração retirada do livro Pomodoro Technique Illustrated (2009). 

      A técnica funciona da seguinte forma: escreve-se no papel todas as tarefas que precisam ser concluídas durante o dia, depois escolhe-se uma das tarefas para ser feita primeiro (aquela que for julgada a mais importante), depois inicia-se o relógio com um tempo de 25 minutos. Durante este tempo não se fará outra coisa a não ser aquela tarefa que foi escolhida. Se ocorrer alguma interrupção durante a execução daquela tarefa, como uma tarefa secundária ou outras requisições, escreva na lista de tarefas como uma nova tarefa a ser feita, e então volte a sua tarefa principal. Ao tocar o alarme, imediatamente devemos para o que estiver sendo feito naquela tarefa e então fazemos uma pausa de 5 min, independente se esta tarefa tenha sido concluída ou não. Durante a pausa, precisamos relaxar a mente e tentar não pensar nas tarefas. Depois da pausa, nós podemos voltar a tarefa, caso esta não tenha sido concluída, ou podemos escolher outra para ser executada. E então refazemos todo o processo.

      O objetivo da Técnica Pomodoro não é o de completar tarefas, mas sim, manter o foco nas tarefas importantes a ponto de evitar perca de energia com atividades sem retorno, tudo isto de uma forma que diminua o stress e melhore a produtividade pessoal. 

      Como utilizar a Técnica Pomodoro junto com as metodologias ágeis?

      Depois de conhecer o Pomodoro, vocês devem ter notado uma singela semelhança entre a Técnica Pomodoro e as Metodologias Ágeis. E sim! O Pomodoro é uma  metodologia Ágil. Henrik Kniberg, um dos escritores do livro Pomodoro Technique Illustrated (2009), diz que a ela é similar a uma metodologia Ágil, como a Scrum e XP, mas a diferença entre elas é que a o Pomodoro é executado em um nível mais baixo ou "micro". As metodologias Ágeis focam em organizar a execução de blocos de incrementos de sistemas ou softwares que trarão maior valor ao produto ao final da iteração. Mas dentro de cada bloco é necessário que exista um gerenciamento de tarefas, onde são escolhidas as mais importantes para a entrega daquele bloco. 

Figura 3 - Pomello

       Existem vários aplicativos que utilizam a Técnica Pomodoro para melhorar a execução de projetos com metedologias Ágeis. O Pomello é um exemplo deles, este software é um contador que vincula-se a uma conta do Trello. Ele usa as tarefas do Trello como suas tarefas do Pomodoro. A cada intervalo de 25 min (ou outros intervalos), são anexadas na tarefas a quantidade de turnos que já foram executadas naquela tarefa. Isto pode ser útil para medir a complexidade de uma tarefa, bem como, saber a produtividade de uma pessoa ou equipe e ver o real tempo trabalhado no projeto.    

 
             E para concluir, este artigo apenas mostra um olhar geral sobre a Técnica Pomodoro, claro que a princípio pareça uma técnica muito engessada, mas uma qualidade que o autor Francesco Cirillo deixa bem claro é que, ao final de cada dia, você terá que analisar como foi o seu desempenho, e então, buscar adaptar a técnica ao seu modo de fazer as tarefas, isto quer dizer que você pode aumentar ou diminuir o tempo, pular pausas... o principal objetivo é que aumentar o seu foco nas tarefas e melhorar a sua produtividade de uma forma feliz e sem stress.



Fonte: Staffan Noteberg, Pomodoro Technique Illustrated, 2009.

Project Model Canvas: Uma ferramenta para Planejamento de Projetos (Parte 1)

Visando simplificar o trabalho do gerente de projetos, José Finocchio Jr. desenvolveu uma ferramenta robusta para gerenciamento de projetos, o Project Model Canvas (PMC). Apesar da robustez, a ideia é simplista e favorece a integração da equipe de trabalho. Segundo Finocchio, “É mais fácil pensar e planejar visualmente”. É justamente essa a proposta do PMC: ser uma ferramenta visual, construída pela equipe, a qual elimine a complexidade e a burocracia do planejamento de qualquer projeto.

Ele é ideal para ambientes que querem aprimorar sua capacidade de planejamento, mas que se caracterizam por inovação, alta dinâmica dos negócios e simultaneidade de projetos (tocados em paralelo), aos quais soluções rígidas e engessadas não se aplicam.

Project Model Canvas

O Project Model Canvas é uma metodologia robusta, porém simplista, de planejamento de projetos, a qual utiliza conceitos visuais da neurociência aliados a uma estrutura lógica de componentes que formam um plano de projeto. Tais componentes estão organizados em blocos de perguntas fundamentais (Por quê, O quê, Quem, Como, Quando e Quanto) integrados em consonância com a teoria que rege o gerenciamento de projetos.

Project Model Canvas e suas perguntas fundamentais.

Esses blocos de perguntas são formados pelos elementos fundamentais do plano, os quais compõem o modelo mental que permite visualizar todos os componentes e suas dependências em uma única página. É recomendável que o canvas seja construído sobre uma única folha de formato A1 e notas autoadesivas, os famosos post-its, com no máximo 140 caracteres por nota. Tal metodologia permite que o modelo seja modificado quantas vezes for necessário. Lembre-se, o plano é um artefato em constante evolução! No início do projeto, as incertezas são grandes e a imprevisibilidade é dominante. Durante o decorrer do projeto, mais informações são disponibilizadas e de forma mais precisa, assim o plano deve evoluir paralelamente.

Project Model Canvas e seus elementos fundamentais.

Dependências entre elementos fundamentais do PMC.

Essa publicação tem como intuito mostrar de uma forma geral o que é o PMC, na próxima publicação destrincharemos cada uma das áreas do PMC e como preenchê-las.

Fontes:

FINOCCHIO Jr., José. Project Model Canvas – Gerenciamento de Projetos sem Burocracia. Editora Campus, 2013.

http://pmcanvas.com.br/

http://www.projectbuilder.com.br/guia-definitivo-do-pm-canvas/

https://danielettinger.com/2015/07/13/project-model-canvas-a-alma-do-projeto/

Kanban: O que é e como funciona o método?

Figure 1 - Kanban.

O que é?

O sistema Kanban está baseado em referências visuais que estão atrelados aos produtos, lugares comuns, murais de produção ou até mesmo em computadores que utilizam uma espécie de método kanban eletrónico para funcionar. São utlizados cartões (post-its), com cores e tamanhos diferentes para definir e descrever as tarefas que precisam ser feitas, que estão sendo feitas e as já conluídas. É um sistema que visa aumentar a eficiência da produção e otimizar seus sistemas de movimentação, produção, realização de tarefas e conclusão de demandas.

Apesar de parecer simpels, o Kanban nasceu com uma ideia complexa de orientar a produção pelo cumprimento de tarefas complexas, e não pela movimentação do estoque. Foi desenvolvido pelos japoneses da Toyota dentro do modo de produção Just In Time (JIT), ou seja, o Kanban não é o JIT, mas sim, parte dele. É importante destacar isso, pois tanto o Kanban como outras técnicas  toyotistas do sistema JIT vieram para modificar uma produção que era puatada ainda pelo modesto fordista de produção, utilizado basicamente desde o começo do século XX em boa parte das plantas industriais de todo o planeta. 

Como funciona? 

O cartão kanban é responsável pela comunicação e pelo funcionamento de todo o sistema, nele devem estar contidos as informações mínimas para o bom funcionamento da linha de produção. Sendo necessário, ele poderá conter um número maior de informações, desde que sejam importantes para a área específica, onde se pretende implementar o sistema kanban.

Um quadro Kanban é uma ferramenta que ajuda a visualizar o fluxo de trabalho de qualquer projeto. Ele fornece alto nível de transparência, permitindo que todos entendam o status de um projeto com um simples olhar.

Esses quadros e cartões visuais integram o sistema Kanban, que ajudam os trabalhadores a planejarem a produção na indústria e a controlar o estoque. Assim, conforme a quantidade de cartões disponíveis nos quadros são tomadas decisões, priorizando o que é mais importante, realizando setup de máquinas e até mesmo as paradas para manutenção.

Existem dois tipos de Kanban - o de produção e o de movimentação. Kanban de Produção informa a um processo fluxo acima qual tipo e em que quantidade o produto deve ser produzido para atender a um processo fluxo abaixo. Geralmente colocam se murais contendo cartões (post-its) em um espaço que possa ser visualizado por todos os funcionários resposáveis por desempenhar ações naquela linha de produção. Os murais costumam ser dividos em três seções: To do (por fazer), Doing (fazendo/em execução) e Done (feito/concluído). Mais divisões podem ser inseridas no mural para adequar com necessidade de cada projeto.

Figure 2 - Kaban de Produção.

O Kanban de Movimentação, também denominado ainda de Kanban de Transporte, notifica os diversos setores de produção de uma linha para quando realizar determinada ação ou quando esperar pela próxima ordem. Os cartões são afixados nos produtos, geralmente, o cartão de movimentação é afixado em substituição ao cartão de produção, e levados a outro processo ou local, onde são retirados e voltam à etapa inicial.

Figure 3 - Kanban de Movimentação.

Vídeo de explicação abaixo:

Fonte:

https://www.industriahoje.com.br/o-que-e-kanban
https://pt.wikipedia.org/wiki/Kanban
http://www.leanti.com.br/conceitos/9/O-que-e-Kanban.aspx
https://www.citisystems.com.br/kanban-conceito-sistema-o-que-e-on-line/