Você é desenvolvedor sênior, pleno ou júnior?

Nos últimos tempos tenho ouvido falar muito sobre a categorização dos desenvolvedores ( sênior, junior, pleno….), por isso resolvi postar as minhas duvidas e com base em alguns conceitos que aprendi ao longo do tempo que trabalho desenvolvimento de sistemas quero tentar questionar essa categorização imposta pelo mercado, mas uma coisa quero que fique claro, não tenho a intenção de mudar o mundo apenas questiona-lo(risos).

Entendo muito bem porque foi criado essa categorização para desenvolvedores, é para valorizar quem tem uma maior experiência e teoricamente um maior conhecimento, porem  acredito que esse suposto “maior conhecimento” é questionável uma vez que tenho visto que ele é muito baseado em o quanto o desenvolvedor conhece a linguagem, e não estou eu aqui a dizer que o conhecimento da linguagem não é importante, ela é muito importante mas não é a única variável, existem outras que devem ser medidas e dependendo da empresa e da maneira de trabalho acredito que deveriam ter um peso maior que o próprio conhecimento da linguagem.

Imagine você, uma empresa onde é utilizado métodos agéis no desenvolmento de software e contrata um desenvolvedor que nunca trabalhou assim porem ele tem uma vasta experiência na linguagem que o projeto será desenvolvido, tendo o costume a trabalhar em projetos onde ele é o único da equipe, não precisando assim se comunicar com ninguém, não tendo ninguém para pedir ajuda e sendo acostumado sempre a receber elogios pessoais, será que para trabalhar na empresa em questão ele é sênior?

E quanto aos teste, conheci desenvolvedores com vasto conhecimento na linguagem e que não gostavam nada dos teste unitários (não estou nem falando em TDD) e inevitavelmente ao fim das tarefas tinhamos sempre varios problemas com BUGs, eu participei de uma palestra onde o palestrante fez o seguinte comentario “quem não faz teste automatizados, não desenvolve profissionalmente...”, esse programador que citei anteriormente seguindo esse conceito que apresentei ele pode ser considerado sênior?

Portanto, se pretendemos quantificar a capacidade de um profissional deveriamos identificar quais as reais necessidade da vaga e quais as filosofias de trabalho são seguidas pela empresa e não só definirmos que ele é sênior, pleno, ou junior pelo tempo de trabalho, pois como vimos nem sempre essa variável  é a mais importante. E vocês o que acham?

Implantando métodos ágeis em uma equipe gerenciada pelo BPC - parte 1

Estou dando inicio a uma série de post onde pretendo relatar como foi implantar métodos ágeis em uma equipe que utilizava o BPC na sua essência. Neste primeiro post vou falar de como foi implantar o SCRUM, destacando as dificuldades do processo de transição entre uma metodologia e outra.

A equipe de desenvolvimento era composta por 4 a 5 programadores e um gerente de projetos. O papel de analista era desempenhado pelo gerente e em outras situações pelos próprios programadores. Cada programador era responsável por um projeto, sendo assim, tínhamos sempre em desenvolvimento de 4 a 5 projetos, algumas vezes 1 programador ficava de responsável pelos BUGs, de todas as aplicações do setor de desenvolvimento, formando o cenário antes do SCRUM.

Devido a diversas questões de mercado, a empresa em questão unificou-se a outras grandes empresas formando uma grande rede nacional, e com isso surgiu a necessidade de um sistema que seria utilizado por toda a rede recém formada. Por causa da experiência da equipe de desenvolvimento no sistema que era necessário, a equipe foi designada a desenvolver o projeto em conjunto com a infra da sede, o nosso cliente também estava na unidade sede. Foi ai que começou os nossos problemas.

• Primeiro, o usuário possuía um sistema que cobria todas as suas necessidades e não desejava a troca do mesmo, a troca de sistema estava sendo feita para reduzir custo pois os sistema terceiro tinha um custo altíssimo para a rede, sendo assim desde as primeiras reuniões ele tentava complicar ao máximo o desenvolvimento do novo sistema.
• Segundo, as equipes da unidade sede trabalhavam utilizando metodologias tradicionais de desenvolvimento, e nós a BPC, em outras palavras, incompatibilidade total de trabalho.
• Terceiro, o projeto era muito grande e devido as possibilidades que tínhamos de gerenciar o projeto (tradicionais ou BPC), era inviável desenvolver, pois se utilizássemos a tradicional não conseguiríamos entregar no prazo e se utilizássemos a BPC provavelmente entregaríamos no prazo porém não garantiríamos a qualidade.

