[1]

VISÃO ÁGIL

AGILE BRAZIL 2010 - A CONFERÊNCIA BRASILEIRA SOBRE AGILENo mês de junho desse ano, Porto Alegre será palco da conferência Agile Brazil 2010. Que nesse ano reunirá toda a comunidade ágil nacional e terá a presença ilustre de Martin Fowler.

A Conferência Brasileira sobre

M é t o d o s Á g e i s d e

Desenvolvimento de Software É

uma conferência nacional sem fins

l u c r a t i v o s o r g a n i z a d a p o r

representantes das pr inc ipa is

comunidades ágeis brasileiras. O

e v e n t o t e m c o m o p ro p ó s i t o

promover a comunicação e a

colaboração entre seus integrantes

visando à disseminação coordenada

da cultura Ágil por todo o país.

O Agile Brazil 2010 acontecerá

no campus central da PUCRS, em

Porto Alegre, de 22 a 25 de junho,

contando com cursos, apresentação

de trabalhos e relatos de experiência

provenientes de várias regiões do

país, alem da participação de

c o n v i d a d o s r e c o n h e c i d o s

internacionalmente.  Martin Fowler,

cientista chefe da ThoughtWorks,

Philippe Kruchten, professor da

UBC em Vancouver (Canadá) e

conhecido também por ter liderado a

equipe do RUP na Rational Software,

David Hussman, Agile Coach e

ganhador do Gordon Pask Award

2009 e também Klaus Wuestefeld

que simplesmente é o pioneiro da

divulgação de XP no Brasil e figura

com bastante respeito no cenário

internacional.

E por final, é importante destacar

que esse é um evento extremamente

democrático, onde até mesmo a

escolha do logo do evento foi aberta

ao público.

O site oficial é:

www.agilebrazil.com/2010/

COMMUNITY JOURNAL

Martin Fowler

