Um dos assuntos que tem balançado o mundo Ágil recentemente é o Scaled Agile Framework (SAFe). Existem inúmeros mitos sobre Ágil no mercado que geram certa confusão, entretanto, muito se comenta que Ágil não funciona em grandes projetos com apenas o uso de SCRUM, como exemplo projetos onde você tenha acima de 70-100 pessoas, alto nível de dependência, complexidade e em um ambiente onde há inúmeros outros projetos acontecendo de forma simultânea.

Eu concordo que SCRUM por si só não é suficiente para este tipo de cenário, Scrum of Scrums pode ajudar mas está longe de resolver os problemas e desafios que fazem parte de um ambiente como este, assim sendo é necessário repensar a forma com que aplicamos as práticas ágeis.

Com base nisso foi criado o Scaled Agile Framework (SAFe), framework que reúne uma série de práticas ágeis/lean já existentes, otimizadas de forma a atender a realidade do desenvolvimento de software nos dias de hoje e a realidade das empresas do segmento conhecido como Enterprise, para que isso seja possível SAFe é aplicado sobre 3 níveis: Portfólio, Programa e Equipe. No Agile in Rio estarei apresentando as principais características do SAFe  e como o mesmo vem sendo aplicado em grandes empresas e projetos dos mais diversos segmentos.

O Agile in Rio será em Niterói na Rua Gastão Gonçalves, 79, Santa Rosa, mais precisamente na Universidade Unilasalle, informações e inscrições podem ser feitas diretamente no site do evento.

Nos vemos lá.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

Existem inúmeras formas de se começar a implementar práticas ágeis, mas quando falamos em práticas de gestão para as equipes aí vem a pergunta, como começar e o que utilizar?

Se você conversar com profissionais que tenham experiência em ágil, pode ver que a grande maioria irá recomendar o uso do SCRUM, eu concordo com esse recomendação. O framework SCRUM fornece meios que quando bem implementados, ajuda a disciplinar as equipe, o que é fundamental para o sucesso da mesma.

Assim como a disciplina, o aumento da colaboração é fundamental e um benefício direto para as equipes que utilizam SCRUM, colaboração esta que tende a ser continua e trará um impacto direto nos projetos trabalhados. Começar com ágil e implementar SCRUM pode parecer fácil, mas existem diversos fatores que acabam dificultando a implementação, a maioria destes fatores estão ligados a mudança, o que para muitas pessoas pode ser algo difícil de lidar.

Existem inúmeras técnicas para facilitar a implementação, que recomendo que seja equipe por equipe. Começar pequeno é uma abordagem que ajuda no processo de implementação como um todo e irá ajudar no processo de disseminação e expansão para outras equipes. Muitas equipes começam com os post-it na parede, stand ups, planejam seus sprints e por ai vai, esse começo é importante para ajudar a criar um ambiente colaborativo, ajudar na mudança de cultura, criar disciplina e assim se tornar a base para uma implementação de sucesso.

Começamos pequeno, entretanto as equipes crescem, o volume de trabalho aumenta, muitas vezes as equipes estão distribuídas, surge a necessidade de se obter métricas para ajudar a acompanhar o desempenho das equipes, sejam elas quantitativa e/ou qualitativa e muito mais. Como alcançar tudo isso? Certamente o quadro com post-it, o uso de planilhas excel para controlar backlog, calcular velocity,  não serão o meio mais eficiente, por  isso as ferramentas estão ai e certamente irá nos ajudar a ser mais produtivo.

Muitas pessoas me perguntam se sou contra os quadros na parede com post-it, e sempre respondo que não sou, acho sim que quadros trazem transparência, eficiência em alguns casos, mas chegamos a um certo ponto em que os quadros já não atendem as nossa necessidades, nessa hora ferramenta é fundamental. Ferramenta nos traz visibilidade não importa onde estamos, maior produtividade, métricas em tempo real, aumenta a colaboração e assim por diante.

Enfim, existem diversas formas de se implementar e acelerar a adoção de SCRUM em sua empresa. Na próxima quarta-feira, 17 de Julho às 11h (Horário do Brasil) estarei apresentando um webinar sobre esse tema e todos os leitores do meu blog estão convidados. As inscrições podem ser feitas aqui.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

Se você está procurando aperfeiçoar seus conhecimentos e técnicas em relação a como escrever User Stories, recomendo assistir o vídeo abaixo, eu (Andreano Lanusse) e meu amigo Luciano Rodrigues apresentamos sobre este tema como parte da série de webinar TeamStart da Rally Software.

Escrever User Story vai muito mais além do que apenas definir quem solicitou, a funcionalidade e o porque, neste vídeo falamos sobre os diversos aspectos que envolvem a definição de uma User Story, o papel do Product Owner na priorização e definição das User Stories no Backlog, o grooming do Backlog, o que fazer com grandes User Stories e muito mais.

