Porque você deve usar um software com Kanban para gerenciar sua equipe?

Kanban

Porque você deve usar um software com Kanban para gerenciar sua equipe?

Michelly Oliveira   10:13:00

Autora: Juliana Sampaio

Os ganhos que uma empresa obtém ao adotar uma metodologia ágil de gerenciamento de projetos com o uso da ferramenta Kanban são vários. Não é a toa que o 1º princípio do Manifesto Ágil é “Indivíduos e interação entre eles mais que processos e ferramentas”. As empresas que valorizam os indivíduos mais do que processos, atraem colaboradores motivados e inovadores. Mas nem tudo são flores, o gerente de projetos deve ter atenção redobrada em manter a equipe motivada e organização nestes ambientes mais livres.

Neste artigo vamos aprofundar nos ganhos que essa mudança traz para a sua equipe de gerenciamento de projetos, e eles são muitos. Veja a seguir:

 Maior controle das atividades

Quando você gerencia uma equipe utilizando um software com Kanban, delegar tarefas fica muito mais fácil, já que a caráter visual dessa ferramenta permite um maior controle sobre o que ainda precisa ser feito e a quantidade de atividades que cada colaborador já está desempenhando.

Outra vantagem é desse sistema é que o gerente de projetos consegue acompanhar o andamento das tarefas de forma mais fácil, com notificações sobre atrasos e gargalos.

Com a adoção do kanban, gerenciar vários projetos fica bem mais simples, pois cada um gera o seu quadro, o que facilita bastante a vida do gerente.

Melhora a Comunicação

Ao usar uma ferramenta on-line dessas, o feedback dos colaboradores é imediato. E em empresas que usam a metodologia ágil, feedback constante é fundamental. As interações na equipe também evoluem muito quando o kanban é usado. Quer mais dicas para melhorar a comunica~ção da equipe? Então esse e-book é leitura obrigatória!

Gerenciamento de Prazos

Usando essa ferramenta, o gerente consegue definir melhor os prazos para todas as tarefas, e quando há atrasos é o sistema que notifica o funcionário, economizando tempo do gestor e evitando desgastes.

Outra vantagem é a redução do Work in Progress (colocar o artigo Porque o trabalho em andamento (work in process) pode matar sua empresa), o trabalho em andamento, o que traz um ganho de eficiência enorme na sua equipe, que reduz a alternância entre tarefas e assim consegue se concentrar e concluir mais rapidamente as que estão em andamento no momento.

Estratégia

Com um sistema com esse recurso, a gestão se torna mais precisa, facilitada e assertiva, o que permite acompanhar constante mente os resultados e fazer ajustes para os projetos e a empresa não saiam dos trilhos. Outra vantagem, é que as colunas do kanban não são fixas, o que possibilita também realizar o planejamento para melhorar a organização interna.

Comprometimento

Uma palavra chave para entender o impacto da Kanban na empresa é transparência. O andamento, quantidade de tarefas por colaborador e gargalos / atrasos ficam visíveis a todos da equipe e da gerencia. Assim como quem é quem não é produtivo, o que pode ser um desafio no momento da implantação, mas deve ser superado em prol do bom funcionamento do escritório de Gestão de Projetos.

Mas na maioria das vezes, o que se percebe no ambiente de trabalho é um aumento na sensação de pertencimento e colaboração entre os membros da equipe. Quando todos estão a par do que se passa, é mais fácil ser ser eficiente, seja ao começar uma tarefa que na qual o colaborador tem capacidade para realizar, ou mesmo ajudar um colega que está preso em uma atividade e que pode atrasar todo o projeto.

E essas foram apenas os destaques dos ganhos que a sua empresa pode conseguir ao adotar um software com Kanban para gerenciar sua equipe. Já adotou esse sistema e mais vantagens para compartilhar? Comente no blog!


Fonte: projectbuilder.com.br

O papel da documentação de software nas metodologias ágeis

Documentação

O papel da documentação de software nas metodologias ágeis

Michelly Oliveira   11:23:00

"Dentro de métodos ágeis, preferimos software em funcionamento mais que documentação abrangente."

As razões para essa frase aparecer no Manifesto Ágil são várias, mas, para mim, a mais impactante é que, quando temos uma documentação extensa, frequentemente cria-se a ilusão de que não precisamos conversar com o cliente e entendê-lo melhor, já que o documento (supostamente) cobriria essa função.

