Usando mapas conceituais para entendimento das regras de negócio

Resumo
Gostaria de apresentar aqui uma prática que me ajudou muito no início de um projeto de software com um nível de conhecimento científico alto. Esse projeto ainda está em andamento, e hoje – depois de um ano – eu posso ver o quanto a adoção dos mapas conceituais me ajudou a entender as regras de negócio e a estabelecer o escopo do sistema e posteriormente o detalhamento das suas funcionalidades.

Desafios
Quando eu entrei no projeto, me deparei com um desafio: criar um software a partir das melhores práticas de zootecnia, estudadas e comprovadas durante anos por especialistas e que agora deveriam ser estruturadas para desenvolver um produto que trouxesse ao produtor rural todo esse conhecimento de forma acessível e que fornecesse benefícios práticos para o seu negócio.

Para isso eu contava – e ainda conto – com uma equipe de especialistas que me dão suporte para esse desenvolvimento. Então eu pensei: “beleza, tenho várias pessoas que sabem tudo sobre o assunto, então construir o sistema vai ser fácil”. Mas peraí, quem vai desenvolver sou eu! Eu preciso conhecer o assunto para poder estruturar o sistema, construir a lógica executada por trás de todas as tarefas e decisões que o sistema deve tomar. Além do mais, cada especialista tem conhecimento construído durante anos sobre um determinado assunto. O que eu realmente devo aprender? Qual parte desse conhecimento deverá entrar no sistema? É preciso filtrar as informações e para isso eu preciso entender como funciona o negócio.

Para responder a essas perguntas e entender como funciona o negócio, eu adotei os mapas conceituais, que me foram apresentados ainda na graduação pela minha amiga e mentora Silvana Rossy. Um mapa conceitual é uma representação do conhecimento utilizada para diversos fins, mais popularmente para potencializar o ensino e aprendizado. Através dos mapas podemos organizar nosso conhecimento. Isso é feito através de conceitos conectados por palavras de ligação, formando uma proposição. Existe muito assunto para se falar sobre mapas conceituais que não cabem a este artigo. Uma interessante representação do que são mapas conceituais pode ser encontrada no site do Cmap Tools, onde eles utilizaram um mapa conceitual para explicar o conceito do próprio mapa conceitual.

Ferramenta
Não é necessário nenhuma ferramenta para criar mapas conceituais, bastam lápis e papel. Porém o uso de uma ferramenta ajuda muito para fins de documentação e modelagem junto aos stakeholders. A ferramenta que eu uso é o Cmap Tools. Ela é fácil de usar e bem prática, permite que várias pessoas modifiquem os mapas remotamente, exporta os mapas para diferentes formatos e os disponibiliza na internet.

Utilizando os mapas conceituais para entender o negócio
A princípio eu li alguns livros e artigos sobre zootecnia de forma geral, para começar a criar alguma coisa. Escrevi minhas primeiras proposições, para então discuti-las separadamente com cada especialista, cada um responsável por uma área do negócio.

Várias reuniões aconteceram, e durante cada uma delas os mapas aumentavam, se modificavam, dúvidas iam surgindo e outras eram solucionadas. O interessante dos mapas conceituais é que através deles é possível construir conhecimento de forma fácil e divertida. Tudo o que eu fiz foi criar alguns pequenos mapas no início. A partir das reuniões, eles cresceram colaborativamente e naturalmente.

É muito difícil abordar um assunto desconhecido para alguém com uma pessoa que sabe muito sobre ele. Como explicar para ela o que eu quero saber? Se deixar, a pessoa fala durante meses sobre aquilo. Os mapas realizam perfeitamente essa tarefa. Foram tantas as vezes que eu entreguei um pequeno mapa para um especialista e ele começou a complementá-lo instintivamente. Cada proposição nova gerava uma conversa e outras proposições surgiam facilmente. No final eu tinha algo parecido com isso:

Mapa conceitual do manejo alimentar

Mapa conceitual do manejo alimentar

