terça-feira, 27 de outubro de 2009

Programação em Par

Oi pessoal,

Segue um video e uma apresentação referente a programação em par.

Link original do post: http://ow.ly/wQbN





Uma boa leitura.

Abraço a todos,

Abu

Understanding Scrum success

Oi pessoal,

O link do material é: http://jeffsutherland.com/scrum/PracticalRoadmapMunich20091020.pdf





Jeffsuther vem mostrando o "pulo do gato" para utilizarmos CMMI nível 5 e Scrum. Este material realmente vale a pena de ser lido.

[]s

Abu

Gerenciamento de Custo e Prazos – UGF

Bom dia pessoal,

Terminou no dia 27 de outubro o quarto e ultimo encontro da disciplina de Gerenciamento de Custos e Prazos em projetos. Está disciplina foi ministrada na turma do CURSO de Pós-Graduação “Lato Sensu” MBA Executivo, realizado no Centro Internacional de Estudos do Cone Sul e Universidade Gama Filho - UGF, Florianópolis / SC.

A ementa da disciplina foi: Estruturas Analíticas de Projeto (EAP). Definição das Atividades. Seqüenciamento das Atividades. Rede Lógica de Precedências. Diagramas ADM e PDM. Estimativa de Duração das Atividades. Método PERT/CPM. Desenvolvimento da Programação. Controle da Programação. Curvas-S de acompanhamento de Progresso Físico previsto e realizado. Caminho Crítico. Folgas. "Crashing". "Fast Tracking". Nivelamento de Recursos. Método de seleção de projetos. Análise Financeira de Projetos. Classificação das Estimativas de Custos. Nível de Precisão e Risco nas Estimativas de Custos. Orçamentação. Controle de Custos. Método "Earned Value".

Na minha retrospectiva desta disciplina posso afirmar: “Foi muito divertido e prazeroso ministrar este conteúdo a vocês”. Eu tive a oportunidade de conhecer novas pessoas e com certeza novos colegas de profissão. A riqueza desta turma esta na multidisciplinaridade, onde em sala de aula nos tivemos profissionais da área de TI, Saúde, Educação, Engenharias, entre outras.




Um abraço a todos,

Abu

sexta-feira, 23 de outubro de 2009

Software de Teste / Web / Ruby On Rails

Oi pessoal,

Este software Watir faz lembrar o Selenium, mas ele é bem mais simples de instalar e utilizar.

Link do software: http://watir.com/

Ferramenta de Gravação do Teste: http://itest2.com/downloads

Abraço a todos,

Abu

Combinando Técnicas de Ágil e PMBOK

Oi pessoal,

Vamos falar da combinação de técnicas para encontrar o melhor modelo para os projetos que estamos realizando.

A empresa GTT está com uma demanda muito grande de projetos, como os nossos projetos possui a necessidade de adquirir matérias primas, construir equipamentos, desenvolver software, terceirizar serviços e produtos, controlar orçamento, etc... Todo o planejamento do projeto é desenvolvido utilizando PMBOK.

Nos temos ate mesmo um quadro com o cronograma.



Os produtos (Hardware e Software) são projetados e construídos com conceitos de Lean. Toda visão do produto vem de uma reunião entre todos os envolvidos no projeto e após esta reunião o nosso Product Backlog de software está montado.

Para o gerenciamento do desenvolvimento das historias do Product Backlog nós utilizamos o quadro de Kanban.

Na foto a baixo podemos ver dois quadros de Kanban, onde cada quadro esta sendo desenvolvido para atender um contrato e cada contrato demanda trabalho para vários produtos de software.





Nós temos software para desktop que trabalha diretamente acoplado ao hardware, software web, software para dispositivos moveis, software para gravar / gerar etiquetas de RFID, etc.

No cronograma em PMBOK nos temos apenas os produtos a serem entregues de software em auto nível, junto com a data de inicio e a data de termino, este cronograma não se preocupa com os detalhes que estão sendo desenvolvidos pela equipe de software. Na equipe de software é que nos temos o controle dos requisitos e tarefas.

Para um controle do que deve ser desenvolvido em software nos utilizamos prazo rígido, orçamento rígido e escopo variável, onde após a priorização do escopo nos atacamos os itens mais importantes primeiro, deixando os itens secundários para serem construídos apenas após o termino dos itens mais importantes.


Parabéns ao gerente da fabrica (Fabrício), ao engenheiro chefe (Thiago), ao departamento de vendas, que realmente trabalha integrada com a equipe técnica e a equipe de Hardware e Software.

Abraço a todos,

Abu

domingo, 18 de outubro de 2009

Não fique criando cenários...

Oi pessoal,

