Plano de Projeto de Software para o desenvolvimento do SIGE (Sistema de Gerenciamento de Eventos)

Nossa última postagem apresenta o documento o Plano de Projeto de Software para produtos da Lacertae SW, desenvolvido na matéria de Gerência de Projetos do Departamento de Computação da UFS em 2017.2, ministrada pelo Prof. Doutor Rogério P. C. do Nascimento.
 

Plano de Projeto de Software para o desenvolvimento do SIGE (Sistema de Gerenciamento de Eventos) de Igor Costa

Os processos básicos do FDD (Feature Driven Development)

Como mencionado anteriormente, Jeff Luca foi o criador da FDD. Ele propôs uma solução que é uma mistura de 5 processos que abrangem: o desenvolvimento do modelo, sua listagem, design, planejamento e a implementação de das funcionalidades. Para facilitar o entendimento do FDD, o próximo post irá descrever os 5 processos básicos de FDD.

1º processo: desenvolvimento de um modelo geral

Neste primeiro processo, o FDD empurra equipes para construir um modelo de objeto do problema de domínio. Diferentemente de outras metodologias, a modelagem no FDD é uma atividade multifuncional, iterativa e colaborativa. Os membros da equipe (desenvolvimento, especialistas em domínio e programadores-chefe) trabalham juntos para compor um modelo para a área do domínio e são guiados por um arquiteto-chefe.

A ideia é ter equipes diferentes propondo modelos diferentes e, mais tarde, depois de serem revisados, seja escolhido uma opção de modelo ou misture-os. Finalmente, o modelo de área do domínio será incorporado no modelo geral. O resultado é um modelo de objetos (e/ou de dados) de alto nível, que guiará a equipe durante os ciclos de construção.

Essa forma de concepção é uma ótima maneira de iniciar o projeto, pois permite que a equipe obtenha uma sólida compreensão do projeto, bem como uma comunicação sólida.

2º processo: criando a lista de recursos

Nesse processo a lista de funcionalidades pode ser comparada com o backlog do produto no scrum, e as funcionalidades seriam algum tipo de história de usuário. Depois de ter o modelo geral pronto, com base no conhecimento obtido durante essa fase, teremos que identificar as funcionalidades que são mais importantes para o cliente e que deverão guiar o projeto. As funcionalidades não devem levar mais do que duas semanas para serem concluídos e, se o fizerem, devem ser colocados em mais de uma funcionalidade. Elas geralmente são expressas como uma ação, resultado e objeto. O resultado desse processo é uma hierarquia de funcionalidades que representa o produto a ser construído (também chamado de product backlog, ou lista de espera do produto).

 3º processo: planejando por funcionalidade

O terceiro processo, é mais ou menos sobre o planejamento em que ordem as funcionalidades serão implementadas, trata-se de organizar. Os conjuntos de tarefas que são atribuídas aos programadores. Também deve ser levado em consideração a prioridade e valor para o negócio/cliente. O resultado desse processo é um plano de desenvolvimento, com os pacotes de trabalho na sequência apropriada para a construção.

Obviamente, durante o planejamento, levamos em consideração aspectos diferentes, como riscos, dependências de complexidade, carga de trabalho da equipe, etc.

4º processo: detalhando por funcionalidade

Como durante todos os processos, utilizamos o conhecimento que recebemos do primeiro processo de modelagem. O programador chefe assume a responsabilidade de selecionar um grupo de funcionalidades que devem ser desenvolvidos a seguir. Ele também terá que determinar as classes de domínio que serão envolvidas. Depois que o grupo de funcionalidades for definido, todos começam a trabalhar juntos para fazer o trabalho, onde o especialista em domínio será responsável por analisar e projetar uma solução para cada funcionalidade. O resultado desse processo é o modelo de domínio mais detalhado e os esqueletos de código prontos para serem preenchidos.

5º processo: construindo por recurso

Com base no trabalho realizado no processo de detalhamento da funcionalidade, os responsáveis pela classe atribuída na tarefa, terão de implementar todos os itens que são necessários para suportar os detalhes da funcionalidade. Dessa forma, trabalhamos no código que foi desenvolvido, realizamos testes unitários e inspeções de código para garantir que tudo esteja correto e seja aprovado pelo programador-chefe que dará o aval para sua entrega ao cliente. O resultado desse processo é um incremento do produto integrado ao repositório principal de código, com qualidade e potencial para ser usado pelo cliente/usuário.