Com o cenário descrito acima foi que surgiu a idéia de utilizar as metodologias ágeis, pois ao analisar o projeto identificamos que devido ao tamanho do projeto era praticamente impossível identificar todos os requisitos no inicio para fecharmos o escopo, e também verificamos que os requisitos poderiam ser entregues de acordo com a necessidade do cliente. Inicialmente a gerência relutou em aceitar o uso do Scrum, pois tanto a BPC quanto as Tradicionais fecham o escopo no inicio do projeto e como iríamos trabalhar com escopo flexível isso gerou uma grande desconfiança, se conseguiríamos entregar o projeto, mas por falta de opção eles tiveram que aceitar, uma vez que não conseguiriam entregar o projeto utilizando nenhuma das metodologias já utilizadas.

Após o convencimento dos gerentes veio a montagem e o treinamento do time. Esse momento foi bastante complexo, pois como foi citado anteriormente todos eram acostumados a trabalhar sozinhos em seus projetos, e a partir daquele momento deveríamos trabalhar em equipe como um time e não mais individualmente. Com isso, surgiram dificuldades como:

• Trabalho em equipe. Este foi o maior problema por causa da vaidade de cada um. Não tínhamos a ideia de time, onde o pensamento de um complementa o do outro, no inicio o que imperava era o individualismo e cada um queria impor a sua ideia, isso gerava muito conflito entre os membros da equipe, ao longo do tempo foi passado ao time que ninguém era melhor ou pior, e que juntos o nosso conhecimento seria muito maior.
• Velocidade x Qualidade. Quando terminávamos a reunião de planejamento, cada um pegava uma estória e fazíamos o mais rápido possível aquele requisito. Nos primeiros sprints, tivemos diversos problemas, pois nenhum requisito foi entregue 100%, sempre presamos a entrega e até aquele momento não nos preocupávamos muito com a qualidade e isso foi sentido fortemente na primeira entrega pois poucos requisitos foram entregues. Devido a essa primeira experiência começamos a garantir nossas entregas, era melhor entregar uma estória 100% do que 5 pela metade.
• Porco e Galinha. Na histórinha conhecida do “Porco e da Galinha” quem se comprometi é sempre o “porco”, só que no inicio as “galinhas”(gerência) insistiam em se comprometer com o cliente com as entregas dos requisitos, e isso gerava um grande desconforto entre o time e a gerência, pois eles estavam traçando cronogramas sem consultar os “porcos”, com o tempo a confiança da gerência na equipe foi aumentado e esse problema foi resolvido, pois eles começaram a enxergar o comprometimento do time para com o projeto.
• Cliente. O nosso cliente estava acostumado a trabalhar com escopo fechado, onde ele definia todas as funcionalidades do sistema no inicio e após uma serie de documentos assinados não se mexia mais no escopo do projeto. Sendo assim sempre que queria fazer uma solicitação ele enviava email para toda a gerência fazendo o maior “barulho”, pois ele achava que nós não faríamos o que ele estava solicitando. Aos poucos fomos explicando para ele a nossa maneira de trabalhar, pois ele também fazia parte do time e sem ele o projeto seria inviável. Quando entendeu que nós não éramos inimigos dele e sim parceiros nessa nova empreitada, o projeto fluiu naturalmente.

Depois de aproximadamente 2 meses do inicio do projeto a maioria das dificuldades acima já estavam controladas e sendo bem administradas, porém até hoje algumas vezes elas teimam em voltar, mas hoje administramos muito bem todas elas.

Abaixo vou listar as principais vantagens que tivemos com o uso do Scrum na gerência dos nossos projetos.

• Comprometimento. O nosso time hoje é muito mais comprometido com o trabalho do que antes, pois hoje somos ouvidos nas decisões referentes aos cronogramas do projeto.
• Qualidade. a quantidade de problemas que temos hoje em nossas entregas é muito pequena, uma vez que presamos muito a qualidade da entrega e não a quantidade.
• Conhecimento. o conhecimento dos membros do time aumentou exponencialmente, pois ao dividirmos nossas experiências e conhecimento nivelamos por cima a equipe.
• Respeito. as ideias e opiniões de todos são respeitadas hoje, pois sabemos que dentro do time nós nos completamos.

Tentei passar neste post um pouco da minha experiência na implantação das metodologias ágeis no desenvolvimento de softwares, o Scrum foi utilizado na gerência dos projetos com o auxilio do Extreming Programming (XP), a união dessas duas metodologias foi importantíssimo para o sucesso do projeto, pois o Scrum atacou a Gerência do Projeto e o XP a engenharia do sistema. Sobre o XP, falarei no próximo post.

Princípios Básicos da Metodologia Bamu Pitissu Cabortero

A metodologia Bamu Pitissu Cabortero(BPC) é baseaso em 13 principios, no qual todos os seguidores dessa metodologia tem que seguir, abaixo eles estão listados:

1. Rapidez, esse é o principio básico da BPC, não precisamos de 3 ambientes, alteramos direto em produção.
2. Comprometimento é medido em horas extras, quanto mais horas você trabalhou a mais que teu horario de serviço mais comprometido o colaborador é.
3. Todo o requisito é uma barbada, não existe requisito difícil e sim programador com má vontade de trabalhar.
4. Todo o requisito já foi implementado pelo menos uma vez, é só copiar e colar e talvez fazer alguns ajustes(Reutilização do Código).
5. Na BPC existe duas funções, o Pavão(analista de requisitos,analista de sistemas, analista de negócios, arquiteto de software e gerente do projeto), e a peonada que é composta pelo que sobrou (programador, web designer, dba …).
6. O Pavão manda e o resto obedece(não se pode questionar, porque o Pavão muitas vezes não sabe responder, por isso ele não deixa abertura a questionamentos).
7. O Cliente deve ser um refém da equipe de desenvolvimento, pois assim o time terá emprego por um longo prazo.
8. Cada programador é o dono do código, sendo assim a “merda que ele fez, ele que resolva”.
9. Se for mexer em um arquivo compartilhado, altere logo e comite de uma vez, pois se der “merda” em outro lugar quem mexer depois que se vire.
10. Todo o colaborador que trabalha com essa metodologia quando é questionado por qualquer coisa referente ao seu trabalho responde imediatamente com um "balanço de ombro" dizendo a celebre frase "Não é problema meu.".
11. A prioridade dos requisitos dessa metodologia é ditado pelo posto de quem solicitou, quanto mais alto o posto maior a prioridade do requisito.
12. Todo o requisito é feito no mínimo duas vezes, pois quem implementa o BPC tem que ser malandro, como todo malandro a primeira vez ele sempre vai procurar o caminho mais fácil, e como não vai dar certo ele vai implementar a segunda vez indo pelo caminho correto porem não tão fácil.
13. Após a entrega do sistema, ele jamais apresentará um problema, por isso sempre devemos achar alguém ou algo para colocar a culpa (Servidores, Usuários, etc... ), frase clássica "O problema é deles...".
14. E por ultimo mas não menos importante, se o sistema estiver funcionando na minha maquina, o problema não é meu

Ordenando Um Array de Objetos

Bom Dia a todos,

Nesse primeiro post vou escrever sobre um problema que tivemos logo que começamos a programar orientado a objetos na empresa na qual trabalho, que foi ordenar uma array de obejtos, pois antes nós realizávamos essa ordenação direto na base de dados dando apenas um order by.

Problema: Possuo um array de objetos Eventos no qual é composto por um Objeto Local que esta agregado ao um Objeto Período, eu preciso que seja ordenado o array de Eventos pela data inicial do período, abaixo esta o diagrama de classes.

Solução: A ideia vai ser tentar criar algo que possamos utilizar em todos os problemas parecidos que possam surgir a partir de agora. A solução proposta foi criarmos uma classe OrdenacaoColecao na qual se passássemos o array, ela nos retornaria o array ordenado, só que tínhamos um problema, como saberíamos qual atributo testar? Para resolver esse problema criamos uma Interface (IOrdencao) na qual possui o método retonarAtributoComparavel(), e todo o objeto que estivesse dentro do array deveria implementar essa Interface. Abaixo esta o diagrama da solução proposta e a seguir a explicação das classes e dos métodos.

Classe OrdenacaoColecao:

• Atributo:

1. $arrayOrdenavel: onde vamos setar nosso array para ser ordenado;
2. $tipo : armazena o tipo de ordenação se 'DESC' ou 'ASC';
3. $nivelComparacao: para cada atributo é determinado um nível. Exemplo: $titulo é o nivel 1, data inicial é o nível 2 e assim sucessivamente até suprir as necessidades de quem está implementando;

• Métodos:

1. comparar: método no qual o algorítimo de comparação entre os objetos é desenvolvido, passando por parâmetros os dois objetos a serem comparados (o método é privado);
2. usort : método responsável por fazer a ordenação, utilizando uma função nativa do php;

Interface IOrdencao

• Método:

1. retonarAtributoComparavel: retorna o atributo da classe na qual desejamos realizar ordenamento, ele deve ser tradado antes do envio, o método possui um parâmetro $nivel no qual poderemos criar vários níveis de ordenação.

ClasseConcretas: são as classes que irão implementar a nossa interface;

Clique aqui para baixar o exemplo de ordenação

Com o exemplo colocado acima conseguimos ver perfeitamente a implementação da solução proposta para o nosso problema, estou a disposição para tirar qualquer dúvida a respeito da solução proposta.

Se alguém tiver alguma ideia de problema relacionado a orientação a objetos é só enviar que nos próximos posts estarei respondendo.

Até a próxima.