sábado, 29 de março de 2008

Auto-analise dos Nossos Projetos

Oi pessoal,



Recebi esta figura do Victor Hugo Germano (http://malditacomedia.blogspot.com).

Esta imagem serve para uma auto-analise dos nossos projetos.


Abraços,

Abu


segunda-feira, 24 de março de 2008

Incremental e Iterativo

Oi pessoal,


Vamos falar hoje de desenvolvimento Incremental e Iterativo. Vamos iniciar olhando a foto de baixo, onde podemos observar graficamente a diferença entre as duas técnicas.



Quando eu era mais novo e possuía uma empresa de desenvolvimento de software, eu costumava ir ate o cliente, fazer o levantamento de requisitos, o entendimento de cada requisito, prototipação das telas, rascunho do banco de dados, etc etc etc. Minhas atividades tinha o objetivo de sair com todas as informações necessárias para a construção do sistema inteiro (quando ele era pequeno) ou de alguns módulos (quando o sistema tinha um porte maior).
Mas este trabalho tinha o foco de garantir que a minha entrega não teria retrabalho, isto é, após eu entregar o sistema o cliente estaria satisfeito e eu receberia a minha recompensa ($$$).
O problema desta técnica é que ela exigia do cliente uma visão muito assertiva do que ele realmente desejava, mas nem sempre o cliente tinha total informação e visão do que ele desejava de sistema.
O cliente passava a ter uma noção do que ele realmente queria quando estava utilizando o software e desta maneira ele passava a gerar solicitações de mudança.
O sistema nem tinha nascido direito e já estava com solicitações de modificação, e vinha a minha pergunta, onde eu errei na analise ou o cliente não sabe o que deseja.
Este modelo de desenvolvimento de software é o que se chama de “Incremental”.
Já no desenho de baixo é mostrada a pintura de forma “Iterativa”, onde as definições dos requisitos são realizadas junto com o desenvolvimento do software. Nesta técnica não quer dizer que nos não sabemos do que se trata o sistema e passamos a descobrir no decorrer do desenvolvimento. Vocês podem observar que o esboço da pintura já existia, isto é, “ESCOPO INICIAL”.
Mas os detalhes de cada item do sistema são definidos conforme o sistema vai sendo desenvolvido, isto é, a pintura tem que ter olhos e dois olhos, porem a cor de cada olho e os seus detalhes serão definidos no decorrer do desenvolvimento.
A pintura tem que ter boca, mas se ela vai sorrir ou vai ficar seria, é uma opção definida no decorrer da execução da pintura. Desta maneira podemos ate mesmo tentar qual fica melhor, sorrindo ou serio.
A diferença entre as duas técnicas esta no fato do cliente saber tudo o que ele deseja com o mínimo dos detalhes desde o inicio do projeto (Incremental) ou ir colocando os detalhes na execução do projeto (Iterativo).
Ambas as técnicas podem levar ao resultado final, sim, podem, porem devemos lembrar que os requisitos (Itens de Backlog) sempre mudam, a questão é como vamos trabalhar com esta mudança. Na técnica Iterativa nos conseguimos absolver as mudanças com um impacto menor, pois esta técnica já é feita para se trabalhar com as mudanças.

Um abraço a todos e boa semana.


Obs.: Eu não lembro de onde tirei esta foto, desculpe.

Abu

domingo, 23 de março de 2008

Qual é a diferença entre Scrum e RUP?

Oi pessoal,

Hoje eu vou publicar uma tradução parcial do post realizado no Blog (Breakfast) sobre Scrum e Rup. O texto original pode ser acessado pelo endereço: http://scrum-breakfast.blogspot.com/2008/02/what-is-difference-between-scrum-and.html

Item - 1
O livro de RUP chega ao capitulo 3 sem sequer mencionar “pessoas”. Em seguida ele passa o resto do livro dizendo aos “trabalhadores” como eles devem executar o seu trabalho de maneira minuciosa. (e sim, mesmo dentro das iterações, existe “waterfall”).


Item - 2
Mas Scrum enfatiza as pessoas e as suas responsabilidades e comprometimento uns aos outros. Ele não nos diz o que devemos fazer, mas garante que se todos jogarem pelas regras, todas as informações estarão disponíveis o mais rapidamente, para que as pessoas possam fazer os seus trabalhos de maneira otimizada.


Item - 3
As pessoas criam um projeto de sucesso, não as metodologias. E um líder de projeto ruim pode prejudicar o projeto mesmo utilizando qualquer tipo de metodologia.


Scrum não é uma bala de prata, mas com certeza ele ajuda na maioria das situações, isto é, projetos.

Eu já trabalhei com as mais diversas metodologias e processos e concordo plenamente com o autor do texto, SÃO AS PESSOAS QUE POSSIBILITAM A ENTREGA OU NÃO DE UM PROJETO.

Mas não adianta colocar pessoas boas para trabalhar com uma metodologia que não pode ser aplicada na integra. Eu mesmo participei de alguns grandes projetos que foram um fiasco, utilizando uma variação do RUP. Neste projeto não era permitido utilizar as boas praticas do RUP, pois a variação criada pela empresa não ficou boa.

Como eu sei que não ficou boa, simples, após três projetos fracassados com profissionais comprometidos e capacitados fica fácil identificar que o problema não são as pessoas.

O líder do projeto, também chamado de gerente, líder técnico, coordenador, analista sênior, ou qualquer outro nome, tem que ter o bom censo de verificar que as técnicas utilizadas não estão trazendo resultados e tomar uma decisão para que o projeto não seja fracassado.

RUP funciona? Se bem aplicado sim, eu já trabalhei em bons projetos que utilizaram RUP e entregamos o produto. O que eu tenho observado é que existem pessoas que não conhecem RUP na integra e desta maneira prejudicam a reputação desta metodologia.

Eu utilizaria RUP em outros projetos? A resposta é não, depois que passei a entender e trabalhar com Scrum eu não aplicaria o RUP em outros projetos, pois o Scrum permite resultados rápidos no desenvolvimento de software.

Mas volto a lembrar, não estamos falando de BALA DE PRATA.

Abraços a todos,


Abu

quinta-feira, 20 de março de 2008

Você sabe o que é Scrum?

Oi pessoal,


Segue copia do artigo publicado no site da Knowtec (http://www.knowtec.com/index.php?m=ver&id_item=18)


Abraços,


Abu


-------------------------------------------------------------

Postado por: Nelson Abu

* Escrito em parceria com Marcelo dos Santos

Você sabe o que é Scrum?

Scrum é um processo de gerenciamento de projetos ágeis, adaptado para a área de desenvolvimento de software, pelo especialista Ken Schwaber. Ken define Scrum, em um de seus livros, como: “um processo Ágil ou ainda um framework para gerenciamento de projetos Ágeis. É um processo de gerência de projetos, certamente não é uma metodologia, pois isto seria pesado demais” .

A primeira experiência com o Scrum ocorreu em uma fábrica de automóveis, onde se constatou que a utilização de equipes pequenas e multidisciplinares produzia melhores resultados. Em analogia a essas equipes, associou-se a formação do Scrum a de um jogo de Rugby. A partir de 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo em desenvolvimento de software em todo o mundo.



*Formação de Scrum em jogo de Rugby

Martin Fowler, um dos maiores estudiosos em desenvolvimento de software, comenta em seu artigo A Nova Metodologia que: “Nos últimos anos, vem crescendo rapidamente o interesse em metodologias ágeis (ou "leves"). Também caracterizadas como um antídoto contra a burocracia ou uma licença para "hackear". Estas metodologias despertaram os interesses em toda a extensão da indústria do software”.

Dentre as técnicas de utilização do Scrum, há a entrega de produtos em períodos de tempo pré-estabelecidos, nunca inferiores a uma semana ou superiores a trinta dias.

Para estimular o contato entre empresa e cliente, os projetos são interrompidos em períodos regulares de tempo. A essas ações dá-se o nome de Sprint. Ao término de cada Sprint, o cliente recebe um conjunto de funcionalidades desenvolvidas e prontas para serem utilizadas. A melhor maneira de comprovar se o software atende às necessidades é fazer com que o cliente o utilize, apontando as qualidades e o que falta ser aperfeiçoado.

Importante destacar que a participação ativa do cliente no processo de desenvolvimento de software faz com que sejam atribuídas a ele algumas responsabilidades como definição das funcionalidades do produto, decisão quanto às datas de lançamento de conteúdo e ajuste de funcionalidades.

Portanto, diante dos inúmeros desafios que o mercado em Tecnologia da Informação nos oferece, a Knowtec não vê seu cliente como mero comprador de software, mas como um parceiro na pesquisa e no desenvolvimento do produto. E o Scrum é apenas um dos meios para alcançar esse objetivo.

Saiba mais:
-Schwaber, K. and Beedle, M., Agile Software Development with Scrum, NJ, Prentice-Hall, 2002.
-Desenvolvimento Ágil utilizando SCRUM, FAQ realizado por Ken Schwaber, 2006.

domingo, 16 de março de 2008

Palestra de Scrum no BARDDAL

Oi pessoal,


Segue em anexo mais um conjunto de fotos de workshop sobre Scrum. Desta vez foi na Faculdade Barddal, numa sexta feira a noite muito bonita.
Como as fotos mostram tivemos sala cheia, com vários alunos da instituição, de outras faculdades e de empresas da grande Florianópolis.
A infra-estrutura oferecida pela faculdade estava impecável, bem como as professores da instituição que participaram do evento.
Agradeço principalmente ao Professor Fábio Favarim e a Professora Dra. Mirela Sechi Moretti Annoni Notare, que viabilizaram tudo que foi necessário.


Abraço a todos,

Abu






quarta-feira, 12 de março de 2008

Evento em Londres

Oi pessoal,


Segue um link de um evento em Londres. Como o pessoal:


M. Fowler
Refactoring, Analysis Patterns

Erich Gamma
GoF Design Patterns Author

Kent Beck
First software patterns, XP, xUnit

Rod Johnson
Spring Creator

Randy Shoup
eBay Architect

Neal Gafter
Java Language Architect, Generics

Kevlin Henney
Pattern-Oriented Software Architecture

Linda Rising
Patterns Almanac, Patterns Handbook

Gregor Hohpe
Author, Enterprise Integration Patterns


Como o meu amigo Victor (http://malditacomedia.blogspot.com/) fala: CCCCCRRRREEEDDDDOOOO

O LINK é: http://jaoo.dk/london-2008/conference/

Obs.: lembrando que em breve as apresentações estarão disponíveis no www.infoq.com


Amplexos,


Abu

segunda-feira, 10 de março de 2008

Dibert e Agile



Bom dia pessoal,


Adorei esta imagem do Dibert, ela representa muito bem a visão dos “leigos” com relação ao mundo Ágil.
Uma vez eu estava numa roda de bate papo, cervejinha, etc. com colegas de trabalho e como era inevitável iniciamos uma conversa sobre desenvolvimento de software.
Depois de muito bate papo ficou evidente que os colegas estavam com visões pré-definidas, que já tinham recebidos de outros colegas de trabalho. Eles infelizmente levaram a informação como verdadeira e o pior de tudo, ficavam repetindo a informação para outros colegas de trabalho.

Ágil não tem nada a ver com nada de documentação, nada de planejamento e programação desde a primeira palavra do cliente que pode ser interpretada como um “requisito”.

Para quem realmente já leu alguma coisa sobre Scrum pode observar que existe um planejamento e acompanhamento do projeto muito bom, onde é analisado a quantidade de requisitos a serem desenvolvidos (Itens de Backlog), estimados, priorizados, divididos em Sprint´s, criados gráficos de visibilidade do Produto Backlog, acompanhamento diário da execução do Sprint, reuniões de entrega do serviço ao cliente ao termino de cada Sprint (Sprint Review), reunião de melhoria do processo (Sprint Retrospective) , e muito mais.

E quanto a documentação?

Esta é a melhor parte, deve ser criados documentos de agreguem valor ao software, nada de documentos desnecessários, que são criados apenas para cumprimento de tabela.
Se Use Case é importante para o seu negocio, agrega valor, então utilize. Mas será que não existe uma maneira melhor de fazer?
Criar UML de todo o sistema é importante para o seu negocio? Não vai deixar a manutenção muito cara? O Cliente esta exigindo? Não existe uma maneira melhor de fazer?
Devemos lembrar sempre, que a documentação tem que agregar valor ao produto e principalmente, ela deve ser facilmente mantida.
Existem documentações de apoio a construção do sistema e documentações de apoio a manutenção do sistema, este item também deve ser avaliado.

Espero que tenham gostado, neste post não vou entrar no mérito de como fazer uma boa documentação, fica para os próximos,


Abraços,


Abu

quinta-feira, 6 de março de 2008

Palestra de Scrum no BARDDAL

Oi pessoal,

Segue a publicidade da minha próxima palestra de Scrum

Link original: http://www.barddal.br/faculdades/site/index.php?cnt=noticias_detalhe&id=183&pag=1

---- X ----

Scrum: método ágil para Gerenciamento de Projetos


05/03/2008 - Palestra sobre Scrum no dia 14 de março

Scrum é um método ágil para Gerenciamento de Projetos. Dentro do Scrum trabalhamos com a auto-organização da equipe, gráficos de acompanhamento do projeto, priorização das tarefas a serem realizadas, estimativas de esforço e principalmente, com a habilidade da equipe de realizar o projeto.


Mini-Currículo do Palestrante Prof. Nelson Abu Samra Rahal Junior:


Graduado em Processamento de Dados
Pós-graduação em Didática e Metodologia de Ensino
Pós-graduação em Gerência de Projetos para a Área de TI (PMI)
Mestrado em Ciência da Computação
Certificado em Scrum Master
Professor universitário desde 1996
Atuante ativamente na área de desenvolvimento de software no mercado de Florianópolis desde 1998.

quarta-feira, 5 de março de 2008

Reuniões Diárias: Produtivas X Perda de Tempo

Oi pessoal,

Esta rolando esta semana um bate papo nos fóruns internacionais de Scrum sobre as vantagens e desvantagem de uma reunião diária.
Alguns participantes do fórum têm comentado que estas reuniões são uma perda de tempo, não são divertidas, etc etc etc. Também esta sendo comentado que neste período de tempo a equipe poderia estar trabalhando duramente no projeto.
Devemos lembrar que o objetivo da reunião diária é para promover a comunicação entre a equipe e principalmente identificar obstáculos para que o Scrum Máster possa resolver e continuar viabilizando a execução do projeto.
Fazer pessoas se comuniquem é muito difícil e principalmente fazer com que esta comunicação seja produtiva mais ainda. É papel do Scrum Máster, fazer com que estes encontros sejam produtivos, não permitindo que nos encontros diários existam “ruídos” de comunicação.
O próprio Ken publicou esta imagem. Segue um resumo do texto para reflexão.



A reportagem esta falando de um empregado de uma empresa de publicidade que foi encontrado morto em sua cadeira de trabalho. Este empregado de nome “George”, 51 anos teve um ataque cardíaco em quanto trabalhava e seus colegas de trabalho não perceberam que ele estava morto.
Pelo exame realizado em “George”, ele faleceu na segunda-feira, mas ninguém notou ate o sábado de manha, quando um colega de trabalho perguntou porque ele estava trabalhando no fim de semana.
O chefe de “George” comentou que ele era sempre o primeiro a chegar e o ultimo a sair e sempre ficava muito concentrado em seu trabalho.
A moral da historia é que: “Não se deve trabalhar muito duro. Ninguém repara mesmo”.



Eu fecho esta postagem com a minha opinião sobre o caso: “Não é uma reunião de 15 minutos diária que vai fazer o projeto ficar atrasado ou mais atrasado. Mas esta reunião diária se bem realizada pode trazer ganhos significativos ao projeto.”


Abraços a todos,


Abu