Scrum em tempo real

Oi pessoal, este texto não é meu, é uma copia que eu fiz na cara dura do meu amigo Yugo. O Yugo esta trabalhando com esta tecnologia RFID.

Link original: http://yugosfera.wordpress.com/2008/05/02/scrum-em-tempo-real/

Pois é, faz um bom tempo que não publico nada neste Blog.

A razão de estar tão ausente é empolgação na nova empresa que estamos começando, para trabalhar com tecnologias Rfid. Mas esta eu não poderia deixar passar. Trata-se de uma tecnologia que os caras do MIT desenvolveram, integrando Rfid com Post-it. Finalmente alguém pensa em alguma inovação desta idéia, sem seguir a mesma idéia!






De cara lembrei do professor Nelson Abu, e sua metodologia de projetos favorita, o Scrum. (e daquele monte de post-its coloridos que ele tanto gosta)

Diz aí Abu: que tal bolarmos uma solução para operacionalização do Scum utilizando esta solução de post-its com Rfid ealgum software de controle de Musts, Shulds, Coulds e Wants pronto para esta tecnologia? Tenho até um nome: e-Scrum!

Tá certo, eu topo fazermos em Ruby-on-Rails!

Assistam o vídeo e acessem o artigo, do Engadget

Este atigo do Engadget foi indicado pelo meu sócio-amigo Thiago Freitas. Valeu cara!

Abraços a todos e MUITO OBRIGADO YUGO.


Flw

Waterfall

Bom dia pessoal,


São 07:45 da manha, dia bonito mais frio em Floripa.

Eu estava lendo os email dos fórum de desenvolvimento ágil e encontrei este desenho. O tema já velho conhecido nosso, “Watetfall”.

O Frango tem uma duvida e mesmo tendo o colega (o porco) sentado ao seu lado, ele não tira a sua duvida, isto é, se recusa a fazer perguntas ao porco. Na verdade ele ignora totalmente a existência do colega ao lado.

No desenvolvimento “Waterfall” nos temos constantemente este tipo de situação, pois espera que o processo de analise e entendimento do sistema seja realizado de maneira que as informações necessárias para o desenvolvimento sejam todas identificadas.

Neste tipo de entendimento, quando o programador vai desenvolver os requisitos levantados pelo analista de sistemas, o programador NÃO vai ter duvida de nada, pois tudo já foi pensado e discutido com o cliente.

Eu tive uma vez um gerente de produtos que em uma reunião de processos de desenvolvimento de software comentou: “O analistas de sistemas possui uma restrição de horários para realizar a analise do software, pois meus analistas de produtos são muito atarefados e não podem perder tempo conversando com os analistas de sistemas”.

Eu lembro que entrava em sala de reunião para fazer a analise do sistema com um cronograma determinando: 3 horas / 150 requisitos. O cronograma não previa o entendimento do requisito.

Após o levantamento do requisito e a elucidação do mesmo por intermédio de casos de uso, escritos sem os analistas de produtos, nos tínhamos a validação dos mesmos. Com direito a apenas uma correção e revalidação.

Casos de uso aprovado, diagramas de UML e após os diagramas codificação. Uma vez terminado os códigos testes de homologação da Iteração.

O interessante é que muitos dos erros de analise do sistema eram pegos apenas na parte de teste de software, quando o analista de testes estava criando os casos de testes. Com estes erros identificados, o analista de sistemas voltava ao analista de produtos para dar inicio a todo o processo de novo, mas com um detalhe, quando a empresa deixava o analista de produtos conversar com o analistas de sistemas de novo.

WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL ...


Mas tem gente que ainda acha que este processo não é WATERFALL - WATERFALL - WATERFALL - WATERFALL - WATERFALL


Abraços a todos,

Abu