Mundo Ágil

Agilidade com Django

2012-02-22T20:07:00.000-08:00

Nos pots anteriores, vinha falando sobre APM ou Agile Project Management, ou ainda apenas Desenvolvimento Ágil.
Enfim, resolvi diversificar o blog, e escrever também sobre ferramentas que auxiliam a produtividade de equipes ágeis, e a escolhida da vez será o framework - Django.

Vamos lá...
Para começar Django é um framework web de alto nível e escrito em Python, uma poderosa linguagem multiparadigma, caso não conheça a linguagem, aconselho a dar uma visitada no site oficial, clicando aqui.

Django

O framework foi criado pelo grupo editorial "The World Company" para a criação da versão web de seus jornais. Posteriormente, em 2005, foi liberado sob a licença BSD, tornando-se assim um software de código aberto.
Assim como outros frameworks ágeis, Django utiliza o conceito DRY (Don't Repeat Yourself) ou em português "Não se repita".
O framework, adota o modelo de convenção, no lugar das massantes configurações, isso acaba agilizando bastante o desenvolvimento.

Inside of Dango

Model Layer - Camada de representação de dados do projeto. No caso do Django, o sistema ORM (Object-relational mapper) é frequentemente utilizado na criação dos nossos modelos de classes.
Templates - Comumente conhecido como View no modelo MVC, neste caso alterado para template, pois o framework lida nesta camada com modelos de templates html.
Controller - Em Django essa camada é feita por dois componentes: URL Dispatcher e as Templates (Views)
Resumindo: Django trabalha com o conceito: MTV (Modelo, Template e View), conforme você poderá observar na figura abaixo:

Django overview

Alguns aspectos interessantes sobre o framework:

Interface Administrativa automática - Isso mesmo, com Django, você elimina o trabalho de ter que criar uma interface de administração para o seu sistema ou site, ele faz isso automaticamente para você.
Suporte a internacionalização
Formulários - geração automática de formulários (Html) e fácil manipulação dos dados enviados por eles.
Segurança - gerenciamento de autenticação de usuário e controle de permissões.
Sistema de cache - componentes prontos para serem utilizados no cacheamento do seu sistema.
Sistema de templates - fácil manipulação dos templates, em uma linguagem de manipulação de dados clara e simples de utilizar até por não desenvolvedores, por ex: Webdesigner ou desenvolvedores de interface.
Outros componentes - serialização de dados, sistema de testes automatizado, serviço de mensagens (e-mail e troca de mensagens entre usuários), geração de feeds (RSS/Atom), paginação de resultados e etc.

Instalando

Você irá precisar do Python instalado, você poderá obter daqui: http://python/download. Aqui uma OBSERVAÇÃO importante: Caso você opte pela versão 3.x de Python, procure a versão mais atual, neste caso a 1.3
Baixe a última versão do framework do site do projeto, neste caso deste endereço: www.djangoproject.com/download
Descompacte tudo
Com o Python já instalado, abra um terminal (prompt no Windows) com a permissão de Administrador (Windows, acima da versão XP) e vá até o diretório em que o Django foi descompactado.
Agora execute o comando python setup.py install como administrador (Windows, acima da versão XP), caso opte pelo linux/OS X não esqueça de usar o comando sudo.

O resultado deverá ser igual a imagem abaixo:

Pronto você deverá ter seu Python e o Django devidamente instalados em seu computador, agora é só praticar.
No próximo post, vou explicar como criar uma app com Python Django.

Abraços e até a próxima.

Referências:
Novatec - Python e Django - Osvlado Santana e Thiago Galesi
Django Brasil - www.djangobrasil.org
Django Project - www.djangoproject.com

Como obter uma visão consistente em um projeto ágil.

2012-01-29T04:33:00.001-08:00

Em muitas empresas que adotam o desenvolvimento ágil, o Product Owner é reposnsável por manter a visão dos produtos, dos sistemas e de aplicações que estejam sob sua responsabilidade, ou área.
É de responsabilidade do product owner os seguintes itens:

Manter a visão atualizada, como já dissemos;
Promover a visão junto ao time;
Responsável pelos requisitos e documentações;
Participar das cerimônias de entregas;
Participar do planejamento das iterações representando o cliente;

...
Geralmente os questionamentos ligados a visão do produto/projeto, que um Product Owner bem treinado deveria fazer são:

Qual problema este produto/projeto resolve para o meu cliente?
Quais as funções e benefícios a solução agregaria ao meu cliente ?
Para quem é esta solução ?
Que performance, segurança, escalabilidade e outras coisas, preciso entregar para o meu cliente ?
Quais plataformas, padrões, aplicações e etc, terá que suportar?

"O resultado da reunião para criar a visão será uma lista de funcionalidades, com uma breve descrição do cenário."
A visão poderá ser mantida em um documento, no qual descreva de forma clara e sucinta, descrevendo o seu valor para o usuário. Poderá ser um documento formal, ou uma lista de requisitos.
Ainda no documento de visão, deveríamos incluir os requisitos não funcionais, no qual incluem: segurança, performance, qualidade, compatibilidade, entre outros itens que serão necessários para construir o sistema.
Você pode se perguntar: Preciso de todas essas informações no documento de visão ? Nãoo seria mais fácil chamar esse documento de Documento de Escopo do Projeto ?
R: O importante é você ter um documento com as informações que serão necessários para começar o projeto, o nome ou a forma como você irá formalizar essas informações, ao meu ver tanto faz, desde que você as tenha de forma clara e objetiva.
Elas serão úteis mais para frente, principalmente para decomposição da deste documento ou visão, como chamamos.
Como pode se observar, um documento de visão, é muito similar ao documento de escopo de projeto, no qual o PMBOK adota, onde você tem uma breve descrição do projeto, os requisitos, funcionais e não funcionais e toda e qualquer informação que seja relevante ao projeto.
Calma, sei que essa declaração é um pouco estranha e vai de contra a muitos pensamentos agilistas, mas francamente, não sejamos puritanos. Qual o problema de montar um documento bem elaborado, que será crucial para ajudar a decompor a visão de forma mais segura? Claro que não precisamos seguir o modelo do PMBOK, mas é importantes termos bem claros quais são os objetivos do projeto, e francamente o modelo sugerido pelo PMBOK casa bem com determinados projetos.
No próximo post, vamos abordar uma forma de decompor esta visão.

Agile Development - The customer in site role

2012-01-28T04:35:00.000-08:00

Hi, in this post I’ll write about the confusion that many agile teams are doing about the role of Customers and Product Owners. I hope that you enjoy.
Let’s to the work…
In the Agile Development we see the Customer role are the principle business owner. Well, and where stays the Product Owner role ?
As you can see, this roles cause confusion in agile teams beginners, because it is difficult to distinguish to what extent do each role.
Therefore, I’ll try to show the main differences between the role of Customer and Product Owner role.
Below is a brief description of the differences:
The Customer (in site) Role:

Focus on the vision of the product
Helps the team to build the product vision
Participates in frequent deliveries

and more…
The Product Owner:

Maintain the vision of the product
Promote the vision
Responsible of the requisites and documents
Participates in frequent deliveries with their ideas
They can be a Product Manager

and more…
Well, As you can see the papers often seem confusing, but in their essence they are totally different.

Critérios para ser um bom Product Owner

2011-09-20T20:18:00.000-07:00

Com o advento do Scrum, surgiram alguns novos papéis nas empresas, como o do Product Owner, mais conhecido como P.O., Scrum Master e Time.

Sem dúvida alguma, o papel de P.O. é de suma importância dentro das equipes, é tão importante quanto o do Scrum Master, que infelizmente muitas pessoas acreditam ser o único e mais importante papel, já que ele é o responsável por manter os processos em dia. Infelizmente as pessoas acabam esquecendo que O P.O. é o responsável por manter a visão do projeto/produto, que é o meio de comunicação entre a equipe e o cliente, que sem ele o Scrum Master e o Time não teriam razão insumos suficientes para desenvolverem o produto, já que o P.O é a materialização das regras de negócio do produto, ele é principal representante do cliente para e equipe. Enfim... figura fundamental do time.

Abaixo, gostaria de citar alguns critérios que acredito serem importantes para se tornar um bom Product Owner.

Ser comprometido com o projeto/produto.
Sem dúvida alguma, um bom P.O. precisa estar comprometido com o negócio em que está envolvido, e com a equipe. Aqui a sugestão seria, não seja P.O. de mais de um produto/projeto, pois isso irá dificultar o seu comprometimento e conhecimento sobre os projetos, mas sabemos que muitos fazem isso, se envolvem com um ou mais projetos ao mesmo tempo.
Boa comunicação
Item imprescindível para um bom P.O., pois ele será a ponte de comunicação entre o time, cliente e stakeholders.
Ter espírito de liderança
Outro ponto fundamental, é ter espírito de liderança, pois ele será o responsável por toda a visão do projeto/produto, tendo o poder de alterar a qualquer momento, guiando a equipe no processo de desenvolvimento.
Possuir boa habilidade em negociação
O que falar de um P.O. que não tenha habilidade de negociar com o Cliente e com a Equipe ? Bom, uma coisa é certa o backlog nunca irá parar de crescer. Outro ponto é que ele não saberá negociar com a equipe os itens que irão entrar nas sprints. Logo, eis um item muito importânte na vida de um P.O.
Ser um visionário
Muito importante, pois poderá vir do P.O. a visão do produto no levantamento dos requisitos, mas a visão não se restringe apenas no ínicio do projeto, ela poderá se propagar em todo o ciclo, pois será de suma importância o P.O. identificar se o Projeto/Produto está tomando o rumo esperado pelo mercado, caso não esteja, é de responsábilidade dele fazer uma análise de mercado para ver o que poderá ser feito do produto/projeto. Também é de responsábilidade do P.O. difundir a visão entre os evolvidos no projeto.
Ser qualificado para o projeto/produto
Aqui acho que vou criar um pouco de polêmica, mas francamente um P.O. que não seja qualificado irá atrapalhar mais do que ajudar. Óbviamente o P.O. não precisa ser um especialista do negócio, mas o quanto mais ele conhecer, mais irá ajudar, e também deverá ser uma pessoa qualificada para o produto/projeto.
Trabalhar em equipeO P.O. tem que trabalhar para o time e com o time, pois ele é o ponto focal do negócio para a equipe Scrum, logo ele não deverá adotar um perfil centralizador, negligenciando a informação da equipe. O P.O. faz parte do time!

Resumindo...
Para se tornar um bom P.O. eu diria que a pessoa teria que ter a grande habilidade de lidar muito bem com as pessoas e com os requisitos de software. Também ser organizado, pois organizar backlog é uma tarefa muitas vezes dificil e que requer muita atenção do P.O.E para finalizar: "Ouça sempre o que o seu time tem a dizer, análise as informações que chegam, e só depois tome alguma decisão. Não tenha medo de se envolver com os demais pápeis do Scrum, o quanto mais o P.O. se envolver no processo de desenvolvimento do projeto, mais ficará ciente do andamento da equipe e de suas dificuldades, participe das Dailys e retrospectivas sempre que puder."

E nunca esqueça:
"O Product Owner é um membro da equipe Scrum, assim como o Scrum Master e o time."

Abraços e até a próxima!

Referências:

Gestão de Produtos com Scrum - Roman Pichler

Desenvolvimento de Software com Scrum - Mike Cohn

F.D.D. para equipes não tão ágeis

2011-09-13T16:28:00.000-07:00

Na realidade, este post é sobre uma apresentação que fiz em conjunto dos meus amigos Guilherme Pinter e Everton Lentez no TDC Floripa 2011, sobre como a FDD (Feature-Driven Development) pode ajudar equipes baseadas em processos PMBOK e em metodologias como RUP a mudarem o seu mindset para um modelo mais ágil.

Link da apresentação no slideshare, TDC Floripa 2011, no qual foi apresentado um case do Portal Unimed, sobre os benefícios da mudança de métodos tradicionais para metodologias ágeis em seus processos de desenvolvimento de software.

Ágil cabe na minha empresa ?

2011-09-11T15:15:00.000-07:00

É notável que hoje muitas empresas pensam em adotar metodologias ágeis para o desenvolvimento de software acreditando ser a melhor forma de resolver os problemas que tem nos seus projetos.
Infelizmente a grande maioria das empresas acabam adotando algumas práticas ágeis achando que elas irão resolver os seus problemas, sem antes mesmo de ver a causa raiz deles.

E gostaria aqui de repetir um clichê dos agilistas: "Desenvolvimento ágil não é uma bala de prata que irá resolver todos os seus problemas"

E gostaria ainda de acrescer ainda algo mais: "Você poderá piorar ainda mais seus processos e criar um ambiente ainda mais caótico para seus projetos."

Um bom conselho que gostaria de dar a você caro leitor, é: "Antes de implantar qualquer prática ágil em sua empresa, antes de contratar qualquer consultoria ou coaching ágil para seus projetos, reveja seus processos e objetivos de sua empresa".

O fato de rever seus processos irá ajudar a mapear os gaps que existem e que lhe forçam muitas vezes a pensar em adotar algo diferente para sanar esses problemas.
Infelizmente, caso você tenha problemas processuais, o que não é nada muito fora do normal acontecer, mesmo adotando um framework ágil você não irá resolve-los, e ainda irá correr o risco de esconder os seus problemas que poderão culminar o fracasso de seus projetos.

Mas então vem a pergunta do título, como saber se o ágil cabe na minha empresa ?
R: Segue abaixo as minhas considerações:

Ser uma softhouse. Infelizmente não conheço nenhum case que se tenha usado metodologias ágeis em projetos que não sejam para software.
Analise se as metodologias ágeis irão ajudar a melhorar o seu ROI, caso realmente venha contribuir, o que geralmente elas fazem muito bem, acho que é um bom indicio de se pensar em adotar alguma prática ágil.
Não menos importante, abertura a mudança e comprometimento do seu time com as propostas das metodologias ágeis
Tenha seus processos muito claros e mapeados antes, pois isso irá ajudar a saber se cabe ou não em sua empresa.
Isso ajuda bastante a compreender como funciona cada time e auxília a escolha da metodologia que mais se adapta a realidade deles.
Seu modelo de negócio consegue ter a participação do cliente de forma efetiva, seja ele client-in site ou o usuário final.
Sua equipe ter pessoas experientes e se possível com que já tenham trabalhado com alguma metodologia ágil.
Times pequenos, não mais do que 10 pessoas.

OBS: Apenas citei alguns pontos que acho crucial para implantação do ágil em empresas de software. Sinceramente, se você já usa alguma metodologia baseada no PMBOK e está se sentindo bem com ela, que a saúde de seus projetos é boa e que não há uma necessidade urgente de aumentar o ROI, tenha calma e analise bem se compensa mudar.

E aí, vai encarar ?

Desenvolvimento ágil exige muito esforço corporativo, compreenção e muita paciência para os envolvidos, pois geralmente se leva de 6 meses a 1 ano para se colher realmente algum fruto.

Abraços e até a próxima

Início {

2011-09-09T17:54:00.000-07:00

Este post tem a intenção de ser o start desse blog, no qual espero que não seja apenas um a mais no meio de tantos outros.
A idéia central do Blog, é falar sobre o mundo ágil, com técnicas desde da concepção a materialização dos softwares com foco em práticas ágeis.

Espero que gostem...