É engraçado como diferentes formas de abordar um assunto podem fazer com que o conhecimento se desenvolva de formas tão variadas. Os mapas conceituais me permitiram entender uma área grande de forma rápida e surpreendente; permitiram orgazinar, representar e compartilhar conhecimento.

Além de tudo isso os mapas são úteis para a especificação de requisitos. Através deles é possível delimitar o escopo e definir quais atividades devem compor o sistema. Foi a partir dos meus mapas conceituais que eu escrevi os casos de uso que usei para detalhar cada atividade.

Conclusão
Utilizar mapas conceituais como auxílio ao entendimento das regras de negócio é uma ótima prática que eu recomendo sempre que um projeto de software abordar um assunto de difícil entendimento e/ou com altos níveis de conhecimento científico agregado. Eles ajudam a criar uma ponte entre as pessoas que detêm conhecimento e os desenvolvedores, guiando as reuniões, através de uma linguagem de fácil entendimento e que não necessida de conhecimentos de informática para ser aplicada e entendida.

Peço que, se alguém utilizar os mapas conceituais do jeito que descrevi ou de qualquer outra forma que beneficie um projeto de desenvolvimento de software, poste um comentário ou me mande um e-mail contando como foi a experiência.

Obs: post publicado originalmente no meu blog.

Scrum Overview

Recentemente escrevi meu artigo de conclusão de curso de Sistemas de Informação (IESAM) sobre gerenciar de forma ágil uma implantação de sistemas ERP com Scrum. Com isto resolvi postar um resumo sobre Scrum para aqueles que ainda não o conhecem.

Figura 01

Figura 01

1. Scrum
Scrum é um framework com conjunto de práticas objetivas, papéis bem definidos e totalmente adaptáveis, seu ciclo de vida se resume em interações e funcionalidades incrementais, é um método ágil voltado para gerenciamento de projetos. Com isso, permite um melhor acompanhamento do que está acontecendo durante o projeto, facilitando o ajuste durante o projeto e fazendo com que possamos alcançar os objetivos do projeto de forma ágil. Ou seja, Scrum não diz exatamente o que fazer, não irá resolver todos os problemas, mas com certeza os problemas serão mais facilmente identificados.

2. Ciclo do processo Scrum
O Scrum é baseado em interações bem definidas, com duração de uma a quatro semanas, também chamados de Sprint. Antes de cada Sprint é realizado todo planejamento inicial do objetivo que o cliente almeja. A partir desse momento é criado o Product Backlog, baseado na visão de negócio do cliente, com todos os requisitos a serem implementados. Depois de preparado todo Product Backlog, é realizada a primeira reunião de planejamento do Sprint, onde são selecionados os itens pelo Product Owner e o Scrum Master a serem desenvolvidos que agregarão mais valor ao negócio do cliente naquele momento e depois colocado na ordem de maior prioridade, em seguida realizamos a segunda reunião de planejamento do Sprint, onde a própria equipe estima o esforço das tarefas, faz a divisão das tarefas entre os diferentes membros e compromete-se a concluir as tarefas no final da interação e define de quanto tempo vai ser a Sprint. A partir desse momento é criado o Sprint Backlog que são as tarefas selecionadas pela equipe para ser executada na Sprint.
A próxima etapa é a execução do Sprint com base nos itens do Sprint Backlog, durante a execução as tarefas são acompanhadas por reuniões diárias que não podem passar 15 minutos e a equipe deve responder três perguntas diante dos envolvidos: O que você desenvolveu até o momento? O que você irá desenvolver? Quais impedimentos você está tendo? Com base nessas perguntas o Scrum Master consegue ter uma visão de como está o andamento do projeto, conhecendo os impedimentos que estão acontecendo.
No final da Sprint é realizada uma reunião de Revisão da Sprint, com o objetivo, de mostrar ao Product Owner e todas as partes interessadas as funcionalidades que foram concluídas. A equipe apresenta os resultados obtidos durante o Sprint e possíveis modificações nos itens do Product Backlog. Logo após é realizado outra reunião de Retrospectiva do Sprint, onde é feito uma “lavagem de roupa suja”, onde os membros da equipe devem responder duas perguntas: O que aconteceu de positivo durante esse Sprint? O que pode ser melhorado para o próximo Sprint?