Caso você ou um amigo queira conhecer mais sobre SCRUM, recomendo assistir o vídeo aula que se encontra neste aqui.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

O primeiro artigo da série sobre migração de sistemas legados ou mal estruturados gerou vários comentários, recebi centenas de e-mails com perguntas e sugestões, o qual agradeço a todos que até aqui contribuíram, o feedback só vem a ajudar na evolução dos artigos sobre o tema, continuem publicando seus comentários.

Com a diversidade de tecnologias nos dias de hoje, está cada vez mais difícil decidir qual utilizar e principalmente saber por quanto tempo a tecnologia escolhida nos dará o suporte necessário, vamos neste artigo abordar a avaliação de tecnologias e fornecedores, assim como plataformas.

Avaliando tecnologias e fornecedores

Hoje temos inúmeras tecnologias, desde Open Source, gratuitas e comerciais, algumas suportadas por grandes fabricante de software e outros por aqueles que chamamos membros da comunidade, há também aquelas com muito pouco suporte e que tem sua evolução comprometida ou até mesmo já foram descontinuadas.

Escolher tecnologias sólidas e que tenha o suporte de empresa ou grupos comprometidas com sua evolução é fundamental. Obviamente todos tendem a escolher o que é gratuito, lembre-se que nada nada é grátis, tudo tem um custo que mais cedo ou mais tarde você estará pagando.

A avaliação da tecnologia está diretamente ligada a arquitetura a ser adotada em seu novo projeto. A evolução tecnologica nos últimos 10 anos foi tanta que se tornou impossível ter uma solução baseada em apenas uma tecnologia, fornecedor, plataforma e muito menos uma linguagem, nos levando a uma maior cautela na hora da escolha.

Além de uma avaliação técnica é SUPER importante avaliar diversos aspectos da empresa, como por exemplo:

• Quais os clientes desta empresa? No website da empresa deve constar casos de sucesso, use seu network e valide os clientes desta empresa e o que eles pensam da tecnologia.
• O que os clientes falam ou pensam da empresa? Um bom lugar para saber isso são os foruns de discussão das empresas, a maioria tem um e se não tiver, procure no Google. Procure se certificar das informações que você venha encontrar com profissionais que conheçam esta empresa.
• Qual o RoadMap? Procure saber junto a empresa qual o RoadMap para as respectivas tecnologias que você venha a utilizar, além disso se possível uma conversa para saber mais a fundo sobre este RoadMap, eu diria que tecnologias que não tenham um horizonte definido para os próximos 5-10 anos, devem ser descartadas.

Esses são alguns aspectos que considero importante em uma avaliação, obviamente não são os únicos, entretanto se ao avaliar uma empresa e ela for mal nesses 3 pontos, você já pode descartá-la.

Estamos conectados

Integrações entre sistemas é algo que não foi inventado hoje, nossos usuários não estão mais sentados e obtendo informação no computador à sua frente e muito menos esperando o próximo dia de trabalho. A diversidade de plataformas, dispositivos móveis, notebooks e etc. gerou a necessidade de se ter a informação disponível por toda a parte.

Este cenário mudou a forma com que desenvolvemos software, o modelo Cliente/Server se tornou obsoleto e ineficaz, modelos de arquitetura distribuída surgiram no final da decada de 90, a Microsoft iniciou com a arquitetura DNA, surgiram os WebServices, SOA se tornou o padrão, os servidores de aplicação Java ganharam espaço, hoje falamos em REST e Cloud vem para nos ajudar a escalar e distribuir nossa arquitetura.

Pare por 5 minutos e pense nas arquiteturas e tecnologias mencionadas no parágrafo anterior, coloque isso em uma perspectiva para os próximos 10 anos, reflita sobre o que você já desenvolveu até os dias de hoje e se pergunte “O que eu faria diferente daqui pra frente?”.

Arquitetura baseada em serviços

Desenvolver soluções de software e não pensar em uma arquitetura baseada em serviços é como dar um tiro no pé e estar condenado ao fracasso no curto prazo. A razão porque digo isso é muito simples, estamos conectado através dos mais diversos dispositivos e a informação tem de estar disponível em todos eles, separar camada de negócio e apresentação é fundamental, sendo assim, uma boa arquitetura é chave e pode definir o rumo dos seus negócios.

Desktop ou Web

Vamos direto ao ponto aqui, assumir que suas aplicações de negócio devam ser aplicativos desktop é um retrocesso, se você pretende migrar suas aplicações legadas para a mesma plataforma que elas estão, neste caso de Desktop para Desktop, melhor não começar, fique onde está.

Obviamente aplicações de backend, processamento de dados que rodam nos seus servidores (geralmente em modo console), estes são aplicativos desktop e estes devem continuar assim, entretanto seu frontend não deve mais estar baseadas em interfaces desktop, esta é minha recomendação.

