Artigos

Quarta, 28 de setembro de 2016 / Daniel Biasoli

Funções e Cargos Dentro de Um Time de Desenvolvimento Scrum
     Para muitas instituições, desenvolvimento ágil é uma abordagem nova de desenvolvimento de software. Isto significa quebrar alguns hábitos antigos e criar novos. Às vezes gerentes de projetos que trabalham em empresas que adotam “títulos” para seus funcionários de TI envergonham-se porque acreditam que em Scrum não devem ser abordados títulos de trabalho aos seus desenvolvedores e sim, apenas, “Time de Desenvolvimento”.
     Realmente, Scrum define apenas três papéis: Product Owner, o ScrumMaster e o Time de Desenvolvimento (não aborda os títulos de trabalho que se adotam no mundo corporativo, como líder de projeto, testador, analista de negócios, desenvolvedor, DBA, administrador de dados, etc). Nas instituições, de modo geral, os títulos de trabalho servem a um propósito valioso. Eles refletem o lugar da pessoa na hierarquia corporativa. Autoridade, experiência e alcance podem ser transmitidas através de títulos. Isso ajuda os gestores de recursos a construir equipes com uma mistura de especialistas e profissionais de menor experiência. Além disso eles ajudam a definir sua área de especialização (muitos sequer trabalham com codificação de software). Finalmente eles são usados para criar um plano de carreira dentro de uma instituição, adicionando prefixos como “júnior” ou “sênior”.
     No contexto de uma equipe ágil, temos que aceitar que somos todos membros de um time de desenvolvimento. No contexto da hierarquia organizacional, estes títulos ajudam a criar um time robusto e diversificado porque um testador olha para uma história de usuário diferente de um analista de negócios; um analista de negócios pode ter um conhecimento mais diversificado do que um desenvolvedor ou um administrador de dados. Um analista júnior pode ter uma experiência diversificada para ensinar um sênior e assim por diante.
     O desafio de um ScrumMaster é justamente abraçar esses títulos de forma eficaz o suficiente para satisfazer as necessidades institucionais ainda com a visão suficiente para que o processo permaneça ágil.

Terça, 5 de abril de 2016 / Daniel Biasoli

Utilização do Método MoSCoW Para Gerenciar Contratos em Scrum
     Amigos, peço desculpas por ficar um tempo sem escrever. Simplesmente o site caiu no meu esquecimento pelos mais diversos motivos. Devido a pedidos de alguns amigos, volto a escrever com o compromisso de ser mais assíduo por aqui.
     No tema de hoje vou comentar sobre o método MoSCoW. Você já ouviu falar?
     O método MoSCoW é uma maneira simples de classificar e priorizar requisitos para inclusão em um sistema de informação. Foi originalmente incluído nas técnicas do Método de Desenvolvimento Dinâmico de Sistemas (DSDM), o qual foi criado para apoiar as empresas que adotam métodos de desenvolvimento ágil como Scrum, XP, etc.
     Este método requer que o analista classifique todos os itens que trabalhará em quatro categorias:
     - Mo: Must have (deve ter): vital, ou seja, deve ter
     - S: Should have (deveria): importante, mas não vital
     - Co: Could have (poderia ter): será bom ter, mas não é realmente importante
     - W: Won’t have (não terá): não será desenvolvido ou incluído
     Por ser um procedimento simples, para a utilização do método MoSCoW, não existe um processo a ser seguido. Em projetos que utilizam metodologias ágeis é possível utilizar os conceitos “Should have” e “Could have” como uma tolerância ao escopo previamente definido, quando o cliente solicita mudanças a serem incorporadas em um product backlog.
     Obviamente, uma empresa que desenvolve contratos baseados em Scrum deve se adaptar às mudanças dos clientes, mas, em seguida, o cliente também deve entender que o escopo não pode ser corrigido e que há sempre um custo para alguma mudança. É neste exato momento que o desenvolvimento de software pode “jogar”, baseando-se nas predefinições dos Shoulds e Coulds.
     O princípio MoSCoW permite incluir condições que indiquem que o alcance da meta do cliente pode ser flexível, porém deve ser negociado baseado em sugestões customizadas previamente.
     Trabalhar com o princípio MoSCoW significa deixar um espaço para a negociação de escopo no contrato, ao invés de fazer um preço fixo, com escopo fixo e contrato de tempo fixo, o que é lamentável tanto para a equipe quanto para o cliente.
     Para entender um pouco mais sobre o método MoSCoW, deixo os seguintes links para conhecimento:
     - http://www.ronielton.eti.br/blog/2014/02/15/artigos-prince2-moscow-e-gerenciar-por-estagios/
     - http://www.faustolevandoski.com.br/wp-content/uploads/2011/10/Metodologias_V0.5.pdf
     - https://www.dsdm.org/content/moscow-prioritisation
     - https://onofri.org/b/la-tecnica-moscow-come-bilanciare-la-priorita-dei-requisiti-di-un-progetto-in-dsdm-atern/ (italiano)

