A partir de agora, vocês podem acessar meu novo blog: http://blog.anascimento.net

Abs

Ontem (13/03/09), a Stefanini It Solutions realizou um café da manhã SCRUM e SOA na cidade do Rio de Janeiro.

Estive lá com o Tuca (blog.tucaz.net), e fizemos uma apresentação sobre SCRUM juntamente com o Alexandre Magno.

Alias, finalmente conheci o Alexandre pessoalmente, muito gente boa o cara, mas voltando ao evento…

A idéia foi montar uma mesa de discussão com alguns profissionais de nível técnico e gerencial de nossos clientes no RJ. O evento foi muito bom, com certeza tivemos nosso objetivo alcançado.

O Alexandre iniciou conceituando muito bem o SCRUM e suas diferenças com as chamadas metodologias tradicionais de desenvolvimento. Já nessa apresentação surgiram várias dúvidas e o pessoal participou bastante.

No segundo momento, eu apresentei basicamente quais são os modelos de venda de projetos ágeis e como estamos tratando esse assunto no mercado. Como sempre é nessa parte que a coisa “pega”.

Isso vai ser assunto de um outro post, mas só para resumir: Hoje um dos maiores problemas que temos com metodologia ágil no mercado de TI brasileiro é COMO VENDER!!!

Após algumas boas discussões, acho que alguns clientes aceitaram bem e outros nem tanto. Na minha humilde opinião, acho que vai demorar ainda um pouco mais para que as grandes empresas arrisquem num modelo de contratação de escopo aberto, que é onde conseguimos obter um maior ganho com processos ágeis.

Valeu mesmo pelo evento, estamos começando a ver a coisa andar.

Abraços

Capa MundoNET edição 12

A nova edição da Revista MundoNET apresenta um artigo meu e do meu amigo Tuca falando um pouco sobre Scrum For Team System e alguns pontos interessantes sobre a adoção de processos ágeis.

Procuramos abordar de forma geral como uma ferramenta pode nos auxiliar na hora da implantação de um processo Ágil, sem deixar de lado o ponto mais importante que é a mudança de cultura nos envolvidos.

Particularmente eu gostei do artigo da capa que nos traz algo bem simples e extremamente útil para a maioria dos desenvolvedores.

Ponto positivo também para a arte e diagramação da revista, ficou muito bonita. Quem costuma acompanhar as edições da MundoNET provavelmente notará essa diferença.

Gostei bastante do resultado… dúvidas e comentários sobre o artigo são mais que bem vindos.

Abs

Neste tempo que estive “fora” por aí, foi criado o .NET Architects, grupo voltado para discussão acerca de arquitetura de software na plataforma Microsoft .NET

O grupo já teve três reuniões, dentre as quais eu participei somente da última delas.

Nosso objetivo com esse grupo é reunir interessados em estudar e conversar sobre aspectos avançados - e alguns básicos também – sobre arquitetura de software em .NET.  Temos técnicos, desenvolvedores, arquitetos, gerentes, enfim, um verdadeiro “leque” de pessoas envolvidas na iniciativa.

O grupo é aberto a quem quiser participar e quem quiser saber mais informações é só acessar o site .NET Architects.

Abaixo vocês podem conferir os vídeos do terceiro encontro do grupo.

Primeiro a apresentação sobre DDD do Giovanni.

Depois da apresentação tivemos um debate com todos os presentes por cerca de uma hora. Foi bem interessante, recomendo à todos que dêem uma olhada.

Os vídeos das primeiras reuniões do grupo podem ser conferidos em .NET Architects.

Isso ai galera, abraços.

Depois de um grande sumiço, estou de volta por aqui.
Acho que todos que lêem este blog entendem perfeitamente o que é um final de projeto não é mesmo? eheheheh. Ainda mais quando isso acontece junto com o final de ano.

Neste tempo, pensei bastante no que quero fazer com meu blog e cheguei a algumas conclusões bem interessantes.

