Não foi difícil, uma prova média, mas o material de estudo não é completo e não abrange todas as perguntas da prova. Fiz pela Certiprof na faixa, talvez só com o material não dê pra passar de primeira.
Manual Kanban do Scrum.org:
Baixar Manual Kanban do Scrum.org (PDF)
Slides Treinamento CertProfi:
Baixar Slides Treinamento CertProfi (PDF)
Figura 1 - Certificado KIKF - Buga
O problema não é o mainframe, são os processos!
Tudo isso porque li uma matéria do Itaú...
Do nada me chega essa daqui abaixo (atualizado em 11.10.2019)
https://valor.globo.com/opiniao/coluna/o-principio-do-fim-para-os-grandes-bancos.ghtml
Segue meu texto original
De uma aula introdutória de economia lá nos idos de 1998 tomei conhecimento da ameaça de novos entrantes, nunca estudei a fundo, longe disso, mas as ideias do Michel Porter - esse das 5 forças e o famoso 4 P consegui pegar o principio, na minha Pós em Negocios Financeiros uns anos depois tive contato novamente e por vezes me deparei com o cenário! Eu mesmo já fui um novo entrante quando montamos a fábrica de rodinhas e shapes de skate. Bom, introdução feita, seguem os comentários...
Esses dias mesmo me peguei fazendo uma conta de padaria para estimar os valores desembolsados pelos bancos para a IBM, isso sempre foi uma barreira para a entrada de novos "players" no mercado... Você não poderia ter banco há alguns anos sem o processamento mega hiper blaster e sem igual de um mainframe! E isso amiguinho era muito caro, digo, é muito caro! Voltando a conta de padaria, não tenho os dados mas chuto que os top 4 (BB, ITAÚ, BRADESCO, CAIXA) devam ter algo perto de meio milhão de MIPS instalado cada um, isso em valores atuais deve ser algo em torno de uns 2.5 bilhões de reais - CAPEX como chamam os entendidos - e isso é só o valor pra comprar os computadores!!! Depois tem um valor mensal pelo uso (tanto dos softwares como do hardware), no mês eu chuto mais uns 30 milhões pra IBM desembolsados por cada um. Esse valor de largada inviabiliza qualquer tentativa de se abrir um banco! Ah, mas esses são os top 4, beleza pega o Santander que é o quinto - não lembro de cabeça e se sair para procurar perco a linha do raciocínio - mas ele gastou alguns bilhões pra montar o data Center aqui do lado de casa, o Itaú idem com Mogi. É um rio de dinheiro! Enfim, quero reafirmar que você não conseguia abrir um banco sem um mainframe.
Alguma coisa mudou, na década de 90 a "baixa plataforma" iria acabar com o mainframe, foram feitas algumas tentativas de migração de mainframe pra micro computador mas não era nem de longe alguém querendo abrir um banco eram os próprios bancos tentando reduzir a conta para com um grande sócio, a IBM. Resumo, não deu certo a capacidade de processamento estava muito aquém do necessário.
Alguma coisa mudou 2. Tudo evolui, o mainframe evoluiu, os micros também...
Sem falar em armazenamento!
Quando vi um mainframe pelo primeira vez me vi dentro de um microcomputador! Entende-se mainframe aqui como o andar inteiro onde ficava todo o aparato tecnológico necessário para o seu pleno funcionamento.
Bom, estou falando de armazenamento, pois bem, estava em desativação uma "colmeia", basicamente era um grande depósito de fitas magnéticas, um conjunto de módulos acoplados (acho que eram 12 no total) com um robô que se encarregava de pegar as fitas e carrega-las em disco quando alguém solicitava um arquivo que estava gravado em alguma das milhares de fitas que la estavam. Sabe a capacidade dessa colmeia ? 10 teras, o mesmo que a capacidade de 10 celulares top de linha da Samsung hoje!
A última vez que li as especificações de um mainframe lembro de algo que me chamou a atenção... Não é o objetivo, nunca foi, mas adaptou-se e o mainframe hoje (um único mainframe) consegue sozinho rodar algo em torno de 10.000 máquinas/servidores Linux, é algo assombroso pra uma máquina que tem o tamanho de uma geladeira de americano de duas portas, eu desconheço por completo como que a IBM comercializa isso, você ter um mainframe pra rodar Linux, mas existe e é muito legal para comparação.
Hoje é possível criar essa mesma quantidade de servidores/máquinas na Amazon/Google/ ou mesmo na própria IBM sem ter que desembolsar nada de investimento inicial, paga-se apenas o que usar!
O que aconteceu de mágico ? Nada!
Não foi algo disruptivo como afirmam, foi apenas uma evolução natural da tecnologia...
O que antes era uma vantagem competitiva e barreira a novos entrantes se tornou um dos maiores pesadelos dos grandes bancos, o mainframe!
É um baita dinheiro que se paga para a IBM, mas o processamento em PCs (bare metal, virtualizados, nuvem ou o que quer que seja) para os volumes que os grandes bancos possuem não fica muito mais barato a ponto de valer a pena monetariamente, mas mesmo assim eles estão caminhando para a transformação que pode significar sua derrocada em menos de uma década.
Para quem quer começar o custo do mainframe é proibitivo, porém do processamento em PCs é viável e atualmente já dão conta do processamento necessário.
O problema dos grandes bancos não é o mainframe, mas os processos internos que acabaram sendo incorporados ao longo das décadas.
Existem instalações que você sequer consegue ver a compilação de um programa pra tentar ajudar seu coleguinha! Código fonte de outro sistema ? Jamais! Consultar um dado de produção ? Ficou louco ?!?!
As disciplinas de computação que são ensinadas nas faculdades e que são vistas como verdade não possuem paralelo no mundo mainframe, mas mesmo assim tentam incorporar coisas que não fazem sentido, quer exemplo? Veja um teste unitário automatizado em Java, em mainframe sequer é possível fazer a analogia do que viria a ser o teste unitário! É outro conceito, não se aplica! Gasta-se um tempão fazendo atividades que não levam a lugar algum! Como um teste "mockado" que não chegou a ir no banco de dados, cara é mainframe, o banco vai estar lá...e funcionando!
A moda agora é o Ágil! Desculpe pessoal, mas deixa eu contar, o desenvolvimento de software no mainframe nasceu ágil!
Eu trabalhei em uma equipe que rodava ágil no mainframe antes mesmo de ser modinha ou mesmo de termos consciência que o que fazíamos tinha esse nome, os mais antigos sempre lembravam que antigamente todo mundo trabalhava igual a nossa equipe, mas eram outros tempos, fomos os últimos sobreviventes.
Nosso time era pequeno, multidisciplinar, autogerenciavel, todo mundo sabia exatamente o que o outro estava fazendo e se estava precisando de ajuda, éramos donos do negócio, tinhamos iniciativa, comprometimento, responsabilidade e autonomia ímpares! Fazíamos entregas rotineiras (2 a 3 vezes por mês) de novas funcionalidades e melhorias no sistema, realizavamos testes automatizados, controle de versão com retorno instantâneo em caso de deploy com problemas. Precisava de um dado de produção, tá aqui, na mão, agora! Eu mesmo acessava a tabela ou o arquivo para consultar o que quer que fosse necessário. Precisa corrigir um dado, processar algo urgente? Um job@ resolve seu problema e se for urgente, urgente mesmo da até pra rodar na janela do on-line! Por vezes esbarravamos em processos que iam além de nossos conhecimentos e poderes, mas devido a criticidade do sistema esses impedimentos eram resolvidos muito rapidamente, o ser um sistema crítico era o abre portas para que os processos rodassem rápido e que a ajuda chegasse a galope, uma pena pois deveria ser assim com todos os sistemas. Poderia falar horas a fio sobre isso, mas fica para outra oportunidade.
Os processos incorporados na rotina ao longo dos anos foi o que acabou fazendo com que projetos começassem a demorar cada vez mais.
No tempo de uma Sprint você sequer consegue enviar seu pacote para o ambiente de homologação!
Vai precisar adicionar uma coluna em uma tabela! Lá se foi sua Sprint e você nem viu sinal da nova coluna!
Ah, mas o problema é que não temos as ferramentas para DevOps no mainframe! Balela, tem tudo e nem precisa de nada novo, a própria IBM pra quem for preguiçoso tem o UrbanCode que faz um deploy automatico com interface gráfica e tudo! Não precisa nunca ter visto um Jcl na vida pra conseguir usar, mas isso é outro tópico e todos os grandes bancos têm suas ferramentas para deploy em produção de versões de aplicaçoes no mainframe de maneira automatica.
Sair do mainframe esperando que os tempos de projetos serão menores, que irão dar conta de lançar produtos na velocidade de uma startup é uma utopia!
Uma startup não tem um "by the book" a ser seguido, o cara precisa enviar pra produção uma alteração que não deu pra testar direito ele vai lá e manda se der problema ele volta e analisa.
Isso é inconcebível de acontecer hoje em dia num grande banco! Mesmo existindo ambiente de produção para baixa controlada se você fizer algo assim será demitido! Se bem que pensando aqui... a propria start up quando fica muito grande acaba incorporando os mesmos processos seguidos pelos grandes bancos e acaba perdendo seu grande diferencial e tem que contratar muito mais gente pra dar conta de um monte de coisa que não precisava e nao existia no começo! Mas isso é assunto pra outro dia.
Uma pena os bancos estarem gastando tempo com conversões de sistemas para "baixa plataforma" tentando ganhar velocidade na entrega de projetos ou mesmo iniciando projetos novos já em PCs sendo que o que precisam é somente voltar para suas raízes tecnológicas de 20, 30, 40 anos atrás.
Um banco digital a partir do zero, hoje em dia, sai em menos de 3 anos, já vi projetos de produtos/soluções bancárias que demoraram mais que isso!
Repito, o problema não é a tecnologia, mainframe ou PC, são os processos.
Entretanto, como não temos fintechs rodando mainframe só confirmarei isso daqui uns 10 anos quando os bancos tiverem concluído a migração quase que total do mainframe para PCs e os projetos continuarem demorando o mesmo tempo que outrora.
Encerrei como deu, to com sono, quando tiver tempo reescrevo.
Atualização 2024 09 25 - Não rolou de sair pra vereador nem na de 2020 que foi pandemia e tals e nem nessa de 2024, quem sabe na de 2028, vou perguntar pro sunega como que foi esse rola.
Sobre as certificações, firme e forte, não faço mais provas faz um tempo, mas é sempre bom um papel que certifique seus conhecimentos.
Uns anos atrás, seilá uns 5 (estamos em 2018), não me ligava em certificação, sempre quis fazer, mas nunca fui atrás, seja porque onde eu trabalhava ninguém tinha e quando eu puxava o assunto recebia sempre críticas do tipo... a gente nunca precisou, pare com essa ideia de aprender coisas novas, gastar tempo e dinheiro à toa, enfim, eu tinha vontade de fazer certificação de PMP - Project Management Professional tinha dois amigos meus que tinham, o Allan e o Flavio, cheguei a conversar com eles, mas tinha que ler o tal do livro da Rita, fazer 352 mil exercícios e ficar um dia todo fazendo prova além do que era uma graninha considerável o processo todo, e acabei deixando pra lá.
Depois que vim para o "mercado" o pessoal começou a cobrar e como não tenho formação na área de computação abracei a ideia e fui mandando ver nas certificações básicas pra saber ao menos o essencial pra poder conversar com o pessoal que manja dos assuntos... pra eu parar com os achismos e ter um pouco mais de conhecimento, afinal conhecimento nunca é demais.
Nessa jornada das certificações, fiz algumas bem "diferentes" mas que me fizeram ter uma visão mais mercadológica ou mesmo acadêmica das disciplinas que eu tinha contato, mas estava aprendendo ou fazia as coisas na orelhada, sem muito embasamento teórico. O caso do Lean é um desses casos! Trabalhei com metodologias ágeis e desenvolvimento enxuto na IBM mas lá eles deram uma customizadinha das boas nos processos e embora eu já tivesse trabalhado com SCRUM anteriormente na Stefanini e parando pra pensar no próprio Banco do Brasil a gente se organizava e trabalhava bem alinhado com o manifesto ágil, mas voltando ao Lean, estou atualmente trabalhando com "Lean Digital Transformation" recebi uma enxurrada de material, consegui garimpar bastante, aprendi muito no dia a dia, mas pra variar falta o "reconhecimento", nem que seja pra eu mesmo pra saber que sei o que o pessoal está falando, consigo entendê-los e conversar na mesma língua!
Sempre curti estudar, o problema é priorizar isso com todos os eventos da vida atualmente, mas consegui parar um tempinho, estudar, fiz um treinamento on-line pela TIEXAMES, que abordou praticamente tudo que caiu na prova, a dinâmica do treinamento deixa um pouco a desejar, mas ajuda bastante quem estiver inseguro ou meio perdido com os textos.... Sem falar que só pode fazer o exame depois de ter cursado um treinamento de alguma entidade associada.
O site da Lean IT é o https://www.leanitassociation.com/
e os PDFs pra você estudar sozinho estão aqui:
Foi isso, boa sorte, a prova é super tranquila, se você tem bom senso e já trabalhou com Lean, dá pra passar sem sequer ler um texto! É básico! Café com leite pra quem, assim como eu, já está trabalhando com o assunto, entretanto, como disse, um papel pra mim significa bastante, não sei porque, talvez um dia junto com minha psicóloga consiga descobrir, mas por enquanto continuo sob a mesma condição!...
Colecionando certificados!
Aproveito aqui pra deixar a hashtag #Buga2020 pois pretendo sair de vereador aqui por campinas em 2020 e nada melhor que começar a campanha cedo!
Figura 1: Certificação de LITA Lean IT Foundation do Buga