Sexta, 20 de outubro de 2015 / Daniel Biasoli

SIRC - UNIFRA, em Santa Maria/RS
Já havia mencionado que fiquei muito feliz com o convite para ministrar uma palestra e um minicurso no evento. Por lá tive a oportunidade de encontrar vários amigos de longa data. Agradeço, de coração, o tratamento e o carinho que os professores Mirkos Ortiz Martins e Gustavo Cantarelli tiveram comigo.


Foto com o ex-estagiário de TI da Unipampa, Jean Rangel, que também esteve participando do evento


Apresentação da palestra Metodologias Ágeis com FDD na UNIPAMPA - Daniel Biasoli

Sexta, 21 de agosto de 2015 / Daniel Biasoli

Palestra e Oficina no SIRC - UNIFRA - Santa Maria
     Fiquei muito feliz com o convite:
     O SIRC é organizado pelos Cursos de Ciência da Computação e de Sistemas de Informação do Centro Universitário Franciscano de Santa Maria e apoiado pela Sociedade Brasileira de Computação.
     O principal objetivo do evento, em sua XIII edição, é promover a discussão em torno de temas relevantes e atuais na área de informática.
     Estarei prestigiando este evento!

Terça, 1º de julho de 2014 / Daniel Biasoli

O que você faria no seu primeiro dia como Gerente de Projetos?

A ansiedade do seu primeiro dia em um novo emprego sempre estará presente. Ser líder de uma equipe não é diferente. Aqui estão algumas dicas simples e valiosas para você começar bem no primeiro dia como Gerente de Projetos:
     1. Procure lembrar o nome de todos os membros de sua equipe e suas pronúncias corretas. Existem diferenças culturais, e muitas vezes as pessoas não gostam quando você menciona os seus nomes de maneira errada. Se necessário, peça desculpas, e pergunte ao colega como mencioná-lo corretamente. Realize algumas técnicas de memorização em sua mente para associar os nomes aos rostos.
     2. Procure saber como foram as reuniões anteriores à sua chegada e peça todas as atas para que você possa analisar. Faça um mapa mental dessas reuniões. Na maioria das vezes elas dão ritmo à sua equipe.
     3. Almoce com sua equipe. Não apenas no primeiro dia, mas todos os dias.
     4. Seja humilde e conheça todos. Somente quando perguntado, explique um pouco sobre os seus créditos profissionais. Acredite: a maioria dos seus novos colegas já conhecem o seu histórico. Evite se vangloriar dos seus feitos. Soa como necessidade de autoafirmação e, em alguns casos, como blefe.
     5. Não critique a falta de agilidade na equipe; isso não é um bom começo.
     6. É a primeira impressão da sua equipe sobre você que dará uma relação de confiança para que vocês iniciem um bom trabalho.


Quarta, 25 de abril de 2014 / Daniel Biasoli

Dia Internacional das Mulheres nas Tecnologias da Informação e Comunicação

Parabéns a todas as nossas colegas pelo Dia Internacional das Mulheres nas Tecnologias da Informação e Comunicação.
Em uma área tecnicamente exigente, onde o preconceito rola solto, o desprendimento das mulheres na nossa área, sendo elas a maior parte da população mundial, se torna fundamental para a evolução da profissão e de novas tecnologias.
Grande abraço e parabéns, mais uma vez!


Quarta, 23 de abril de 2014 / Daniel Biasoli

Qual o melhor dia para começar uma sprint?

Em alguns projetos, talvez a grande maioria deles, os times de desenvolvimento que trabalham com a metodologia Scrum iniciam suas atividades de sprint na segunda e terminam na sexta-feira. No entanto é muito importante considerar alguns detalhes antes de escolher o melhor dia para iniciar uma sprint:

1) Sexta-feira antecede o final de semana, o que significa que as pessoas estão planejando suas folgas. Se a sprint termina na sexta-feira, então há uma perda no último grande dia de uma sprint. É normal e óbvio que a grande “correria” de uma sprint aconteça no seu último dia. Se uma sprint fechar em uma quarta-feira, por exemplo, os membros de um time terão mais tempo para terminar suas atividades dentro de uma sprint.

