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.
Pessoal, nesta semana iniciamos uma discussão sobre gestão de crise. Tentamos responder: Qual é a origem da crise?
Identificada a crise, é importante, neste momento, tentar delimitar o seu tamanho, o seu contexto ou as suas fronteiras.
Se você conseguir identificar o tamanho da crise, você consegue prever o esforço necessário para superá-la.
Vamos um exemplo:
Pandemia de COVID-19, quando iniciou, os especialistas diziam que a fase crítica poderia durar 2 anos, até que as vacinas fossem desenvolvidas. E dentro de algumas condições de contornos, os especialistas minimamente acertaram.
Atualmente a pandemia arrefeceu, e estamos voltando a uma certa normalidade.
Perceba que para buscar uma previsão do tamanho da crise é necessário conhecer o cenário no qual você se encontra e buscar fatos semelhantes na história.
Identificar o tempo e o tamanho da crise é de fundamental importância para enfrentá-la.
Olá pessoal, vamos iniciar uma série de textos sobre gestão de crise.
A ideia é entender e trabalhar em situações adversas e possibilitar que os problemas possam ser minimizados.
Iniciamos nosso primeiro texto definindo o que é crise
Uma crise é caracterizada como uma mudança brusca ou uma alteração importante no desenvolvimento de um qualquer ação, evento ou acontecimento. Essas mudanças podem ser políticas, econômicas, sociais, físicas ou simbólicas. Crise pode ser definida também como uma situação complicada ou de escassez. Uma pessoa, uma empresa, um país e até a humanidade podem atravessar diversas crises.
É importante entender qual é a origem da crise? O que provocou a mudança brusca em um determinado evento?
Na maioria das vezes existem diversos sinais que podem indicar que uma entidade qualquer irá entrar em crise. Vamos a um exemplo bem simples.
Um determinado governo de um determinado país, fura o teto de gastos e provê subsídios para determinados produtos por algum tempo. Imagine que esses produtos continuam sendo valorizados no mercado internacional. Imagine também que em um determinado momento o governo não terá mais como prover os subsídios, pois terá que pagar as dívidas adquiridas.
O que irá acontecer?
Uma disparada de preço do referido produto.
Se os produtos forem importantes para a cadeia produtiva de uma empresa, ela pode entrar em crise.
Perceba que existem sinais que a crise irá acontecer. Alguns sinais sobre a crise são latentes ou mais claros, outros são difíceis de perceber. Exemplo: O ataque de 11 de setembro. Tenho a plena convicção que a maioria das pessoas não imaginavam que aquele ataque iria acontecer.
Saber de onde vem a crise, qual é a sua origem, é de extrema importância para que possamos enfrentá-la.
O Squad se caracteriza como a equipe que irá trabalhar em um determinado projeto. São os programadores ou desenvolvedores que irão executar as tarefas caracterizadas no Backlog.
No Scrum o Squad se constitui em uma equipe mais enxuta, ou seja, ela possui entre 4 a 8 pessoas, dependendo do tamanho da Backlog. Eu já vi Squad com 10.
Uma vertente importante e já implementada pelo proponente deste blog é trabalhar com várias Squads, implementando o Scrumde Scrums.
Já o Capacity Planning (gestão de capacidade) por ser caracterizado pelo mapeamento e alocação de um conjunto de boas práticas, inerentes aos colaboradores de um determinado time.
Nesse caso: Capacity Squad = “Os caras” são bons em que. (Na zaga ou no ataque? Onde escalar o quarteto fantástico?)
Após as definições vamos a questão delineada por um de nossos interlocutores:
No momento de definir o Capacity de uma Squad rodando Scrum, é necessário considerar o Capacity Planning ou apenas o tempo produtivo de desenvolvimento/testes?
Vou responder a questão dentro de minha experiência em lidar com equipe em vários tipos de projetos, inclusive de software.
Geralmente, em um ambiente de produção de software, quanto maior o conhecimento de um colaborador, mais produtivo ele será.
Na engenharia de software dois fatores influenciam diretamente na produtividade:
1 – conhecimento sobre o modelo de negócio na qual a aplicação está sendo desenvolvida. Programadores não podem ser considerados como meros construtores de código (isso é uma outra discussão que podemos alinhavar)
2 – conhecimento sobre a tecnologia implementada na aplicação.
Perceba pela figura que o quadrante preto é o desejável para definir o Capacity Squad.
Porém o desejável nem sempre é aplicável. Correto?
O estado atual do projeto, a capacidade e a maturidade da equipe em relação ao processo, serão de fundamental importância no Capacity Squad.
Outro fato que implica no Capacity Squad é a gestão de conhecimento.Compor equipe com pessoas experientes e com novatos. Fato esse que vai ao encontro da racionalidade e equalização do conhecimento no modelo de negócio e na tecnologia.
O que eu faria então?
Analisaria:
a) o momento na qual a empresa se encontra em relação ao processo e maturidade de seus colaboradores;
b) o estado atual do projeto em relação a expectativas das entregas.
Para mapear o meu Capacity Squad.
A composição depende do momento, não tem uma fórmula, é dinâmica.
Claro que o time tem que possibilitar que eu construa soluções distintas para as diversas situações atravessadas pelo processo.
O conceito foi criado em 2004 durante Pacto Global, evento liderado pelo Banco Mundial. Três palavras da língua inglesa compõe a sigla:
Environmental
Sustainability
Governance
A ideia é aplicar esse conceito dentro de organizações estruturadas ou empresas. Essas organizações não devem pensar no lucro somente, aspectos ligados a adequação ambiental, sustentabilidade e governança devem ser considerados no core da gestão.
Além do ROI (Retorno Sobre o Investimento) e da sustentabilidade financeira, a empresas devem ter como métrica:
O Ambiente
Para que essa métrica seja atingida a empresa deve responder positivamente algumas questões:
A organização usa recursos naturais e os repõe?
Não emite gás que provoca o efeito estufa?
Prima pela eficiência energética?
Evita poluição e realiza gestão de resíduos?
Todas as questões levantadas nessa métrica podem ser compactadas em uma: Como a empresa lida com o meio ambiente?
A Sociedade
Para que essa métrica seja atingida a empresa deve responder positivamente algumas questões:
Os colaboradores recebem um pagamento justo e digno?
Não considera em hipótese alguma a mão de obra escrava?
Não considera em hipótese alguma a mão de obra infantil?
Prevê a inclusão dos grupos discriminados?
Prima pela diversidade?
Possui aproximação com a comunidade local?
Todas as questões levantadas nessa métrica podem ser compactadas em uma: Como a empresa se relaciona com os seus colaboradores?
A Governança
Para que essa métrica seja atingida a empresa deve responder positivamente algumas questões:
A empresa possui um conselho deliberativo independente?
Ela prima pela ética e transparência?
A remuneração dos gestores (CEOs, CIOs) não extrapolam?
Existe inclusão e diversidade na Gestão (CEOs, CIOs)?
Aspectos ligados a processo, planejamento, gestão são amplamente considerados na estrutura organizacional?
Todas as questões levantadas nessa métrica podem ser compactadas em uma: Como a empresa se relaciona com a sociedade?
Veja quem investiu em em ESG no mundo entre 2016 e 2018(Fonte: Inovação e ESG, da consultoria ACE Cortex).
Japão: aumento de 307%;
Austrália: aumento de 46%;
Canadá: aumento de 42%;
Estados Unidos: aumento de 38%;
Europa: aumento de 11%;
No Brasil cerca de 50% das grandes empresas se preocupam com o ESG. E em uma pesquisa com os consumidores brasileiros é possível considerar que 87% prefere comprar de uma empresa sustentável e 70% não se importam em pagar um pouco a mais por isso.
Para finalizar afirmo que o conceito ESG não revela nada de novo. Algo que todos nós devemos internalizar no nosso processo de EDUCAÇÃO.
RESPEITO AO MEIO AMBIENTE
RESPEITO AO PRÓXIMO
ÉTICA E TRANSPARÊNCIA
Nome novo para algo que já pregamos (ou deveríamos pregar) há muito tempo.
Uma excelente questão apresentada no título deste post.
Verifique o posicionamento de alguns profissionais da área de engenharia de software.
Apenas 26,3% acreditam que sim.
Para respondê-la, vamos apresentar formalmente duas métricas tradicionais:
Pontos por Função
Pontos por Caso de Uso
A técnica para mapear a complexidade de um software por Pontos de Caso de Uso foi proposta em 1993 por Gustav Karner. Ela é baseada em duas outras técnicas – Pontos de Função e o Mk II (adaptação da técnica dos pontos por função, comumente utilizada pelos ingleses). A técnica mapeia a complexidade dos atores e dos casos de uso. Aprofunde-se nessa métrica por meio deste link.
Pontos por Função é uma das técnicas (ou métodos) que proporcionam estimar a complexidade de um software. Formalmente, FPA é caracterizado como um método que busca medir a complexidade de um software pela quantificação das funcionalidades. É importante ressaltar que tal método foi criado em 1974 pela IBM e foi, posteriormente, desenvolvido por Caper Jones e pelo International Function Point Users Group. Você encontra mais informações sobre Pontos por Função neste link.
Após a definição de duas métricas tradicionais da área de engenharia de software, vamos a customização customização de uma delas.
Vamos partir da métrica de pontos por função, mais precisamente dos Arquivos Lógicos Aritméticos – os ALIs. Na métrica em questão um arquivo nativo da aplicação é classificado dentro de 3 parâmetros:
Complexidade Baixa;
Complexidade Média;
Complexidade Alta.
Os parâmetros de complexidade são mapeados a partir da quantidade de campos, presente no arquivo, e da forma de organização das tuplas (ou linhas) que os compõem. Quanto maior o número de campos e quanto maior as formas de organização das tuplas, mais complexo é o arquivo. Veja só:
Arquivos que possuem a quantidade de campos entre 1 a 19 e uma forma de organização de registro (ou tupla) possuem uma complexidade baixa.
Arquivos que possuem a quantidade de campos entre 20 a 50 e uma forma de organização de registro (ou tupla) possuem uma complexidade baixa.
Arquivos que possuem mais de 50 campos e uma forma de organização de registro (ou tupla) possuem uma complexidade média.
Para conferir toda a complexidade dos arquivos, das entradas, das saídas e das consultas você pode consultar essa planilha.
Você pode alterar as faixas para mapeamento da complexidade, sempre respeitando os parâmetros de sua base histórica de projetos. Uma proposta:
Arquivos que possuem a quantidade de campos entre 1 a 9 e uma forma de organização de registro (ou tupla) possuem uma complexidade baixa.
Arquivos que possuem a quantidade de campos entre 10 a 20 e uma forma de organização de registro (ou tupla) possuem uma complexidade baixa.
Arquivos que possuem mais de 20 campos e uma forma de organização de registro (ou tupla) possuem uma complexidade média.
Perceba que você está mexendo na linha 8 da planilha.
Para finalizar nossa resposta. É possível customizar uma métricas de software tradicional desde que você tenha parâmetros em sua base histórica de projetos muito bem definidos. Para ter parâmetros bem definidos é necessário possuir um processo de software institucionalizado.
Mas lembre-se de uma premissa, quando você tiver que participar de uma concorrência ou licitação para vender um software, e essa licitação estabelecer como métrica pontos por função, você deverá utilizar a forma tradicional da métrica.
Fica uma provocação: Vamos criar uma métrica de software para sua empresa? A sua métrica!
Nós engenheiros de software, analistas de sistemas e desenvolvedores sempre proclamamos a ideia de termos uma relação próxima entre nós e nossos usuários – as (pessoas que manipulam e usam o software). Essa relação, atualmente é chamada de DevOpS.
Vários autores classificam DevOps como uma cultura que aproxima DEsenVolvedores de software (Dev) e os OPeradores de Software (OpS). A ideia central é proporcionar uma comunicação mais clara entre os papéis supracitados. Trabalhar com a automação e monitoramento em todas as fases da construção de software também é algo defendido por vários autores.
Novamente, ressalto que DevOpS é um nome novo para algo que já fazemos há anos.
A aproximação entre Desenvolvedores e Usuários proporciona a liberação de pacotes de software com o alinhamento mais próximo com os objetivos do negócio da organização. Fato este preconizado pela engenharia de software.
Automatizar o processo de produção de software, capturando as informações sobre a construção do produto também preconizado pelas velhas Fábricas de Software da Década de 1960, fato explicitado por Cusumano em sua obra Japans Software Factories.
Por fim, às vezes acreditamos que estamos usando um conceito inovador dentro do ambiente produtivo, porém se formos a fundo nos pressupostos da engenharia de software, o conceito já é usado com sucesso há tempos.
Pessoal, nessa semana recebi diversas dúvidas sobre Grooming Scrum. Neste post vou definir a referida técnica, apresentar um processo simples e elegante que proporciona a qualquer profissional da área de processos e executar essa técnica. Importante, eu vou apresentar, eu não vou descrever, institucionalizar o processo.
Antes de iniciar a definição é necessário substituirmos o termo Grooming por Refinement. Grooming na nossa língua portuguesa receba a tradução de aliciamento de crianças na Internet.
Refinement é definido como o ato de preparação de sua Product Backlog (PB). Lembre-se que a PB se caracteriza como tudo aquilo que você necessita executar para construir um determinado produto. Na Engenharia de Software, a PB acondiciona as características ou requisitos de um determinado Software.
Eu, particularmente, relaciono o ato de preparação com o ato de cuidar. Isso mesmo, cuidar. O cuidado com algo ou alguém remete a ideia de zelo e proteção. Neste caso o Refinement se refere ao zelo com as características ou requisitos de seu produto de software.
Diante do contexto apresentado, podemos elencar algumas questões para serem respondidas:
I – Como proteger e zelar a sua PB?
O zelo e a proteção nesse caso refere-se ao entendimento, detalhamento (componentização), descoberta (e não especulação) de novos itens e estimativas de tempo de produção de um determinado requisito de software.
II – Existem boas práticas para proteger e zelar a sua PB? Existem boas práticas para implementar o Refinement?
Não existe uma fórmula pronta para implementar o Refinement durante a construção de um software, podemos elencar aqui algumas ações que executamos dadas as características de projetos que gerenciamos. Vamos a elas:
Priorize: Reúna o Scrum Team e o Product Owner. A reunião tem como pauta a priorização dos requisitos. O que deve ser implementado primeiro? O que é mais importante? Qual a relação de dependência dos requisitos? É possível quebrar essa relação de dependência?
Componentize: Scrum Team e Product Owner (PO) devem ter a capacidade de dividir as grandes pedras e pedras menores. Certamente será muito mais fácil carregar pedras menores durante a Sprint. O saciamento da sede da equipe de usuários também será melhor gerenciada com as entregas constantes. Você pode utilizar o velho e bom diagrama de componentes proposto, nas décadas de 1970 e 1980, pelo Edward Yourdon.
Descubra: Isso mesmo, descubra novos itens, novas características, novos requisitos de software. Eu escrevi descubra, eu não escrevi especule. Durante o processo de componentização você pode descobrir junto ao PO novos componentes de software. Quando partirmos para uma maior granularidade, vamos percebemos características que não tínhamos percebido antes.
Estime: Qual é o tempo e esforço para a construção de um determinado componente? Qual é o tempo e esforço para executar um determinada Sprint? Você consegue responder essas questões com uma base histórica de projetos institucionalizada. Já publiquei vários textos dentro deste tema no blog.
O processo apresentado é simples e não traz nenhuma inovação conceitual para a engenharia de software. Priorizar, Componentizar, Descubrir requisitos e Estimar tempo e esforço já é realizado pelos Engenheiros de Software a décadas. Neste caso, no meu ponto de vista, Refinement é um termo novo na boa e “velha” Engenharia de Software.
Embora esta atividade proponha apenas exercitar o refactoring de um código feito por outra pessoa e expor a experência, eu gostaria de expor uma ocasião real que tive quando trabalhei como programador para um projeto especifico.
O projeto era de uma aplicação que pretendia organizar o fluxo de aprovação de novos produtos de uma empresa de cartão de crédito.
Foi escolhido o Lotus Notes/Domino como plataforma, pela facilidade que o software apresentava na criação de sistemas com fluxo, aprovações e integração com sistemas de email.
Eramos 2 programadores, eu (programador1) ficava responsável por criar os módulos, formularios e eventos, enquanto o outro (programador2) era responsavel por acoplar os “objetos” que eu criava no sistema principal. Claro, alteração e refinamento do meu trabalho, era parte da responsabilidade do outro programador.
Então de certa forma, eu entendo que faziamos uma especie de refactoring, já que o meu códio era refatorado imediatamente ao ser implementado no sistema final, portanto listo algumas das caracteristicas do refactoring, que colaboram com a minha afirmação.
Reestruturação do Código: a reestruturação do código era inerente neste caso, pois o programador1 nem sempre tinha visibilidade do sistema como um todo, e o programador2 precisava entender o código para acopla-lo no sistema principal.
Manter o Comportamento: O programador2, precisava manter o comportamento dos modulos feitos pelo programador1, caso contrário o modulo era devolvido ao programador1 para reescrita.
Melhorar a Forma e Estrutura: O programador2 era responsável por adaptar o codigo que recebia ao sistema principal.
Preservar a funcionalidade: durante a integração dos modulos novos, o programador2 precisava garantir a preservação das funcionalidade oferecidas originalmente.
Melhorar a Leitura e manutanção: O programador1, precisava escrever o código de forma que fosse possivel o trabalho do programador2 sem ajuda, enquanto que o segundo precisava fazer o mesmo ao acoplar no sistema principal.
Escalabilidade: Ponto chave na maneira em que trabalhávamos, era importantíssimo que tivessemos esta caracteristica em mente o tempo todo, de outro modo não teria sido possivel aplicar nossa maneira de trabalho.
Concluindo, claro que tivemos momentos de incertezas e problemas no fluxo de nosso trabalho, mas funcionou e nós conseguimos entregar o que foi planejado usando este modelo de trabalho, que no caso foi aplicado por nós por questões logisticas que nos impediam de estar ao mesmo tempo executando este projeto.
por Thomaz Martins – Especialização em engenharia de software.
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.
Pessoal, hoje vamos falar um pouco sobre Análise de Impacto no Negócio.
É importante ressaltar que toda organização pode ser impactada de forma negativa dada a efusão de um evento externo não programado ou dada a tomada de decisão incorreta na modelagem de um processo de negócio. Analisar este impacto e definir ações que minimizem o estrago é de extrema importância dentro de qualquer ambiente de negócio. É aí que entra o Business Impact Analysis (BIA).
Em resumo, a BIA tem como objetivo avaliar os riscos que um determinado projeto pode oferecer à sua organização. Desenvolver uma boa análise de impacto que um projeto pode trazer ao seu negócio pode evitar a execução de procedimentos que apresentem riscos à sua organização.
Para realizar a Análise de Impacto em seu Negócio sob a luz da execução de um projeto qualquer execute os passos abaixo:
Selecione a unidade de negócio e verifique qual projeto você deseja executar dentro daquela unidade.
Faça o mapeamento das atividades do projeto que você quer executar.
Analise o impacto de cada atividade mapeada no projeto sob a luz de dois prisma:
Ocorrência de um evento externo durante a execução da atividade;
Problemas de modelagem ou concepção na sua atividade. Se problemas de modelagem ou concepção foram detectados, retorno ao passo 2.
A BIA deve gerar alguns artefatos importantes:
Processo mapeado.
Relato dos impactos mapeados.
Plano de contingência caso algum evento externo ocorra.
Perceba que a BIA depende de diversas ações importantes dentro da atividade de gerenciamento. Destacamos aqui algumas delas:
Definição do escopo do projeto.
Mapeamento das atividades e tarefas do projeto.
Modelagem do projeto em uma linguagem clara, concisa e consistente.
Análise das variáveis que compõem o ambiente externo.
Avaliação do projeto modelado.
Para finalizar, a figura abaixo tenta apresentar de forma simples e elegante os 3 passos da Análise de Impacto no Negócio.
Engenharia de Software 