Vamos iniciar alguns post com conhecimento retirado do livro: Modelagem Ágil, de Scott W. Ambler.

Não fique criando cenários “O que acontecerá se...” até não agüentar mais, pagina 36 do livro.

Muitas vezes, vejo desenvolvedores de software desviarem-se de suas tarefas para tentar construir um software que satisfaça às necessidades de seus usuários de um modo eficaz, com cenários tolos do tipo “o que acontecerá se...”. Eles começam a modelar demais o software para resolver todos os problemas imagináveis, com os quais os clientes dificilmente estão preocupados ou acreditam ser tão remotamente provável deles acontecerem que estariam dispostos a correr o risco. Então, por modelarem em excesso, os desenvolvedores também constroem em excesso. Sim, você não quer ser completamente simplista em seu trabalho. É razoável esperar que alguns problemas em banco de dados e falhas de rede, entre outros, realmente ocorram, mas você precisa ser realista quando estiver modelando.



Abraço a todos,

Abu

Responder a mudanças vale mais que seguir um plano

Oi pessoal,

Vamos iniciar alguns post com conhecimento retirado do livro: Modelagem Ágil, de Scott W. Ambler.

Responder a mudanças vale mais que seguir um plano, pagina 24 do livro.

As pessoas mudam suas prioridades devido a vários motivos. À medida que o trabalho no sistema progride, muda a compreensão dos clientes do projeto sobre o domínio do problema e sobre o que você está construindo. O ambiente de negócio sofre alterações. A tecnologia muda no decorrer do tempo, embora nem sempre para melhor. A mudança é uma realidade no desenvolvimento de software que seu processo de software deve refletir. Não há nada de errado em ter um plano de projeto. Na verdade, me preocuparia com qualquer projeto que não o possuísse. Entretanto, o plano deve ser maleável; caso contrário, torna-se rapidamente irrelevante.


Abraço a todos,

Abu

A colaboração do cliente vale mais que a negociação de contrato

Oi pessoal,

Vamos iniciar alguns post com conhecimento retirado do livro: Modelagem Ágil, de Scott W. Ambler.

A colaboração do cliente vale mais que a negociação de contrato, pagina 24 do livro.

Apenas seus clientes podem dizer o que querem. Sim, eles dificilmente acertarão na primeira vez. Sim, eles provavelmente mudarão de idéia. Trabalhar junto com os clientes é difícil, mas é a realidade do trabalho. Ter um contrato com eles é importante, e entender os direitos e as responsabilidades de cada um pode se constituir nos alicerces do contrato, este contrato não é substituto para a comunicação. Os desenvolvedores de sucesso trabalham próximos aos clientes; se esforçam para descobrir o que os clientes necessitam e os educam durante este processo.


Abraço a todos,

Abu

Um software funcionando vale mais que documentação extensa

Oi pessoal,

Vamos iniciar alguns post com conhecimento retirado do livro: Modelagem Ágil, de Scott W. Ambler.

Um software funcionando vale mais que documentação extensa, pagina 24 do livro.

Se você perguntar aos usuários se eles querem um documento de 50 páginas descrevendo o que você pretende construir ou o software real, o que você acha que eles escolherão? Minha hipótese é de que em 99 em cada 100 vezes eles escolherão o software. Se este for o caso, não faria mais sentido trabalhar de modo que você produza um software de forma rápida e freqüente, dando a seus usuários o que eles preferem? Além disso, suspeito que os usuários entenderão mais facilmente qualquer software que você produzir do que diagramas técnicos complexos que descrevem seu funcionamento interno ou uma abstração de seu uso, não acha? A documentação tem o seu lugar; escrita de maneira correta, é um guia importante para as pessoas entenderem como e por que o sistema é construído e como trabalhar com ele. Entretanto, nunca esqueça de que o objetivo principal do desenvolvimento de software é criar software, não documentos – de outra forma, nós o chamaríamos de desenvolvimento de documentação.


Abraço a todos,

Abu

Indivíduos e Interações valem mais que processos e ferramentas

Oi pessoal,

Vamos iniciar alguns post com conhecimento retirado do livro: Modelagem Ágil, de Scott W. Ambler.

Indivíduos e Interações valem mais que processos e ferramentas, paginas 23 e 24 do livro.