No entanto, esse pensamento se baseia em pontos perigosos: assume-se que quem escreveu a documentação realmente entendia do negócio, que essa pessoa (ou comitê) conseguiu escrever de forma clara para todos os indivíduos que a consumirão, que esses indivíduos vão interpretar o texto bem e ninguém esquecerá de detalhes potencialmente muito importantes… e de que esse documento será sempre atualizado, conforme as mudanças aconteçam.

Na prática, a frase do Manifesto significa que evitamos desperdiçar tempo com documentações que não serão lidas ou que ficarão obsoletas rapidamente. Em vez disso, preferimos que o próprio software seja sua documentação, através de:

• Testes de unidade automatizados: código que verifica um método/função/classe que, para um dado cenário controlado, a saída esperada é tal. Essa é uma documentação para o desenvolvedor que for alterar esse código interno no futuro.
• Testes de aceitação automatizados: código que simula o que o usuário do sistema fará, seu comportamento usando uma funcionalidade. Essa é uma documentação para quando o time for alterar o que um determinado código faz.
• Clean code: prática de trabalhar ativamente para deixar o código claro e coeso, para que o próximo que venha a mexer nele não precise gastar tempo desvendando o que ele faz. Esse é um guarda-chuva gigante de boas práticas no dia-a-dia de desenvolvimento.
• Se o código ainda não está bom, a ponto de qualquer um entendê-lo… Documentação dinamicamente gerada: geração automática, através de ferramentas específicas de cada linguagem, da relação entre as partes e classes do sistema. Frequentemente, usa-se UML aqui, e há diversas ferramentas que analisam um código e geram os diagramas que refletem o estado atual do design e arquitetura do sistema.

É claro que, dependendo do seu contexto, você pode ser obrigado a prover certas documentações para, por exemplo, o cliente. Nesse caso, fazemos o possível para evitar trabalho desnecessário, mas… infelizmente, jogamos com a regra do jogo atual.

Como é possível organizar essas documentações de software ao final de cada iteração?

O método mais comum para nos certificarmos que uma certa documentação obrigatória seja entregue é acrescentar um passo ao nosso Critério de Pronto, para que todo o time saiba, claramente, que todo item desenvolvido precisa ser documentado e, também, para que eventuais gargalos nesse step fiquem explícitos para todos.

Fonte: blog.alura.com.br

Fundamentos Agile: O básico, o simples

Scrum

Fundamentos Agile: O básico, o simples

Michelly Oliveira   12:29:00

Há muitos "sabores" do Agile : XP, Scrum, FDD, Kanban, SAFe, LeSS e assim por diante. Estes são chamados de "frameworks ágeis", e cada um tem sua própria meta : XP é focado no desenvolvimento de um software , Scrum é focado na organização de um processo de equipe e SAFe é focado em projetos em grande escala. Embora as muitas e óbvias diferenças entre os frameworks (objetivos E práticas) , todos eles falam a mesma língua : Agile.

O efeito Scrum

Scrum é o framework mais didático e popular. É fácil de usar, e ainda traz muitos desafios à sua utilização. A Scrum Alliance oferece treinamentos e certificações bem aceitos para diferenciar os profissionais que são treinados na utilização de Scrum para entregar software. Assim, embora eu ache que XP ainda é o framework ágil mais completo para uma equipe, muitas empresas estão começando sua jornada ágil através do Scrum. Muitas pessoas pensam que Scrum é sinônimo de Agile.

Rude despertar

Há muitos profissionais de software em todo o mundo. Mais cedo ou mais tarde, um profissional que utiliza apenas Scrum vai tropeçar em cima de alguém que fornece software muito bem usando Kanban, ou usando apenas XP. Isso é muito comum. E, geralmente, este não é um momento do tipo: neste momento, o profissional Scrum percebe que há algo muito maior do que Scrum. Isto é Agile. E então uma nova (e enorme) viagem começa: a compreensão do universo Agile através de estudo e experimentação de sua grande variedade de frameworks, a descoberta de novos papéis e disciplinas e a abstração de um método.

Incrementos, ciclos curtos e feedback

Esta é a essência do Agile. Se você ou sua equipe oferecer software através de pequenos incrementos, demonstrando-o em curtos períodos de tempo, para recolher feedback que vai influenciar o software que está em desenvolvimento (e o processo que você está usando para isso), você está fazendo Agile. Você não precisa mesmo nomear o processo que você está usando. Você está apenas entregando software.
Dependendo do contexto você e sua equipe estão desenvolvendo um software (uma startup com 5 pessoas ou uma grande empresa com 6.000 pessoas) você vai precisar de conjuntos de ferramentas e processos totalmente diferentes para entregar pequenos incrementos de software em ciclos curtos e recolher feedback. Aqui vem a variedade de frameworks ágeis disponíveis para nós usarmos.