Fonte: https://apiumhub.com/tech-blog-barcelona/feature-driven-development/
https://pt.wikipedia.org/wiki/Feature_Driven_Development
https://imasters.com.br/artigo/13370/agile/fdd-um-metodo-agil-e-eficiente/

O que é Feature Driven Development(FDD)?

O lema do FDD é "Resultados frequentes, tangíveis e funcionais".

Em tradução livre: Desenvolvimento Guiado por Funcionalidades, é uma das seis metodologias ágeis originais do desenvolvimento de software. Essa metodologia situa-se numa posição intermediária entre as abordagens mais prescritivas (Processo Unificado, Cascata tradicional - Waterfall) e as abordagens Ágeis (XP - Programação Extrema, Scrum, Crystal, etc.).

O FDD foi criado por Jeff De Luca, um gerente de projetos australiano, no final da década de 90. Quando ele estava tentando fornecer uma solução de desenvolvimento de software para um grande projeto em Java para o United Overseas Bank em Singapura, entre 1997 e 1999, a partir do Método Coad (uma metodologia completa para Análise, Desenho e Programação Orientados por Objetos, desenvolvida por Peter Coad nas décadas de 1980 e 1990) e das técnicas de gerenciamento iterativo, incremental e enxuto de projetos.

A primeira descrição oficial dos processos foi publicada no livro "Java Modeling in Color with UML", por Peter Coad, Eric Lefebvre e Jeff De Luca, em 1999.

O FDD é um processo de desenvolvimento, que assim como todas as metodologias ágeis, é iterativo e incremental com o objetivo de entregar software funcional e que agregue valor para o cliente. Misturando as melhores práticas com o objetivo de focar no que é importante para o cliente. Isso significa que os desenvolvedores se concentram nos recursos que o cliente valoriza, as funcionalidades que eles esperam e precisam.

No FDD, as funcionalidades são tão importantes quanto as histórias de usuários são para Scrum. Já que elas ajudam os desenvolvedores no planejamento de seus trabalhos.

O FDD chama a atenção por algumas características:

• Propõem entregas de resultados úteis a cada duas semanas ou menos
• Utilização de blocos bem pequenos de funcionalidade valorizada pelo cliente, chamados “Features”
• Planejamento detalhado e guia para medição
• Oferecer rastreabilidade e relatórios com precisão
• Monitoramento detalhado dentro do projeto, com resumos de alto nível para clientes e gerentes, e até sugere a utilização da documentação como forma de comunicação dentro da equipe de desenvolvimento.
• Fornece uma forma de saber, dentro dos primeiros 10% de um projeto, se o plano e a estimativa são sólidos

O site oficial da metodologia é http://www.featuredrivendevelopment.com, incluindo um fórum de discussão onde as pessoas podem aprender mais sobre o tema.

Fonte: https://apiumhub.com/tech-blog-barcelona/feature-driven-development/

https://pt.wikipedia.org/wiki/Feature_Driven_Development

http://heptagon.com.br/fdd/fdd-oque/

https://imasters.com.br/artigo/13370/agile/fdd-um-metodo-agil-e-eficiente/

Time Scrum e suas peculiaridades

                     Time Scrum. Fonte: Bruno Barros

O Time Scrum é uma equipe de pessoas que estão juntas para atingir um objetivo em comum através do Framework Scrum. Ele é composto por um Product Owner, o Time de Desenvolvimento e um Scrum Master.  O modelo do Time Scrum foi projetado para otimizar a flexibilidade, a criatividade e a produtividade. Times Scrum intregam produtos de forma iterativa e incremental, maximizando o feedback dos seus clientes. Desta forma temos sempre uma atualização disponível daquele produto.

O Product Owner

O Product Owner é responsável por maximizar o valor do produto que é entregue pelo Time de desenvolvimento. Como isto é feito pode variar de acordo com a organização, time ou indivíduo.

Ele é uma pessoa e não um grupo. Suas decisões podem representar os ideais de um grupo, mas as responsabilidades, por exemplo a de gerenciamento do Backlog, são vinculadas somente ao Product Owner. 

