TCC da pós, uma pitada de scrum e um exemplo de marketing

Hoje trago algumas novidades e um pequeno (não tão pequeno assim) desabafo no final. Primeiro de tudo, há uma boa justificativa para o meu "sumiço". Eu estava trabalhando com afinco no meu trabalho de conclusão de curso da pós-graduação, e é com orgulho que lhes digo que a coordenação do curso aprovou o meu trabalho para avaliação da banca, o que me deixa muito feliz, pois isso significa que é muito provável que em breve finalmente eu me torne um especialista em gestão de tecnologia de informação.

Em meu trabalho faço uma comparação entre as filosofias de desenvolvimento de software ágil e tradicional. O objetivo do trabalho é mostrar as diferenças entre as filosofias de desenvolvimento e identificar os cenários mais favoráveis para a adoção de cada uma das vertentes. Confesso que foi muito díficil ser imparcial na argumentação, já que durante as pesquisas quanto mais aprofundei o meu conhecimento nas práticas ágeis, mais fiquei favorável a adoção de práticas ágeis ao invés das tradicionais.

Mudando um pouco de assunto, vou fazer uma prévia dos próximos posts. Aqui na Datasul Saúde (unidade Sorocaba) houve nos últimos meses uma campanha interna muito legal, chamada "Agiliza Sorocaba". Em breve disponibilizarei um bate-papo com a Erika, que idealizou, organizou, orientou e incentivou toda a campanha. Nesse bate-papo vamos falar mais a fundo sobre isso, então essa foi só pra dar o gostinho da coisa. Enfim, como todos fomos aplicados e atingimos a meta da campanha, fomos agraciados com um passeio totalmente "di grátis" ao Hopi Hari. Muito legal não acham? Realmente, foi um prêmio muito legal, com direito a acompanhante e ajuda de custos para o lanche e tudo.

O único problema é que, como bem diz o ditado: Alegria de pobre dura pouco. Foi uma coisa impressionante, assim que descemos do ônibus começou a chuva que continuou o dia todo. Além disso, o parque estava entupido de gente, ouvi relatos de pessoas que ficaram somente meras 5(CINCO) horas inteiras na fila da montanha russa e debaixo de chuva. Nessas horas é que a gente vê o verdadeiro poder do marketing. Para qualquer ser humano normal é óbvio que o parque estava superlotado, é inadimissivel passar 8 horas em um lugar e conseguir ir apenas em apenas 3 ou 4 atrações de um parque que tem dezenas de atrações. Em um certo momento do dia, tudo o que eu queria era conseguir um lanche em menos de 2 horas e um lugar coberto, quentinho e sem chuva para comer o bendito lanche. Se fosse um parque "normal", isso já seria motivo suficiente para nunca mais voltar lá e falar mau do lugar com um megafone no próximo comício(oops, inauguração de obra) do Lula. Mas como é o Hopi Hari, o lugar mais divertido do muuuuuuunnndo, dou um desconto e só reclamo um pouco no blog mesmo. E certamente, a próxima vez que eu voltar pra lá, vou pesquisar muito para saber em qual época do ano e dia da semana o parque é mais tranquilo, porque aquele lugar mais vazio deve ser animal. O pior de tudo é isso, é bem possível que eu ainda volte pra lá, isso sim é marketing bom, você se ferra e mesmo assim quer mais.

Café com Agile - parte 3

Meus caros, finalmente chegamos a terceira e última parte do nosso Café com Agile. Se você, caro leitor ficar com alguma dúvida, envie para o Sandro ou para mim, que oportunamente iremos responder.

Tanto eu, como o Sandro já conheciamos tanto Scrum como PMI, com a diferença que o Sandro é um especialista em Gerência de Projetos e eu sou um grande entusiasta e estudioso de Scrum e Agile em geral. No início da conversa, o único objetivo era um poder aprender com o outro, eu queria conhecer mais sobre os conceitos de PMI e ele conhecer um pouco mais sobre Scrum, e nesse ponto tenho certeza que atingimos o nosso objetivo e de quebra, o papo foi até surpreendente.

Gostei muito dessa experiência, e espero que aqueles que lerem também gostem. E agora, deixando a parte "sentimental" de lado, vamos ao derradeiro final do papo.

