Este blog tem como meta apresentar algumas discussões e opiniões relacionadas a engenharia de software. O blog foi criado pelo professor José Augusto Fabri da Universidade Tecnológica Federal do Paraná em 2008. Espero que vocês aproveitem os textos aqui apresentados.
O Product Owner se caracteriza como um dos principais papéis dentro do processo Scrum. O PO tem a responsabilidade de representar os interesses dos stakeholders e maximizar o valor do produto. O Product Owner pode ser o responsável por definir e priorizar as funcionalidades do produto, com base nas necessidades e objetivos do cliente e do negócio.
Responsabilidades do PO:
Definir e manter o Product Backlog;
Priorizar o Product Backlog de acordo com o valor e a necessidade de cada funcionalidade;
Descrever as funcionalidades do produto de forma clara e detalhada;
Trabalhar em colaboração com a equipe de desenvolvimento;
Participar das reuniões diárias de acompanhamento do progresso do projeto;
Participar das reuniões de planejamento de Sprint;
Participar das reuniões de revisão de Sprint;
Garantir que o produto esteja sendo desenvolvido de forma eficiente e eficaz.
O papel do Product Owner é fundamental para o sucesso do projeto, pois ele é responsável por garantir que o produto final atenda às necessidades e expectativas dos stakeholders e gere valor para o negócio.
Perceba que PO é caracterizado como um papel, esse papel pode ser assumido por vários colaboradores dentro de um projeto. Isso facilita o balanceamento da carga frente a complexidade de um modelo de negócio.
O PO não pode ser considerado o ser onisciente dentro da equipe, isto não é bom para ele nem para demais membros do time. O PO tem que exercer a liderança dentro da equipe, essa liderança não pode ser autocrática, liberal, democrática, situacional. O PO deve potencializar as qualidades, conhecimentos, experiências e trabalhar os gaps dos liderados.
Por fim, é importante que o PO tenha uma relação de confiança com toda equipe, incluído da alta gerência. Caso o PO não tenha uma liderança sólida, não possui a confiança de toda a gerência ele não pode ser PO.
Reflita, o PO é um papel, esse papel pode ser constituído por várias pessoas que possuem liderança e conhecimento.
Pessoal, hoje vamos falar de um tema importante que venho estudando há alguns anos, o treinamento em gestão de projetos com a utilização de brinquedos.
O termo brinquedo se caracteriza como um vocábulo do século XIX e sua derivação vem de brinco ou brincar. É importante ressaltar que para brincar não necessitamos de um brinquedo ou objeto lúdico – brincar de pega pega é um exemplo. Alguns historiadores relacionam o sufixo edo com a madeira. A madeira foi utilizada na confecção dos primeiros artefatos que foram utilizados na ação de brincar.
Ao utilizar um brinquedo durante o contato com um determinado conceito abstrato, o aluno pode tornar o processo de aprendizado mais atraente e interessante, gerando uma positividade no desenvolvimento cognitivo. Quando combinamos os brinquedos com as aulas, certamente o processo de absorção do conhecimento pode ser potencializado.
Dado o pressuposto que: Brincar pode ser positivo em um treinamento. Um questionamento surge: Como o aluno pode aprender o conceito de Gestão de Projetos a partir da utilização de um brinquedo ou de uma brincadeira?
Vamos tentar responder o questionamento com um exemplo prático.
Vamos trabalhar a Introdução a Gestão de Projetos utilizando um brinquedo. Definir as grandes atividades de gestão – Planejamento, Execução e Controle de Projetos – será o nosso foco. Vamos trabalhar também o conceito de Base Histórica de Projetos e inserir a técnica Kanban dentro de tudo isso.
A brincadeira e o Brinquedo
Solicite que cada aluno ou colaborador tenha em mãos 6 folhas de papel sulfite e uma caneta azul ou preta.
Cada aluno ou colaborador deve gerar uma folha Kanban (vide figura abaixo).
Cada aluno ou colaborador deve recortar uma folha com 3 post-its. Cada post-it deve conter as seguintes informações: Produto a ser gerado, nome, data, tempo planejado e tempo de execução (vide figura abaixo).
Cada aluno ou colaborador vai construir 3 aviões – seguindo as orientações do vídeo abaixo:
Solicite que cada aluno ou colaborador preencha as informações no primeiro post-it.
_______________________________
Produto a ser gerado: Avião 1
Nome: José Augusto Fabri
Data: 21/04/2021
Tempo planejado: 4 minutos.
Tempo realizado: Deixe em branco. Essa informação será preenchida somente quando o post-it atingir o quadro pronto.
_______________________________
Solicite que cada aluno ou colaborador preencha as informações nos próximos post-it.
_______________________________
Produto a ser gerado: Avião 2
Nome: José Augusto Fabri
Data: 21/04/2021
Tempo planejado: Deixar em branco. Essa informação será preenchida com base no tempo realizado do primeiro post-it.
Tempo realizado: Deixe em branco. Essa informação será preenchida somente quando o post-it atingir o quadro pronto.
_______________________________
A Figura abaixo e o vídeo acima apresentam a configuração da brincadeira e a montagem do brinquedo.
Brincando
Agora é só brincar seguindo os passos abaixo:
Solicite que cada aluno ou colaborador coloque todos os post-its no quadro para fazer.
Assim que o aluno ou colaborador iniciar a construção do primeiro avião ele pode colocar o post-it no quadro fazendo.
Peça para cada aluno ou colaborador marcar o tempo que ele leva para construir o avião.
Terminada a construção, cada aluno ou colaborador deve movimentar o post-it para o quadro pronto e anotar o tempo realizado.
Solicite que cada aluno ou colaborador planeje o tempo de construção para o próximo avião.
Volte ao passo 2.
Após construir os 3 aviões, solicite que todos gerem a relação apresentada na tabela abaixo.
Produto
Nome
Data
Planejado
Realizado
Avião 1
José Augusto Fabri
21/04/2021
4 minutos
3 minutos
Avião 2
José Augusto Fabri
21/04/2021
3 minutos
2m30 segundos
Avião 3
José Augusto Fabri
21/04/2021
2m30 segundos
2m35 segundos
Trabalhando os conceitos
Agora vamos trabalhar alguns conceitos inerentes a Introdução a Gestão de Projetos.
Para construir o primeiro avião você fez o planejamento do tempo de construção. Perceba que você não possuía informação alguma sobre a sua capacidade produtiva.
No planejamento para a construção do segundo e o do terceiro avião, você utilizou a informação tempo realizado. Aqui já podemos abordar a importância de uma base histórica de projetos.
Com o Kanban você controla constantemente a execução do projeto. Perceba que na figura acima você possui 1/3 do projeto pronto.
A tabela acima já se configura como uma base histórica de projetos. Você pode utilizá-la em um próximo projeto para a construção de novos aviões.
Ah… Para encerrar, achou a construção do avião complexa, pode construir um mais simples.
Nos últimos dias recebi algumas questões sobre documentação de software.
Vamos à elas:
1 – O que pode ser encarado como um documento de especificação de uma funcionalidade em um determinado software?
2 – É necessário documentar, formalmente, todas as funcionalidades de um determinado software?
Vou iniciar nossa discussão pela segunda questão.
Não é necessário documentar, formalmente, todas as funcionalidades de um determinado software. Documente apenas as funcionalidades custodiais, ou seja, aquelas que automatizam uma regra de negócio mais complexa. Por exemplo: Não é necessário documentar a funcionalidade que tem como objetivo colecionar em uma tabela as informações de uma pessoa. Neste caso, se você tiver a lista de campos (com o tipo de dados definido), basta. Não é necessário descrever esta funcionalidade, por meio de um caso de uso, por meio de um cartão de história. Não perca tempo com isso.
Vamos para a segunda questão.
Qualquer informação que elucide alguma dúvida de uma determinada funcionalidade de um software pode ser encarada como documentação. Exemplo: Caso de uso; cartão de história; gravação de um determinado usuário que apresenta as entradas, a forma de processamento e saída de uma determinada funcionalidade podem ser encaradas como documentação de software.
Fica a dica, documente o que é necessário, aquilo que é mais complexo e custoso.
Pessoal, a Notação Húngara foi proposta por Charles Simonyi, e tem como objetivo facilitar o reconhecimento de qualquer tipo de variável em um código fonte.
A origem do nome da notação foi caracterizada a partir de uma brincadeira dos primeiros que trabalharam com a linguagem. Eles teciam o seguinte comentário:
“O nome das variáveis fica tão estranho que até parece Húngaro”
Existem algumas convenções para se denominar as variáveis. Vamos a elas:
Implementar nome mnemônico com significado – tem como objetivo facilitar a lembrança do significado da variável pelo programador.
Utilize nomes curtos e simples – facilita a programação e evita erros de compilação.
A notação Húngara é simples e intuitiva. Veja só:
Defina a variável de com um nome curto, simples, intuitivo.
A primeira letra do nome é maiúscula e restante das letras é minúscula. Assim como o meu e o seu nome. Por exemplo, Pedro.
Insira o tipo da variável em letra minúscula, respeitando a tabela abaixo, a frente do nome variável.
Nome
Descrição
s
String
sz
Aponta o primeiro caracter da terminação zero da string
st
Ponteiro da string, o primeiro byte é contado dos caracteres
h
handle (título)
msg
Message
fn
function (usada com pointer)
c
char (8 bits)
by
unsigned char (byte or uchar – 8 bits)
n
Int
b
Boolean (verdadeiro ou falso)
f
Flag (boolean, logical)
u
integer
w
Word
ch
Char, com texto ASCII
l
long int (32 bits)
dw
unsigned long int (dword – 32 bits)
Veja alguns exemplos.
bVerdade
boolean
sNome
string
uValor
inteiro
msgAviso
message
Facilite a sua vida padronizando minimamente o seu código.
Ah… você pode adaptar a notação Húngara para suas variáveis.
Antes de reponde-la é importante salientar que UML é uma linguagem de modelagem utilizada para especificar negócios e software.
A UML possui 9 diagramas
Diagrama de caso de uso,
Diagrama de classes,
Diagrama de sequência,
Diagrama de atividades,
Diagrama de máquina de estados,
Diagrama de comunicação,
Diagrama de componentes,
Diagrama de implantação,
Diagrama de composição estruturada.
Enquanto engenheiro de software e com uma vasta experiência no mercado produtor de software posso garantir que a maioria dos projetos utilizam fortemente 3 diagramas.
Caso de uso: sua função é materializar (ou explicitar os atores) e as funcionalidades de um software ou processos de um negócio.
Diagrama de classes: Diagrama de grande importância, ele irá explicitar todas as classes que possibilitam a criação de objetos.
Diagrama de sequência: Utilizado na especificação de uma cena (ou caso de uso). Este diagrama possui na sua simbologia atores, objetos e a troca de mensagem entre esses. Este diagrama é criado de forma concomitante com o diagrama de classes, fato este que provê consistência entre eles.
E os demais?
Em meu ponto de vista você vai utilizar os demais quando necessitar de algo um pouco mais específico.
A engenharia pode ser caracterizada como a arte de aplicar os conhecimentos, advindos das mais variadas áreas de conhecimento, na criação ou aperfeiçoamento de materiais, estruturas, máquinas, aparelhos, sistemas ou processos.
Já a ENGENHARIA DE SOFTWARE pode ser considerada uma área da Ciência da Computação que tem como objetivo a especificação, desenvolvimento e manutenção de sistemas de software. Atualmente, a ENGENHARIA DE SOFTWARE, também estabelece uma relação estreita com outras áreas do conhecimento, tais como: Gerência de Projetos; Teoria da Qualidade; Gestão de Conhecimento.
Ao analisar ambas as definições é possível perceber que todas tratam o que fazer e não como fazer. Este fato é estendido aos livros, modelos de qualidade, disciplinas, consultorias e cursos ligados à ENGENHARIA seguem o mesmo raciocínio, relatam o que e não como.
Afirmo isto com legitimidade, pois participo de diversas consultorias e trabalho dentro de um curso de engenharia de software que contrapõe a afirmação apresentada acima. A prova desta contraposição está ligada ao feedback que recebo de vários alunos e clientes (empresas que nos contratam, via Fundação, em consultorias). Estes feedbacks estão armazenados em minha base histórica de projetos, compartilho alguns com vocês.
O método de trabalho delineado pela sua equipe para nossa empresa alterou nossa forma de trabalho. Vocês executaram conosco, de forma prática, o método proposto, todos perceberam como fazer para estabelecer métricas de qualidade. A outra consultoria dizia-nos apenas o que fazer”. (feedback obtido após a implantação de um processo em uma empresa).
“Professor, em sua disciplina sempre você apresenta como trabalhar a engenharia de software, você vai além do campo teórico, sempre embuti a prática em todas as aulas – esta constatação também pode ser estendida a todos os demais professores” (feedback obtido no final de 2014, após ministrar aulas de introdução a engenharia de software, no curso de Bacharelado em Engenharia de Software da Universidade Tecnológica Federal do Paraná).
Todos nós, profissionais que trabalhamos diretamente com as Engenharias, devemos relatar para toda a comunidade, acadêmica e empresarial, como fazer e não somente o que fazer.
O como fazer gera mais positividade, ou seja, a percepção do processo é real e todos entendem passo a passo aquilo o que está sendo construído. Possibilitam os envolvidos a receber um conjunto de conhecimentos mais sólidos.
Importante: O como fazer provê um aprendizado mais rápido e com maior qualidade.
Saia da esfera teórica e atinja a prática, durante a realização de seu trabalho, de suas aulas, de suas consultorias e na concepção de seus livros e materiais – foque mais o como.
Acredito que estamos perdendo este horizonte. As nossas universidades são, em sua grande parte, teóricas. A indústria necessita de pessoas que resolvem problemas de forma rápida e consistente.
Enfim, que tal praticar mais aengenharia do como e menosa engenharia do que?
Pessoal, este texto destina aos diretores de escolas (públicas ou privadas) e professores que desejam utilizar o Mindstorms (robô apresentado na foto) no ensino fundamental e médio.
No texto, nós professores do Laboratório de Inovação (LabInov) da Universidade Tecnológica Federal do Paraná, campus Cornélio Procópio (UTFPR-CP), estamos trabalhando com alguns projetos que envolvem alunos de escolas públicas e privadas no ensino de conceitos abstratos como física, programação de computadores, lógica e matemática.
Os objetivos dos projetos estão diretamente ligados a ideia de potencializar o raciocínio abstrato dos alunos e implementar técnicas para melhorar o desenvolvimento cognitivo.
Iremos apresentar uma pequena parte de um dos projetos desenvolvidos pelo LabInov.
Projeto: Ensino de geometria plana utilizando a Linguagem Logo e Mindstorms ev3.
Público alvo do projeto: Alunos do ensino fundamental.
Durante a execução deste projeto os alunos tiveram contato direto com os conceitos de introdutório ligados a geometria plana. Foram trabalhados conceitos inerentes a: reta; semireta; segmento; ângulo e propriedades angulares das figuras geométricas.
Abaixo é possível encontrar dois vídeos que trabalham diretamente estes conceitos utilizando a linguagem logo.
Perceba que no primeiro, os alunos do ensino fundamental executam os procedimentos: reta; semireta e segmento. Importante este procedimentos foram implementados pelos próprios alunos
Já o segundo apresenta os alunos implementando procedimentos: quadrado, quadrado1, triângulo e pentágono. No procedimento quadrado os alunos não utilizam o comando repita, comando este que agiliza a construção dos procedimentos. O repita é utilizado para as demais figuras. Por fim é importante ressaltar que na construção do triângulo e do pentágono os alunos percebem que uma das propriedades da figura é dividir 360 (área da circunferência) pelo número de lados que a figura possui. O resultado desta divisão caracteriza o grau que o ângulo deve possuir na composição da figura.
Após apresentar os referidos conceitos utilizando a linguagem Logo, os alunos trabalham diretamente com o Mindstorms (vide vídeos abaixo).
No primeiro vídeo é possível perceber que os alunos inserem dentro de uma estrutura de repetição dois objetos, o primeiro objeto possibilita o robô traçar os lados do quadrado, o segundo proporciona ao mindstorms rotacionar 90º.
O segundo vídeo apresenta o Mindstorms ev3 trançando um quadrado.
Já o terceiro apresenta os alunos interagindo fortemente com Mindstorms.
Por fim, é importante salientar que estou a disposição de todas as escolas do Brasil para realizar apresentações aos alunos, esta apresentação é classificada como um dia diferente da matemática na escola. Basta agendarmos e equalizarmos a forma de deslocamento, que um dos pesquisadores do LabInov vai até a escola.
A Universidade Tecnológica Federal do Paraná – Campus Cornélio Procópio oferece, a partir do segundo semestre de 2014, o curso de Bacharelado em Engenharia de Software. Atualmente o profissional desta área é um dos mais procurados no Brasil e no Mundo. Veja o projeto pedagógico do curso neste link.
Na figura ao lado você encontra o modelo que norteou todo o desenvolvimento do projeto pedagógico.
Informações adicionais:
Titulação Conferida: Bacharel em Engenharia de Software.
Modalidade de Curso: Ensino presencial
Local de Oferta: Universidade Tecnológica Federal do Paraná Campus Cornélio Procópio.
Coordenação e Unidade Executora: Coordenadoria de Engenharia de Software
Duração do curso: 08 semestres letivos.
Regime escolar: Semestral, com a matrícula realizada por disciplina.
Número de vagas: 88 vagas por ano, com 44 vagas ofertadas em cada semestre.
Turno previsto: Noturno.
Engenharia de Software 