Para que o Product Owner tenha sucesso, suas decisões devem ser respeitadas. Suas decisões devem estar visíveis por todos os envolvidos através do Product Backlog. Ninguem pode forçar o Time de Desenvolvimento a trabalhar em outros requisitos além dos que foram definidos pelo Product Owner.

Como o Product Owner é uma pessoa que gerencia o Product Backlog, eis aqui algumas das suas funções de gerenciamento:

-   Explicar claramente cada Item do Product Backlog;

-   Organizar os itens do Backlog para melhor atingir os objetivos e missões;

-   Otimizar o valor do trabalho executado pelo time de desenvolvimento;
-   Garantir que o Product Backlog esteja visível, transparente e claro para todos, e mostre o que será trabalhado mais adiante;
-   Garantir o entendimento dos itens do Product Backlog no nível necessário;

O Product Owner pode delegar as atividades mencionadas acima para o time de desenvolvimento, mas ele continua sendo o responsável por elas.

O Scrum Master

O Scrum Master é um servente-líder que possuí a responsabilidade de promover e dar suporte do Scrum para todo o Time Scrum. É ele quem leva a todos à entenderem a Teoria do Scrum, práticas, regras e valores. O Scrum Master ajuda aos que estão fora do Time Scrum a entenderem como devem interagir com o Time Scrum. Ele promove a mudança nas interações para maximizar o valor do produto criado ao final da Sprint.

O Scrum Master trabalha para o Product Owner de várias formas, eis algumas:

- Garantindo que todos do Time Scrum entendam as metas, escopo e produto da melhor forma possível;

- Encontrar técnicas para o efetivo gerenciamento do Product Backlog;

- Ajudar o Time Scrum a entender a necessidade de itens claros e concisos do Product Backlog;

- Compreender o planejamento do produto em um ambiente empírico;

- Garantir que o Product Owner saiba como organizar os itens do Product Backlog;

- Entender e praticar a agilidade;

- Facilitar a concretização dos eventos do Scrum conforme solicitado ou necessário;

O Scrum Master auxilia o Time de Desenvolvimento através de diversas maneiras, incluído:

-  Instruindo a equipe de desenvolvimento a ser auto-organizável e multifuncional;

- Ajudando a equipe de desenvolvimento a criar produtos de alto valor;

- Removendo impedimentos ao progresso da equipe de desenvolvimento;

- Facilitando eventos Scrum conforme solicitado ou necessários;

- Treinando o Time de Desenvolvimento em ambientes organizacionais em que Scrum ainda não está totalmente adotado e compreendido;


O Scrum Master auxilia a organização através das seguintes formas:

- Planejando implementações Scrum dentro da organização;

-  Ajudar os funcionários e as partes interessadas a compreender e promover o desenvolvimento de produtos Scrum;

- Criando mudanças que aumentam a produtividade do Time Scrum;

-  Trabalhando com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum na organização.

O Time de Desenvolvimento

O Time de Desenvolvimento é um grupo de pessoas que trabalham para entregar um incremento utilizável de um produto. O lançamento deste incremento deve ser mostrado durante a Sprint Review. Somente os integrantes do Time de Desenvolvimento é quem podem criar este incremento. O Time de Desenvolvimento deve ser capaz de gerenciar e organizar as o seu trabalho.

Quanto ao tamanho, é recomendável ter um time com três à nove pessoas. Com menos de três membros, a interação diminui e os ganhos em produtividade se tornam pequenos. Times de Desenvolvimento muito pequenos podem conter limitações de habilidades, isto leva a criação de um produto com pouca criatividade e qualidade. Tendo mais que nove membros, a complexidade de gerenciamento aumenta. Times muito grandes requerem um nível de gerenciamento de trabalho maior, sem contar que o controle dos processos empíricos se tornam impraticáveis. O Product Owner e o Scrum Master não fazem parte dentro do Time de Desenvolvimento.

O Time de Desenvolvimento possui as seguintes características:

- São auto-organizáveis. Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento como eles devem transformar o Product Backlog em um incremento lançável;

- São multi-funcionais. Ele possui todas as habilidades necessárias para a construção de um incremento lançável;

- Não reconhece títulos para membros do Time de Desenvolvimento. As pessoas não possuem títulos que denotem uma funcionalidade desempenhada naquela equipe; 

- Não reconhece subgrupos dentro do Time de Desenvolvimento, mesmo que estes estejam vinculados à tarefas específicas como testes, arquitetura, operações, análise de negócio e etc;

