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

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

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

Gostaria de convidar a todos para o Agile Brazil 2012, que acontece entre os dias 5 e 7 de setembro em São Paulo e estarei palestrando sobre “Desafios na Gestão de Equipes Virtuais”. O evento é uma grande oportunidade para aqueles que querem conhecer, aprimorar seus conhecimentos e técnicas em metodologias ágeis, além de estender seu network.

Este será meu primeiro evento oficial pela Rally, patrocinadora oficial do evento. Eu estarei presente ao evento todos os dias, compartilhando idéias com a comunidade ágil, muitos deles desenvolvedores, temos 3 dias para conversar e colocar os assuntos em dia.

Minha palestra (“Desafio na gestão de equipes virtuais”) acontece no dia 5 de setembro às 16:30, estamos cada vez mais atuando com equipes virtuais, modelo este que tem suas vantages e desvantagens, traz novos desafios, surpresas, involve liderança e outros aspectos a serem apresentados. Você talvez pergunte porque trazer este tema para o Agile Brazil, um dos aspectos mais importantes em Ágil é o trabalho em equipe e quando temos que trabalhar com equipes virtuais, ágil traz um valor fundamental a este modelo.

Nos último 15 anos tive a oportunidade de liderar e atuar em diversos projetos, sendo os últimos 6 anos projetos aqui nos EUA o qual pude atuar com equipes espalhadas pelo mundo (EUA, Europa, Rússia, Japão e outros países), aprendi muito nestes projetos, o que fazer, o que evitar, o que funciona, o que não funciona, os principais erros e motivações que levam as empresas à adotarem este modelo e outros tópicos. Estarei trazendo situações reais pelas quais passei e situações atuais vividas aqui na Rally.

Apesar do título focar em equipes virtuais, muito do que será apresentado se aplica a equipes locais.

Todos estão convidados, aproveita e faça sua inscrição para o Agile Brazil 2012.

Nos vemos no Agile Brazil!!!

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

Está na moda e a cada congresso, reunião com clientes e grupos de usuários que participo vejo mais e mais arquitetos, desenvolvedores, gerentes de projetos e outros profissionais da área de tecnologia interessados por Metodologias Ágeis. Atualmente temos uma variedade de metodologias, sendo Scrum e Extreme Programming (XP) as mais conhecidas. Considero Scrum e XP muito práticos e nada burocráticos, se você está buscando melhorar o seu processo de desenvolvimento, sem dúvida é bom começar a pesquisa sobre ambos.

Muitos acham que Scrum e XP conflintam no mundo Agile, pelo contrário eles se complementam. Scrum atua no lado gerencial do projeto fazendo com que o produto especificado seja entregue ao final da iteração. Já o XP atua nas práticas de engenharia de software a serem aplicadas no projeto  como: test-driven development, refactoring, pair programming, simple design, etc. Além disso Scrum pode ser aplicado além dos projetos de software, pois ele não especifica prática como pair programming ou test driven development, mas especifica como gerenciar os requisitos ou novos recursos solicitados pelo cliente.

Eu não vou detalhar ambas as metodologias neste post, existe muita informação na Internet que lhe trará uma rápida introdução sobre as duas, Google é seu amigo.

Scrum e Extreme Programming sem dúvida estão bem alinhados, se você conhece equipes que utilizam uma das duas metodologias certamente seria difícil decidir por qual delas optar. As diferenças existem e são pequenas, mas são importantes.

• Equipes Scrum tipicamente trabalham em iterações (sprints) que vão de 2 semanas até 1 mês. As equipes XP também trabalham em iterações que vão de 1 a 2 semanas.
• Equipes Scrum não permitem alterações em seus sprints, uma vez definido o sprint na reunião de planejamento e acordado os itens do backlog a serem entregues, estes itens não serão alterados até o final do sprint. XP é mais flexível em relação a mudanças no sprint, desde que o time não tenha começado a trabalhar em um dos itens anteriormente definidos, este item pode ser trocado por outro item de período de implementação equivalente.
• Equipes XP trabalham em ordem de prioridade, recursos a serem desenvolvidos são priorizados pelo cliente e o time é obrigado a seguir esta ordem. Ao contrário do Scrum o product owner define a prioridade do product backlog, mas o time irá definir a sequência de implementação dos itens do backlog.
• Scrum não estabelece quaisquer práticas de engenharia de software, XP sim. Estas práticas são extremamente importantes no desenvolvimento de software e algo que eu particularmente gosto bastante, particularmente desenvolvimento dirigido por testes, foco em testes automatizados design simples, refactoring e outros.

São pequenos detalhes que podem fazer uma grande diferença na sua equipe de desenvolvimento.

Sempre queremos melhorar nosso processo de desenvolvimento, mas não sabemos por onde começar, tantas siglas, metodologias, processos, etc. que achamos tudo muito complicado e isso acaba desestimulando. Minha recomendação é começar com Scrum, simples, efetivo, fácil de implementar, envolve os membros da sua equipe e os resultados aparecem em pouco tempo.

Depois vá para o XP, dependendo do que você tem hoje no seu processo vai descobrir que algumas partes do XP já são utilizadas pela sua equipe, isso irá ajudar no processo de implementação, pois sua equipe não se sentira mandada a fazer algo, lembre-se acima de tudo estamos lidando com pessoas.

Nos meus próximos posts sobre metodologias ágeis vou abordar alguns pontos do Scrum e como complementá-lo na gestão de projetos, também vou falar sobre a utilização prática das “práticas do XP”, coloco entre aspas porque as práticas não são exclusivas ou foram inventadas pelo XP e sim fazem parte da sua metodologia.

Até a próxima.

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