Concentrando-se nos fundamentos Agile

O Consórcio Internacional de Agile (ICAgile) está oferecendo um conjunto de treinamentos e certificações focados em trabalhar com Agile, não importa o framework que você está usando. A principal preocupação do ICAgile é ensinar as pessoas a essência do Agile e como trabalhar com ele, desde o levantamento de requisitos até o testar um software. Eles não oferece qualquer tipo de framework ou processo, ajudando as pessoas a entender a mentalidade por trás de cada framework Agile existente, e torná-lo mais fácil e seguro de usar/mesclar os frameworks, dependendo do problema que você está tentando resolver.
Como o processo de certificação do ICAgile concentra-se em ensinar as pessoas como entregar software com uma mentalidade Agile, e não na mecânica e processos específicos, eu realmente acredito que essas faixas de formação, muito mais do que suas certificações, podem nos ajudar a orientar os profissionais de software através de um verdadeiro desenvolvimento/entrega ágil de software.

Link(tradução): Adaptworks

Gerenciando a vida com kanban

Organização Pessoal

Gerenciando a vida com kanban

Michelly Oliveira   13:23:00

Aprenda como organizar o dia a dia, planejar viagens, priorizar leituras e manter as séries em dia usando um quadro kanban

por Paula Ribas

O kanban é um sistema de sinalização bastante usado por quem trabalha com metodologias ágeis. De origem japonesa, a palavra kanban significa "cartão visual" (ou registro visual). No desenvolvimento de software, o método consagrado por David Anderson é usado para dar visibilidade ao fluxo de trabalho, limitar a quantidade de tarefas em andamento e facilitar a melhoria contínua dos processos de um time.
E não é só para o desenvolvimento de software que o kanban é útil. Além de ser adotado em várias indústrias diferentes, o sistema é também uma ótima opção para ajudar na organização pessoal.
Mas como e onde aplicar o kanban na vida? Vamos começar pelo básico: construir um quadro kanban.

 O quadro kanban

Um quadro kanban em geral é dividido em três colunas: a fazer, fazendo e feito. É uma maneira simples e intuitiva de organizar e gerenciar o andamento de tarefas e atividades. Não significa, no entanto, que você não possa adaptar a divisão de colunas para situações e necessidades específicas.
A ideia do quadro kanban é funcionar como uma visualização objetiva e funcional. Para isso, você pode usar tanto post-its na parede do seu quarto, quanto uma ferramenta como Trello, Taiga, Kanboard, Kanbanchi etc.
Para exemplificar algumas aplicações do kanban para organização pessoal, usamos o Trello, uma ferramenta já bastante popular e disponível gratuitamente nas versões desktop e mobile.

Kanban para organizar tarefas do dia a dia

Para visualizar o quadro completo clique aqui

Sabe aquele monte de coisa que você tem para fazer mas sempre se esquece? Pagar uma conta, adicionar aquele item na lista do supermercado... Ou aquelas outras que você sabe que precisa fazer mas procrastina até não poder mais? Marcar um horário no dentista, arrumar o armário bagunçado…
Pois é. Passar tudo isso para um quadro kanban é uma boa forma de evitar esquecimentos e até mesmo a procrastinação, já que visualizar continuamente o que precisa ser feito funciona como um estímulo para finalizar tarefas e mover cartões para a coluna de itens concluídos.
Como o quadro preferencialmente deve ser visualizado todo dia, montá-lo em uma parede usando post-its pode ser uma boa opção. Um quadro no Trello, por outro lado, tem como vantagem poder ser atualizado onde quer que você esteja — desde que você tenha o aplicativo instalado no celular. Use o que fizer mais sentido para você.
Ah, o modelo acima de quadro para organização do dia a dia está disponível para ser copiado no Trello (basta clicar em Menu > Mais > Copiar quadro) e adaptado da forma que você quiser.

Kanban para planejar viagens

Para visualizar o quadro completo clique aqui