- Membros do Time de Desenvolvimento podem possuir habilidades específicas e áreas de especialização, mas a responsabilidade de entregar o incremento do produto é de todos.

Referências:

•  http://www.fabiocruz.com.br/valores-scrum/, acessado em 08/01/2018. 
•  Ken Schwaber and Jeff Sutherland, The Scrum Guide, 2017, Creative Commons. 
•  https://www.scrum.org/, acessado em 27/12/2017 
•  PRESSMAN, Roger S. Engenharia de Software, Oitava Edição. Editora MCGrawHill: Porto Alegre, 2016. 

Siles da Apresentação dos assuntos do DevFlash

Segue os slides apresentados pelo grupo 4 - DevFlash.

Apresentação de Metodologias Ágeis de desenvolvimento gp4 por Carlos Alberto

Framework para desenvolvimento ágil Scrum

Framework Scrum - Fonte:Scrum.org

Scrum é um framework de desenvolvimento de tarefas complexas, de forma adaptativa e focada em melhoria contínua do produto e em aumentar o seu valor. Ele foi criado em 1990 por Ken Schwaber e Jeff Sutherland. Sua primeira definição formal tornou-se pública em 1995, durante a conferência de OOPSLA.

Ken Schwaber (à esquerda) e Jseff Sutherland (à direita).

Ele foi criado para ser leve, simples de entender e difícil de dominar. O Scrum é um framework para processos e pode muito bem ser utilizado no dia a dia de uma equipe de desenvolvimento. Ele não é um processo, técnica ou uma metodologia definitiva, mas sim um framework onde você pode empregar vários processos e técnicas afim de torná-lo mais robusto e adaptado a realidade do seu projeto.

Jogada Scrum do Rugby

Seu nome vem de uma jogada executada em uma partida de Rugby. Essa jogada é utilizada para dar o reinício do jogo, que acontece geralmente após a ocorrência de uma penalidade. Cerca de oito jogadores se unem e empurram outros oito jogadores do time adversário, o objetivo é avançar o máximo possível para marcar pontos.

A filosofia do Scrum está fundada sobre o processo de controle empírico, isto é, na maioria das vezes evitamos o uso de planejamentos detalhados por métricas abusivas para dar lugar ao "colocar a mão na massa" só depois tirar conclusões acerca do que fora feito. O empirismo afirma que o conhecimento vem da experiência e da tomada de decisões baseadas naquilo que sabemos. O Scrum aproveita-se disso empregando uma abordagem incremental e iterativa para otimizar a predição de riscos a media que o processo evolui. 

Pilares do processo Scrum - Fonte: Scrum.org.

Três pilares sustentam a implementação do processo de controle empírico presente no Scrum. São eles: transparência, inspeção e adaptação. 

• A transparência torna todas as informações acerca do projeto claras e visíveis a todos os envolvidos. Isto pode ser feito através do uso de dicionários para termos e siglas muito utilizadas no processo ou compartilhar uma definição comum de "tarefa finalizada". 
• A inspeção dos artefatos do Scrum deve ser feita por todos, com o objetivo de avançar até a meta da entrega e então observar se estão surgindo desvios indesejáveis. Não é aconselhável que as inspeções sejam executadas a todo o momento. A melhor forma é que sejam feitas por inspetores experientes e de forma que não atrapalhem o desenvolvimento do time.
• A adaptação deve ocorrer quando é notado um desvio da meta, geralmente apontado pela inspeção. Caso um desvio ocorra, rapidamente ele precisa ser ajustado para minimizar problemas futuros. O Scrum fornece alguns eventos para adaptação como o Sprint Review e Sprint Retrospective.

Valores do Scrum - Fonte: Scrum.org

Com os pilares sobre o processo, torna-se um terreno fértil para dar origem aos cinco valores que devem ser empregados ao Time Scrum. O Time Scrum poem estes valores em prática a medida que aprendem e exploram os papéis, eventos e artefatos do Scrum. Os cinco valores são:

• Coragem: o Time Scrum deve ter a coragem de fazer o que é certo e não ter medo de errar, afinal, é isto que o empirismo prega, o erro deve ser encarado como um ponto para se aperfeiçoar e corrigir.
• Foco: todo o time deve estar focado em uma unica Sprint e um conjunto de metas fornecidos pelo Sprint Backlog.
• Comprometimento: as pessoas se comprometem a alcançar as metas do Time Scrum.
• Respeito: o time deve ser capaz de respeitar a cada membro independente de suas habilidades, papéis e experiências.
• Abertura: O Time Scrum e os seus stakeholders devem estar abertos a fornecerem as informações necessárias ao trabalho, como também, fazer parte do dia a dia de desenvolvimento.

Para concluir, vimos a definição do framework Scrum, que é muito utilizado para o gerenciamento de processos de desenvolvimento de software. Vimos que o Scrum trabalha sobre o modelo empírico de processo, onde as decisões são melhor tomadas a medida que vão solucionando os problemas. Abordei os três pilares do Scrum que são a transparência, Inspeção e adaptação. Como também conversamos sobre os cinco valores que o Time Scrum deve desenvolver durante o processo: Coragem, foco, comprometimento, respeito e abertura. Com isso espero ter dado uma visão introdutória ao Scrum de forma que fique bem clara sobre os seus objetivos e o porque este framework é tão utilizado no mundo de desenvolvimento de software.

Referências:

•  http://www.fabiocruz.com.br/valores-scrum/, acessado em 08/01/2018. 
•  Ken Schwaber and Jeff Sutherland, The Scrum Guide, 2017, Creative Commons. 
•  https://www.scrum.org/, acessado em 27/12/2017 
•  PRESSMAN, Roger S. Engenharia de Software, Oitava Edição. Editora MCGrawHill: Porto Alegre, 2016. 

Kanban vs Scrum

Figure 1 -  Kanban e Scrum

Scrum e Kanban são ferramentas de processo que, em certa medida, te ajudam a trabalhar de maneira mais eficaz, dizendo a você o que fazer. Java também é uma ferramenta, ela lhe fornece uma maneira mais simples de programa. 

Como quaisquer ferramentas, Scrum e Kanban não são perfeitos nem tampouco completos. Eles não lhe dizem tudo o que você precisa fazer, eles apenas lhes oferecem algumas restrições e orientações. Por exemplo, Scrum lhe restringe a ter iterações de tempo fixo e equipes multifuncionais, enquanto que Kanban lhe restringe a utilizar quadros visíveis e limitar o tamanho de suas linhas de produção. 

Podemos comparar ferramentas analisando quantas regras elas oferecem. Prescritivo significa “mais regras a seguir” e adaptativo significa “menos regras a seguir”. Prescritivo 100% significa que você não precisa usar seu cérebro, já há regra para tudo. Adaptativo 100% significa faça qualquer coisa, não existe nenhum tipo de regras ou restrições. Como podemos ver, os dois extremos da escala acabam se tornando ridículos.

Scrum e Kanban são ambos altamente adaptativos, mas falando relativamente, Scrum é mais prescritivo que Kanban. Scrum lhe dá mais restrições, por conta disso, deixa menos opções abertas. Por exemplo, o Scrum prescreve o uso de iterações de duração fixa, o Kanban não.

Kanban deixa quase tudo em aberto. As únicas restrições são: Visualize Seu Fluxo de Trabalho e Limite Suas Atividades em Andamento. Apenas a alguns centímetros de Faça Qualquer Coisa, mas ainda assim surpreendentemente poderoso.

Scrum ou Kanban?

Assim como o Scrum, o Kanban é centrado no valor entregado: as pessoas da equipe têm uma certa autonomia sobre suas responsabilidades, e essencialmente eles têm a mesma missão, que é continuamente eliminar desperdícios e remover obstáculos.

Kanban e Scrum compartilham alguns dos mesmos conceitos, mas têm diferentes abordagens. Eles não devem ser confundidos um com o outro. O quadro abaixo separa algumas diferenças que eles possuem.

Figure 1 - Diferenças Scrum x Kanban

O Kanban e o Scrum não são necessariamente relacionados para serem comparados, e nem são excludentes. Seus objetivos são complementares, e para uma melhor otimização muitas vezes eles são adotados juntos.

Algumas equipes misturaram os ideais do Kanban e scrum para o "scrumban." Eles tomam os sprints de extensão fixa e as funções a partir do scrum, e o foco nos limites de trabalho em progresso e tempo de ciclo a partir do Kanban. Porém, para as equipes que acabaram de começar com o agile, é altamente recomendável escolher uma metodologia ou outra e usá-la por um tempo. Você sempre pode iniciar aquela que for ideal mais tarde.

