thegoodfellas/blogset-br huggingface dataset:
Tem cada coisa que me acontece...Estava eu hoje, baixando o restante dos materiais desenvolvidos para colocar como anexo no meu TCC (que e para ser impresso e entregue HOJE), quando no meio dos arquivos, casos de teste e sabe Deus mais o que tem la, eu acho um arquivo com o nome "CONTA O CMMi"...Pensei: vai ser legal ler isso aqui, vai que alguem da banca faz alguma contestacao relacionado com o que ta aqui ne?Pra que eu fui ler aquele texto???? Que vontade de jogar meu TCC no lixo depois disso...uhauhahuauahuahuuhahuauhahuahuaAvisando: se voce nao sabe o que e CMMi, RUP, ou qualquer outro modelo de Gerenciamento de Projeto, talvez nao entenda nada do que segue, mas pra quem e da area, vale a diversao...P.S.: Por favor, so deixem para enviar isso para os professores da Ciencia da Computacao depois das bancas de TCC passarem...p.p.S.: Para quem e da area: o cara indica um monte de ferramentas legais...http://www.linhadecodigo.com.br/artigos.asp?id_ac=1262Vou comecar ja arrumando encrenca: Nao gosto do CMMI. Pronto.E isso mesmo, nao gosto. Tem gente que nao gosta de VB, tem quem nao goste de praia, tem quem nao goste do Flamengo, e eu nao gosto do CMMI, qual o problema?Depois que li um livro muito interessante chamado Freakonomics, percebi como pode ser perigoso esse negocio chamado senso comum. E esse e meu principal argumento contra o CMMI.Como assim? Bom, primeiro vale explicar o que e o senso comum:Senso comum e algo que a maioria das pessoas acredita, faz muito sentido numa primeira analise, da ate uma sensacao de bem-estar acreditar naquilo, mas que muitas vezes acaba se mostrando nao ser totalmente ou mesmo nem parcialmente verdade.Ta, mas e dai? E o CMMI?Vou entao contar um caso e depois volto nele. Esse caso aconteceu comigo tem algumas semanas, acompanhe comigo:Fui chamado a uma reuniao com diversos arquitetos, desenvolvedores e gerentes de projeto, com o objetivo de assistir a uma palestra de um gerente de projeto da nossa empresa que conseguiu tocar com sucesso um projeto de dois anos, com uma grande equipe, desenvolvendo uma aplicacao bastante heterogenea e complexa. O objetivo era podermos aprender com as melhores praticas que eles usaram.Sala cheia de gente, todo mundo cheio de perguntas a fazer, inclusive eu, e chega o tal gerente, que calmamente prepara o projetor e comeca a contar sobre a complexidade do sistema que eles criaram. Era realmente um projeto que tinha tudo para dar errado, risco altissimo.E eu ficava pensando comigo: Nossa... Esse cara deve ser um guru de gerenciamento de projetos, deve saber tudo sobre metodologias, processos, PMBOK, CMMI, RUP, sei la mais o que, me da ate vergonha de fazer pergunta boba.Antes que eu pudesse perguntar qualquer coisa, outro membro da equipe foi mais rapido:- Qual ferramenta de gerenciamento de projeto voces usaram?E ele, calmamente, respondeu:- Nos preferimos desenvolver nossa propria ferramenta.E nesse momento, pode-se ouvir um sonoro What?? de todos ali presentes. Pensei comigo: Que guru que nada, esse cara e Deus. Deve ter desenvolvido uma super ferramenta por ter se sentido limitado com relacao as outras do mercado.E ele continou:-
Isso mesmo, criamos a nossa. Querem ver? Tenho aqui alguns slides dela.E trocou para um slide com uma foto da janela da sala dele, cheia de post-its colados nela. E continuou:- Apresento nossa ferramenta de gerenciamento e acompanhamento de projeto.Apos alguns minutos de gargalhadas gerais, ele continuou as explicacoes sobre a tal ferramenta, e aos poucos fomos percebendo que aquilo nao era uma piada: Ele realmente tinha gerenciado um projeto de dois anos, para uma grande companhia aerea, com diversos riscos tecnologicos, de prazo e escopo com seus post-its colados na janela.A ideia era muito simples: Cada cor representava um membro da equipe. Como nao tinha tantas opcoes de cor de post-its, ele agrupava por equipe para facilitar a visualizacao. Cada post-it representava uma tarefa, entao tinha o nome da tarefa e a quantidade de horas para terminar, e cada janela representava uma semana. Entao ele olhava para a janela da semana atual e podia dizer quais as tarefas para aquela semana, quem estava cuidando de que, e quanto faltava para terminar. Quando algo precisava ser atualizado/modificado eles rabiscavam os post-its, trocavam de posicoes, ou mesmo colavam novos por cima dos velhos. Todo dia, pela manha, eles faziam uma reuniao rapida onde cada membro da equipe falava o que tinha feito ontem e o que tinha para fazer naquele dia. Isso era importantissimo, porque assim todos davam noticia do projeto como um todo e por terem visoes diferentes, muitas vezes descobriam erros antes mesmo deles serem implementados e mudavam o curso das coisas.Calmamente, ele foi continuando as explicacoes. Disse que todo dia um membro da equipe cuidava dos problemas mais criticos que eles encontravam pelo caminho. Dai, ele mostra uma foto do sujeito cuidando desses problemas. So que na foto o rapaz estava usando um chapeu de pirata enquanto trabalhava!Risos de novo. Agora sim, isso e piada!Mas nao era piada nao. Usar o chapeu de pirata significava duas coisas: 1-Sim, eu estou a par dos problemas criticos e estou trabalhando para corrigi-los. 2-Nao me perturbe, a menos que seja algo muito, muito serio.Bom, nao vou ficar aqui detalhando todas as coisas malucas que eles inventaram neste projeto, mas basta dizer que foi muito bem sucedido, dentro do prazo, dentro do orcamento e deixou o cliente satisfeitissimo. Isso basta para voce? Para mim, basta.Se voce e um cara especialista em processos, fa do CMMI, provavelmente ja esta ai doido para vir aqui me dar uma surra, alem de achar que isso tudo que o tal gerente de projetos fez e ridiculo e irresponsavel, que se o projeto foi bem sucedido, foi apenas sorte. Seu senso comum esta dizendo: E impossivel que um projeto termine bem sem um bom modelo de processos, todo mundo sabe disso! Entao deixe agora eu explicar o meu ponto de vista disso tudo:Ao refletir sobre todos os projetos de desenvolvimento de software bem-sucedidos de que tenho noticia, percebi que eles usaram tecnologias diferentes, metodologias diferentes (isso quando usavam alguma), tiveram abordagens diferentes em todos os sentidos. Alguns, inclusive, aconteceram muito antes de qualquer um de nos ter sequer ouvido
falar em CMMI.Entao o que fez esses projetos darem certo?Eu so consigo lembrar uma coisa em comum em todos eles: Pessoas. Pessoas competentes, com dominio de conhecimento na area em que atuavam, muito bom senso (que e diferente de senso comum) e trabalhando em equipe.Enquanto o Brasil inventa leis todo dia para resolver problemas que nunca sao resolvidos, so fazendo aumentar a nossa burocracia e criando uma quantidade impossivel de regras que acaba levando as pessoas a nao segui-las por completo (o que acaba gerando o fenomeno das leis que pegam e as leis que nao pegam), eu nao consigo evitar ver o CMMI da mesma forma. E eu nao sou o unico que pensa assim: CMMI is often criticized for being overly bureaucratic and for pushing reliability over services provided - Wikipedia. Alias, se voce quiser ver uma boa critica a modelos burocraticos como esse, assista Brazil, o Filme.Agora me ajude um pouco, responda a essas perguntas: (interessante que em espanhol, responder e contestar, que em portugues seria manifestar-se contra, mas aqui eu queria que voce realmente se perguntasse seriamente e de mente aberta essas coisas)- Se seus projetos estao sempre atrasando, voce realmente acha que implantando um modelo de processo como prega o CMMI isso vai deixar de acontecer? Voce analisou o motivo desses atrasos para saber se eles estao mesmo relacionados a processos?- Se seus projetos estao caros e voce esta perdendo sua competitividade no mercado por causa disso, voce realmente acredita que o CMMI vai baratea-los? Como?- Se seus desenvolvedores tem dificuldade em lidar com a complexidade tecnologica com que atuam, por falta de treinamento ou mesmo de perfil, voce realmente acredita que com processos que burocratizam seu desenvolvimento isso vai melhorar? - De que adianta documentar tanto algo que tem grandes chances de mudar na semana que vem? Nao lhe parece que a quantidade de artefatos nao-codigo que voce produz e diretamente proporcional a falta de flexibilidade, a lentidao e as chances de voce ter documentos inconsistentes, nao condizentes com a realidade?- Qual a utilidade de fazer reunioes de sessao-humilhacao para perguntar para todos por que suas tarefas estao atrasadas em relacao ao cronograma original e os processos nao estao sendo seguidos? O que sinceramente voce espera ouvir como resposta? Sera que as pessoas e que estao erradas ou voce e que esta sendo incompetente em definir processos possiveis e gerenciaveis? Qual a chance desses atrasos deixarem de acontecer so por causa desse tipo de reuniao? O que voce acha que isso vai causar no ambiente (pessoas) da sua empresa ao longo do tempo?Pense comigo: Se sua equipe esta produzindo codigo com muitos bugs, criar uma area de testes nao vai fazer esses bugs deixarem de ser produzidos. O unico efeito que vai realmente acontecer e que agora voce vai gastar 10% de desenvolvimento, 50% testando e corrigindo o que foi mal desenvolvido e 40% gerenciando todo o processo, tudo bem controladinho com numeros bonitinhos para que voce possa analisar de mil maneiras diferentes como voce esta perdendo dinheiro. E sabe por que isso acontece? Acontece porque
muitas pessoas que pensam no CMMI ou em qualquer modelo de processos como solucao magica para os problemas de uma fabrica de software, se esquecem de analisar as reais causas dos problemas que ocorrem ali (que podem, inclusive, ser a falta de processos bem definidos).O CMMI e essa visao mecanicista de que se pode dividir em pedacos, controlar, monitorar, padronizar e aprimorar o trabalho humano seguindo a risca processos formais, produzindo de forma homogenea, ja foi tentada no passado (estou falando do Taylorismo e da administracao cientifica) com resultados, no minimo, questionaveis. Se voce quiser ter uma ideia da essencia do que era o Taylorismo, assista Tempos Modernos, de Charles Chaplin, que ate hoje ainda e um filmao. A administracao cientifica era fundamentada em: Planejamento, preparacao dos trabalhadores, controle e execucao (nao parece familiar? Olha o CMMI velho de guerra ai).A preparacao dos trabalhadores pressupoe o estudo dos tempos e movimentos, que visa a isencao de movimentos inuteis (movimento inutil e o seguinte: Se no meio do trabalho voce interrompe suas atividades para cocar o nariz, isso e movimento inutil, a empresa esta perdendo dinheiro e voce esta sendo improdutivo). Isso para mim e CMMI niveis 4 e 5 (gerenciado quantitativamente e otimizado). Acontece que esse modelo de administracao ja foi estudado, criticado, melhorado e depois surgiram novas correntes que tambem foram estudadas, criticadas e melhoradas. Estamos falando de 1903 ate 2007, tem muito chao ai. E uma das coisas obvias que se pode concluir do trabalho de Taylor, e que ele peca por ignorar as varias variaveis humanas em um processo produtivo. Nem o melhor pianista do mundo e capaz de tocar duas vezes exatamente da mesma forma uma peca musical, imagina querer que isso se aplique a uma empresa de servicos de grande porte. O erro dessa visao mecanicista e a banalizacao da complexidade de um ambiente de producao: E querer que as pessoas se comportem como maquinas. Alias, depois de ver a Ferrari do Felipe Massa quebrar no GP da Australia, eu comeco a me questionar se ate para as melhores maquinas a gente pode querer esse tipo de homogeneidade, previsibilidade e consistencia.Entao se voce achou ridiculo o chapeu de pirata e os post-its na janela, eu aposto que voce sequer levou em consideracao que os desenvolvedores, DBAs, analistas e todos daquela equipe sao seres humanos e estavam lidando com um prazo impossivel, um escopo impossivel, com varios fatores para contribuir com o stress e a falta de produtividade, e que coisas como essas ajudam pelo menos um pouco o bom humor e o espirito de companheirismo na equipe. E isso para mim vale mais do que processo, documento ou carimbo. Se voce nao levou esse fator em conta antes de fazer um julgamento desse caso, cuidado! Talvez voce esteja julgando e concluindo coisas importantes sem a devida visao sistemica de todos os fatores envolvidos. E olha que eu nem mencionei a cervejinha liberada toda sexta depois do almoco que eles tinham por la.Ja vi projeto sem documentacao dar certo. Ja vi projeto sem testes, sem escopo, sem muita
coisa dar certo, contra todas as apostas (inclusive a minha). Obviamente nao foram todos. Mas nunca, nunca mesmo, vi projeto com equipe desqualificada, com gerentes que tratam funcionarios como maquinas, com burocracia em demasia dar certo, seja la que modelo de processos fosse utilizado.Eu perguntei o que esperar do CMMI, agora vou falar a minha opiniao: A unica certeza que voce tem quanto ao CMMI e que ele vai aumentar seus custos. O resto sao apostas que voce faz que podem ou nao dar certo, dependendo de um numero enorme de variaveis. Dai voce tem que se perguntar: Qual meu modelo de negocio? Que tipo de clientes estou querendo? Sera que eles vao me preferir, mesmo com custos superiores, ou sera que eles vao contratar o Ze da esquina e seus tres filhos porque eles fazem por 1/3 do preco? (Depois vou dar um puxao de orelha nos clientes tambem, aguenta ai) Eu, alias, deixei de usar a oficina autorizada para fazer revisao do meu carro no Seu Valdir, um mecanico na esquina da rua de casa. Isso porque o Valdir - que me conhece pelo meu primeiro nome - me liga para falar que descobriu que nao precisa trocar a repimboca da parafuseta e me explica detalhadamente o motivo, enquanto eu que nao entendo lhufas do que ele esta dizendo, fico feliz em ver a dedicacao dele em me manter informado e resolver o meu problema da melhor forma possivel, enquanto que na autorizada eu tenho que falar com o Call Center que vai estar encaminhando minha duvida para o tecnico responsavel que vai estar solucionando o problema em questao e que vai estar me retornando em no maximo 24 horas. Nem!Cuidado ao correlacionar CMMI com aumento nas vendas, a menos que voce esteja atuando em licitacoes onde isso realmente seja um requisito essencial.Agora que eu ja joguei muita pedra falando daquilo que eu nao acredito, quero falar do que acredito, assim voce que esta lendo pode jogar pedra em mim tambem:- Eu acredito em processos sim, mas naqueles que sao automatizados. As maquinas que cuidem deles. - Acredito em usar Frameworks que possibilitem voce programar metade, 1/3, 1/10 do que programaria normalmente, tirando a repeticao mecanica e deixando a mente humana para cuidar daquilo que realmente so ela sabe fazer. - Acredito em ferramentas de build e deployment automatico (veja MSBuild, NAnt, CruiseControl.Net). -Acredito em geradores de codigo (veja CodeSmith, MyGeneration, IronSpeed e outros) para reduzir o trabalho bracal.- Acredito em testes automatizados, unit (veja Visual Studio Team System e NUnit), load testing (veja o Visual Studio Team System e o ANTS Load), testes de seguranca (veja o watchfire appScan), ferramentas de validacao do codigo (de novo o Visual Studio), testes de web services (veja Parasoft), etc.- Acredito em ferramentas de profiling (veja o red-gate ANTS Profiler, onde voce pode ver quantas vezes cada metodo do seu codigo executou e quanto tempo levou) para detectar e melhorar os problemas de performance.- Acredito na evolucao das linguagens de desenvolvimento para que suportem contratos (veja o spec# da Microsoft) que aumentam a
robustez do codigo.- Acredito em fazer intervencoes em servidor de producao apenas por meio de scripts (VBS ou de preferencia Powershell, veja um exemplo de como usar o Powershell para deployment) ou pacotes automatizados (veja WIX), assim voce consegue replicar as mesmas alteracoes em qualquer servidor depois, em segundos. Para que roteiro de instalacao se seu roteiro e legivel pela propria maquina?- Acredito em processo de desenvolvimento com zero artefatos nao codigo, por meio de ferramentas graficas/codigo, como WF, SDM, DSL e DTS/SSIS, entre outros.-Acredito que se voce sabe que tal funcao nao pode levar mais de 10 segundos para executar, que tais sistemas precisam estar funcionando sempre, que tal regra de negocio nao pode ser violada, melhor mesmo e escrever unit tests e outros scripts que automatizem os testes, assim voce pode repeti-los sempre que mudar algo e garantir que as coisas estao mesmo funcionando como especificado. Isso vale mais que documentos de mil linhas que nos dois sabemos que ninguem vai ter paciencia de ler detalhadamente.Isso tudo e processo sim, mas automatizado, onde voce aperta um botao e as coisas acontecem. Mas ainda falando do que eu acredito: Eu acredito demais naquele sujeito que, quando seu servidor capota e seu sistema para de funcionar, ele chega, olha, e sem documentacao nenhuma nem processo nenhum, examina tudo como um bom e velho medico de familia e resolve o problema. Isso porque ele e bom no que faz.E enquanto tiver gente que ache que com bons processos conseguira manter o custo da equipe baixo, precisando de pessoas apenas para tarefas repetitivas, sem muita qualificacao, conseguindo maior competitividade no mercado (olha a administracao cientifica e o estudo de tempos e movimentos de novo... Sera que estamos passando pela revolucao industrial da informatica e estamos condenados a cometer os mesmos erros que foram cometidos la? Sera que a sequencia de acontecimentos repetira mais um ciclo, do homem-maquina ao crash economico de 29?), eu so consigo ver empresas crescendo gracas as pessoas, seja la qual for o custo delas. Voce deve economizar com tudo, menos com o ingrediente essencial do seu sucesso. Esse voce tem que tratar bem, mimar mesmo, porque ele e sua vitrine. Ele e que vai arrancar elogios do seu cliente, vai encanta-los, vai salvar sua pele mil vezes e vai fazer seus clientes e funcionarios sumirem tao facilmente se voce manda-lo embora para cortar custos. Nao por ma fe, mas e porque no fundo, no fundo, seus clientes nao estao nem ai para a sua marca, sua empresa ou mesmo voce, o que eles gostam mesmo e de serem bem atendidos.E quanto a voce, senhor cliente (falei que ia puxar a orelha), enquanto voce insistir em contratar sempre aquele que faz o preco mais baixo, mesmo quando esse preco e obviamente irracional, nao reclame que seu ambiente de TI seja um desastre. Se alguem tentasse me vender uma BMW 0 km por R$ 600,00 eu nao compraria, porque obviamente tem algum trambique ai. Entao por que voce insiste em ser o pato ao contratar sistemas dessa forma? Deixe de ser bobo!
Peca detalhes, investigue, interrogue se for preciso! E principalmente: Questione sobre a qualificacao da equipe que vai desenvolver seu sistema.Voce ja foi atendido por alguma empresa com ISO 9000? E sera que todas as vezes que voce foi atendido por uma empresa com essa certificacao, o atendimento foi bom? Pois eu ja fui atendido pessimamente por empresas com essa certificacao, sabe por que? Pessoas.Lembre-se das pessoas, coloque um papel na parede da sua sala, se for preciso, e escreva: Prometo que sempre vou me lembrar das pessoas.E agora, sendo justo: Nao vejo problema nenhum, nem no CMMI nem em nenhuma outra abordagem parecida, contanto que se tenha em mente tudo que mencionei acima. Alias, o CMMI pressupoe People with skills, training and motivation (mas nao fala como diabos voce vai conseguir manter as pessoas motivadas com essa montanha interminavel de regras, ai os gerentes comecam com os premios financeiros, igualzinho a turma do Taylor defendia. Depois veio o Abraham Maslow que mostrou que motivacao e muito mais complicada que isso). Isso, alias, faz o maior sentido, ja que o CMMI te diz o que voce tem que ter, mas nao como conseguir, entao novamente a essencia do sucesso do CMMI nao esta baseada no processo, e sim as pessoas. Entao qualquer bom resultado obtido com o CMMI nao pode ser creditado a processos exclusivamente. E ai vem o grande erro dos fanaticos por CMMI, porque geralmente eles se esquecem desse detalhe. Ao ler sobre o CMMI nivel 1, encontrei um trecho interessante: Success in these organizations depends on the competence and heroics of the people in the organization and not on the use of proven processes. Agora me diga: Tem como uma empresa de servicos obter sucesso que nao seja por causa de pessoas competentes?E se esse texto longo foi dificil de ler ate o final, imagina entao aqueles seus documentos de especificacao de casos de testes, diagramas de fluxo, requisitos funcionais, nao funcionais, visao escopo, memoria de reuniao, planilha de horas... que nem sao tao divertidos? Tenha do.
Quando eu achava que mais nada no mundo me surpreenderia, eu comeco a reparar em atitudes (ridiculas) das pessoas que querem ser, acontecer e aparecer mas, nem mesmo sabem quem sao.- Quem e voce?- Sou filha da presidente da republica, pode me dar licenca?- Sinto muito, preciso anotar aqui a sua identificacao. Ja sei quem e sua mae, mas quem e voce?- Meu pai e o mais famoso cirurgiao plastico do Pais, agora, deixe-me passar.- Mais uma vez, sinto muito, mas preciso saber quem e voce, e nao quem e seu pai.- Nao vai me deixar entrar? Meu primo e um advogado muito conceituado, vou processar voces!- A senhora pode evitar tudo isso e me dizer apenas quem e.- Vai querer briga entao? Vou chamar meu irmao, ele e delegado!- Sinto muito, sem saber quem e a senhora, sua entrada sera impossivel em nosso estabelecimento...E a pessoa sai inconformada.- Mas como isso e possivel? Conheco pessoas poderosas, influentes... Qual e?--> Ninguem nunca pensou que ao inves de conhecer pessoas poderosas, o poderoso poderia ser voce? Ao inves de precisar chamar o filho do amigo do vizinho para te ajudar com um "probleminha" voce poderia ser o filho do amigo do vizinho?Qual a vantagem de ter pessoas conhecidas, amigos fodas, se voce no final nao e nada?Hoje, ao inves de procurar contatos por ai, amizades interessadas, as pessoas deviam pensar em ser alguem.E voce, quem e? Dia 10 de Setembro rolou em Sao Jose do Rio Pardo um campeonato (muito legal, diga-se de passagem) de MMA...La fui eu, mais um grupo de amigos, assistir ao campeonato...Assistimos as vitorias, as derrotas, os gritos da torcida contra os caras que ficavam na nossa frente pra filmar o evento, contra o juiz, a mesa de pontos e tudo o mais que parece comum, nestes tipos de campeonato...Apos o evento, fomos a um churrasco e la ficamos conversando sobre o campeonato e sobre as tecnicas e tal, ate que eu ouco um "tive um choque de cultura muito grande hoje... estou repensando os nossos treinamentos..."Epaaaaaa...Perai....Rolou um campeonato, que tem regras...Regras que, na minha opiniao, "desfavorecem" a arte que eu faco...Mas, de uma certa maneira, "desfavorecem" tambem algumas outras artes...E um misto de regras; por isso MMA (Artes Marciais Mistas).Mas quem foi que disse que eu faco artes marciais pra participar de campeonatos?Campeonatos limitam muito a gente... Por exemplo: eu nao posso chutar a garganta do cara, enfiar o dedo no olho dele, segurar a cabeca dele e dar com ela no chao (e eu treino pra isso)! No campeonato voce usa uma luva pra socar e dai, eu fico completamente impedida de segurar seu braco, torcer seu pulso e arrancar seu ombro...Nada disso faz com que a arte marcial que eu pratico seja menos eficiente...Ela so nao vai ajudar tanto em exibicoes de MMA...O cara que faz jiu-jitsu nao tem kimono para pegar e fazer alguns estrangulamentos;o cara que faz capoeira nao pode usar o "voo do morcego" (acho que e este o nome da tecnica);o cara que chuta nao pode "pedalar" caso o oponente o leve
ao chao...o cara que da cotoveladas, nao pode acertar a nuca do outro...e por ai vai...Nao e choque cultural nenhum... E um choque de realidade...Eu nao treino para campeonatos, eu treino para ser eficiente se algum dia eu precisar...A arte que eu faco, nao e voltada para campeonatos, e voltada para ser FATAL...No meio de uma briga, de uma situacao de risco, se eu precisar me defender o meliante que me atacar nao vai dizer "ei... nao vale colocar o dedo no meu olho, chutar minhas genitalias e amassar meu nariz"...Esta e a minha realidade!