Q ue numa en t r e v i s t a concedida a Danilo Sato (http://www.dtsato.com/blog/), afirmou que: “Estou empolgado em visitar o Brasil. Esta será minha primeira vez na América do Sul e tanto eu, quanto minha esposa estamos ansiosos há tempos por essa visita”.

Nessa Edição:

# Agile Brazil 2010# Experiência Sicoob Brasil

# Testes Unitários# Por que usar “story points”?

# Coaching para Auto-Organizacão

# Essência Ágil# Notícias

# 1

Foto

: Pr

agda

ve/F

lickr

Março 201O

[2]

Junior, fale um pouco sobre o que é o Sicoob Brasil e como a área de TI atua na companhia?

O S i c o o b B r a s i l é a

C o n f e d e r a ç ã o N a c i o n a l d a s

Cooperativas de Crédito, com sede

em Bras í l i a , é uma empresa

prestadora de serviços, que além de

outras atribuições como órgão

normativo e padronizador da Rede

Sicoob, faz o outsourcing completo

de TI para o Bancoob e também das

cooperativas de crédito filiadas à

Rede Sicoob. Fornecemos desde o

desenvolvimento de um sistema de

automação bancária completo ,

como também a ope ração e

produção deste sistema além da

disponibilização e manutenção do

datacenter. A Rede Sicoob conta

atualmente com mais de 1.700

pontos de atendimento, abrangendo

21 unidades da federação, e as

cooperat ivas operam com os

principais produtos do mercado

bancário (depósito à vista, a prazo,

operações de crédito, convênios de

arrecadação, cobrança, dentre

outros), inclusive por meio de canais

automatizados como Internet/Office

Banking, auto-atendimento, etc..

Conte-nos um pouco sobre o que motivou a TI do Sicoob Brasil a apostar num caminho baseado em metodologias ágeis para os seus processos internos de desenvolvimento de software?

I n i c i a l m e n t e h o u v e u m a

conjunção de interesses, tínhamos 5

gerências de sistemas trabalhando

de forma despadronizada, cada uma

usando seu método e produzindo os

seus artefatos. Além disso, os

p r ó p r i o s p ro fi s s i o n a i s d a T I

manifestavam o interesse de ter uma

metodologia única. Havia portanto, a

necessidade de padronizarmos de

u m a M D S ( M e t o d o l o g i a d e

Desenvolvimento de Software) na

organização. Foi quando resolvemos

contratar uma consultoria para nos

apresentar este novo framework/

método, até então pouco conhecido

por nós. Toda a área de TI ficou

b a s t a n t e e m p o l g a d a c o m a

abordagem proposta e, para nossa

surpresa, os gestores de negócios

gostaram bastante da proposta deste

modelo. Buscávamos um modelo

que conciliasse agilidade na entrega

das soluções de TI, mas não

deixando de lado a documentação

dos pro jetos (como uma das

premissas , foi colocado que

tínhamos que ter a documentação

necessária aos projetos e que,

em contrapartida, de nada adiantava

termos dezenas de artefatos para os

projetos e as soluções de TI não

entregues).

Qual foi a estratégia de condução que o Sicoob Brasil usou para iniciar a adoção de metodologias ágeis?

Aproveitamos a oportunidade e

por intermédio de uma de nossas

empresas parceiras, passamos a

contar com um profissional com

amplo conhecimento no assunto,

compondo nosso time. Inicialmente

criamos uma grupo de trabalho,

chamado GT-MDS, composto por

Anal istas das 5 gerências de

sistemas e também da nossa área de

qualidade. Esse time foi responsável

por estudar as principais práticas

comuns às diversas gerências e as

metodologias existentes de mercado

(modelo convencional e ágil) e

propuseram a revisão de nossa MDS.

Esse modelo passou a ser aplicado

e m p r o j e t o s p i l o t o s p a r a

posteriormente ser institucionalizada

formalmente na organização.

EXPERIÊNCIAEntrevista com o Antônio Cândido Vilaça Junior – Superintendente de Sistemas de Informação do Sicoob Brasil, sobre a visão estratégica da organização acerca das metodologias ágeisPor Manoel Pimentel

Antônio Vilaça JuniorSuperintendente

Sicoob Brasil

Maiores informações: www.sicoob.com.br

[Visão Ágil - Community Journal - 01]

[3]

De que forma têm sido o seu envolvimento como superintendente nesse processo de adoção?

A S u p e r i n t e n d ê n c i a t e m

patrocinado todo este processo de

mudança cultural na organização de

T I e v e m a c o m p a n h a n d o o s

resultados dos projetos. Em alguns

casos temos viabilizado a montagem

de equipes multi-disciplinares, com

profissionais de todas as gerências

de desenvolvimento, para trabalhar

em alguns projetos estratégicos,

buscando a d isseminação do

conhecimento entre as equipes e

agilidade na entrega dos projetos.

Como você avalia a complexidade financeira/bancária do ambiente de TI do Sicoob Brasil com a aderência a metodologias como o Scrum? Ou seja, na sua visão estratégica é possível conciliar processos enxutos, flexibilidade e colaboração, com o que os órgãos reguladores norteiam para as instituições bancárias/financeiras brasileiras?

R e a l m e n t e n ã o é f á c i l

desenvolver soluções de TI em

instituições financeiras. Os bancos

são demandadores vorazes de

tecnologia e além disso, os órgãos

regu ladores a todo momento

estabelecem demandas de caráter

legal que, em nosso caso são

tratadas com prioridade máxima. São

mui tos assuntos que acabam

concorrendo. De qualquer forma,

acredito ser sim possível conciliar

u m a M D S ( M e t o d o l o g i a d e

Desenvolvimento de Software) enxuta

nesse ambiente complexo e até por

isso, buscamos esse modelo

d i f e r e n c i a d o o n d e t e m o s

experimentado, até o momento, uma

vivência positiva.

Quais os resultados práticos que você como parte da alta direção da companhia já consegue observar?

Não dá para dizer que usamos

todos os preceitos das metodologias

ágeis. Compilamos o que já tínhamos

de positivo e similar aplicados nas

gerências e mesclamos com os

conceitos ágeis. Vejo por exemplo

que passamos a ter um envolvimento

e maior comprometimento dos

gestores de negócios, que se

aproximaram mais da TI e se

sentiram parte do sucesso/fracasso

dos p ro je tos . Ou t ra ques tão

interessante trata-se das reuniões

diárias, onde o t ime expõe o

andamento das diversas tarefas e

acabam compartilhando os assuntos,

disseminando conhecimento na

e q u i p e . O s q u a d r o s d e

acompanhamento, espalhados por

toda a TI possibilitam uma visão

rápida dos status dos projetos. Para

mim o ponto principal diz respeito

aos Sprints onde a equipe define

suas metas internas e principalmente

focando em entregáveis que geram

valor para o negócio. Esse ponto é

essencial pois podemos colocar

parte da solução em produção, sem

ter que aguardar o término completo

d o p r o j e t o , s e n d o q u e a s

funcionalidades entregues já podem

ser utilizadas pelo gestor, muitas

vezes, já permitindo a realização de

negócios. Ainda estamos no começo

da implantação deste novo modelo

de trabalho, mas pelos projetos

concluídos e vendo a empolgação da

equipe de TI, não temos dúvidas que

lograremos sucesso.

QUAL A A ESSÊNCIA ÁGIL?

O Maré de Agilidade é um evento

da comunidade para a

comunidade. Ele já foi organizado

em Brasília(DF), Salvador(BA),

Fortaleza(CE) e Belém(PA). Entre

em contato para saber como levá

−lo para sua cidade! Estamos

amplamente dispostos a ajudar,

Basta vontade de fazer!

www.maredeagilidade.com

[Visão Ágil - Community Journal - 01]

[4]

Neste artigo vamos falar um pouco sobre como fazer testes unitários mais expressivos, utilizando a combinação de dois frameworks bastante conhecidos: JUnit 4 e Hamcrest.

O JUnit é um framework uti l izado na automação testes unitários, ele fornece mecanismos padrões para ver ificações ou assertivas de saída de programa, que são: assertTrue, assertFalse, a s s e r t E q u a l s , a s s e r t N u l l , assertNotNull...

Já o Hamcrest é uma biblioteca projetada para trabalhar com ocorrências em objetos, permitindo a definição de regras declarativamente. O Hamcrest foi feito para ser utilizado por outros frameworks, podemos citar o JMock como seu grande utilizador.

Com a combinação JUnit + Hamcrest temos um poderosa ferramenta para construção de testes unitários, com esta combinação podemos aumentar a semântica dos testes e expressando melhor as i n t e n ç õ e s d o p r o g r a m a d o r. Hamcrest também permite a criação de assertivas customizadas de acordo com a necessidade do teste, encapsulando lógicas através do uso de açúcar sintático.

Açúcar sintático é uma c a m a d a o u a b s t r a ç ã o d e d e t e r m i n a d a s l ó g i c a s d e programação para facilitar a leitura, o entendimento e a escrita do código fonte. Também pode ser vista como uma excelente técnica de refatoração (What is refactoring?) de código.

Veja os exemplos a abaixo:

ENGENHARIA

Testes Unitários com: JUnit 4 + Hamcrestpor Renato do Amaral Guimarães

assertThat, is: Oferece um açúcar sintático (similar ao assertEquals).

import static org.hamcrest.MatcherAssert.assertThat;import static org.hamcrest.Matchers.is;... @Test public void testAssertThatIs() { List<String> nomes = Arrays.asList("JUnit", "Hamcrest"); String primeiroNome = nomes.iterator().next(); assertThat(primeiroNome, is(String.class)); assertThat(primeiroNome, is("JUnit")); }

assertThat, is, not: Oferece um açúcar sintático, idêntico ao exemplo anterior porém negando a condição.

import static org.hamcrest.MatcherAssert.assertThat;import static org.hamcrest.Matchers.is;import static org.hamcrest.Matchers.not;... @Test public void testAssertThatIsNot() { List<String> nomes = Arrays.asList("JUnit", "Hamcrest"); String primeiroNome = nomes.iterator().next(); assertThat(primeiroNome, is(not("Hamcrest"))); }

[Visão Ágil - Community Journal - 01]

[5]

assertThat, equalTo: Verifica a igualdade objeto usando Object.equals.

import static org.hamcrest.MatcherAssert.assertThat;import static org.hamcrest.Matchers.equalTo;... @Test public void testAssertThatEqualTo() { assertThat(10, equalTo(Integer.valueOf(10))); }

assertThat, containsString: Verifica se existe ocorrência da String

import static org.hamcrest.MatcherAssert.assertThat;import static org.junit.matchers.StringContains.containsString;... @Test public void testAssertThatContainsString() { List<String> nomes = Arrays.asList("JUnit", "Hamcrest"); String primeiroNome = nomes.iterator().next(); assertThat(primeiroNome, containsString("Uni")); }

assertThat, everyItem, containsString: Verifica se existe ocorrência da String em todos os itens da lista.

import static org.hamcrest.MatcherAssert.assertThat;import static org.junit.matchers.JUnitMatchers.everyItem;import static org.junit.matchers.StringContains.containsString;... @Test public void testAssertThatEveryItemContainsString() { List<String> nomes = Arrays.asList("JUnit", "Hamcrest"); assertThat(nomes, everyItem(containsString("t"))); }

assertThat, everyItem, not, containsString: Verifica se não existe ocorrência da String em qualquer elemento da lista, caso tenha alguma ocorrência o teste falha.

import static org.hamcrest.MatcherAssert.assertThat;import static org.junit.matchers.JUnitMatchers.everyItem;import static org.hamcrest.Matchers.not;import static org.junit.matchers.StringContains.containsString;... @Test public void testAssertThatEveryItemNotContainsString() { List<String> nomes = Arrays.asList("JUnit", "Hamcrest"); assertThat(nomes, everyItem(not(containsString("bug")))); }

[Visão Ágil - Community Journal - 01]

[6]

Conclusão

Como podemos perceber n o s e x e m p l o s a c i m a , e s s a combinação de JUnit e Hamcrest pode elevar a qualidade de nossos testes tornando-os mais intuitivos e fáceis de ler.

Um dos princípios da XP é que tenhamos como artefatos permanentes somente código e testes, levando isto em conta é fundamental que o teste unitário aja como documentação do software

fornecendo exemplos concretos de como utilizar a unidade testada. Quanto mais semântica tiver o teste unitário mais bem documentado estará o software.

ReferênciasUnit Test: http://c2.com/cgi/wiki?UnitTest

JUnit: http://junit.sourceforge.net/

H a m c r e s t T u t o r i a l : h t t p : / /code.google.com/p/hamcrest/wiki/Tutorial

 

assertThat, both, is, and, is: Verifica se a variável é de um determinado tipo e possui um determinado valor.

import static org.hamcrest.MatcherAssert.assertThat;import static org.junit.matchers.JUnitMatchers.both;import static org.hamcrest.Matchers.is;... @Test public void testAssertThatBothIsAndIs() { List<String> nomes = Arrays.asList("JUnit", "Hamcrest"); Integer quantidadeNomes = nomes.size(); assertThat(quantidadeNomes, both(is(Integer.class)).and(is(2))); }

assertThat, both, containsString, or, containsString: Verifica o conteúdo da variável possui um valor "ou" outro.

import static org.hamcrest.MatcherAssert.assertThat;import static org.junit.matchers.JUnitMatchers.both;import static org.junit.matchers.StringContains.containsString;... @Test public void testBothContainsStringOrContainsStrin() { List<String> nomes = Arrays.asList("JUnit", "Hamcrest"); String primeiroNome = nomes.iterator().next(); assertThat(primeiroNome, both(containsString("nit")).or(containsString("cre"))); }

assertThat, hasItems: Verifica se existe determinados itens na lista.

import static org.hamcrest.MatcherAssert.assertThat;import static org.junit.matchers.IsCollectionContaining.hasItems;...@Testpublic void testHasItems() { List<String> nomes = Arrays.asList("JUnit", "Hamcrest"); assertThat(nomes, hasItems("JUnit", "Hamcrest"));}

Renato do Amaral Guimarães

É Consultor de T.I., atuando na área de desenvolvimento e a r q u i t e t u r a d e s o f t w a r e utilizando metodologias ágeis em ambientes corporativos. Também um entusiasta da tecnologia e das metodologias ágeis.

Auto

r:

[Visão Ágil - Community Journal - 01]

[7]

O objetivo deste artigo é motivar o uso de story points. Medir tamanho/esforço e não tempo para avaliar o custo das stories traz diversas vantagens conforme veremos na Seção 1. Veremos também por que alguns métodos ágeis, como o Scrum, preferem o uso de pontos em detrimento a medidas de tempo, como Homem-Dia (HDia) ou Homem-Hora (HH). Vale lembrar que também é possível ser ágil usando medidas de tempo, inclusive. Na Seção 2, d e s c r e v e m o s a l g u m a s desvantagens de se usar pontos. Primeiro, vamos citar os porquês de se estimar. Chris L e i s h m a n , d a e m p r e s a Thoughworks, listou em seu blog [1] os 3 Ps que são a razão para e s t i m a r : ( i ) P r e v i s ã o , ( i i ) Performance e (iii) Priorização. Ou seja, estimamos (i) para poder dizer em quanto tempo somos capazes de fazer um determinado conteúdo (ou, numa visão time-box, o quanto somos capazes de fazer em um período fixo de tempo); (ii) para identificar perdas e ganhos de desempenho baseado na nossa velocity; e (iii) para fornecer ao product owner a informação de custo de implementação para ele decidir a prioridade de execução das stories.

Recentemente, Francisco Trindade publicou um post no Blog Visão Ágil [2] relembrando que tudo o que não é desenvolvimento de software é custo, incluindo o tempo de fazer estimativas. Por isso, fazer estimativas deve ser objetivo e o preciosismo está fora de questão. Acredito que a prática do planning p o k e r, a l i a d a à p o n t u a ç ã o Fibonacci são bem apropriados para o serviço.

1. Vantagens do uso de Story Points

Usualmente, para cada story do backlog deverá ser atribuído um valor da série aproximada de Fibonacci (1,2,3,5,8,13,20,40,100). O significado dos valores é relativo, onde uma story de pontuação 8 demanda aproximadamente quatro vezes mais esforço que uma story de pontuação 2. Essa atribuição deve ser feita pelo time e não por uma ú n i c a p e s s o a ( n o p r o c e s s o tradicional, atribuir custo a um requisito muitas vezes é feito por alguém que nem faz parte da execução do mesmo, o que pode levar a erros grosseiros de previsão). Para começar a pontuar as stories de um product backlog (a nossa lista de requisitos), pega-se a story que o time julga ser a de menor esforço e atribui pontuação 2. As demais s t o r i e s d e v e r ã o s e g u i r u m a pontuação relativa a essa primeira.

Abaixo estão listadas as vantagens do uso de story points:

1.1. Foco em estimativa relativa

Para o ser humano, é muito mais intuitivo fazer estimativas relativas do que absolutas. Por exemplo, não é trivial responder a perguntas como: qual é o peso de um cavalo ou qual é o peso de um elefante? Mas é fácil responder: quem pesa mais, o cavalo ou o elefante? Por isso, pontuar por comparação relativa é mais efetivo do que elucubrar valores absolutos.

1.2. Performances individuais diferentes

Um problema inerente do uso de HDia é que essa medida depende do desempenho de quem está executando o serviço. Os indivíduos diferem em know-how, experiência, competência etc. E, se não sabemos previamente quem executará a tarefa (algo importante nos métodos ágeis) fica difícil de estimar em horas ou dias de trabalho.

1.3. Foco em tamanho/esforço e não em duração

Ao ser perguntado sobre o uso de pontos em uma entrevista, Mike Cohn [3] começa explicando que é natural pensar primeiro em tamanho (do esforço) para depois se calcular tempo. Quando alguém pergunta qual o tempo que se leva de carro do Rio de Janeiro a Foz do Iguaçu, primeiro averiguamos a distância, então verificamos quem está dirigindo, o veículo, qual é a velocidade média prevista, quantas paradas pretende-se fazer etc. Depois de verificar o esforço então podemos prever as horas. Mas na nossa área, as pessoas perguntam e respondem em medida de tempo sem ser criterioso com o esforço. Boris Gloger, instrutor de Scrum que já veio diversas vezes ao Brasil, diz que para evitar a confusão entre esforço e duração, ele passou a não usar mais o termo “estimation” e sim “sizing”[4].

GESTÃO

Por que usar “story points”? - Parte 1Por Rodrigo de Toledo

“tudo o que não é

desenvolvimento de software é

custo”

[Visão Ágil - Community Journal - 01]

[8]

1.4. Usar HDia sempre leva a um fator de ajuste

Quando se usa medida de tempo em HDia ou Homem-Hora (HH) acaba-se por contar com um dia cheio de trabalho o que de fato não acontece. Sempre existem as paradas eventuais: emails, cafezinho, toalete, conversa paralela, notícias. Obrigatoriamente é necessário fazer um ajuste no HDia, um fator pelo qual você deve multiplicar seu HDia real em HDia produtivo. Por exemplo, Kniberg da Crisp [5] concluiu que para o seu time em Estocolmo o fator de ajuste (focus-factor) é de 70%. Porém, descobrir esse tipo de informação pode ser perigoso, mal interpretado por um diretor ou até algo desmotivante para o time. Esse problema é mencionado por Mark Striebeck [10] no seu conhecido

artigo sobre a implantação do Scrum na Google.

1.5. Com HDia a aceleração da equipe pode ficar mascaradaObserve que à medida que o seu time vai ganhando experiência no projeto, tarefas de esforço similares t e n d e m a d i m i n u i r o t e m p o necessário para a execução. Se você estiver usando story-points, isso será percebido com um aumento de produtividade do time (mais pontos por sprint). No entanto, caso a opção seja usar HDia para classificar as stories, o resultado é uma diminuição na estimativa em horas de novas tarefas e o ganho de produtividade não ficará explícito (ruim para a auto-estima e valorização do time).

Rodrigo de Toledo

É graduado e mestre pela PUC-Rio e PhD pelo INRIA na França.N a á re a a c a d ê m i c a , t e m diversos artigos internacionais em computação gráfica e lecionou por alguns anos na PUC-Rio. Rodrigo trabalhou por dez anos no Tecgraf onde desempenhou por um ano o papel de Scrum Master.Atualmente é engenheiro de software na Petrobras onde atua também como Product Owner, além de se dedicar à divulgação dos métodos ágeis.

Auto

r:

O processo de Coaching atua na complexa relação caminho/meta, de maneira a ajudar um indivíduo ou time a percorrer o seu caminho e, principalmente, a remover seus próprios obstáculos, a fim de alcançar determinada meta.

O Coaching é composto por dois papéis. O primeiro é o Coachee que é o indivíduo que é responsável por uma determinada meta e o outro papel é o Coach, que é o profissional que fornece o processo de Coaching para ajudar um Coachee a se desenvolver e a chegar nos seus próprios resultados.

Coaching e Agile possuem muita sinergia. Isso é possível pois Agi le possui como al icerce a existência de equipes de alta performance através da Auto-Organização.

E n t e n d e - s e q u e a u t o -organização acontece quando um indivíduo ou equipe possui o espaço necessário para criar e desenvolver (dentro de sua capacidade e ritmo) seus próprios meios para atingir uma meta.

Desenvolver esse senso de auto-organização nos indivíduos não é fácil. Sendo assim, um dos melhores caminhos para levar uma equipe a desenvolver atitudes auto organizadas é através da geração de responsabilidade plena no time sobre um determinado assunto.

Isso também é um exemplo claro de que no processo de Coaching, o Coach deve estimular o C o a c h e e a d e s e n v o l v e r a consciência suficiente sobre:

• quais os motivos estão por trás do uso de determinada caminho ;

• q u a i s o s r e s u l t a d o s esperados com sua adoção e;

• como que adota r esse caminho, vai ajudá-lo a chegar em sua meta.

Auto-organização têm tudo a ver com processo de Coaching pois, para que a mesma funcione, é preciso que a equipe tenha a disciplina necessária para se manter no caminho rumo a uma meta.

Para finalizar, é importante entender que disciplina, nesse contexto de Coaching, nada mais é do que a habilidade de um indivíduo (no caso o Coachee) em ter o foco necessár io e , pr inc ipa lmente, conseguir identificar, potencializar e manter os comportamentos que agregam mais valor à sua meta.

LIDERANÇACoaching para Auto-Organização e Disciplinapor Manoel Pimentel Agile Coach e Diretor Editorial da Visão Ágil

[Visão Ágil - Community Journal - 01]

[9]

GUMA-RS Requirements DOJO! 13 de Março de 2010 na PUC-RS!Se você é um agilista, imagino que você já saiba o que é

um Coding Dojo: uma reunião de desenvolvedores de

software cujo objetivo é desenvolver novas

competências pela prática disciplinada e

colaborativa de resolução de problemas de

programação. Se você já entendeu o que é um

Coding Dojo, talvez você já tenha em mente o

que pode será um Requirements Dojo: uma reunião

de Product Owners e profissionais em geral cujo objetivo

é desenvolver novas competências pela prática

disciplinada e colaborativa de resolução de problemas

de captação e análise de requisitos de software. Nele,

iremos praticar, ainda de forma inédita na

comunidade internacional de desenvolvimento

de software, diferentes níveis de abstração

em relação a requisitos de negócio, usuário

e software.

Quando?

13 de março de 2010, das 09h30min as 12h

Mais informações em:

www.guma-rs.org

PodcastsA BlueSoft há algum tempo vem presenteando a comunidade brasileira de agilistas, com um série de excelentes vídeos sobre Agile.

Vale muito a pena conferir em:

bluesoft.wordpress.com

CURTAS SBQS CARREIRA SBSI USABILIDADE

IX Simpósio Brasileiro de Qualidade de Software - SBQS De 07 a 11 de Junho - www.ufpa.br/sbqs2010/

Academia do AgileA primeira formação completa em Agile.

www.globalcode.com.br

Simpósio Brasileiro de Sistemas de Informação - 16 a 18 de Junho de 2010 - www.sbsi2010.com.br

Programa de Capacitação: Avaliação de Usabilidade12 a 13 de Maio-www.oncast.com.br/blog/?p=711

GUMA - Grupo de Usuários

de Metodologias Ágeis do RS/Brasil

RÁPIDAS[Visão Ágil - Community Journal - 01]

[10]

Conversamos com alguns profissionais de referência em nossa comunidade ágil, sobre qual a essência da agilidade na opinião de cada um deles. O resultado (que pode ser visto abaixo) foi um rico e inspirador texto sobre o que realmente é o movimento ágil e como o mercado pode se beneficiar disso.

Para Felipe Rodrigues - Engenheiro de Software da Fratech (SP), a essência ágil é:

“Estabe lece r um amb ien te

propício para o cultivo de confiança entre os envolvidos no projeto, de forma que uns confiem nos outros,

permitindo um ambiente mais flexível e menos burocrático e focado para a execução das tarefas que compões o projeto.

” Já para Samuel Crescêncio - CEO da OnCast Technologies (SC), a essência ágil é:

“ Penso que a real essência

de ser ágil está em como nos relacionamos com o nosso próximo. Ao longo dos anos, a p re n d i q u e e n t e n d e r o s princípios que sustentam as práticas, dominar as ferramentas

d e g e s t ã o , c o n h e c e r profundamente e aplicar as técnicas de engenharia são itens que estão entre os essenciais no desenvolvimento á g i l . En t re t an to , obs e r vo que ao ap l i ca r o

desenvolvimento ágil, muitas empresas pecam por não equilibrar corretamente as forças entre princípios, cultura, gestão e engenharia. Certamente, entender as necessidades em cada uma destas áreas é muito difícil e isto só pode ser alcançado com uma comunicação fluida entre os diversos setores da empresa. Comunicação fluida, todavia, não dignifica memorandos, e-mails, gráficos ou qualquer coisa do gênero. Comunicação fluida é a conversa franca e direta, de modo que possa criar relacionamentos fortes. Ainda, a predisposição de ambos os lados para entender os motivos alheios e a colaborar mutuamente em busca de um único objetivo é imprescindiível para se obter o sucesso. Portanto, concluo que não há como atingir o sucesso no desenvolvimento ágil de software sem construamos relacionamentos empáticos e verdadeiros, sendo esta, em minha opinião, a pura essência do desenvolvimento ágil.

” Renato Willi - Coordenação Colaborativa da SEA Tecnologia (DF), também compartilha seu pensamento sobre a essência ágil:

“ A essência do Agile pra mim está

em seus valores: na colaboração, c o m u n i c a ç ã o , a p r e n d i z a d o , aperfeiçoamento contínuo e respeito. É difícil resumir. Trata-se de uma nova forma de encarar o trabalho, talvez uma

" fi l o s o fi a " m a i s a d e q u a d a a o s trabalhadores do conhecimento, em contraposição à filosofia da era industrial.

”

OPINIÃO

A Essência Ágil

[Visão Ágil - Community Journal - 01]

[11]

E Luiz Cláudio Parzianello Agile Coach and Trainer da da Surya Gestão Digital (RS), acrescenta que:

“Muitos acreditam que o

Manifesto Ágil não passa de uma piada, enquanto outros acreditam que  ele marca  o início de uma m u d a n ç a n a h i s t ó r i a d o desenvolvimento de software. Alguns acreditam  que  tudo

isso é um mero modismo, enquanto out ros conqu is tam cont inuamente  melhor ias substanciais  na  qualidade e produtividade de suas equipes de desenvolvimento. Muitos acreditam que agilidade é assunto para pequenos, enquanto poucos já demonstraram que milhares de pessoas trabalhando de forma colaborativa e distribuída é coisa de gente grande. Pois bem, pude perceber ao longo dos últimos 10 anos, assessorando  empresas  e capacitando profissionais  em projetos de implantação de Metodologias Ágeis, que a  agilidade não está associada somente  a uma nova cultura de crenças e valores, mas principalmente a uma

nova busca de descobertas e iluminação. Iluminação no sentido de enxergar de vez que o desenvolvimento de software é um problema de logística  que deve ser sustentado por  uma forte cultura de comunicação e colaboração entre todas as partes interessadas num produto ou projeto de software. Logística no sentido de desenvolver competências para a  entrega rápida  de pequenos i nc remen tos de so f twa re de a l t a qualidade,  mantendo sempre  um  ritmo constante sustentáve l . Comunicação e co laboração no sentido  de  compreender  como a menor quantidade de software irá aumentar a vantagem competitiva de nossos clientes (fazer cada vez mais com cada vez menos). Se você promover de forma honesta a melhoria contínua de pessoas, ferramentas e métodos, você com certeza encontrará o pensamento Ágil e descobrirá que esse é o único caminho para o sucesso e a satisfação de sua equipe de desenvolvimento.

”

Olá amigo Agilista!

Essa foi a primeira edição do Visão Ágil Community Journal. Que têm como principal o b j e t i v o t r a z e r um novo f o rma t o d e disponibilização de notícias e conhecimentos para nossa comunidade de agilistas. Com esse novo formato, nossos leitores terão um conteúdo mais direto, mais simples e mais ágil (com entregas constantes).

Um cordial abraço:

Manoel Pimentel - Diretor Editorialcontato: manoel@visaoagil.com

Conselho Editorial:- Felipe Rodrigues de Almeida- Renato Willi

SIGA-NOS:

/visaoagil

Editorial:LEIA NOSSAS REVISTAS:

www.visaoagil.com

[Visão Ágil - Community Journal - 01]