Figura 02

Figura 02

3. Papéis
No Scrum temos três papéis principais: Product Owner, Scrum Master e a Equipe, abaixo a figura 2 que representa a responsabilidade que esses três papéis têm em relação ao Scrum:

3.1. Product Owner
É o dono do produto, geralmente é representado pelo o cliente. Ele é responsável por definir as características do produto a ser desenvolvido, identifica os requisitos do produto, tira dúvida da equipe quanto ao entendimento dos requisitos. É o único que define a ordem em que esses elementos serão desenvolvidos, de acordo com o valor apresentado pelos clientes e usuários de cada negócio, alimenta o Product Backlog para o planejamento da Sprints. E define as metas e toma decisões relativas Release planejamento. Uma pessoa que desempenha esse papel deve ter as seguintes competências:
– Bom conhecimento de negócio.
– Ser capaz de demonstrar uma liderança, respeitado pelos interessados externos (clientes e usuários). – Ser capaz de tomar decisões no momento certo (não muito cedo, nem muito tarde). – Flexível a mudanças. – Boa comunicação com a equipe. – É importante que ele esteja disponível para responder às perguntas da equipe.

3.2. Scrum Master
É responsável pelo andamento do projeto, pela aplicação das práticas do Scrum. Levando para o lado tradicional é o Gerente de Projeto. Durante o desenvolvimento, ele acompanha a equipe no dia a dia, retirando os impedimentos e ajudando a equipe a se auto-gerenciar, buscando melhor resultado da equipe. Para conseguir isso ele executa as seguintes tarefas:
– Tem como objetivo através das reuniões do scrum animar e motivar a equipe.
– Eliminar impedimentos, tendo em consideração os acontecimentos ocorridos em qualquer momento do projeto, a fim de resolvê-los o mais rápido possível, ao mesmo tempo proteger a equipe e priorizar o comprometimento da equipe com o projeto.
– Certifique-se de que a equipe permanece centralizada no projeto com objetivo proposto inicialmente, que é desenvolver os Itens do Backlog e estreitar colaboração com o Product Owner, e permanece produtivo.

3.3. Equipe
É composta por seus membros (desenvolvedores), que é capaz de realizar todas as diversas tarefas para as quais ele tem responsabilidade coletivamente durante cada Sprint. É capaz de determinar o que precisa ser feito para alcançar o sucesso do Sprint, a equipe deve ser capaz de executar as diferentes tarefas para as quais assume responsabilidade coletivamente durante o Planejamento do Sprint. Isto significa que devem ser de amplo conhecimento, tais como análise, projeto, codificação, testes e outras tarefas. A equipe é geralmente feita de 3 a 10 membros.

3.4. Stakeholder
São aqueles que não participam diretamente do projeto, mas podem influenciar no produto a ser desenvolvido, ou seja, não participa do desenvolvimento, mais está interessado no desenvolvimento do produto e pode ter valores que podem influenciar no crescimento do produto.

4. As práticas do Scrum (Conceitos, Artefatos e fases)

4.1. Product Backlog
A partir de uma reunião inicial com todos os envolvidos e interessados do projeto, são levantadas todas as implementações a serem desenvolvidas a partir da necessidade do negócio do cliente, contém uma lista de requisitos a serem desenvolvidos durante o projeto. É visível a todos, e regularmente atualizado. É apresentado na primeira reunião de Planejamento do Sprint, uma vez aprovado, temos os itens necessários para compor o Sprint Backlog.

4.2. Reunião de Planejamento do Sprint
A reunião de planejamento se divide em duas partes:

4.2.1. Primeira Reunião de Planejamento do Sprint
Com duração de no máximo quatro horas, o Product Owner junto com a Equipe discutem os itens do Product Backlog, são selecionadas neste momento as tarefas que tem mais prioridade para o cliente.