A Web evolui demais e hoje não temos as limitações do passado com browsers, uma solução Web traz flexbilidade para a empresa, reduz seu custo operacional, abre as portas para novos modelos de comercialização de software (SaaS) e muito mais, pretendo abordar em detalhes este tema em outro artigo.

Mobile

Em algum momento você terá de suportar uma ou todas as três plataformas móveis do mercado (iOS, Android e Windows Phone), em um curto espaço de tempo você vai saber com base no feedback dos clientes ou na necessidade do mercado que sua solução atende.

Existe uma grande discussão entre apps nativas ou web para dispositivos móveis, isso vai depender muito do tipo de aplicativo que você deve desenvolver. Inicialmente desenvolva apps nativas, pois ainda existem limitações com relação a web apps em Mobile, em alguns casos será melhor utilizar um modelo híbrido onde a sua app nativa irá chamar páginas webs, o qual é uma boa opção quando você precisa de maior flexibilidade.

Um aviso importante, não decida que suas apps para mobile serão todas web porque simplesmente você quer economizar com a assinatura anual da Apple de U$ 99 ou a da Google para Android que custa U$ 30, chamamos isso de economia porca.

Em breve pretendo publicar um artigo sobre o tema apps nativas vs web e seus respectivos pros e cons.

E agora?

Reuna sua equipe e converse com eles sobre essa potencial migração, compartilhe com eles a ideia de uma arquitetura distribuida, o suporte a dispositivos móveis, pergunte quais os benefícios e problemas que uma nova arquitetura deveria trazer.

Esta conversa com o time é uma oportunidade para aprender mais sobre os problemas existentes, o que pode ser melhorado, quais as vantagens competitivas que uma migração pode trazer para a empresa e assim por diante.

Faça esse exercício, enquanto isso vou preparando o próximo artigo.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

Se você está buscando melhorar a colaboração, trabalho em equipe e entregar projetos sejam eles de software ou qualquer outro mais rápidos e com melhor qualidade, reserve um tempinho e participe do Agile Brazil 2013, que será realizado em Brasília entre os dias 26 e 28 de junho.

Agile Brazil é o evento mais importante sobre Agile no país, o lugar certo para aqueles que querem aprender e aprimorar seus conhecimentos em metodologias ágeis, já participei de outras edições e recomendo, vale muito a pena. Ano passado tive a oportunidade de palestrar no evento, este ano enviei algumas propostas de palestra e estão sendo avaliadas pela equipe do evento. Alias você pode ver todas as palestras enviadas e que estão sendo avaliadas neste momento, muito legal esse nível de transparência do evento.

O evento traz diversas trilhas com palestras e palestrantes de alto nível, abordando diversas metodologias e tecnologias, como não poderia ser diferente a Rally Software está patrocinando o evento e toda sua equipe estará lá, incluindo eu.

Outra coisa bem bacana que antecede o evento é a Virada Ágil, nela você poderá fazer diversos treinamentos a um custo muito baixo, mas muito baixo mesmo que chegam a 50% de desconto, você não irá encontrar esses preços fora do Agile Brazil, então aproveite. Mais informações sobre a Virada Ágil aqui.

Não importa seu cargo é importante participar deste evento, seja desenvolvedor, tester, analista, líderes de equipe, gerentes, etc. O evento traz um benefício muito grande para os participantes e o que você aprender poderá ser aplicado de imediato no dia-a-dia de trabalho da sua equipe ou de você mesmo.

As inscrições para o evento já estão abertas, quanto mais cedo você se inscrever mais barato será, então aproveite e se inscreva já.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

Para aqueles que estão buscando aprender mais sobre métodos ágeis, recomendo assistir o vídeo abaixo onde eu (Andreano Lanusse) e o Luciano Rodrigues da Adaptworks falamos sobre os fundamentos do SCRUM. Essa apresentação foi realizada recentemente em dos webinars promovidos pela Rally e faz parte de uma série de webinars a serem realizados regularmente.

Se você está começando ou querendo começar com métodos ágeis o webinar abaixo é um bom começo.

O download dos slides pode ser feito através deste link.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

Migração de sistemas legados é um assunto que pode render horas, dias, semanas ou meses em qualquer empresa, algo que considero normal, pois envolve uma quantidade enorme de variáveis e traz grandes desafios. Não precisamos ir muito longe para identificar sistemas legado e os desafios para mantê-lo nos dias de hoje.

Sistemas que cresceram muito rápido e em um curto espaço de tempo, menos de 1 ano por exemplo, pode não ser considerado legado, entretanto na maioria das vezes este crescimento rápido e não planejado não irá suportar o crescimento da empresa a médio e longo. Com isso, o assunto migração entra em cena novamente.