Equipes constroem sistemas de software e, para fazê-lo, elas precisam trabalhar junto com programadores, testadores, gerentes de projeto, modeladores e clientes. Quem você acha que desenvolveria um sistema melhor: cinco desenvolvedores de software com suas próprias ferramentas trabalhando juntos em uma única sala ou cinco pessoas pouco habilitadas com um processo bem-definido, as mais sofisticadas ferramentas disponíveis e os melhores escritórios que o dinheiro pode comprar? Se o processo fosse razoavelmente complexo, eu apostaria nos desenvolvedores de software, e você? O ponto é que os fatores mais importantes a considerar são as pessoas e como elas trabalham juntas, porque se você não entender isso bem, de nada adiantarão as melhores ferramentas e processos, os quais são importantes, não me entenda mal, mas não tão importante quanto trabalhar efetivamente juntos. Lembre-se do velho adágio: um tolo com uma ferramenta ainda é apenas um tolo. Pode ser difícil para a gerência aceitar isso porque muitas vezes ela quer acreditar que pessoas e tempo, ou homens e meses, são intercambiáveis (Brooks, 1995).


Abraço a todos,

Abu

sexta-feira, 16 de outubro de 2009

Gerenciamento de Riscos - ESUCRI - Criciúma

Oi pessoal,

Hoje estou iniciando a minha aula na pós-graduação em Criciúma na Faculdade ESUCRI.

Como a disciplina é de Gerenciamento de Riscos eu estou ministrando o conteúdo com uma dinâmica chamada "Cesta Salva Ovos".

O objetivo do projeto é criar uma cesta com os materiais disponíveis para que um Ovo em queda livre de uma altura de 1 metro e 50 centímetros não quebre, isto é, seja salvo pela "Cesta Salva Ovos".




O resultado do projeto será colocado no Blog e no Youtube.

Vamos aguardar...

Abraço a todos,

Abu

quinta-feira, 15 de outubro de 2009

terça-feira, 13 de outubro de 2009

Premiação de Elinor Ostrom com o Nobel de Economia não foi surpresa

Oi pessoal,

Este post é uma reportagem da radio cbn - Noite Total.

Titulo: Premiação de Elinor Ostrom com o Nobel de Economia não foi surpresa



Ele tem uma parte bem interessante sobre auto organização.

[]s

Abu

The ROI of Testing

When determining how much testing you should do, consider the benefits of both manual and automation testing.



Abraço a todos,

Abu

domingo, 11 de outubro de 2009

UML e Martin Fowler

Bom dia pessoal,

Segue frases retiradas do livro: UML Essencial 3 edição de Martin Fowler.

- Os criadores da UML vêem os diagramas como secundários; a essência da UML é o metamodelo. Os diagramas são simplesmente uma apresentação do metamodelo.

- Quase sempre utilizo a UML para fazer esboços. Acho os esboços UML úteis para desenvolvimento e engenharia reversa, tanto na perspectiva conceitual como na de software.
Não sou adepto dos projetos de desenvolvimento detalhados; acredito que é muito difícilfazê-los bem feitos, e eles retardam o trabalho de desenvolvimento. É razoável fazer projetos em nível de interfaces de subsistemas, mas mesmo assim, você deve esperar alterações nestas interfaces, a medida que os desenvolvedores implementam as interações nelas.

- Você não pode olhar um diagrama de UML e dizer exatamente como seria o código equivalente. Entretanto, você pode ter uma idéia aproximada de como ficaria o código.

- Em muitos lugares, diferentes diagramas podem ser úteis, e você não deve hesitar em usar um diagrama que não seja feito com UML, se nenhum diagrama da UML atende o seu propósito.

- Normalmente, a unica maneira de saber se você está no caminho certo é produzir software integrado testado.

- As pessoas dizem que estão fazendo software iterativo, mas na verdade estão usando o processo cascata. Os sintomas são:
a) "Estamos fazendo uma iteração de análise seguida de duas iterações de projeto..."
b) "O código dessa iteração está repleto de erros, mas vamos limpá-lo no final."

- O teste e a integração são as atividades mais difíceis de estimar; portanto, é importante não ter uma atividade aberta como essa no final do projeto.

- Uma técnica comum no caso de iterações é usar um quadro de tempo. Isso obriga uma iteração a ocorrer em um período de tempo fixo. Se você achar que não vai conseguir fazer tudo o que pretendia durante uma iteração, deve deslocar alguns funcionalidades dela; você não deve deslocar a data da iteração. A maioria dos projetos que utilizam desenvolvimento iterativo usam o mesmo período de iteração por todo o projeto; desse modo, você consegue um ritmo de construção regular.

- Na verdade, uma das maiores vantagens do desenvolvimento iterativo é que ele suporta melhorias freqüentes no processo. Ao final de cada iteração, realize uma retrospectiva de iteração, na qual a equipe se reúne para considerar como as coisas ocorreram e como elas podem ser aprimoradas.