Planejar uma viagem envolve muita coisa: escolher datas, definir roteiro, comprar passagens, reservar hotéis, e por aí vai. Do momento da decisão de viajar ao momento de partir rumo ao destino, é tanta coisa para resolver que fica fácil se perder e deixar detalhes importantes para a última hora.
É aí que entra o kanban: usando um quadro simples, você se organiza para planejar tudo com antecedência e com facilidade. Fazer um levantamento de tudo que precisa ser feito e deixá-lo visível te ajuda a priorizar as tarefas mais importantes ou mais urgentes e garante que você não se esqueça de nada.
O exemplo de quadro para planejamento de viagem acima também está disponível para ser copiado no Trello e adaptado como você achar melhor.

Kanban para priorizar leituras

Para visualizar o quadro completo clique aqui

Se você ama ler, há boas chances de que você sofra de dois problemas comuns entre amantes de livros: comprar livros compulsivamente e não conseguir lê-los na mesma velocidade e/ou começar várias leituras simultaneamente, estendê-las durante meses e abandonar algumas pelo caminho. Se esse for o seu caso, o quadro kanban pode ser a solução dos seus problemas (é sério).
Visualizar as leituras que estão em curso, as que estão paradas e os próximos livros que você quer ler pode tornar mais simples a tarefa de gerenciar sua rotina de leitura. Lembra da função de limitar a quantidade de trabalho em andamento que o kanban cumpre no desenvolvimento de software? A lógica é a mesma: se a coluna "Lendo" ou a coluna "Não terminei" estiverem muito cheias, talvez seja melhor concluir alguns livros antes de começar outros.
Na coluna "Quero ler", você pode adicionar e priorizar os próximos a serem lidos. Uma boa prática é mover para o topo os cartões dos livros que você considerar prioridades, deixando-os sempre visíveis e à frente dos demais na fila de leituras.
O modelo de quadro para organizar leituras também está disponível para cópia e adaptação no Trello.

Kanban para manter as séries em dia

 Para visualizar o quadro completo clique aqui

Vamos falar de um vício cada vez mais comum: séries. Você sofre crises de abstinência quando acaba uma temporada? Troca um bar no sábado por uma maratona daquela série que acabou de sair no Netflix sem pensar duas vezes? Acompanha tanta série de uma vez que não sabe nem por qual começar quando chega o final de semana? O kanban pode te ajudar!
Como tem sempre aquela época no ano em que várias temporadas novas são lançadas ao mesmo tempo, visualizar tudo em um quadro pode te ajudar a se programar melhor. E quando o "Assistindo" estiver mais vazio, dá até pra escolher entre começar uma série nova ou dar mais uma chance para uma daquelas que você abandonou.
Da próxima vez que alguém te perguntar o que você tem assistido ou pedir indicações de séries, é só compartilhar seu quadro! O modelo de quadro para organizar séries que você viu ali em cima está disponível para ser copiado e adaptado com as suas favoritas.



Fonte: https://medium.com/%C3%A1gil-al%C3%A9m-do-software-thoughtworks/gerenciando-a-vida-com-kanban-55139b9026bc#

Princípios do manifesto ágil

Principles

Princípios do manifesto ágil

Michelly Oliveira   22:08:00

Nós seguimos os seguintes princípios:

• Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
• Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
• Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.
• Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
• Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
• O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
• Software funcional é a medida primária de progresso.
• Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
• Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
• Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
• As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.
• Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Os seis papéis em um time ágil

Scrum

Os seis papéis em um time ágil

Michelly Oliveira   23:29:00

Já deixamos claro em vários momentos neste Blog que só trabalhamos com métodos ágeis aqui na Concrete Solutions. Isso porque acreditamos que o processo de desenvolvimento Waterfall é um processo ultrapassado que nunca deveria ter sido aplicado em software. Este processo tem o problema de assumir uma realidade estática na qual pessoas oniscientes preveem o futuro. Ou seja, você acredita que sabe o problema a ser resolvido e a solução para ele antes de começar a criar o seu produto.

Este post tem por objetivo explicar um pouco de como funcionam os times ágeis, destacando a responsabilidade e a importância de cada papel dentro deles.

Antes disso, devemos ressaltar que estamos analisando os times ágeis que funcionam para desenvolvimento de produtos digitais. Cada produto também tem suas peculiaridades e funções específicas que podem interferir nessa estrutura de time. Aqui, nossa intenção é mostrar um time básico, com o qual desenvolvemos a maior parte de nossos produtos.

Também temos alguns conceitos que devemos explicar antes de entrar nos papéis. O trabalho em métodos ágeis é dividido em “sprints”, períodos de tempo pré-definidos, que seguem um “backlog”, lista organizada e priorizada do que tem que ser feito. O backlog é definido na planning, que antecede toda sprint, e revisado ao final dela, no que chamamos de “review”. Diariamente, o time tem reuniões rápidas (de no máximo quinze minutos) chamadas de “dailys”, nas quais os participantes apresentam o que cada um resolveu entre um dia e outro, eliminam as tarefas e assumem novas responsabilidades.