Pra resumir, agora com uns “diazinhos” de folga no final de ano vou aproveitar para colocar alguns posts atrasados e a partir do ano que vem prometo que estarei mais por aqui.

Abraços

Como disse para vocês no início, entre começar com agilidade e o primeiro post neste blog passou-se algum tempo… Nesse tempo, passei por algumas experiências interessantes e aos poucos vou compartilhar delas com todos.

Um assunto sobre o qual eu não poderia deixar de falar é este: HUMILDADE e CONFIANÇA quando se trata da adoção de um processo ágil. Parece meio “romântismo” isso, não é? Eu explico porque:

Imagine uma equipe vivendo seu dia-a-dia baseada em processos tradicionais de desenvolvimento de software, onde temos cada um preocupado somente com a “sua parte” no trabalho. É muito fácil imaginar isso, uma vez que este ainda (infelizmente), é o modelo que domina o mercado:

Nesse modelo, consigo identificar por experiência própria que temos dois perfis que tendem a reprovar totalmente um modelo Ágil de desenvolvimento. Alguém tem um palpite?

heim?

Pois é… Gerente de Projeto e Analista de Sistema.

Esses são os perfis que naturalmente possuem maior resistência ao modelo Ágil de desenvolvimento. Sobre o Gerente de Projeto eu não vou nem comentar porque todo mundo já está cansado de saber o porque da resistência: O cara perde o poder de mandar em todo mundo, simples assim.

Agora, eu gostaria de falar sobre o outro perfil: O “analista de sistemas”:

Esse cara - ”O Analista” – está acostumado a ser o responsável funcional por alguma parte do sistema, ou até mesmo todo o sistema. Ele é a pessoa que possui interface direta com o cliente, então só ele pode ter acesso ao cliente. Por isso, ele cria um relacionamento de proximidade com o cliente e naturalmente acaba tratando a equipe de codificação como simples ” braços”, porque toda a inteligência está na sua cabeça e nos seus modelos escritos na ferramenta Case.

Eu costumo chamar esse tipo de profissional de “Analista Moisés” (Perdoem a citação bíblica).

“Para que não conhece a história, Moisés era no antigo testamente um cara que falava com Deus pelo povo. Somente ele podia subir até o topo da montanha e falar com Deus, depois transmitir a mensagem de Deus ao povo.”

Pois é… não há nada de errado com o Moisés lá da bíblia… mas na verdade se olharmos para esse analista, vemos que ele pensa ser um tipo de Moisés. Só ele pode falar com “deus”, ou seja, o cliente… até porque na cabeça dele, desenvolvedor não tem capacidade para tratar de negócios, não é mesmo???

É daí que surge a grande resistência do modelo ágil… TODO o time se torna responsável pelo que antes era de domínio de um perfil apenas. As classes que antes eram pensadas e modeladas na ferramenta case agora são de domínio de todos…

Em um cenário como este é preciso que esse profissional tenha uma boa dose de humildade e confiança em seu próprio trabalho. Não é porque não existe mais a exclusividade no acesso ao cliente ou na modelagem do sistema que o analista ou até mesmo o gerente perderão seus lugares no time…o mais importante é passar a focar as energias em algo que realmente traga valor, ao cliente e a equipe.

Eu não gostaria que você entendesse isso como uma crítica a todos os analistas, até porque qualquer um na equipe pode ser um ponto de resistência ao processo. Mas realmente essa é a experiência que vivi aqui na implantação do Scrum em nosso time e continuo vendo pelo mercado, onde vou falar sobre processos ágeis.

A maior resistência está nestes dois perfis. Isso acaba sendo uma grande armadilha para toda uma equipe Agil, principalmente porque em geral, os gerentes e analistas estão mais próximos ao cliente e se a resistência passar da equipe e chegar no P.O, a chance de tudo ir por água abaixo é muito grande.