- Uma das minhas preocupações com os projetos é que, mesmo para um bom projetista, é muito difícil fazê-los corretamente. Freqüentemente, verifico que meus próprios projetos não sobrevivem intactos ao contato com uma codificação. Ainda considero meus esboços UML úteis, mas não creio que eles possam ser tratados como absolutos.

- Um cenário é uma seqüencia de passos que descreve uma interação entre um usuário e um sistema.

- Um caso de uso é um conjunto de cenários amarrados por um objetivo comum ao usuário.

- As funcionalidades constituem uma boa maneira de repartir um sistema para planejar um projeto iterativo, pelo qual cada iteração implementaria várias funcionalidades. O caso de uso fornecem uma narrativa de como os atores utilizam o sistema. Então, embora as duas técnicas descrevam requisitos, seus propósitos são diferentes.


Toda vez que eu leio e releio este livro sempre encontro informações uteis. A edição é de 2005 e possui um capitulo muito bom de desenvolvimento ágil. Eu gosto muito de UML, considero ela muito util para o auxilio de análise de sistemas orientada a objetos e um mecanismo de comunicação com a equipe, onde podemos planejar rapidamente uma estratégia de como vamos desenvolver os requisitos da iteração.

Abraços a todos,

Abu

sábado, 10 de outubro de 2009

Tigrão Pipas

Oi pessoal,

Segue as fotos de uma atividade que eu participei com a minha filha no colégio dela. A atividade foi realizada no dia dos pais.

A atividade foi possível graças as instruções do "Tigrão", que possui uma fabrica de construção de pipas. Para quem tiver interesse o e-mail da fabrica é: tigraopipas@hotmail.com

Todos os domingos na Pedra Branca o tigrão e sua equipe estão ensinando as pessoas a montar pipas.

Vamos as fotos...









Lições Aprendidas: Eu nunca fiz Pipa e so consegui fazer com a ajuda de um instrutor. A primeira pipa tinha cara de pipa mas não funcionava. A segunda pipa com a ajuda do instrutor funcionou muito bem.
Durante a produção de pipas foi fácil identificar "padrões utilizados", que eram os nós. Também uma especificação teria ajudado muito, pois a unica coisa que tínhamos era apenas a "visão do produto", mas para quem não possui experiência visão é muito pouco.


Vou transformar esta brincadeira em alguma ferramenta de meus treinamentos, assim que tiver o material eu faço um post.

Um abraço a todos,

Abu

Piano stairs - Rolighetsteorin.se - The fun theory



Outros vídeos: http://www.rolighetsteorin.se/en/

Abraço a todos,

Abu

quinta-feira, 8 de outubro de 2009

Scrum - Secretaria da Fazenda

Oi pessoal,

Segue as fotos do treinamento de Scrum realizado na Secretaria da Fazenda do Estado de Santa Catarina.

Alguns anos atrás eu já tinha tido a oportunidade de realizar um treinamento com a Secretaria da Fazenda e como o mundo é bem pequeno...

No treinamento utilizamos a dinâmica do "Lego" para projetar uma cidade. Nesta dinâmica foi montada uma equipe de 7 Product Owner’s e cada Product Owner tinha a responsabilidade de projetar a sua parte da cidade com a equipe do projeto.

Montamos equipes de 5, 4 e 3 pessoas, para mensurar produtividade e problemas de comunicação e trabalho em equipe.

O resultado foi...















O resultado foi uma bela cidade, construída em duas releases com muita criatividade e qualidade. Também tivemos um monte de brincadeiras, basta olhar as construções desenvolvidas.

Meus amigos da Fazenda, muito obrigado pela oportunidade. Eu "de novo" aprendi muito com vocês.

Um grande abraço,

Abu

domingo, 4 de outubro de 2009

Pós-Graduação - Unisul - Araranguá - ICONIX / UML

Bom dia pessoal. Terminou neste fim de semana a terceira e ultima aula de pós-graduação na Universidade Unisul do campus de Araranguá. Foi ministrada a disciplina de Análise Orientada a Objetos ICONIX.

ICONIX permite rapidamente fazer um entendimento dos requisitos e uma modelagem orientada a objetos de “como” o sistema vai atender os requisitos solicitados pelo cliente.





ICONIX trabalha com uma modelagem iterativa e incremental do sistema, permitindo com que poucos diagramas da UML possibilitem uma criação de uma solução arquitetônica elegante para o nosso sistema.

Fotos da Turma e dos Trabalhos realizados





















A todos os alunos o meu muito obrigado, foi muito divertido realizar os meus trabalhos com vocês. Adorei a cidade, adorei a comida e quem sabe nos encontramos de novo em uma nova oportunidade.

Lembrando, os meus endereços eletrônicos estão todos no blog, é so chamar.

Abraços,

Abu