Meu objetivo nesta série de artigos é ir a fundo no tema, trazer um pouco da minha experiência, sugerir caminhos e alternativas para uma migração menos dolorosa, além de recomendar soluções que irão ajudá-los. Vale lembrar que não existe receita de bolo e vocês verão isso aqui, cada caso é um caso e ninguém melhor do que você para saber dos problemas nas soluções desenvolvidas por você ou sua empresa. Faça seus comentários ao final do artigo, eles irão agregar e ajudar outros a refletir sobre que caminho tomar na neste processo, além de me ajudar nos próximos artigos.

Se não é fácil e sabemos, então por onde começamos?

Todos tem de estar desarmados

A primeira coisa a se fazer neste processo é entrar desarmado, aberto a mudança, aceitar ideias, críticas e sugestões, expor o que você pensa e ouvir, ouvir, ouvir e ouvir muito. Todos aqueles envolvidos neste projeto, deverão estar conscientes disso e preparados para mudar seu comportamento, a pior coisa neste longo projeto é ter um grupo de pessoas remando contra, enquanto todos os outros estão remando para frente. Trabalho em equipe será fundamental, críticas, sugestões e debates calorosos existirão, mas todos tem que estar cientes de que é para o melhor do projeto.

Incorporar métodos ágeis como SCRUM já na fase inicial do projeto pode ser de grande ajuda, as práticas ágeis enfatizam muito a colaboração, trabalho equipe, interação entre as pessoas, etc. Isso pode começar a estabelecer um ponto de equilíbrio na equipe e reforçar de forma continua o trabalho em equipe.

Por que migrar?

Faça esta pergunta a si mesmo “Por que migrar?”, esqueça por um instante o famoso ditado “Time que está ganhando não se mexe”, ou seja, “sistema que está funcionando não se mexe”.

A grande maioria dos sistemas ERP desenvolvidos na década de 80 e início dos anos 90 adotaram a arquitetura Cliente/Servidor (Cliente/Server) e foram desenvolvidos para plataforma Desktop, ao longo do tempo isso foi mudando, a web se tornou uma plataforma mais atrativa e hoje vivemos no mundo dos dispositivos móveis. Naquela época muitas soluções baseadas em Web surgiram, mas o avanço da tecnologia foi tão rápido que essas antigas aplicações web não foram bem estruturadas, trazendo vários outros problemas. Enfim, integração entre plataformas e diversidade de meios de acesso tornou o modelo Cliente/Servidor obsoleto.

Considere como exemplo sistemas ERPs legado ou outros similares, reflita sobre o cenário mencionado no parágrafo anterior e traga para sua realidade, seus clientes hoje querem acesso as informações via web, via iPhone, iPad, Android e seus muitos celulares e tablets e assim por diante. A recente pesquisa que fiz aqui no blog mostrou que 75% dos entrevistados irão desenvolver aplicações para mobile e 45% irão migrar suas aplicações desktop para web em 2013. Como você faria essa migração hoje de forma rápida e escalável? Como você integraria apps com seu backend? Quanta regra de negócio seria reutilizada? Já se perguntou?

Seja Desktop ou Web, se seu sistema está baseado em Cliente/Servidor, a eficiência da sua empresa está comprometida pois você está o tempo todo fazendo remendos para atender as necessidades do mercado, isso eleva a dificuldade de manutenção do código, diminui a eficiência da sua equipe, aumenta o seu custo e o custo do seu cliente, ou seja, diminui sua competitividade no mercado.

Já deve fazer um tempo que seu cliente pede para que TODO o sistema seja Web, ele faz questão de dizer TODO O SISTEMA, ele não precisa de tudo e sim certos módulos importantes, como por exemplo relatórios, gráficos estatísticos em tempo real, acesso ao cadastro de clientes, etc. Mais uma vez arquitetura Cliente/Servidor se torna um problema, o seu cliente disse que os relatórios tem de estar acessíveis pela web e relatórios na web podem trazer uma carga enorme em todo o sistema. Como você atenderia a estas solicitações? Não precisa me dizer dos remendos, eu já imagino, replicar os dados para um servidor web, manter sincronizado, etc.. Isso é caro, não é escalável e se torna um remendo temporário que irá rasgar em pouco tempo.

Já se perguntou quanto custa manter seus sistemas Desktop? Depois de muitos anos sua aplicação virou um grande sistema, com dezenas de módulos, integrações, recursos, dependências, etc.. Para responder essa pergunta, você precisa se fazer as perguntas abaixo:

• Quantos problemas de instalação do sistema são registrados mensalmente?
• Quantos problemas de compatibilidade de Windows são registrados mensalmente?
• Quantos problemas de atualização do sistema são registrados mensalmente?
• Quantas visitas mensais os técnicos do suporte técnico fazem a clientes para resolver problemas que não são possíveis de resolver remotamente?
• Quanto representa essa grande estrutura de suporte técnico no seu custo final?
• Que crescimento você estima para o negócio se todo sistema estivesse na Web?
• Quais diferenciais a web traria para o seu negócio?
• Quanto tempo irá levar para você desenvolver uma aplicação Android com base na atual infra que sua empresa oferece?
• Etc…