2) A maior parte das empresas possui funcionários com famílias em outras cidades. É natural que às sextas-feiras os colaboradores queiram retornar para seus locais de origem para aproveitar o final de semana. O clima de folga contagia as pessoas e às vezes há aqueles que planejem, inclusive, sair mais cedo. Se uma sprint terminar numa sexta-feira, isso também afetará o trabalho de fechamento de uma sprint.

3) Na sexta-feira as pessoas estão cansadas depois de todo o trabalho que fazem durante a semana e não são capazes de se concentrar 100% no que estão fazendo dentro de uma sprint.

4) Se uma sprint terminar no meio da semana, haverá mais tempo para acomodar as alterações sugeridas pelos interessados. Se for preciso que um colaborador de sua empresa trabalhe mais horas, pode ter certeza que estas serão muito melhor aproveitadas em uma segunda ou numa terça-feira. Trabalhar após o horário no dia que antecede o final de semana é quase que uma certeza de baixa produtividade.

Com base nos itens acima, minha sugestão é que uma sprint comece em uma quinta e termine em uma quarta. Não há dúvidas de que os membros da equipe terão mais tempo para respirar durante o final de semana, poderão planejar o término dos seus trabalhos mais cedo e aproveitar ainda mais os seus tempos de folga, voltando ainda com mais energia para o trabalho na segunda-feira.


Quarta, 02 de abril de 2014 / Daniel Biasoli

Cozinha x Projeto

Um dos meus maiores hobbies sempre foi cozinhar. A cozinha me faz bem. Gosto muito de fazer pratos diferentes e provar novas receitas que encontro na Internet. Inclusive há quem diga que na cozinha se faz felicidade. Bem, então enquanto faço felicidade, me sinto feliz. No entanto sou ”maniático”: psicologicamente não consigo fazer uma boa comida se minha cozinha não estiver impecável. Preciso que toda a louça esteja limpa, que os ingredientes estejam devidamente separados e, se necessário, já picados. Mentalmente modelo e simulo todas as etapas da criação do prato a ser preparado. Se não for assim, parece que alguma coisa dará errada: seja no tempo de preparo, no gosto da receita ou até mesmo um incêndio da casa (risos).

Assim como na cozinha, projetos são feitos de oportunidades. Há a hora certa para aplicar aquele ingrediente que fará toda a diferença. Se passar do ponto, a comida não terá o mesmo sabor. O que faço na cozinha não é nada diferente quando o assunto se refere a projetos, já que grande parte dos problemas nessa área está relacionada a escopo (PMI 2009), assim como, pela prática, sabe-se que em projetos de software existem altos riscos como atrasos nas entregas e, até mesmo, escassez de mão-de-obra.

Boa parte dos ”tropeços” em projetos, senão a grande maioria, poderiam ter sido evitados se tivéssemos nos antecipado quanto a riscos e oportunidades. Lembre-se: é praticamente impossível fazer um bom gerenciamento de projetos se você não gerenciar os riscos.

Pense bem: quantas oportunidades deixamos passar por não estarmos preparados quando aparecem? Certamente muitas. Gerenciar riscos é extremamente necessário devido à consciência da existência de fatores internos ou externos, cujos resultados, ao longo dos seus ciclos de vida, podem alterar os objetivos de um projeto. Segundo Boehm (1989), “Gerentes de Projetos de sucesso foram bons gerentes de risco”. Isso conduz a um conceito de que a gerência de risco deveria estar integrada à prática de todos os gerentes de projetos, o que na maioria das vezes não ocorre.

Em minha dissertação de mestrado descrevi uma pesquisa na qual propus associar modelagem e simulação de sistemas ao gerenciamento de riscos em projetos de software. Neste e em diversos trabalhos de pesquisa na área de Gerenciamento de Projetos com Modelagem e Simulação, utilizamos a premissa de que é fundamental criar uma cultura de medição e métricas, estendendo esta tarefa a todos os profissionais envolvidos em qualquer projeto. Medições, planejamento de releases, modelagem e simulação, além de servirem para fortalecer o processo decisório, quando os dados são catalogados, constituem “dados históricos”, que alimentam a gestão do conhecimento da empresa, podendo serem usados em futuras estimativas e, consequentemente, contribuindo para maximizar o retorno do investimento da organização.