4.2.2. Segunda Reunião de Planejamento do Sprint
Com duração de quatro horas, a Equipe define as tarefas necessárias, estima o esforço das tarefas, a própria equipe faz a distribuição das tarefas entre os membros da equipe, o Product Owner deve está presente para esclarecimento de dúvidas e por fim a Equipe compromete-se em concluir as tarefas.

4.3. Sprint Backlog
São as tarefas que foram selecionadas na reunião de planejamento do Sprint pela Equipe junto com o Product Owner e Scrum Master, é o ponto inicial de cada Sprint.

4.4. Sprint
São pequenas séries de interações que podem ter uma duração de uma a quatro semanas, no final da interação a equipe tem que ter alcançado o objetivo inicial do Sprint, onde a equipe está focada em não como fazer, mas sim em vamos fazer. A equipe executa as tarefas compõem o Sprint Backlog. O objetivo final de cada Sprint é ter um produto incremental e funcional para o cliente. É a fase principal do Scrum, pois é nesta hora que ocorre a execução das tarefas, depois de todo o planejamento inicial. É importante que os restantes das Sprint tenham o mesmo tamanho da inicial para que não causem perda de ritmo da Equipe. É imprescindível que no primeiro Sprint alcance o sucesso, pois é um período delicado, pois as partes envolvidas e interessadas estão com expectativa muito grande em cima do resultado (produto incremental).

4.5. Reunião Diária do Sprint
Reuniões diárias que ocorre todos os dias durante a execução do Sprint, com duração em média de 15 minutos. O grande objetivo dessa reunião é que todos os envolvidos tenham conhecimento de como está o andamento do projeto e também fazer com que cada um relate os impedimentos que estão enfrentando ao executarem as suas respectivas tarefas.
O Scrum Master é o responsável pela condução da reunião, é muito importante que todos envolvidos no projeto estão participando principalmente a equipe, basicamente a equipe responde com clareza a três perguntas durante a reunião:
a. O que foi concluído desde a última reunião? (Neste momento o Scrum Master registra as tarefas que foram concluídas e as que ainda estão pendentes).
b. Quais impedimentos estão tendo durante a tarefa? (O Scrum Master registra os impedimentos relados por cada membro da equipe, e após o termino da reunião irá propor solução para os problemas citados).
c. Qual será a próxima tarefa a ser executada? (Neste momento todos ficam sabendo quais tarefas cada membro da equipe está executando).
O Scrum Master tem como objetivo nessa reunião não deixar com que a reunião perca seu foco, basicamente responder as três perguntas, ter uma visão que a equipe não perdeu o objetivo final do Sprint, e gerenciar os impedimentos que vão acontecendo durante a execução da Sprint. O ponto forma desta reunião é responder apenas as perguntas feitas pelo Scrum Master e ponto.

4.6. Produto Incremental
No final de cada Sprint há uma entrega parcial do produto. O principal resultado de um Sprint é a entrega incremental e funcional de um produto, os impedimentos para entrega dessa etapa e os novos requisitos adicionado durante o desenvolvimento deste Sprint.

4.7. Reunião de Revisão da Sprint
Esta reunião é realizada no último dia do Sprint com duração de no máximo 4 horas e de responsabilidade do Scrum Master, a Equipe não de gastar mais de uma hora na preparação da reunião. Neste momento é apresentado o resultado da Sprint que é o produto incremental com suas funcionalidades pela Equipe e o Scrum Master para Product Owner e os envolvidos do projeto (cliente). Analisaram junto se foi alcançado o objetivo inicial do Sprint, e já discutem novas funcionalidades para atualizar os itens do Product Backlog que vão sendo identificada ao final de cada Sprint.