Na minha opinião, a agilidade é um processo que naturalmente vai tomar conta de uma grande fatia do mercado de desenvolvimento de software, pense se você está preparado para ela…

No final das contas, a empresa sempre dará crédito ao profissional que joga no time e tem a humildade e confiança para se transformar e melhorar a cada dia.

Abs

Abaixo segue cópia do post colocado no blog do Tucaz (economia de tempo mesmo), sobre nosso mais recente processo de contratação.

Podem mandar e-mail para ele, como está no post ou também para mim: anascimento@stefanini.com.br

Abraços

Segue o trecho:

Mais uma vez estamos contratando. Duas vezes em dois meses… estamos indo bem!

Vamos ao que interessa. Como dito no outro post, continuamos com Scrum e uma equipe enxuta (alguns sairam, pois não se encaixaram e outros entraram) de 12 pessoas distribuidas em três times pequenos e focados. Só que nessa vez não estamos atrás de desenvolvedores (mas se alguém tiver interesse, nunca desprezamos novos bons membros para a equipe), mas sim de um Database Aniquilator, conhecido também como DBA.

A fim de eliminar o desperdício de esforço e melhorar alguns processos descobrimos que alguém especialista em banco de dados, SQL Server principalmente, faz muita falta. No entanto o que precisamos não é alguém que apenas fique conectado como “sa” rodando scripts em produção. Precisamos de alguém que esteja em sintonia com as equipes de desenvolvimento e as apoie o tempo todo em desenvolvimento (dúvidas, organização e tuning), seja responsável pela saúde dos bancos de dados e nos ajude a criar uma política mais eficiente de integração, consistência de dados e deploy.

Somos uma equipe altamente entrosada onde todo mundo joga junto. Nossa equipe não é grande e cresce de maneira organizada e estruturada.

Sendo assim, o perfil de entusiasta é fundamental. Graduação, pós-graduação, mestrado e certificações não é o que estamos buscando. Portanto, não são um diferencial. Fazer apenas sua parte não é o suficiente. Como de costume, é necessário ter interesse em aprender e aplicar novas práticas, interagir com os membros da equipe e aceitar ser desafiado e questionado, pois é isso que faz com que nossa equipe cresca.

Nessa vaga, em especial, além das soft skills os conhecimento técnicos são extremamente importantes. Hoje, nossos bancos de dados são gerenciados por mim e alguns outros membros da equipe. Nós conhecemos alguma coisa de banco de dados, mas nossa especialidade é desenvolvimento, portanto no mínimo o candidato deve conhecer mais banco de dados do que a gente . Especificando um pouco mais precisamos de conhecimentos em: replicação, segurança (roles, rules, etc), organização e distribuição de filegroups, pagefile, etc e SSIS. Experiência em shell, execução de scripts via batch e gerenciamento de instâncias e administração windows server também são necessárias.

Enfim, tudo que um bom projeto de software precisa no que diz respeito a banco de dados.  

Estamos em São Paulo capital, na região de Pinheiros. A Contratação é como PJ e temos alguns benefícios. 

Se você se interessou pela oportunidade email-me azegunis@stefanini.com.br.

Antes de mais nada: É preciso entender quem paga a conta!!! E um dos pilares do SCRUM (por exemplo), não é justamente este? ROI ???
Depois de entendido este “pequeno” ponto, podemos abordar alguns aspectos interessantes em estimativas de projetos Ágeis.

Já que quem paga a conta é o cliente, ele é o cara que deve se sentir seguro em investir seu $$$ em um projeto Ágil. Você pode até não acreditar nisso,  mas acredite… Demonstrar de forma coerente e real que o modelo de venda em um projeto Ágil é superior não é tão difícil, na verdade é mais fácil do que muitos pensam.