Referências:

https://www.infoq.com/br/minibooks/kanban-scrum-minibook#minibookDownload

https://br.atlassian.com/agile/kanban

http://blog.aspercom.com.br/2014/09/05/scrum-kanban-por-onde-comecar/

Kanban: Ferramentas Online para a gestão de projetos

Figure 1 - Quadro Virtual

Kanban, como foi explicado em um poste anterior, é uma metodologia de gestão de trabalho focada no conceito de “just in time” – bem a tempo – onde procurasse priorizar tarefas e organizar a fluxo de trabalho de uma forma mais produtiva. Ele é tradicionalmente feito com o uso com quadros físicos e blocos post-it. Para muitos, o quadro física ainda é mais atraente por servir como um lembrete constante a todos do trabalho que está sendo feito e de seu papel na equipe.

Embora os quadros físicos sejam populares entre algumas equipes, os quadros virtuais são um recurso crucial em qualquer ferramenta de desenvolvimento ágil de software para sua rastreabilidade, colaboração mais fácil e acessibilidade de vários locais.

Independentemente de o quadro de uma equipe ser físico ou digital, sua função é assegurar que o trabalho da equipe seja visualizado, que seu fluxo de trabalho seja padronizado e que todos os bloqueadores e dependências sejam imediatamente identificados e resolvidos

Abaixo listamos algumas principais ferramentas digitais que se baseiam no sistema Kanban. Alguns podem ser bem conhecidas por vocês, outras nem tanto, porém vale a pena conferir outras opções e analisar qual sistema é mais indicado para a sua equipe.

Backlogged

Figure 2 - Backlogged

O Backlogged oferece um sistema Kanban online para gestão de projetos especialmente desenhado para desenvolvedores freelancer e pequenas equipes. Cada projeto recebe um quadro único, onde cartões representam tarefas que podem ser incluídas e movimentadas livremente.

O sistema Kanban do Backlogged conta com quatro colunas: “Pendente”, “Aguardando”, “Executando” e “Concluído”. Cada tarefa – ou história – é representada por uma etiqueta.
Todas as tarefas que ainda não foram iniciadas ficam agrupadas na primeira coluna. As tarefas que estão congeladas ficam na próxima. As que estão sendo trabalhadas na coluna executando e as finalizadas na última.

O sistema Kanban online do Backlogged também permite cooperar com outros membros da equipe. As tarefas possuem estimativas de data, horas de produção e podem ser associadas a pontos de história, para quem usa a metodologia SCRUM. É um dos poucos sistemas Kanban que permite uma fácil associação de pontos sem forçar uma metodologia específica.

Figure 3 - Estimar Tempo de Produção

Para quem quer simplificar, a ferramenta ainda ajuda na estimativa de tempo de produção utilizando um contador de esforço inspirado nas metodologia ágeis, com 6 estimativas pré-programadas que vão de 30 minutos a 16 horas. No modo avançado, as horas e pontos são de inserção livre.
O mais legal do Backlogged é que ele se adequa à forma como você trabalha. E mesmo quem é iniciante no sistema Kanban consegue se entender com a interface amigável e intuitiva.

Preço: R$ 39/mês até 3 usuários.

Vantagens:

• Intuitivo e com um layout de fácil compreensão;
• Integração para equipes com fácil visualização das próximas tarefas;
• Integração entre etapas do projeto e gestão de orçamento;
• Único sistema Kanban online que possui opção de atribuir pontos nas tarefas para uso com metodologias ágeis;
• Layout responsivo funciona bem em celulares e tablets.

Limitações:

• Não é possível adicionar novas colunas ou regras;
• Não está disponível um aplicativo mobile, apesar de ser acessível pelo celular.

Trello

Figure 4 - Trello

O Trello tem como proposta “organizar tudo”. É um sistema Kanban online que não é específico para negócios e busca ajudar pessoas a organizar melhor, desde o projeto da escola até a reforma da casa.

O sistema Kanban do Trello vem com algumas colunas de exemplo e permite criar novas conforme a faça sentido em cada projeto. É preciso um pouco de criatividade mas, quando bem usada, é uma ferramenta muito útil.