4.8. Reunião de Revisão da Sprint
É realizada logo após a reunião de revisão do Sprint com duração de no máximo 3 horas com a participação da Equipe, Scrum Master, Product Owner e os envolvidos e interessados. Os membros da Equipe devem responder a duas perguntas?
a. O que aconteceu de bom durante o último Sprint?
b. O que pode ser melhorado para o próximo Sprint?
O Scrum Master registra as respostas e prioriza na ordem que deseja discutir as melhorias e tem como papel também facilitar ao time melhores formas de aplicar as práticas do Scrum.
Por ser uma reunião de lavagem de roupa suja, deve se ter cuidado para não levar pontos pessoais, pois podem ser fundamentais para prejudicar a aplicação das práticas do Scrum. Essa reunião é fundamental para o progresso e sucesso do projeto, é fundamental a clareza e objetividade para que os participantes alcancem o sucesso da reunião.

FabioGr.com

Clipping: Lançamento do site do TASAFO

O grupo TASAFO, que começou sua atuação em 2007, no curso de Sistemas de Informação do IESAM, incentivado pela Coordenação do Curso e pelos alunos mais motivados pelo desenvolvimento de software com tecnologias livres. Rapidamente contou com a participação e o incentivo de outros grupos e desenvolvedores que trabalham com tecnologia de ponta na região.

Agora o grupo está consolidado na região. Conta com a parceria de outros grupos como o PHP Pai d’Égua, Linux Pai d’Égua e já expandiu sua atuação, pois agora é constituído de participantes de várias instituições e empresas no Estado do Pará e inclusive de outros estados.

O grupo tem o objetivo de discutir tecnologias e metodologias de desenvolvimento ágil, privilegia o empreendedorismo e o uso de Tecnologias Abertas para o desenvolvimento de Software. É um grupo aberto e qualquer um pode participar.

A formação de grupos como o TASAFO deve contribuir para o desenvolvimento regional porque privilegia o uso de plataformas abertas, dissemina o conhecimento ao mesmo tempo em que valoriza as atividades empreendedoras, através da colaboração entre os membros da academia e os profissionais do mercado.

Vale ressaltar que o grupo já tem uma história de participação internacional com a palestra do aluno Luiz Sanches no Fórum Internacional de Software Livre em 2008. No evento, vários integrantes do TASAFO estiveram marcando presença e desde então o grupo tem marcado presença em eventos locais e nacionais de tecnologia de informação.

O site do TASAFO está lançado: http://www.tasafo.org/ e também tem o blog do grupo: https://tasafo.wordpress.com/ que começa com um Papo Ágil, bem interessante. No site, o convite está aberto para aqueles que desejam contribuir e participar de uma produtiva discussão sobre o desenvolvimento de software.


Profa. Silvana Rossy de Brito
srossy@prof. iesam-pa. edu.br

Resumo 1° Papo Ágil

Ata 1ª Papo Ágil.Participantes: Luiz Sanches, Wagner Farias Leonardo Pessoa, Silvana Rossy, Jaime Schettini, Fabio Aguiar, Hayla Cardoso, Alfredo, Cleber Amorin, Diago Araújo, Diego, Eduardo Lieuthier.

Pra início de Papo, todos os participantes se apresentaram e colocaram o porquê de seu interesse sobre desenvolvimento ágil.

Em seguida algumas questões foram levantadas, dentre as quais se destacaram:
  • Para desenvolver de forma ágil é necessário mudar muito paradigmas e aplicar uma nova filosofia() de desenvolvimento;
  • Não existe meu código;
  • Mudança de requisitos não é um problema;
  • Determinar prazos de acordo com a experiência da equipe;
  • Brainstormings, reuniões diárias e rápidas são boas práticas para gerenciamento do projeto;
  • É de suma importância começar a adotar práticas ágeis em nosso dia-a-dia e sem mudanças agressivas;
  • Alguns problemas encontrados durante projetos de desenvolvimento de software de  foram relatados: foi enfatisada a importância da simplicidade para solucionar alguns desses problemas;
  • Experiências sobre programação em pares foram expostas e discutidas.

Para o próximo Papo Ágil ( Data ainda em discurssão): alguns integrantes explanarão de maneira rápida e objetiva alguns conceitos sobre metodologias ágeis, seguido da discussão dos assuntos em questão.