Provavelmente você não tenha a resposta para todas, então é hora de começar a buscar e mensurar estes custos.

Aplicações desktop aumentam o custo final, principalmente por causa do alto-custo do suporte técnico, não estou dizendo para mandar embora metade da equipe de suporte técnico, muito pelo contrário, a equipe de suporte técnico tem um grande conhecimento do sistemas e pode ser reutilizado em outras funções, como desenvolvedores, testadores, analistas, etc…

Que tal oferecer sua solução como serviço (SaaS), o negócio do seu cliente não é TI, porque não ter  uma infra-estrutura na nuvem e oferecer sua solução? Cobrar por este serviço.

São inúmeros os pontos a se pensar, os pontos aqui mencionados são alguns entre os milhares e talvez não seja razão para você, o que é totalmente aceitável da minha parte, entretanto reflita sobre outros pontos que você acha importante e faça sua própria análise.

Vou ficando por aqui com esta primeira parte, enquanto isso reflita sobre as razões que o levaria a migrar sistemas legados ou mal estruturados.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

Amigos leitores do meu blog, ano a ano o blog vem batendo recordes de visitas, para continuar neste ritmo e trazendo conteúdo de qualidade e útil para todos vocês, peço que responda a pesquisa abaixo que tem como objetivo saber mais dos seus planos em relação ao desenvolvimento de software e quais temas seriam úteis para vocês em 2013.

A pesquisa é objetiva e tomará menos de 5 minutos do seu valioso tempo.

PS: A pesquisa pode também ser respondida através deste link http://bit.ly/peal2013

Muito obrigado,
Andreano Lanusse

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

Se você não pode participar do Webinar Rally Live sobre gerenciamento de equipes ágeis e portfólio de projetos não tem problemas, o webinar foi gravado e você pode assistir a gravação aqui.

Neste webinar mostrei como Rally Agile ALM suporta todo o ciclo de desenvolvimento de produto Ágil, fornecendo visibilidade em tempo real dos status do seu projeto.

O Webinar começou com uma pequena apresentação sobre a Rally  depois fomos para a prática, mostrando:

• Como criar e gerenciar o Backlog
• Como planejar iterações (sprint) e releases
• Como executar, acompanhar e comunicar o andamento dos projetos
• Como fazer a Gestão de Portfólio e equipes ágeis de forma integrada

Se você já utiliza ou pretende implantar métodos ágeis como SCRUM, Kanban e outros, assista a gravação do webinar onde mostrei na prática como o Rally irá apoiar a você e sua equipe no dia-a-dia.

Até o próximo!!!

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

Olá a todos os leitores deste blog,

Gostaria de convida-los para um encontro online na próxima segunda dia 12 de novembro às 16 horas (horário de Brasília), onde estará acontecendo o primeiro Rally Live Webinar sobre metodologias ágeis para todo o Brasil.

O Rally Live é um webinar que tem como principal característica ir direto ao ponto, e eu Andreano Lanusse estarei monstrando como o Rally Agile ALM suporta todo o ciclo de desenvolvimento de produto Ágil, fornecendo visibilidade em tempo real dos status do seu projeto.

Durante a apresentação estarei mostrando como utilizar o Rally para:

• Como criar e gerenciar o Backlog
• Como planejar iterações (sprint) e releases
• Como executar, acompanhar e comunicar o andamento dos projetos
• Gestão de Portfólio integrada as equipes ágeis

Todos devem participar, principalmente aqueles que gerenciam equipes de desenvolvimento ágil (SCRUM, Kanban, XP, etc.), responsáveis pelo processo de transformação da empresa para ágil integrando práticas Ágeis e Lean e Gerentes de Projetos/PMO que estão ou pretendem atuar com equipes ágeis.

O evento será transmitido via internet e é 100% gratuito, você só precisa garantir sua vaga ainda hoje efetuando o registro através do botão abaixo.