Sandro: Em nossa última conversa, entendi que a idéia no scrum é fazer entregas constantes, mas a minha dúvida é, como é decidido a ordem em que as coisas serão desenvolvidas?
Milton: Tendo o “Product Backlog” em mãos, o “Product Owner” define o que deve ser entregue primeiro para que o projeto tenha um maior retorno financeiro
Milton: Ai, a equipe de desenvolvimento se reúne, verifica quais itens eles podem entregar no prazo combinado e começam o desenvolvimento destes itens
Milton: Nesse ponto, surge o conceito de time-box, ou seja, em scrum o prazo é fixo, a equipe trabalha em ciclos/iterações que duram de 2 a 4 semanas. Ao final de cada iteração é entregue um incremento do produto
Milton: Cada ciclo ou iteração é o que chamamos de “sprint”.
Milton: Com o incremento entregue, o “Product Owner” pode decidir por utilizar o produto em produção ou aguardar pelos próximos incrementos
Sandro: E já é apresentando ao cliente?
Milton: Sim, em alguns casos o “Product Owner” é o próprio cliente. Inclusive, é uma prática recomendável que, quando o projeto for específico para um único cliente o “Product Owner” seja uma pessoa de negócios do Cliente.
Sandro: Sim, ele seria o gerente de TI ou um analista sênior que esteja a par das regras de negócio e estratégias da empresa
Milton: Não necessariamente, pode ser até um cara de negócio mesmo
Milton: Tem uma coisa q falamos, mas não dei nome, q é o “Sprint Backlog”
Milton: O “Sprint Backlog” é a porção de coisas do “Product Backlog” que a equipe seleciona para desenvolver
Sandro: Hummm esse eu conheço, é o incremento planejado para o próximo Sprint.
Milton: Isso mesmo
Milton: Com isso observamos uma coisa muito interessante, o cliente não precisa esperar uma vida pra ver algum resultado do projeto
Milton: E o fornecedor não precisa ficar uma vida amarrando escopo, nem fazendo planejamentos de projetos enormes, com milhares de documentos e assinaturas de aprovação de escopo e mudanças
Milton: Isso porque o fornecedor foca apenas nas tarefas do “Sprint”, e o “Product Owner” foca em organizar continuamente o “Product Backlog”, medindo o quanto o projeto está dando de retorno financeiro
Sandro: Sim, isso eu visualizei , é sensacional, jogo aberto e de ajustes rápidos!
Milton: Exato
Milton: Além dessa questão sobre o "como tratar o escopo", acredito que temos mais uma diferença marcante, quer dar um palpite? hehe
Sandro: Bom, o que eu gostei muito no scrum foi que possui praticas muito democráticas. Ele permite que o especialista opine, se expresse, participe do processo. Isso muda até mesmo o pique do cara em vir trabalhar
Sandro: Além disso, ele não vê que tem que trabalhar 2000 horas em entregáveis que nem imagina ainda (em finais de semanas e feriados), mas sim 2 semanas (de segunda a sexta) em assuntos já discutidos e planejados para essas 2 semanas
Sandro: Seria isso?
Milton: Sim, você foi na veia do negócio
Milton: A primeira parte é a questão dos papéis, não existe o Gerente de Projeto Super Poderoso, cada papel tem um poder específico, de acordo com a sua função e cada papel deve contribuir com os demais para atingir os objetivos do projeto
Milton: - o Product Owner define os objetivos do produto, e o que será feito primeiro para atingir este objetivo
- o Time define o que é capaz de entregar em cada sprint, bota a mão na massa e procura melhorar o processo sempre para produzir mais
- o Scrum Master, que nem foi citado até agora e é muito importante, isola o time de interferências, remove impedimentos e faz um papel de facilitador entre o Product Owner e o Time
Milton: O segundo ponto é a questão do "tamanho" do projeto. Você deixa de trabalhar com um projeto titânico, e passa a trabalhar com vários mini-projetos, em seqüência, com isso o produto vai crescendo a cada entrega.
Milton: E acho que qualquer Gerente de Projeto concorda que é muito melhor trabalhar com um projeto de 200 horas, do que com um projeto de 20.000 horas
Sandro: Claro, muito melhor
Sandro: E a questão dos poderes de um sobre o outro? No caso do Scrum Master x Product Owner?
Sandro: Existe braço de ferro entre os dois?
Milton: Depende, pode existir, mas por questões políticas. E isso pode acontecer com qualquer tipo de função
Milton: Se os dois fizerem o seu papel e se mantiverem focados no objetivo do projeto não devem ocorrer quedas de braço no sentido político da coisa
Milton: Claro que ocorrerão conflitos, mas são conflitos saudáveis, buscando o melhor para o projeto e não benefícios individuais
Milton: É diferente de você ter, por exemplo, dois Gerentes de Projeto brigando por aquele "Recurso" que é o cara em java, que programa tudo rapidinho
Sandro: Sim, mas ai seriam 2 GPs em uma mesma empresa, se existissem 2 Scrum Master na mesma empresa poderia ter o atrito também?
Milton: Não, porque em scrum a idéia é q a equipe seja fixa. Não vai ter aquela dança de pessoas entre as equipes, porque manter as pessoas trabalhando juntas contribui para o desenvolvimento profissional delas
Milton: Ainda mais quando você possui uma equipe bem heterogenia, onde você tem pessoas com várias funções e com diferentes níveis de experiência. Em uma equipe assim todos aprendem com todos, e se tornam profissionais melhores, aumentando a maturidade e capacidade da equipe
Sandro: entendi
Milton: Bom, acho q estamos chegando ao fim do papo por hoje, mais alguma consideração?
Sandro: Acho que não, clareou pra mim ainda mais as práticas e personagens do scrum, foi show de bola

link para a Parte 1
link para a Parte 2