A apresentação em si é básica, fala sobre SCRUM, seus papéis, responsabilidades, atividades e ciclo de vida. Nesta apresentação tento focar na desmistificação de alguns conceitos e idéias simples que, às vezes, as pessoas que ainda não conhecem o SCRUM possam ter formado naquelas conversas de corredor, e claro, mostrar alguns benefícios e problemas reais que a adoção do SCRUM trará para a organização e para as pessoas envolvidas.

A apresentação está disponível aqui no meu slideshare e também no blog. A conversão/compressão do slideshare deixou a apresentação um pouco mais feia, quem quiser faça o download do arquivo que este estará bem melhor.

Dúvidas, críticas e sugestões farão meu dia um pouco melhor, fique a vontade para me procurar.

As inscrições já estão abertas e o curso será ministrado nos dias 05 e 06 de novembro, em Vitória, dependendo do número de inscritos atingir a quantidade mínima. Ele será ministrado num lugar compatível com o número de inscritos e tem duração de 16 horas.

O curso inédito no Espírito Santo será ministrado pelo instrutor Alexandre Magno, da AdaptWorks, único instrutor certificado pela Scrum Alliance no Brasil. O curso é um sucesso no Brasil inteiro e altamente requisitado em vários estados, tanto pelo fato de ser um curso oficial quanto por ser a porta de abertura para quem deseja não apenas conhecer mas também se certificar nessa metodologia ágil.

O participante ganha ao final do curso um certificado de Scrum Master, que é o início para a especialização na metodologia e associação na Scrum Alliance.

Para garantir sua vaga, envie um e-mail para contato@giran.com.br com seus dados de contato. Entraremos em contato para informar sobre o curso, preço, modos de pagamento e outros detalhes.

Mais detalhes sobre o curso no blog da Giran.

Onde: Anfiteatro da UVV – Vila Velha

Quando: 21/03/2009 – 08:30h

Recepção e credenciamento: 08:30h

Palestras

• 09:00h – Abertura / Apresentação Agile-ES
• 09:30h – Desenvolvimento Ágil com SCRUM
  • Palestrante: Jeveaux é fundador e diretor na Giran Soluções e Ensino, onde trabalha com desenvolvimento de plataformas e serviços para internet de alta performance e escalabilidade utilizando metodologias ágeis como XP e Scrum. É fundador do Grupo de Usuários Java do Espírito Santo (ESJug), do grupo de metodologias ágeis (Agile-ES) e também administrador do PortalJava.com. Jeveaux possui mais de 8 anos de experiência em desenvolvimento de sistemas em diversos segmentos onde teve experiências na globo.com, Vale, Claro, Xerox, CEF dentre outras. Grande entusiasta e participante ativo das comunidades de Java, Agile, Ruby e Linux, mantém um blog em http://jeveaux.com.
• 10:45h – Lean e Kanban: Sustentabilidade e Agilidade em Projetos de Software
  • Palestrante: Alisson Vale tem mais de 15 anos de experiência com desenvolvimento de software e a mais de 6 anos lidera projetos de software dos mais variados tipos e tamanhos. Hoje é Líder de Projeto e Diretor da Phidelis Tecnologia, onde lidera a equipe de desenvolvimento da solução acadêmica oferecida pela empresa.
• 12:00h – Encerramento

Inscrições

https://spreadsheets.google.com/viewform?hl=en&formkey=cFhQbVVRWUFNZEFTQ2dxX2RIWEVhQ2c6MA..

A inscrição é gratuita e obrigatória. Somente os inscritos receberão certificado de participação.

Apoio

• UVV – Centro Universitário Vila Velha

Organização e Realização

• Agile-ES
• Giran Soluções e Ensino
• Phidelis Software Acadêmico

O que muitos não vêem é que, com isso, a receita para o fracasso já está praticamente concluída. O trabalho e esforço de semanas ou até meses onde o arquiteto deu tudo de si, não passa, simplesmente, da pura arte da adivinhação, de previsão do futuro, de achismo e nada mais. O que ele achou que o cliente desejaria, o tempo que ele achou que iria demorar, os prazos que ele tirou da cartola e os resultados que ele sonhou acontecer dificilmente serão alcançados. Isso não acontece por falta de capacidade do arquiteto, pelo contrário, em alguns casos ele é realmente O cara da empresa e possuidor de vasta experiência, mas tentar prever o futuro não é uma ciência exata.

Apenas uma observação aqui: Não sou contra o levantamento de requisitos e especificação de escopo, pelo contrário, acho que é um trabalho de extrema importância, apenas não concordo com a forma que este trabalho é feito na grande maioria dos projetos, onde o pensamento e a organização em cascata impera.

O fracasso numa situação dessas poderá vir quando o cliente, no meio do projeto, resolver mudar tudo. O arquiteto terá que trabalhar mais alguns meses em um novo escopo? O cliente entenderá que deverá pagar por mais alguns meses de replanejamento de escopo? Como o seu escopo reagirá a mudanças, ele foi preparado para isso?

Ou quando ao final do projeto, somente ao final do projeto, uma versão usável for apresentada ao cliente e ele achar que você se enganou e apresentou a solução de um outro cliente a ele, tamanha a discrepância entre as expectativas do cliente e da empresa. E agora, como fica a situação? Inicia-se um novo projeto!? E quem pagará por isso?

Ou no pior dos casos, durante o desenvolvimento do projeto vê-se que o que o arquiteto previu para 10 meses de trabalho com uma equipe de 5 pessoas estava completamente furado, você vai precisar de 20 meses. Então qual é a brilhante ideia? Aposto a minha sacola de mendorato: “- Vamos dobrar a equipe, com 10 pessoas conseguiremos diminuir o prazo pela metade e assim ficaremos dentro do esperado”. É tiro-e-queda, será um grande fracasso. Ter um escopo flexível e incremental seria muito melhor do que incrementar a equipe para seguir o escopo. Afinal de contas, desde quando nove mulheres juntas são capazes de gerar um filho em um mês? Manusear prazos, expectativas e custos de um produto desta forma, definitivamente não dá certo.

Existe ainda um outro lado, aquelas pessoas que não querem se preocupar com problemas de escopo, que não querem ter problemas ao final do projeto se tiverem que discutir com o cliente sobre determinada funcionalidade está certa ou errada ou se deveria existir ou não, estas pessoas são as adeptas do escopo fixo.

Eu costumo dizer que, em projetos com escopo fixo só têm uma certeza: ele irá fracassar!

O fracasso nestes projetos não precisa ser necessariamente a não entrega do produto. Isso quase sempre acontece, mas milagres podem acontecer e o projeto pode ser concluído e entregue no tempo, mas ainda assim será um fracasso. Será um fracasso para o seu cliente, que demandou o projeto. Assim como dois mais dois são quatro, eu aposto o meu mendorato de novo que o seu cliente certamente mudou de idéia em vários pontos durante o desenvolvimento do projeto, mas você, esperto que é, já tinha o seu escopo fixo e para não sacrificar a “entrega” e seguir o maldito escopo, esfregou na cara do seu cliente que ele não poderia mudar nada, que ele não tinha esse direito, que estava escrito no escopo assim como é gravado em pedra e nada daquilo poderia mudar, em hipótese alguma, e mais, se ele fosse teimoso e insistisse em mudar teria uma saborosa multa à sua espera.

Sem dúvida esse cliente não estará com você num próximo projeto. Este é um tipo de fracasso que é muito pior que o anterior, certamente. Seria preferível não entregar tudo o que estava no escopo, renegociar o escopo, incrementá-lo ou decrementá-lo, mas entregar tudo o que o cliente pediu durante o projeto do que ignorar e trocar a sua opinião por um documento que foi feito em alguns dias ou horas numa tentativa de prever o futuro, que acaba quase sempre de modo frustrante para ambas as partes – para a empresa que trabalha desta forma, nem tanto, pois a essa altura ela já terá recebido todo o orçamento do projeto.

Trabalhar com o escopo de forma iterativa e incremental não é nenhum bicho de sete cabeças, seu pescoço não estará na corda desde que todas as expectativas estejam alinhadas, insira o seu cliente no projeto, faça-o participar de todas as etapas e ele mesmo verá e terá consciência de que em determinados pontos o escopo precisa mesmo ser alterado – para mais ou para menos. Aprenda a negociar e gerenciar expectativas com o cliente e o escopo passará a ser o grande amigo do seu projeto.

Além dos links dos artigos no último parágrafo, o Manoel Pimentel disponibilizou uma ótima apresentação sobre Gestão de Requisitos através de práticas Ágeis e Enxutas, que mostra extamente algumas das formas de se trabalhar com escopo incremental e iterativo.

Geralmente os gerentes e diretores (na maioria das vezes) serão duros e contra qualquer tipo de mudança simplesmente pelo fato de a empresa ter gastado centenas de milhares de dinheiros, logo, pensarão por muito tempo que isso (metodologia customizada) deverá dar algum resultado, o que acaba não acontecendo na maioria da vezes. Essa negligência e fraqueza em assumir logo o prejuízo e tentar mudar – para melhor – acaba acarretando em prejuízos muito maiores no futuro, demissões em larga escala, troca de diretoria e por aí vai, já vi isso antes.

Outra justificativa muito usada para evitar mudanças será a falácia de que “em time que está ganhando não se mexe“. Grande parte das vezes falta coragem ou maturidade para enxergar que o time não está ganhando e que precisa ser modificado, sim. Também não é incomum encontrar situações onde a mudança não é vista com bons olhos pois as metodologias pra inglês ver, as certificações (de parede) e demais honrarias são mais valorizadas do que às pessoas e o produto que a organização entrega, então, nesses casos pouca importa se está bom ou ruim.

Mas onde eu quero chegar com esse post? Todas estas situações que falei até agora são conhecidas pela maioria dos desenvolvedores e sabemos que são situações difíceis de serem vencidas, eu mesmo já fracassei em algumas tentativas de mudança diante de tais situações e felizmente já obtive muitos sucessos também.

Recentemente, almoçando com um grande amigo acabamos caindo no papo sobre as nossas empresas e clientes e falamos sobre um caso em especial. Um cliente em que já haviámos trabalhado, onde enfrentamos todas aquelas situações anteriores de uma só vez – acreditem! – continuava na mesma. Com os mesmos problemas de sempre (atraso), mesmos gerentes/diretores e as mesmas pseudo-metodologias e regras internas, a única coisa que não era a mesma eram os clientes, nem preciso dizer o porque.

Mas a disucssão não chegou a ser prática ao ponto de “seja ágil”, “você precisa praticar TDD/BDD”, “agarre-se ao PMBok” ou “se você não aderir ao Scrum não vai ter jeito”, nada disso, não estávamos questionando a metodologia, nem as regras em si, mas sim a resistência em mudar. Fazendo uma breve retrospectiva vimos que 100% dos últimos projetos não haviam sido entregues na data prevista, desses 100%, 100% tiveram o orçamento o estourado e, desses 100%, 100% não atenderam a todas as expectativas do cliente e foram entregues com features a quem do esperado.

Diante de um cenário como esse, por que não deveríamos tentar mudar? Por que não tentar fazer alguma coisa diferente? Se estamos “sendo ágeis com scrum+xp” por que não tentar um modelo mais lento!? Se o RUP/MPS.Br/QualquerCoisa não está dando certo, por que não mudar e tentar outro? Se as metodologias e regras internas não estão sendo suficientes, por que não deveríamos tentar outra? Com um histórico de atrasos e fracassos, o que poderia acontecer de pior, atrasar 9 semanas ao invés de apenas 7!?

Não fique na mesma por muito tempo, mesmo que o seu time esteja ganhando e esteja realmente na frente, experimente mudar, tente melhorar, evoluir. Avalie sempre não só as mudanças, mas veja o que elas poderão fazer por sua organização, por seus projetos, se algo pode ser melhorado, vá em frente, se algo pode piorar, avalie o seu presente e passado e veja se vai, de fato, piorar, ou se você já estava “na pior” e não estava se dando conta. Não seja cético correndo atrás do que está na moda, na crista da onda, isso nem sempre será bom pra você, mas procure sempre avaliar sua situação e ver o que você pode tentar melhorar e o que pode, sem prejuízos, continuar na mesma.

Então, se você também faz rascunhos sofríveis em papel chamex ou se você também tem o péssimo costume de perder ou inutilizar as cartas entre uma sprint e outra e precisa ficar fazendo tudo de novo, aproveite o modelo disponibilizado pelo Flavio e mande fazer os seus cartões de verdade numa gráfica.

Para quem não conhece ou ainda não tem a sua certificação de agilista, CORRA e tire logo a sua também. Vocês vão ver como o mercado se tornará receptivo e aberto, novas oportunidades surgirão o tempo todo, e o salário, aham, o salário você nem vai acreditar:

Certification for Software Professionals. Join the Agile revolution!
http://www.agilecertificationnow.com/
Become a Certified Agile Software Specialist! The Fastest Certification On The Web

Brincadeiras de lado, essa “certificação” é apenas uma paródia, uma brincadeira. É óbvio que isso não vai mudar nada na carreira e nem muito menos vida de ninguém. Mas ainda assim, apesar da brincadeira da certificação, o site passa uma mensagem importante que devemos nos atentar.

Alguns trechos do texto do site expressam exatamente o que muita gente quer, parece brincadeira ao ler, mas já vi muita gente que acreditaria de fato nesta certificação pois é exatamente o que sempre buscaram, talvez eu até me incluiria neste meio se as certificações resolvessem algo de fato. Mas vejamos, por exemplo:

There are no tests, classes, books or interviews!
…
Receive the benefits and admiration that comes with certification!

Bem ao estilo de comercial milagroso de televisão, aqueles do tipo resolva todos os seus problemas em 1 minuto. Até que seria bom se funcionasse, mas as coisas não são necessariamente assim. E mesmo que hajam muitos livros, testes, provas e entrevistas, isso tudo também não vai garantir nada e nem muito menos servir como argumento ou base para muita coisa, e não vai mesmo.

O que eu mais ouço por aí é que: - A certificação não vai mudar nada mesmo, mas pelo menos vou ter respaldo no que eu falar, pois a certificação me dá esse crédito. Será assim mesmo? Eu já participei de tudo que é tipo de projeto com todo tipo de gente que se pode imaginar e sinceramente, dos poucos que eram certificados, muitos não faziam valer este tal “respaldo” da certificação, muito pelo contrário, as discussões, provas de conceitos e o dia-a-dia do desenvolvimento eram sempre os mais engraçados complicados, devido justamente ao fato de serem ignorantes o suficiente para achar que tinham tal crédito (respaldo) para falar e fazer o que bem entendessem, para tomar decisões teóricas.

E o pior de tudo é que quase todas as situações anteriores aconteceram com pessoas com certificações técnicas, o que é pior ainda, pois nestas certificações uma boa base de leitura, estudos e testes deveriam, ao mínimo, colaborar bastante com o conhecimento técnico destes profissionais.

Não desmereço quem tem ou corre atrás de certificações diversas, muito pelo contrário, sejam elas técnicas ou não eu valorizo e respeito muito a dedicação e o esforço que cada um teve pra conseguir seus certificados. Valorizo sim, os esforços, os certificados geralmente não. Mas por que não? É simples: Certificações não funcionam! Em alguns casos certificações técnicas ajudam muito, sim, mas ainda não servem como regra ou pré-requisito para definir o conhecimento de ninguém, quem dirá sua capacidade como um líder, coach, etc.

Não funcionam por um fato bem simples: ninguém vai se tornar um profissional melhor simplesmente porque leu um livro ou assistiu algumas aulas ou fez uma ou duas dúzias de simulados e testes e no final recebeu um certificado. Isso tudo é um sonho, as coisas não funcionam assim no mundo real e nem tendem a funcionar assim um dia. E o maior problema disso tudo é a falta de capacidade da muitos gerentes/diretores para enxergar isso, hoje em dia as companhias estão buscando cada vez mais profissionais certificados sem dar a mínima para o real conhecimento e experiência deste profissional.

Por essas e outras que não é muito difícil encontrar profissionais (que dizem ser) líderes, gerentes, arquitetos, consultores e qualquer outro cargo bonito que você quiser e que, vivem tomando decisões erradas, não assumindo erros, orientando sem saber equipes que também nada entendem o que lhe fora orientado, e por aí vai.

Onde quero chegar com este post? Talvez nem eu saiba, ele está sendo só um desabafo (antigo) e um apelo para que todos que lerem o post também leiam isso, isso e isso.

Só um apêndice ao post

O mais legal é o erro que aparece por alguns segundos antes do “resultado” da certificação. Claro que não é um erro de verdade, faz parte da brincadeira.

Exception: com.agilecertificationnow.certify.CertificationException
    at CertifiedAssesRepository.add() (compiled source)
    at MakeMoneyThroughCertificationController.handleRequest() (compiled source)
    ...

Avoiding Development Disaster

O SCRUM que estou me referindo é um método simples e rápido para gerir o ciclo de desenvolvimento de software, e sim, teve seu nome baseado no SCRUM do Rugby.

Agilidade, quem não tem lido esta palavra ao menos uma vez por dia? Pois é, esta é a bola da vez, linguagens e ferramentas que facilitam e aceleram o desenvolvimento tem aparecido aos montes, evoluções em várias outras linguagens de programação para acompanhar esta tendência também não param de surgir e isso é bom? Sim, eu diria que é excelente, mas não basta o desenvolvedor ser ágil, será que a equipe como um todo está preparada pra isso, o analista, consultor de negócios e o seu gerente, são ou adotam práticas de gestão tão ágeis quanto você? Talvez essa pergunta renda outros posts por aqui.

O Scrum tem como objetivo principal, definir um processo para projeto e desenvolvimento de software, que seja focado nas pessoas e que seja indicado para ambientes em que os requisitos surgem e mudam rapidamente. O Scrum também é considerado um método específico para o gerenciamento do processo de desenvolvimento de software.

O Scrum baseia-se ainda, em princípios como: equipes pequenas (+- 7 pessoas), requisitos que são pouco estáveis ou desconhecidos, e iterações curtas. Divide o desenvolvimento em intervalos de tempos de no máximo 30 dias, também chamadas de Sprints. Este método não requer ou fornece qualquer técnica ou método específico para a fase de desenvolvimento de software, apenas estabelece conjuntos de regras e práticas gerenciais que devem ser adotadas para o sucesso de um projeto. As práticas gerenciais do Scrum são: Product Backlog, Daily Scrum, Sprint, Sprint Planning Meeting, Sprint Backlog e Sprint Review Meeting.

Numa próxima oportunidade, falarei um pouco a fundo das práticas do Scrum. Por enquanto, quem tiver interesse no assunto, vai começar um curso de Scrum na Caelum e também tem a lista do Scrum-Brasil.