Sinta-se a vontade para convidar pessoas do seu ciclo profissional que estão ou pretendem entrar no mundo ágil, basta enviar o link de registro para eles (http://forms.rallydev.com/Q412-RallyLive-Brazil)

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

O SCRUM tem uma prática conhecida como Daily Standup Meeting (Reuniões diárias) onde a equipe se reune diariamente e cada membro da equipe informa o que fez ontem, o que fará hoje e se há algo impedindo que ele execute suas tarefas.

O objetivo desta reunião não é somente criar um fórum regular de atualizações de status, mas também trazer a tona os problemas e definir ações rápidas com o objeto de solucionar os problemas rapidamente. Esse tipo de feedback rápido permite as equipes reagirem rapidamente a mudança com sucesso, a reunião diária é uma das primeiras rotinas essenciais para uma criar uma equipe ágil, independentemente da localização do escritório.

Principais características

• As reuniões diárias são de no máximo 15 minutos e de pé, justamente para não prolongar
• 3 perguntas básicas para estabelecer comprometimento e remover impedimentos.
  • O que eu fiz ontem?
  • O que farei hoje?
  • Estou impedido de fazer tal tarefa porque….
• Nenhum problema será resolvido nesta reunião, estaremos apenas informando o status e não iremos discutir sobre durante esta reunião
  • Se um membro da equipe quer discutir algo, eles pode propor uma discussão para depois

Por que estas reuniões são importantes?

• A equipe avalia como eles estão entregando o plano de iteração.
• Os membros da equipe compartilham com cada um seus compromisos para o dia.
• Fornece visibilidade em atrasos e obstáculos

Quem participa destas reuniões?

• O Scrum Master, Product Owner e o restante da equipe.
• Os stakeholders e clientes podem observar e são incentivados a estar presentes, mas eles não podem interagir/participar da reunião.
• O Scrum Master irá tomar nota de cada impedimento reportado pelos membros da equipe.

Veja que a reunião diária é uma prática simples mas super eficiente que traz grandes benefícios. Como exercício, faça uma lista dos problemas atuais que você enfrenta em projetos ou com sua equipe, você facilmente verá que a falta de comunicação se não for o problema #1 ela estará pelo menos entre os 3 maiores. Comece praticando o Daily Standup Meeting hoje e comece colhendo os frutos já na primeira semana.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

No meu artigo anterior falei sobre o planejamento das equipes ágeis o que nos levou a User Story (histórias) e consequentemente a tarefas, neste artigo vamos mais a fundo na relação entre User Story e tarefas.

Cada história é uma coleção de tarefas, onde a história descreve a necessidade do usuário e a tarefa descreve como a funcionalidade será implementada, como a tarefa representa o trabalho real teremos um nível de granularidade muito maior.

A definição das tarefas para cada história, ocorre quando alocamos a história na iteração atual e isso é muito bom, pois teremos maior feedback e detalhes para assim melhor elaborar as tarefas a serem executadas para aquela história.

As tarefas são estimas em horas, é recomendado estimar o tamanho das tarefas entre 2-12 horas, para tarefas que requerem mais que 12 horas quebre estas em várias tarefas de menos de 12 horas.

Quando uma história está PRONTA (DONE)?

Em SCRUM utilizamos o termo DONE para indicar que uma história já teve seu desenvolvimento finalizado e está pronta para ser avaliada pelo Produtct Owner. A própria equipe cria sua definição de DONE, que pode ser um único critério ou um conjunto, abaixo um exemplo:

• Todas as tarefas completadas (desenvolvimento, testes, documentação)
• Executar e passar em todos os testes de aceitação
• Nenhum defeito aberto
• Aceitação do product owner
• Pode ser enviado ao usuário

Com isso a equipe se compromete a entregar todas as histórias com base na definição estabelecida.

Critérios de Aceitação

Assim como a equipe define o DONE para cada história, o product owner ou cliente são responsáveis por descrever seus critérios para aceitarem a história, estes critérios podem descrever a funcionalidade, comportamento e desempenho que eles esperam para tal recurso.

O papel dos critérios de aceitação é definir o que DONE é exatamente, isso irá ajudar ao desenvolvimento saber quando eles completaram a história. Se existem partes da história que você não quer deixar para o desenvolvimento definir, escreva um critério de aceitação. Por exemplo, se você acha que deve definir as mensagens de erros e como elas serão apresentadas, você pode fornecer um documento de design para explicar o formato e texto das mensagens de erro ou você pode escrever critérios de aceitação para cada história que venha a gerar uma mensagem de erro.

Para finalizar, história, critérios de aceitação e tarefas para implementar a história representa um requisito em ágil.

No próximo artigo vamos falar sobre Daily Standup.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

Na sequência de artigos sobre métodos ágeis vamos conhecer um pouco sobre o planejamento das equipes, abaixo um breve resumo.

Uma equipe ágil trabalha com base em iterações para entregar user stories (histórias). Iteração é o termo genérico utilizado em Agile, em SCRUM iteração é chamada de Sprint, estarei utilizando o termo genérico neste e futuros artigos.

Inicialmente as histórias residem no backlog, onde o Product Owner juntamente com a equipe irá estimar o tamanho e definir a prioridade de cada história, a partir dai se define as iterações de trabalho e aloca-se um conjunto de histórias a serem entregues.

Com base na sua capacidade de trabalho (quantidade ideal de horas para trabalhar nas tarefas) a equipe plenja o quanto ela poderá absorver em cada iteração.

Story Points é a métrica utilizada pelas equipes para estimar o tamanho de cada história e representa o quanto a equipe irá se comprometer, e não só isso, Story Points é uma forma relativa de medir o tempo necessário para se implementar uma história, através de Story Points estamos medindo o tamanho e complexidade e não a expertise e tamanho da equipe, em outras palavras estamos dizendo o quão difícil é em termos de quanto tempo será usado para fazermos algo.

O que é um User Story (Histórias)?

User Story é um requisito que define uma funcionalidade que o usuário necessita, como melhores práticas você pode escreve-lo de duas formas:

• Como <Papel do Usuário> eu preciso <Funcionalidade> de modo que <Valor para o Negócio>
• A fim de <Valor para o Negócio> como <Papel do Usuário> eu preciso <Funcionalidade>

A forma de representar requisitos em Agile é bem diferente do que você está acostumado a ver no método waterfall, em agile vamos ser precisos e especificar aquilo que realmente o usuário precisa e qual o valor para negócio que tal funcionalidade irá trazer, detalhes de como esta funcionalidade será implementada serão descrito nas tarefas a serem geradas.

Durante a reunião de planejamento do Release, as histórias recebem uma estimativa com base em uma escala relativa como Story Points.

Durante a reunião de planejamento da iteração, a história será quebradas em tarefas, as quantas forem necessárias para entregar a história.

Agile é muito disciplinado no que diz respeito a produção de real valor para o negócio e estimativas precisas.

No próximo artigo vamos discutir a relação entre as histórias e tarefas.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

Agora que você já leu meu primeiro artigo da série sobre “Desenvolvimento Ágil de Software”, vamos conhecer os diferentes papéis e responsabilidade de cada um em uma equipe ágil. Assim como existem diversas metodologias ágeis, como: Scrum, Kanban, XP, etc.. Vamos focar a série de artigos em Scrum, pois é a mais utilizada no mundo e em minha opinião a metodologia mais recomendada para aqueles que estão começando com seus times no mundo ágil, vamos ao papéis.

Scrum Master

O Scrum Master é o que chamamos de líder servidor (servant leader), ele é o guardião das práticas Scrum e deve assegurar que todos os envolvidos diretamente no projeto saibam como aplicá-las corretamente. Ele é responsável por disseminar conhecimento sobre o método de trabalho, por assegurar a evolução do time, apoiando o aprendizado multi-funcional e a auto-organização. Este modelo permite o aperfeiçoamento constante das habilidades e capacidades de todo o time, p O que vem a ser líder servidor? O líder servidor atua fundamentalmente para o sucesso do time e não em benefício próprio, ele tem de ser um verdadeiro líder para estar nesta função, buscando facilitar o trabalho dos integrantes da equipe, resolvendo problemas, removendo obstáculos que impeça a evolução do trabalho e o progresso do time, além de eliminar conflitos que venha a existir. Eu destaquei as principais características do Scrum Master, existem outras, abaixo um resumo de suas responsabilidade:

• Permitir estreita cooperação entre todos os papéis e funções
• Remover obstáculos e proteger a equipe de distrações
• Trabalhar com a organização para acompanhar o andamento do projeto e fazer ajustes necessários na estrutura ou processos da organização
• Garantir que as práticas ágeis estão sendo seguidas, incluindo reuniões diárias (stand-ups), reuniões de planejamento, de demonstração e de revisão, e retrospectivas
• Facilitar reuniões de equipe e reuniões de tomada de decisão

Product Owner

O Product Owner é responsável pelo produto e pelo ROI do projeto, ele basicamente faz a interface entre o cliente e o time, isso faz com que o papel do Product Owner seja um fator crítico de sucesso. O Product Owner tem que trabalhar alinhado com o time, caso contrário os objetos não serão alcançados. É muito comum em qualquer tipo de projeto, seja software, industrial, marketing e outros notarmos que os cliente tem dificuldade em expressar suas necessidades, quando fazem mudam com frequência e geralmente a entrega tem de ser para ontem. Por outro a equipe que irá desenvolver o projeto não entendem o que está sendo solicitado e muitas não querem entender, com isso dificilmente atende as necessidades e para finalizar adicionamos a dificuldade na comunicação e entendimento com o cliente. O Product Owner é a interface entre o cliente e sua equipe, aquele que está no papel de Product Owner necessita ter uma grande habilidade de comunicação, pois deverá traduzir os requisitos de negócio em uma linguagem que a equipe entenda, além de avaliar e priorizar o que deverá ser feito com base naquilo que traz mais valor. A questão do valor é algo chave em métodos ágeis e pretendo falar sobre isso mais adiante. Abaixo as responsabilidades do Product Owner:

• Definir os requisitos e priorizar o seu valor
• Determinar a data de lançamento (release date) e conteúdo
• Ter um papel ativo nas reuniões de iteração e planejamento do release
• Garantir que a equipa está sempre trabalhando sobre os requisitos mais valiosos
• Representar a voz do cliente
• Aceitar as histórias (stories) que satisfaçam a definição de pronto (DONE) definida pela equipe e os critérios de aceitação definidos pelos product owner e/ou cliente

Scrum Master, Product Owner e time juntos

No próximo artigo vamos conhecer como os times ágeis planejam seu trabalho.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

A partir de hoje começo uma série de artigos sobre desenvolvimento ágil de software, o objetivo é ajudar vocês leitores do meu blog a conhecer, aprender e saber como aplicar algumas das métodologias ágeis no seu dia-a-dia utilizando Rally como sua ferramenta de apoio, tudo isso de uma forma fácil e leve. Vamos começar entendendo os conceitos, valores, as metodologias SCRUM e Kanban, e aplicar tudo isso no Rally a primeira, melhor e mais completa ferramenta ALM Agile.

Introdução

Desenvolvimento ágil de software (em inglês Agile software development) ou Método ágil é um conjunto de metodologias para desenvolvimento de software, que pode e é aplicado a diversos projetos não relacionados a software. O desenvolvimento ágil traz uma estrutura conceitual para guiar projetos de engenharia de software, assim como outras metodologias de software também o fazem. Em 2001, membros proeminentes da comunidade publicaram o Manifesto ágil, documento que reúne os princípios e práticas desta metodologia de desenvolvimento.

Os princípios do desenvolvimento ágil valorizam:

• Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares funcionais;
• Softwares funcionais são entregues frequentemente (semanas, ao invés de meses);
• Softwares funcionais são a principal medida de progresso do projecto;
• Até mesmo mudanças tardias de escopo no projecto são bem-vindas.
• Cooperação constante entre pessoas que entendem do ‘negócio’ e desenvolvedores;
• Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança.
• Design do software deve prezar pela excelência técnica;
• Simplicidade;
• Rápida adaptação às mudanças;
• Indivíduos e interações mais do que processos e ferramentas;
• Software funcional mais do que documentação extensa;
• Colaboração com clientes mais do que negociação de contratos;
• Responder a mudanças mais do que seguir um plano.

Em projetos ágeis software são desenvolvidos de forma incremental, geralmente em ciclos (iteração/iteration) curtos de 1 à 4 semanas que nos ajuda a manter o desenvolvimento alinhado com as necessidades do negócio. Bem diferente dos tradicionais métodos onde definimos um único ciclo que dura em torno de 6 à 18 meses e de cara levantamos todos os requisitos e riscos antecipadamente, a figura abaixo demonstra os métodos tradicionais. Ágil se adapta ao feedback constante permitindo a entrega dos trabalhos planejados a partir de código implementado e testado a cada iteração (1 à 4 semanas), conforme a figura abaixo. Resumindo em métodos ágeis ao final de cada iteração teremos um parte do nosso software que potencialmente poderá ou não ser entregue, diferente dos tradicionais métodos onde investimos meses para entregar algo.

Vou ficando por aqui, até o próximo artigo que virá em breve.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

Já fazem 2 meses desde meu último artigo aqui no blog e só tenho a agradecer por todos os comentários e e-mails recebidos, sem dúvida ter o seu trabalho e reconhecido e saber que pude ajudar muitos desenvolvedores não tem preço, mais uma vez obrigado a todos.

Desde então tenha estado super ocupado, já de página virada e a todo o vapor em meu novo desafio a Rally Software, para quem não conhece Rally é nada mais nada menos a empresa líder no mercado de Agile ALM e uma das grandes apoiadoras do movimento ágil, e sua plataforma ALM é a melhor e mais completo do mercado, além claro de ser a única solução ALM do mercado que nasceu 100% baseada em metodologia ágil.

Assim sendo, estarei abordando aqui no blog diversos temas relacionados a metodologias ágeis, mas do que isso discutir seus valores, o papel do trabalho em equipe, liderança aplicada ao mundo ágil e não ágil e diversos outros assuntos relacionados.

Aqueles que já me acompanham a algum tempo, lembram dos tempos de Borland onde tive a oportunidades de apresentar e debater com os mais diversos profissionais da área sobre as ferramentas, metodologias e processos que trazíamos naquela época, as quais eram focados no modelo de processo de software conhecido como cascata, o qual se tornou um modelo pesado, caro e ultrapassado na grande maioria dos casos.

Trazer a perspectiva ágil e poder comparar com outros modelos irá facilitar o entendimento, esclarecer as vantages e desvantagens, benefícios, desafios, etc..  Compartilhar a experiência ágil aqui na Rally será algo único, ágil está enraizado na cultura da empresa e isso faz uma grande diferença em todos os sentidos, além disso estarei mostrando como o seu time pode se tornar um time ágil através do Rally ALM, aplicando metodologias ágeis como SCRUM e Kanban.

Vou ficando por aqui e nos vemos em breve.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse