R.I.P – Engenharia de Software

Atenção: Este é um post provocativo, então não se surpreenda com alguns argumentos radicais. O objetivo principal é gerar discussão e avançar a área de desenvolvimento de software.

Quando eu comecei a conhecer Engenharia de Software, era tudo lindo e maravilhoso. Eu li livros como o tradicional livro de Sommerville e toda aquela idea de fazer com que o  desenvolvimento de software chegasse mais perto das tradicionais engenharias fazia muito sentido para mim. Com isso, “ganhamos” o nome de Engenharia de Software.

Quem não lembra (ou vive no seu dia-a-dia) todos aqueles conceitos como gerenciamento de riscos, gerenciamento de mudanças, gerenciamento de projectos, gantt charts, gerenciamento de requisitos, mil e um diagramas UML, etc, etc??

Desenvolvimento de Software deixou de ser uma coisa artesanal para ser uma coisa um tanto quanto burocrática. E o que acontece quando se vira burocrático demais? Sua capacidade de reagir ao que seus clientes querem vai gradativamente diminuindo.

( Nesse momento é importante fazer uma observação para explicar que existem determinados domínios de aplicações que precisam de um controle e burocracia maior do que outros. Um software embarcado que é safety-critical precisa naturalmente de um controle e rigidez maior no seu desenvolvimento. No entanto, uma aplicação web que pode ser deployed muitas vezes ao dia e não um impacto muito grande pode muito bem ser desenvolvida sem maiores burocracias )

Bom, um grupo de pessoas já chegaram a essa conclusão lá em 2001 e eles fizeram nascer uma coisa chamada Manifest Ágil! Esses caras entenderam que existem coisas mais importantes no desenvolvimento de software do que seguir todo o conhecimento que (ainda hoje) tentamos adiquirir de outras disciplinas. Que saber porque??

Porque [praticamente] todo software é SINGULAR!!

Nas outras engenharias é claro que existem desafios, mas a maioria dos projetos como construir um ponte, ou uma casa, ou um carro é um conhecimento estabelecido. E uma vez contruido/montado o primeiro carro (que por sinal, provavelmente vai demorar mais do que os demias), se segue exatamente o mesmo processo para montar os proximos duzentos mil.

No mundo do software, a diferença é que [praticamente] todo software é Singular, [praticamente] todo software é igual ao primeiro carro que precisa ser construido. [praticamente] Todo software é único. Cada linha de código, cada classe, cada método, cada framework. Algumas coisas contribuem para isso como, por exemplo, a velocidade que surgem novas tecnologias, novas linguagens de programação, novos frameworks javascript (os frontend developers sabem do que estou falando).

O post vai ser finalizado com algumas perguntas, que podem gerar debates interessantes….

Levando em consideração que [praticamente] todo software é NOVO, faz realmente sentido tentar se parecer mais e mais com as engenharias tradicionais? Ou deveríamos achar qual é o caminho que faz mais sentido para o desenvolvimento de software  (a depender da área de aplicação?

Deveríamos nos livrar do nome Engenharia de Software? Ou faz sentido tentar se beneficiar de conceitos já estabelecidos nos outras engenharias?

Deixa aí teu comentário sobre esse tópico 😉

Brasil Campeão da Copa do Mundo de Testes de Software

Uma semana se passou após a divulgação do resultado das finais, e talvez nesse momento eu já consiga compartilhar com vocês, de maneira mais precisa, como foi essa experiência.

Após o anúncio de nossa vitória na etapa continental, começamos uma série de preparativos, que consistiram desde a parte logística da viagem (passagens, hotel, documentos…), as demandas da organização (fotos, vídeos, entrevista…) e a preparação técnica para a organização.

Na parte técnica, analisamos o nosso desempenho na fase continental, destacando os pontos fortes que precisavam ser mantidos e os pontos de melhoria, onde precisaríamos realizar ajustes. A partir dessa análise nos dividimos, de modo a realizar as tarefas, que consistiam desde ajustes na estratégia de testes, test report e principalmente atividades de estudo e seleção de ferramentas para áreas como acessibilidade, segurança e usabilidade.

A competição:

A etapa final seguiu o mesmo modelo da continental, tivemos 3 horas para validar a aplicação (Comércio Eletrônico) e enviar um Test Report, que deveria abranger a estratégia utilizada, findings, recomendações e análise do produto. O grande diferencial nessa fase, foi que os jurados, equipe de reportagem e platéia podiam nos interromper com perguntas durante as três horas, o que aconteceu algumas vezes e exigiu jogo de cintura para responder e retomar o trabalho sem perder a concentração.

Este slideshow necessita de JavaScript.

Durante a prova final, utilizamos diversas ferramentas de apoio, abaixo aponto algumas:

  • Google Docs: Colaborativamente alimentávamos o test report, durante a execução, adicionando os defeitos encontrados e informações relevantes.
  • Trello: Antes da competição preparamos um quadro virtual, onde listamos as áreas de teste, e pudemos nos organizar, com o objetivo de evitar duplicação de trabalho e assegurar uma melhor cobertura.
  • MindMeister: Ferramenta para criação de mapas mentais, utilizada para descrevermos nossa estratégia de maneira mais visual.
  • HP Pronq Agile Manager: Ferramenta oficial da competição para gerenciamento dos defeitos.
  • Acessibilidade: Utilizamos ferramentas online, como Wave e daSilva, com o objetivo de apontar falhas de acessibilidade na estrutura do código.
  • Segurança: O Firebug foi uma das ferramentas que utilizamos para identificar potenciais falhas de segurança.

Placar com contagem de bugsAo final das três horas de trabalho intenso, ficou claro para nós ao conversarmos com alguns dos jurados e organizadores, que além das capacidades técnicas em testes, eles também estavam avaliando aspectos relacionados às metodologias ágeis, como a organização da equipe e comunicação interna e com o cliente.

Divulgação do resultado:

No dia seguinte, durante o Keynote de abertura da conferência, recebemos a premiação da etapa continental.

premiacao_etapaContinentalEnquanto, que a divulgação do resultado final aconteceu apenas a noite, durante a festa temática, organizada pelo evento. E claro, que ficamos muito felizes com o resultado final, representando o Brasil e elevando a nossa comunidade de testadores a uma posição de destaque.

Brasil Campeão

Por fim, um agradecimento especial a toda a organização do evento, toda estrutura e apoio fornecido antes, durante e após o evento foram impecáveis. Além da competição, pudemos aproveitar os 3 dias da conferência, que também foram excelentes e em breve compartilharei com vocês um pouco das palestras e workshops que pude assistir.

S.O.L.I.D – Coisas que todo programador deveria saber

Esse post é mais um da série “Coisas que todo programador deveria saber” (talvez o primeiro do BytesDontBite [BdB] com esse título na verdade :P).

Hoje vou falar um pouco sobre o S.O.L.I.D, que é na verdade um acrônimo onde cada letra representa um “princípio” de design de orientação a objetos.  A importância desses princípios é imensa. Então vamos lá:

  • S (Single Resposability Principle) – Toda classe deve ter uma única responsabilidade, e essa responsabilidade deve ser completamente encapsulada por essa classe. Parece uma coisa simples, mas a grande maioria dos problemas que vejo por aí, acontecem pelo simples motivo de termos classes (e métodos) gigantes que fazem tudo o que você pode imaginar. Talvez esse seja, ao meu ver, o mais importante (e o mais simples) desses princípios. Obviamente ele é muito relacionado aos conceitos de (alta) coesão e (baixo) acoplamento, e também é bem descrito e detalhado pelos princípios do GRASP (tópico para o próximo post dessa série)

    Arquitetando…
  • O (Open/Closed Principle) – Todas as entidades do software (classes. módulos, métodos, …) deveriam ser abertas  (open) para extensão e fechadas (closed) para modificação. Isso significa que essas entidades do software tem que permitir uma mudança de comportamento sem a alteração do seu próprio código fonte. Em uma conclusão bem óbvia e simplista, estamos falando de usar mais interfaces e classes/métodos abstratos, que podem facilitar a mudança não dolorosa de comportamento de algumas entidades.
  • L (Liskov Substitution Principle) – Qualquer objeto do tipo X (que é subtipo Y) deveria poder substituir um objeto de tipo Y sem alterar as propriedades básicas do sistema (corretude, etc).
  • I (Interface Segregation Principle) – Prega que as interfaces tenham somente os métodos que serão usados por quem vai implementar essa interface. Ou seja, separar (segregar) interfaces que contenham muitos métodos, em interfaces menores, de forma que, quem implemente a interface, não seja forçado a implementar métodos que não são usados naquele contexto.
  • D (Dependency Inversion Principle) – Esse princípio prega uma forma de desacoplamento, aonde os módulos tem que depender de abstrações (leia-se interfaces) ao invés de depender de classes concretas. Isso se aplica principalmente quando falamos das dependências entre as camadas arquiteturais de um determinado sistema. Uma forma de inversão de dependência é a Injeção de dependência.

Como você pode notar, todos esses princípios meio que se completam de forma a atingir o objetivo que é um design flexível e de fácil manutenção. Espero que tenha sido útil, e até o próximo post dessa série, onde falaremos sobre o GRASP 😉

Estatisticas do BdB no ano de 2013 (Antes tarde do que nunca :P)

Se você está curioso por algumas estatisticas sobre o ano de 2013, aqui está, basta clicar na figura abaixo e seguir o link 😉

Estatisticas do BdB no ano de 2013 (Antes tarde do que nunca :P)

Pedacinho de texto das estatisticas:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 22,000 times in 2013. If it were a concert at Sydney Opera House, it would take about 8 sold-out performances for that many people to see it.

Click here to see the complete report.

Agilidade é Ritmo!

Assitir palestras de alguns gurus é sempre interessante! Mesmo quando a palestra não está legal, em algum momento você pode escutar alguma frase ou alguma explicação que pode mudar sua vida. Eu diria que é mais ou menos como um atacante de futebol que é artilheiro, mas está jogando uma péssima partida, mas o técnico o deixa em campo pois a qualquer momento ele pode fazer um gol!

Dito isto, eu estava em uma longa palestra com um artilheiro, mas a palestra não estava tão interessante. Mas em determinado momento, falando sobre agilidade,  ele disse: “Agile is about rhythm!” Essa frase então chamou minha atenção e fiquei atento a explicação do que isso significava, e fez sentido pra mim.

Se você participa de um projeto que tem um determinado ritmo como por exemplo entregar um release do software a cada 6 meses, você tem “muito tempo” para pensar/fazer/detalhar requisitos, “muito tempo” pra implementar e por aí vai. É óbvio que você vai terminar fazendo mais do que o necessário para o momento e talvez não consiga finalizar tudo, além de colher o feedback muito tarde (em 6 meses tudo pode mudar).

No entanto, se você tem um ritmo de fazer um release por mês, você tem menos tempo pra focar em vários requisitos, por isso você só seleciona alguns deles (os mais importantes do ponto de visto do cliente), você nao tem tanto tempo pra discutir requisitos em um nível de detalhes muito aprofundado (a  não ser que realmente seja preciso) e você não tem tempo para perder tempo com reuniões sem sentido e etc, então você foca em desenvolver aquilo que tem pra ser desenvolvido de forma a receber feedback o mais rápido possível e mudar o mais rápido possível (antes que o custo da mudança seja muito caro ou inviável).

Ah, acho que tem um cenário pior do que os dois que apresentei, que é o caso de você não ter ritmo nenhum!

E você o que acha? Qual o ritmo que faz mais sentido para você ou para sua empresa?

O fator ônibus *

O post de hoje é simples e curto mas apresenta um conceito que é muito importante no dia-a-dia das empresas e dos projetos (principalmente de software, mas não necessariamente se limita a software).

Já participou de algum projeto onde uma ou talvez duas pessoas possuiam todo o conhecimento sobre o projeto? Acho que não é muito difícil isso acontecer, eu mesmo já participei de alguns. Alguns onde outra pessoa tinha todo o conhecimento acerca de um projeto, e outros onde eu mesmo tinha o conhecimento “concentrado” em mim (não porque eu queria, mas por conta das circunstâncias).

O fator ônibus * (do inglês bus factor), significa a quantidade de pessoas, que se forem atropeladas por um ônibus, farão o projeto desandar, ou até mesmo inviabilizar a continuidade do projeto. É óbvio que quanto maior essa medida melhor, pois dificilmente 10 pessoas são atropeladas por um ônibus no mesmo momento.

Moral da história: Se o seu projeto tem o fator ônibus igual a 1 ou 2, você corre sérios perigos! Então corra atrás, compartilhe o conhecimento, treine as pessoas, sugue o que puder sugar dos que tem mais conhecimentos, pergunte, leia, converse e se informe para o bem do seu projeto e da sua equipe!

* Observação: Vale a pena lembrar que o fator ônibus não significa ser literalmente atropelado por um ônibus. Ser atropelado por um ônibus pode significar: Algum membro da equipe conseguir um outro emprego, alguém sair de licença maternidade, alguém decide mudar o estilo de vida, alguém pedir demissão, alguém simplesmente sair de férias por 1 mês (parece absurdo né?), ou realmente alguém for atropelado mesmo por um ônibus 😛

Aprenda as funções do Scrum Master em 5 minutos

O Scrum é uma das metodologias ágeis mais utilizadas pelas empresas de TI, porém diversos pontos ainda geram dúvidas: Papéis, práticas, ferramentas, etc. Nesse contexto, cada equipe acaba realizando seus ajustes baseados na própria experiência e na natureza do projeto.

O Vídeo, abaixo, faz uma representação divertida do papel do Scrum Master na equipe. São apenas 5 minutos, que de maneira divertida traduzem os principais aspectos da atuação desse profissional.

As principais funções do Scrum Master destacadas pelo vídeo são:

– Assegurar a eficiência e comprometimento de todos ao Daily Meeting.

Evitar que o cliente interfira diretamente no trabalho da equipe durante a Sprint.

– Assegurar que a definição de “Pronto” esteja clara para toda a equipe. “Qualidade é chave!”.

Gerenciar o Quadro de Atividades do Scrum.

Remover impedimentos, permitindo a produtividade máxima da equipe.

Proteger e Liderar o time.

Consulte nossa seção de agilidade, e confira outros posts relacionados a Scrum.

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Já conhece o eXtreme Go Horse Programming?

Você conhece o eXtreme Go Horse (XGH) Programming? Não?? Então não perca tempo e veja aqui essa maravilhoso processo 🙂 Será que a vida de desenvolvimento de software fica mais fácil depois das dicas desse processo? 😀

1- Pensou, não é XGH.

XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.

XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer.

Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH.

XGH tende ao infinito.

4- XGH é totalmente reativo.

Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba.

Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update.

Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam.

7- XGH não tem prazo.

Os prazos passados pelo seu cliente são meros detalhes.

Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script maluco).

8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.

Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro.

O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.

9- Seja autêntico, XGH não respeita padrões.

Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10- Não existe refactoring, apenas rework.

Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).

11- XGH é totalmente anárquico.

A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12- Se iluda sempre com promessas de melhorias.

Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10).

13- XGH é absoluto, não se prende à coisas relativas.

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14- XGH é atemporal.

Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.

15- XGH nem sempre é POG.

Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré.

Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem.

Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo.

Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19- Se tiver funcionando, não rela a mão.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos.

Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente.

O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22- O problema só é seu quando seu nome está no Doc da classe.

Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.

Fonte: http://gohorseprocess.wordpress.com/extreme-go-horse-xgh/

Esse texto é uma brincadeira, você pode me xingar no twitter: @maribalbe

É melhor focar no problema? ou na solução?

Cabra-cega – Imagem Retirada de http://fadadacaixinhademusica.blogspot.de/

Cabra-cega é uma brincadeira de criança onde alguém coloca uma venda nos olhos e fica com uma vara na mão para tentar acertar um vaso de barro (cheio de doces e gostosuras) e quebrá-lo, dessa forma não só você ganha os doces, quanto todos ao seu redor tb correm para os doces e assim todos saem ganhando! Não sei no restante do Brasil, mas pelo menos em Recife essa é uma brincadeira bem comum. O detalhe dessa brincadeira é que todos os outros ao seu redor ficam dando dicas apra vocês chegar mais perto, e eventualmente acertar o vaso.

Trazendo isso para nossa realidade de TI, um ponto que venho percebendo com uma certa frequência  é que geralmente estamos fechando projetos e contratos onde nosso cliente chega até nós com uma “solução” para o problema dele, e nós geralmente vamos direto atacar essa pseudo-solução! Isso acontece mais frequentemente em casos onde o cliente tem um certo conhecimento de TI, de desenvolvimento de software, então ele já chega com a solução bolada na sua cabeça! E como cada vez mais temos gente que entende [um pouco que seja] de TI, temos essa situação acontecendo cada vez mais.

Me sinto um pouco jogando cabra-cega. Estamos lá, escutando as dicas e as direções dos outros, mas não sabemos exatamente ONDE está o problema! Estamos com uma venda nos olhos tentando caminhar na direção que os outros estão gritando! E eis que chega o grande conselho desse post (que até parece um pouco óbvio):

Tire a venda dos olhos!!

Faça isso, por favor! Procure entender sempre o problema que está por trás de uma solução proposta, entenda o porquê por trás daquilo e procure identificar outras possíveis saídas para aquele problema. Talvez a solução proposta inicialmente pelo cliente seja realmente a melhor, mas talvez seja a pior também. E você só vai saber se tirar a venda dos olhos! TI é pensar! Muitas vezes somos pagos não para implementar algo para o cliente, mas para PENSAR na situação dele e identificar saídas viáveis!

Vale salientar que isso se aplica a diversos contextos dentro do desenvolvimento de projetos, e ainda mais, se aplica a diversas outras áres além de TI!

Cargo cult, eXtreme go horse e afins

Depois de alguns anos escrevendo código, e também, observando códigos de outras pessoas, meus códigos antigos e código legado percebi alguns comportamentos e padrões entre o aptidão e/ou tempo de experiência X design do código das pessoas.

Investigando esses padrões, consegui entender melhor os “porquês” da incidência, em projetos grandes e bem financiados, de fenômenos como Cargo cult, eXtreme go horse, programação orientada a gambiarra e afins.

Contextualizando – Cargo Cult, descrito por Steven C. McConnell no livro Code Complete, é o fenômeno cultural observado em tribos indígenas/aborígenes, durante a segunda guerra mundial, que envolviam impactos entre duas civilizações, sendo uma moderna em aspectos tecnológicos e outra primitiva. Durante a guerra, soldados americanos necessitavam pousar em ilhas desertas para recarregar combustíveis ou armar mísseis, entretanto muitas dessas ilhas visitadas eram habitadas por esses povos. Ao ocorrer o choque das civilizações, os primitivos imaginavam que os soldados, com todo seu aparato, fossem deuses. Depois da partida da civilização moderna, os indígenas costumavam fazer rituais em determinados períodos do ano com o intuito de invocar os supostos deuses soldados, mudando assim o comportamento cultural/religioso do local.

Ao trazemos esse conceito para computação temos situações clássicas que vivemos no nosso dia a dia, talvez a mais popular seja : Ao perguntar a um desenvolvedor/gerente/engenheiro: – Para que serve esse pedaço de código? Ele te responde: – Não sei, mas não mexe aí! Pode parar de funcionar! Em outras palavras o desenvolvedor possui um tipo de ritual para realizar determinadas tarefas, como inserir código legado, bibliotecas, classes que não necessariamente são úteis para a implementação do mesmo, acarretando a incompreensão sobre o sistema de forma geral.

Para falar de eXtreme go horse temos que esquecer de qualquer boa prática, Scrum, Kanbam, Pair Programming ou qualquer coisa que lembre engenharia de software, isto é, se focar em escrever código e vencer o prazo. Infelizmente é uma realidade triste do mercado, que muitas vezes pode indicar falta de comprometimento do time e falta de alinhamento de interesses entre equipe/empresa ou má gestão do líder.

A verdade é que o caminho para esses cenários(caóticos) são convergentes podendo ser resumidos em falta de maturidade da parte do líder ou desenvolvedor, insegurança, pressão, contratos com prazos irreais, falta de comprometimento da equipe, etc. Muitas vezes esses motivos também podem acarretar um efeito dominó, piorando a situação exponencialmente.

Claro, podemos determinar inúmeras hipóteses para a solução do problema de desenvolvimento de software, entretanto, é fato que a solução está bem longe de determinar metologias rígidas ou mudar conceitos das mesmas. Temos que ir além, precisamos mudar conceitos, quebrar paradigmas, criar um time com determinação e com aptidão, mensurar e explorar potenciais, trabalhar com dificuldades, amadurecer a equipe e acima de tudo cair na real.