Quanto maior a base de conhecimento de uma instituição, maiores as chances de se obterem estimativas próximas da realidade através de séries históricas. A gestão do conhecimento dá suporte ao bom senso e, logo, sensibilidade para análise de valores. Assim como na cozinha, em que o feedback daqueles que servem de cobaia para provar uma receita é extremamente importante para novas receitas, é imprescindível que haja uma socialização de nossas experiências em projetos para agregar valor à base da gestão de conhecimento da organização à qual representamos. O diferencial de um bom projeto está em antecipar, reduzir impactos e aumentar o ganho para as partes interessadas. Com isso evitamos que problemas se tornem realidade e levamos o nosso projeto por meio uma deliciosa e saborosa receita dentro dos limites possíveis.


Terça, 25 de março de 2014 / Daniel Biasoli

Qualquer um pode ser Gerente de Projetos de Software ?

A área de Gerência de Projetos de Software está precisando de profissionais qualificados no mercado. Atualmente há vários itens de descrédito quanto à função deste tipo de profissional na maioria das empresas, seja por parte da sua própria equipe, pela chefia ou por parte dos clientes. À boca pequena, os rumores mais comuns são:

- "Fala muito e sabe menos do que um estagiário".
- "Se uma cobra morder o gerente de projetos, morre com o veneno!"
- "Gerente de Projetos não serve pra nada!"

Para que isso não ocorra é fundamental que um gerente seja conhecedor na área de desenvolvimento e altamente recomendado que conheça técnicas de programação, engenharia, qualidade, testes, riscos, etc.

Jamais um gerente deverá se contentar apenas com métodos e ferramentas. Lembre-se que um software de gestão jamais será capaz de:

- planejar;
- melhorar estimativas;
- forçar as pessoas a cumprirem prazos;
- prover recursos adicionais;
- remover e corrigir problemas imprevistos no seu processo ou produto ou até em um planejamento de release;
- descobrir escopo que você não descobriu;
- alterar escopo de seu projeto ou mesmo negociar novos prazos;
- resolver problemas de sua equipe;

Abraçar a área de Gerenciamento de Projetos de Software sem sequer jamais ter prática na área de desenvolvimento é um tremendo “tiro no pé” da própria empresa. Profissionais provenientes de outras áreas, sem o devido conhecimento prévio na área de software também são um risco ao sucesso de grandes projetos, sendo fadados, inclusive, ao descrédito de todo um time de desenvolvimento.


Quarta, 19 de março de 2014 / Daniel Biasoli

PRIORIZAÇÃO DE IDEIAS

Um dos problemas no ambiente de trabalho (seja desenvolvimento de software ou outro qualquer) é justamente o excesso de ideias ou tarefas a serem cumpridas.
Por este motivo é muito importante adotar uma tática de priorização das necessidades.
Neste momento, uma técnica muito bacana, proposta por Alex Apollonsky, também ScrumMaster certificado pela ScrumAlliance, pode entrar em cena: a "Prioritization Poker"!

A técnica é muito simples:

1- Escreva as ideias ou tarefas que você deseja priorizar em cartões (pode ser cartolina ou até papel comum, mesmo).
2- Escreva um número único no canto de cada cartão.
3- Após, coloque os cartões sobre uma superfície, um ao lado do outro, em ordem aleatória.
4- Analise cada uma das ideias escritas com a equipe (time, se estivermos falando de SCRUM) para garantir que todos estão trabalhando na priorização das mesmas ideias!
5- Peça para cada membro da equipe para votar (escrever um número - este sendo o número único no canto de cada cartão) em uma ideia que acha que tem prioridade mais baixa.
6- Peça aos participantes para não mostrar ou ler o que escreveram. Peça a todos para entregar-lhe os números escritos. Uma ideia mencionada mais do que uma vez, deve ser deslocada para a parte inferior da superfície.
7- Repita os passos 4, 5 e 6, até que todas as ideias sejam priorizadas. Em cada iteração, apenas ideias restantes no topo estarão em votação.

A técnica funciona melhor se o número de pessoas que participam da votação é maior do que o número de ideias a serem priorizadas.

Simples, não? Para que dificultar, se podemos simplificar?

Não dá para esquecer que priorização de ideias e/ou tarefas é extremamente importante para que uma equipe de desenvolvimento mantenha sempre o foco. Manter o foco facilita as ações que levam à melhoria contínua e, neste caso, interfere positivamente no resultado, tanto qualitativamente, quanto quantitativamente.