Dito isso, vamos aos papéis:

1. Product Owner (PO) ou Dono do Produto

O PO é o CEO do produto. Ele é o responsável pela definição de qual vai ser o produto, considerando as funcionalidades que ele terá. Ele deve ter uma visão geral de todas as sprints e gerenciar o backlog de acordo com essa visão, priorizando as tarefas. É o product owner quem diz ao time o que ele tem que fazer, e quando.

2. Scrum Master (SM)

O Scrum Master é o “coach” ágil do time. Ele garante que todas as práticas ágeis sejam seguidas, ou seja, garantir que a daily seja realizada, cuidar do tempo do sprint, etc. Também é função do SM proteger o time, garantindo que ele não se comprometa com mais do que pode desenvolver e gerenciando as expectativas dos stakeholders do produto. Também é o scrum master quem resolve problemas de relacionamento entre o time e impedimentos externos que possam atrapalhar o desenvolvimento do produto.

3. User Experience (UX), Designer ou Designer de Experiência de Uso

O UX é quem define a usabilidade do produto. É a ponte entre o desenvolvimento e o usuário final, aquele que vai usar o produto. Ou seja, ao UX cabe decidir o design e o fluxo que as informações devem seguir. É ele quem define quantas telas, o que terá em cada tela, onde fica cada link e etc.

4. Equipe de Desenvolvimento

É quem realmente faz o produto. Pode ser formada por uma ou até sete pessoas, que não têm funções pré-definidas. A equipe é auto gerenciada e auto organizada, ou seja, os próprios membros elegem quem será o responsável por determinada tarefa e cobram a realização dela. Neste ponto, é importante frisar que o time deve ter todos os perfis necessários para a execução do trabalho. Não adianta, por exemplo, ter quatro pessoas para back-end e nenhuma de front-end.

5. Growth Hacker ou Marketing do Produto

Pessoa cedida normalmente pelo marketing da empresa, o growth hacker é responsável por trazer tração para o produto durante a fase de validação. Este papel é responsável por fazer com que as pessoas saibam que o produto existe e engajar essas pessoas para que elas usem durante o desenvolvimento, uma vez que é por meio do feedback dessas pessoas que o time valida hipóteses e segue ou muda de direção. A diferença entre o growth hacker e o marketing tradicional é que o primeiro tem ênfase no uso de ferramentas mais analíticas, uma vez que seu objetivo é validar hipóteses que influenciam no desenvolvimento do produto, e tem orçamento mais limitado. Por isso, desenvolve campanhas focadas em grupos de usuários específicos.

6. Devops

É o responsável por codificar a infraestrutura na qual será montado o produto. Diferente do papel de infraestrutura tradicional, o Devops cria uma documentação viva do ambiente, que pode ser reutilizada.

Antes de terminarmos, é importante observar que todos esses papéis são interligados e parte de um time. Se não tivermos o PO, o time pode desenvolver um produto errado e todo o orçamento será gasto em engenharia. A frase que resume este ponto é “não importa quão bom seja o seu time se você não der algo relevante para ele fazer”. Sem o PO, o time vai desenvolver um monte de códigos desconexos da realidade, que pode não virar um produto efetivamente “entregável”, muito menos um produto de sucesso.

A falta de um scrum master pode comprometer o tempo em que o produto é criado. O time pode pegar mais tarefas do que efetivamente pode executar, e não desenvolver no tempo certo, enquanto os stakeholders podem ter suas expectativas frustradas. Vai faltar cadência no desenvolvimento do produto. Sem o time de desenvolvimento, não tem produto. Sem UX, não temos garantia que o produto vai ser “usável”, ou seja, que o usuário conseguirá utilizar o que você está criando. Sem o Devops, não haverá uma maneira replicável, automática e documentada para criação de ambiente para desenvolvimento, controle de qualidade e produção, enquanto que sem o growth hacker ninguém vai saber que seu produto existe e você não vai conseguir validar suas hipóteses, nem gerar tração e engajamento.

No fim, pode ser até que o produto saia, mas não aquele produto que você gostaria de construir e nem na velocidade que você esperava. Além disso, é bem provável que seu orçamento acabe muito antes do seu produto.


 Link: Concrete Solutions