O que eu vejo que acaba acontecendo em muitas consultorias e empresas é o “ataque do verme da preguiça”… fácil, quando você olha para o SCRUM na primeira vez é natural achar que se trata de um processo de alocação de mão de obra. Mas, basta estudar um pouco mais para ver alguns benefícios importantes.

Experiência que tenho ao apresentar e oferecer o modelo SCRUM para alguns executivos:

O modelo é adorado por todos, principalmente porque seu foco está na resolução de problemas que todos eles estão cansados de viver. Durante a maioria da apresentação já começam a surgir os questionamentos do tipo: Mas como é vendido este modelo???

Repare que para um executivo, é muito importante saber detalhamente como será o processo de estimativa e venda deste processo. Neste ponto, precisamos aliar o modelo Ágil a outras práticas utilizadas no mercado.

O ponto mais importante nisso tudo é: Quando se fala em consultoria de software, cliente corporativo não comprará a idéia da Agilidade sem ter ao menos uma Ordem de Grandeza de quanto será seu investimento.

Ainda falando em consultorias, temos que fazer estimativas para ganhar propostas ( e a maioria do mercado funciona assim), neste momento não sabemos quase nada do projeto (funcionalidades, ambiente, modelo do cliente, equipe, produtividade, etc), então como estimar? Como dar uma idéia ao cliente?

A resposta é simples: Estimativas são Estimativas, e ponto !!!

Entendido isso fica um pouco mais fácil. Podemos utilizar uma técnica de “sizing” qualquer, APF é uma boa pedida. Essa estimativa pode ser feita com base na técnica APF e na experiência do profissional, bastam algumas conversas com o cliente para conseguir chegar a um nível seguro de assertividade.

Esta estimativa pode ser utilizada para nos dar uma idéia do tamanho do projeto, quantidade de sprints e dimensionamento do time. Pronto!!! Com esses indicadores na mão, temos uma estimativa feita, em tempo de proposta e um contrato no modelo Ágil pode ser feito sob ela.

O mais importante é fazer tudo com a maior transparência possível com o cliente e incentivá-lo a participar deste processo. E, claro: Não cometer os mesmos erros de processos tradicionais que entendem que uma vez contados os Pontos de Função, temos um projeto com o “timer” ligado no forno, só esperando dourar.

E só para quem é contra a utilização de uma técnica de dimensionamento para projetos Ágeis:

“Uma estimativa com desvio de 50%, ainda é melhor do que não fornecer nenhuma idéia ao cliente, desde que fique claro que trata-se de uma estimativa.”

Abraços

Depois de muito enrolar e de usar a famosa “falta de tempo” como desculpa para os amigos, estou finalmente inaugurando meu blog… Eeeeeeeeee

Brincadeiras a parte… o que motivou a criação deste blog foi a vontade de compartilhar minhas experiências, desafios, vitórias e fracassos no mundo do desenvolvimento de software… isso tudo buscando sempre entender o que é de fato desenvolver software com qualidade.

Ultimamente, um dos maiores desafios enfrentados tem sido a adoção de uma Metodologia Ágil de Desenvolvimento, e é sobre este assunto que vou comentar bastante aqui no meu blog.

Neste tempo que passou desde que comecei a estudar e a aplicar Metodologias Ágeis até este primeiro post, pude vivenciar várias situações interessantes… aos poucos vou escrevendo sobre elas.

Um grande motivador para este blog também é meu amigo e companheiro de trabalho Tucaz, que vive me enchendo a paciência todo dia para que eu escreva… (propaganda gratuíta ae Tuca)

Sobre o título do blog… vamos deixar pra lá!!! rs. Eu queria colocar alguma coisa que não fosse tão formal e o que me veio a kbeça foi este mesmo, depois acabei achando bacana e decidi deixar pelo menos por enquanto.

Bom, pra post de inauguração tá legal… espero poder contribuir um pouco com todo mundo que, como eu, tem no desenvolvimento de software uma de suas grandes paixões.

Issae!!! Abraços