Muito se fala em transição da cultura Waterfall para a cultura Agile nos projetos de desenvolvimento de software. E quando falamos em transição, a primeira palavra que nos vem à cabeça é: mudança. E com tal palavra, temos uma enxurrada de emoções: medo, desconfiança, ansiedade, raiva, esperança. Juntando-se a isso a cultura ocidental do imediatismo e a média de duração de 1 ano dos projetos de software, encontramos um ambiente próprio para muitos conflitos, desgastes e frustrações.

Nesta sessão vamos discutir, juntos e através de muitos exemplos e relatos, a importância de uma cadência mais lenta para tal mudança cultural, o foco nas necessidades do ambiente e, principalmente, o foco na melhoria gradual do processo, que se estende muito além da duração de um projeto de software.

Vamos discutir algumas das relações entre ciclo de vida de desenvolvimento de software e ciclo de vida de startups e novas empresas. Todo mundo tem opiniões ou frases feitas, mas poucos discutem os fundamentos por trás dessas áreas. Esses fundamentos são multi-disciplinares e são explicados em áreas que conhecemos nem sempre associamos com software, como biologia ou física.

Quanto tempo seu time leva para colocar em produção uma versão contendo uma mudança de uma única linha de código? Qual o impacto desse delay ao seu negócio?

Entregar software de forma contínua é o atual desafio dos grandes times de desenvolvimento de software. Garantir releases confiáveis exigem práticas, muitas vezes complexas, de build, testes e automação de deploy. Durante esse curso pretendemos tratar os principais desafios relacionados à Continuous Delivery aliando fundamentos teóricos a exemplos práticos, compostos em grande parte de aplicações em cases reais.

Em Abril de 2012 rolou uma discussão intensa sobre testes por causa de um Tweet do @DHH, culminando em opiniões interessantes sobre muitos dos grandes nomes que são referência nesta área:

• DHH I find over-testing to be most common among those first adopting TDD. So excited about the idea that they go completely overboard.
• Michael Feathers @dhh Thoughts on the matter
• Joshua Kerievsky @dhh Test first/after misses the point that TDD is more about emergent design than it is about testing. Do you practice emergent design?
• Rodrigo Yoshima TDD zealots crying RT @dhh On a related topic, I probably do test-first 20% of the time, test-after 80% of the time.
• Uncle Bob Martin @dhh @KentBeck One of Kent’s older wise sayings was: “Test everything that could possibly break.” I think that’s a pretty good recipe.
• Tim O’Brien @dhh over testing is a refuge for procrastinators in denial. You can hide in testing for days convincing yourself you’ve been productive.
• andrewdeandrade Now that’s a testing sentiment I can get behind
• Corey Haines yawn! @dhh (or most people, for that matter) raging about testing isn’t something I pay attention to. Glad I missed it.
• @KentBeck wish there were more examples of “what not to test”

Vemos muito valor em TDD, mas não somos obcecados pela prática. Não questionamos o valor de ter testes para o seu projeto, mas questionamos o valor de querer testar absolutamente tudo, antes.

Recomendamos que participantes tenham experiência prévia escrevendo testes automatizados com ferramentas estilo XUnit, frameworks de Mock e frameworks de testes de aceitação como Cucumber, Fit ou Selenium. Exemplos serão apresentados em Java, Javascript and Ruby.

Venha saber mais sobre Kanban botando da mão na massa. Neste workshop você aprenderá como lidar com gargalos, impedimentos, a limitar o trabalho e a fazer gestão visual do projeto. Tudo isso para acelerar o fluxo de valor do seu projeto. Você fará parte de uma equipe e construirá um Kanban board personalizado durante o workshop.

Somente entender tecnologia (bits e bytes) não é suficiente para entregar valor para o negócio, é preciso conhecer o negócio, os processos e entender as pessoas, suas necessidade, expectativas e preocupações, para entregar produtos (softwares) que agregam valor ao negócio e aos clientes.

Este workshop demonstrará como utilizar boas práticas, técnicas e ferramentas para facilitar o entendimentos do negócio para entregar valor.

Benefícios da Sessão:

Demonstrar boas práticas, técnicas e ferramentas para facilitar o entendimentos do negócio do pela Equipe Ágil (ou Equipe Scrum: PO, SM e equipe de desenvolvedores)

Recomendo que os participantes levem computadores.

Por que personas são relevantes em contextos ágeis?

Em projetos ágeis “personas” devem ser vistas como uma ferramenta fantástica nas mãos de um time. A equipe do Product Owner (composta pelo P.O., especialista em experiência do usuário, analista de negócios…) pode, facilmente, se utilizar de “personas” para alinhar suas expectativas com o time funcional (arquitetos, desenvolvedores, testes…) proporcionando uma visão compartilhada e realista do produto em desenvolvimento. E usar personas pré-definidas como atores de user stories farão com que os requisitos descritos tenham mais credibilidade e mais envolvimento, aproximando-os ainda mais da realidade.

Personas é uma ferramenta de usabilidade que utiliza pessoas fictícias pararepresentar usuários. Utilizamos personas em projetos centrados no usuário (For ThemBy Us), definindo os objetivos e desejos dos reais usuários, orientando decisões como:a interface, a navegação, os recursos e demais elementos do projeto de design.

Mais do que um artefato simples ou uma descrição feita em uma única página, ométodo “Personas” é uma técnica: “driven-design-personas”. Iniciada por Alan Cooper,em 1999. Ele compartilha com o time de projeto uma visão comum dos usuários de umserviço ou produto, em um formato muito atraente. Usar personas é recomendado quando não há nenhuma documentação sobre quem éo usuário do seu produto ou se quer especializar a UI (user interface) do produto parao seu público alvo, com base em pesquisas entrevistas, etc.. Mas quando estamos emum projeto onde o usuário final não é humano, por exemplo um sistema system-to-system, umaAPI, etc. onde nenhum que irá interagir com o sistema é humano acho quenão faz muito sentido usar personas.

E como explica Martin Fowler, User Stories focam nos objetivos do usuário e comoo sistema alcança esses objetivos. User Stories devem ser curtas, simples e claras.Devemos conseguir escrevê-las em um simples e pequeno cartão. Alguns perguntarão o motivo desta proposta estar em “Design” – lembrando que designé a idealização, criação, desenvolvimento, configuração, concepção, elaboração eespecificação de objetos que serão produzidos. O projeto de design necessita deuma análise informacional, a partir de um ponto de vista. Detectar corretamente as“personas-usuárias” e relacioná-las ao objetivo do projeto (user stories) é essencialpara um bom planejamento, de modo que as ações sejam tomadas de forma correta –assim, segue esta proposta, pois para quem é designer, quem é o usuário, e quem é opúblico final, representa o primeiro passo.

Nas artes marciais, Dojo é uma prática feita de maneira controlada para promover o aprendizado de movimentos e técnicas, para que estas se tornem naturais para o aprendiz. Inspirados nesta idéia, os Coding Dojos são encontros em que programadores se reunem para praticar test-driven development, programação em pares e novas linguagens seguindo uma certa disciplina.

O Testing Dojo é uma adaptação do Coding Dojo, na modalidade Randori Kata, para praticar o teste de uma base de código legado. O número de participantes recomendado é de 8 a 20 pessoas. Parte-se de um sistema simples existente e são exploradas técnicas para descobrir um conjunto de problemas presentes nesse sistema. Estes problemas não podem ser revelados no início da atividade.

Segue-se um ciclo de 7 minutos, em que serão encaixadas as tarefas, detalhadas no ítem processo/mecânica. Estas incluem uma apresentação do problema, que é um sistema simples no qual foram injetadas falhas propositais, e a programação em pares de testes automatizados para descobrir os problemas. Os pares se revezam a cada ciclo, para permitir a participação da maioria dos presentes, finalizando com uma retrospectiva.

A palestra irá descrever a experiência da MATERA em elaborar e organizar um novo processo de teste para as equipes responsáveis pela evolução e manutenção do seu portfólio de produtos, durante a transição para um framework de desenvolvimento ágil. Será apresentada uma visão geral do processo de teste (papéis, procedimentos, ferramentas) e os desafios, dificuldades e benefícios observados ao longo da implantação do novo modo de trabalho.