As tarefas, os cartões do sistema Kanban, ficam dispostas nas colunas e podem ser movidas livremente. Cada tarefa pode estar associada a certos participantes e ter identificações por cores.

O layout é agradável e funciona bem em telas grandes. O Trello ainda possui aplicativos para Android e iOS para acompanhar seu sistema Kanban de qualquer lugar.

Preço: Gratuito com versão paga disponível por U$5,00 por usuário/mês e permite maior customização.

Vantagens:

• Flexibilidade e layout agradável;
• Associação de arquivos com cartões.

Limitações:

• Não é focado em negócios e não permite uma visualização do esforço de tarefas;
• Não permite adicionar regras para as colunas.

KanbanFlow

Figure 5 - KanbanFlow

O KanbanFlow é um software Kanban online para profissionais que permite maior flexibilidade na organização das colunas, tarefas e regras de fluxo de cartões.

As tarefas podem receber cores e estar associadas a participantes de cada projeto. Os participantes podem marcar que estão trabalhando em uma tarefa e acompanhar seu tempo gasto com um cronômetro embutido.

A interface é razoavelmente intuitiva mas peca um pouco em usabilidade. As vezes se mostra um pouco engessada e é difícil localizar algumas funções. Entretanto, é muito completo em termos de personalização.

Preço: R$ 15,00 por usuário/mês com versão gratuita disponível.

Vantagens:

• Implementação de restrições e regras nas colunas;
• Cronômetro de tarefas.

Limitações:

• Visual engessado e nem sempre muito intuitivo;
• A visualização é prejudicada quando há muitas tarefas ou participantes.

Referências:

http://backlogged.com.br

https://trello.com

https://kanbanflow.com

Industrial XP

No final da década de 1990, três visionários de software chamado Kent Beck, Ward Cunningham e Ron Jeffries foram pioneiros da Extreme Programming (XP), um processo de software ágil que mudou a forma como o mundo planeja, testa, constrói e entrega software.

Desde então o desenvolvimento ágil vem se tornando uma alternativa viável para o uso em equipes de desenvolvimento de diversos tamanhos e tipos de organizações, logo a lógica industrial e outros líderes de XP e Ag    ile evoluíram para XP em diversas indústrias, e essa evolução trouxe a criação de uma nova vertente, o XP industrial surgiu como resultado. É nada mais que o XP inserido no DNA de uma organização.

Segundo Joshua Kerievsky , pioneiro no desenvolvimento do XP, “A IXP é uma evolução orgânica da XP. Ela é imbuída do mesmo espirito minimalista, centrado no cliente e orientado a testes da XP. Difere da XP original principalmente por sua maior inclusão do gerenciamento, por seu papel expandido para os clientes e por suas práticas técnicas atualizadas ”.

Para que o IXP funcione com sucesso em projetos de larga escala em grandes organizações, são necessárias a inclusão de seis novas práticas para auxiliar no funcionamento do projeto.

• Avaliação imediata: a equipe IXP verifica se todos os membros da comunidade de projeto estão a bordo, tem o ambiente correto estabelecido e entendem os níveis de habilidade envolvidos.
• Comunidade de projeto: a equipe IXP determina se as pessoas certas com as habilidades certas e o treinamento corretos, estão prontos para o projeto.
• Mapeamento do projeto: a própria equipe IXP avalia o projeto para determinar se ele se justifica em termos de negócios e se vai ultrapassar as metas e objetivos globais da organização.
• Gerenciamento orientado a testes: a equipe EXP estabelece uma serie de “destinos” mensuráveis que avaliam o progresso até a data e, então, define mecanismos para determinar se estes foram atingidos ou não.
• Retrospectivas: uma equipe IXP conduz uma revisa técnica especializada após a entrega de um incremento de software. Denominada retrospectiva, a revisão examina “problemas, eventos e lições aprendidas” ao longo do processo de incremento de software e/ou do desenvolvimento da versão completa do software.
• Aprendizagem continua: a equipe IXP é estimulada a aprender novos métodos e técnicas que possam levar a um produto de qualidade mais alta.

O IXP também modifica várias práticas XP existentes e redefine certas funções e responsabilidades para torna-las mais receptivas em projetos importantes de grandes organizações.

Fontes:
PRESSMAN, Roger S. Engenharia de Software, Oitava Edição. Editora MCGrawHill: Porto Alegre, 2016.
http://industrialxp.org/

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/