XP - Dúvidas em Entregas Frequentes

Assuntos Gerais Agile
#1

Fiz uma busca neste fórum e não encontrei nada relacionado a essa minha dúvida.

A XP fala em Entregas Freqüentes: Coloque um sistema simples rapidamente em produção, e depois libere novas versões em ciclos curtos.

Estou fazendo um sistema de Ordem de Serviço para a empresa onde trabalho e, há uma semana, surgiu uma dúvida. Desde então estou pensando no assunto. Meu bom-senso me diz que a primeira opção é a verdadeira. Gostaria da opinião do pessoal:

[list]Somente um projeto de certo porte é passível dessa quebra em sistemas mais simples, liberando pequenos módulos para produção. Ex: Um ERP seria quebrado no Módulo de Vendas, Módulo de Compras, RH, etc. Inclusive, meu pequeno sistema de OS seria um dos módulos desse grande sistema;
[/list]
[list]É possível sim quebrar meu sistema de OS e liberar sub-módulos (estranha a denominação, eu concordo), como Cadastro de Clientes, Cadastro de Técnicos, Cadastro de Aparelhos, etc.
[/list]

O que é mais lógico e viável? Liberar este meu sistema completo depois de 45 dias (o prazo que dei para a patrãozada), ou quebrar em módulos e liberar pequenas versões em ciclos mais curtos, com Entregas Freqüentes, com análise, implementação, testes em cada módulo?

Obrigado!

#2

Eu apostaria na segunda opção…
O uso de frequentes entregas ajuda ao teu cliente a visualizar o sistema como um todo e caso ele já note alguma anomalia ou alguma parte do sistema que ele não aprovou (ou, como normalmente ocorre, ele especificou errado), ele já solicita a alteração do mesmo.
Isso evita que no final dos teus 45 dias, o cliente olhe e diga: “Não era bem isso que eu queria”…

#3

Divida as entregas por funcionalidades, fica mais facil dividir.

#4

Obrigado pelas respostas!

Respondendo ao Aleck e ao Eltonk.

Essa divisão seria como mencionei? Cadastro disso, cadastro daquilo? Pois vejo apenas essas quebras como funcionalidades.

Imaginei como objetivos deste sistema o seguinte:
[list]Organizar a AT da empresa[/list]
[list]Acompanhamento em “tempo real”, pelos clientes, dos aparelhos em manutenção, diminuindo, assim, a quantidade de ligações que o Gerente Técnico recebe durante o dia[/list]
A extrema simplicidade do sistema me gerou estas dúvidas. Fora as operações de CRUD, as funcionalidades seriam esse acompanhamento dos status das Ordens de Serviço e o envio de um aviso ao cliente quando o status de uma Ordem mudasse.

Como eu já disse, sou extremamente novo nessa área de “Projeto de Software bem feito” e tenho dificuldades de identificar certas coisas (ou insegurança: se estou especificando da forma correta), como as funcionalidades.

O que eu disse está correto?

#5

Você deve quebrar o sistema em uma forma que esse pequeno release funcione em produção.

Não adianta você implantar por exemplo só o cadastro de Clientes, se o cadastro de cliente necessida por exemplo, de um objeto Cidades, e esse cadastro de cidades ainda não existe.

Tente definir também espaços curtos para lançar esses releases (3, 4 dias, já que é um sistema pequeno talvez).

Depois que colocar os pequenos releases em produção, sempre BUSQUE feedback das pessoas que estão usando-o, assim você pode rapidamente verificar alguma falha ou carencia nesse release e arrumar no próximo.

#6

faça isto, libere funcionalidades.

Tenha em mente sempre liberar primeiro as funcionalidades que agregam mais valor de negócio ao seu cliente.

Por exemplo: em um sistema de processamento de títulos, o que agrega mais valor é o processamento em si, os cadastros são periféricos e para te falar a verdade, você verificará que seu cliente dirá que alguns deles nem precisarão ser construidos…

#7

Obrigado pelos esclarecimentos! Senti a neblina começar a dissipar.

O sistema é pequeno sim. Muito simples.

Vou fazer assim então. A análise do sistema já está, teoricamente (pois mudo constantemente), pronta.

Vou liberando os cadastros. O cadastro de clientes necessita do cadastro de endereços e do cadastro de comunicação. Assim, esse módulo já está bem definido. Depois libero de aparelhos, e assim por diante. Como trabalho na empresa onde essa joça vai entrar em produção, o feedback dos usuários ocorre de forma simples e me ajuda bastante. Outros trecos que já coloquei em produção por aqui funcionaram dessa forma, só que com o sistema inteiro. =)

Comecei a estudar a XP depois do start-up deste projeto. Inclusive depois que fixei os prazos. Isto, inclusive, fiz no método waterfall: Até o dia tal entrego a Análise, até o dia tal, a implementação das classes, até o dia tal as JSP’s e até o dia tal a geringonça vai estar em produção. No meio da análise comecei a ler o livro do Beck e olhei para o quadro branco que fica ao lado de minha mesa. Pensei, tá tudo errado se eu quiser implementar um pouco de XP, que seja. Então pensei em refazer o processo, foi quando surgiu a dúvida. Será que o meu sistema era grande o suficiente para ser quebrado? Pensei na questão e hoje postei para saber a opinião do pessoal.

Gostei muito das análises de todos. Vou refazer o processo em papel e no quadro branco da minha casa. No quadro branco daqui do trabalho, vai ficar a waterfall mesmo. No próximo vejo se ganhei bagagem para aplicar direito (em parte) essa metodologia.

Obrigado!

#8

[quote=AvilaCS][quote]

É possível sim quebrar meu sistema de OS e liberar sub-módulos (estranha a denominação, eu concordo), como Cadastro de Clientes, Cadastro de Técnicos, Cadastro de Aparelhos, etc.

[/quote]

faça isto, libere funcionalidades.

Tenha em mente sempre liberar primeiro as funcionalidades que agregam mais valor de negócio ao seu cliente.

Por exemplo: em um sistema de processamento de títulos, o que agrega mais valor é o processamento em si, os cadastros são periféricos e para te falar a verdade, você verificará que seu cliente dirá que alguns deles nem precisarão ser construidos…

[/quote]

Opa… informação nova. =)

Liberar o processo das OSs antes de liberar os cadastros? Aí virei de cabeça para baixo mesmo. =)

As entradas para fazer o sistema funcionar seriam colocadas na unha na base de dados?

#9

quem deve priorizar o que eh mais importante em cada iteração é o cliente.
ele é quem vai definir quais funcionalidades agregam mais valor e o que deve ser implementado a cada iteração.

[]'s

#10

[quote=jgbt]quem deve priorizar o que eh mais importante em cada iteração é o cliente.
ele é quem vai definir quais funcionalidades agregam mais valor e o que deve ser implementado a cada iteração.

[]'s[/quote]

Blz, vamos supor, para agilizar, que ele tenha decidido pelo processo das OSs. É o que me parece mais lógico, mas como eu disse, é uma suposição.

As entradas para fazer essa moenda funcionar precisam ser inseridas na unha. Isso é uma prática normal?

#11

[quote=celso.martins]
Blz, vamos supor, para agilizar, que ele tenha decidido pelo processo das OSs. É o que me parece mais lógico, mas como eu disse, é uma suposição.

As entradas para fazer essa moenda funcionar precisam ser inseridas na unha. Isso é uma prática normal?[/quote]
se ele decidiu isso, sim vai ser feito dessa maneira.
lembre-se, como são iterações curtas, talvez na proxima ele queira s cadastros… e assim vai…

[]'s

#12

[quote=celso.martins]
Liberar o processo das OSs antes de liberar os cadastros? Aí virei de cabeça para baixo mesmo. =)
As entradas para fazer o sistema funcionar seriam colocadas na unha na base de dados?[/quote]

Mais ou menos isto. Suponha que no exemplo que dei o cliente solicitou e priorizou as seguintes entregas:

[list]processar compras de CDB pré-fixado;[/list]
[list]processar vendas de CDB pré-fixado;[/list]
[list]processar compras de LFT;[/list]
[list]processar vendas de LFT;[/list]
[list]cadastro de título e de emissão de títulos[/list]
[list]cadastro de tipos de título, de tipo de emissão, de locais (cidade, estado, país), de usuários, etc[/list]

Neste exemplo, a primeira iteração requer informações cadastrais básicas do título e da compra em si. Além disto é requerido que seja feito o processamento da compra e a apresentação da consulta com o resultado. Outras informações cadastrais como por exemplo: os tipos de títulos (pré, pós, etc) que serão mostrados em um combo na tela de compra, não precisam ser implementados, pode ser feito insert na mão.

Assim, a primeira iteração teria um cadastro básico do título, uma tela de compra de CDB, uma tela de solicitação de processamento e uma tela de consulta de processamento.

E lembre-se o processo é iterativo e incremental, portanto em cada nova iteração você vai refatorando e adicionando as informações necessárias e construindo o essencial para que o software possa ir para produção.

#13

[quote=jgbt]

se ele decidiu isso, sim vai ser feito dessa maneira.
lembre-se, como são iterações curtas, talvez na proxima ele queira s cadastros… e assim vai…

[]'s[/quote]

Maravilha! Acho que estou começando a entender!

Obrigado a você Jgbt, e a todos que responderam!

#14

[quote=AvilaCS][quote=celso.martins]
Liberar o processo das OSs antes de liberar os cadastros? Aí virei de cabeça para baixo mesmo. =)
As entradas para fazer o sistema funcionar seriam colocadas na unha na base de dados?[/quote]

Mais ou menos isto. Suponha que no exemplo que dei o cliente solicitou e priorizou as seguintes entregas:

[list]processar compras de CDB pré-fixado;[/list]
[list]processar vendas de CDB pré-fixado;[/list]
[list]processar compras de LFT;[/list]
[list]processar vendas de LFT;[/list]
[list]cadastro de título e de emissão de títulos[/list]
[list]cadastro de tipos de título, de tipo de emissão, de locais (cidade, estado, país), de usuários, etc[/list]

Neste exemplo, a primeira iteração requer informações cadastrais básicas do título e da compra em si. Além disto é requerido que seja feito o processamento da compra e a apresentação da consulta com o resultado. Outras informações cadastrais como por exemplo: os tipos de títulos (pré, pós, etc) que serão mostrados em um combo na tela de compra, não precisam ser implementados, pode ser feito insert na mão.

Assim, a primeira iteração teria um cadastro básico do título, uma tela de compra de CDB, uma tela de solicitação de processamento e uma tela de consulta de processamento.

E lembre-se o processo é iterativo e incremental, portanto em cada nova iteração você vai refatorando e adicionando as informações necessárias e construindo o essencial para que o software possa ir para produção.
[/quote]

Perfeita a explicação. Estou precisando exatamente disso. Associação das idéias ao mundo real do desenvolvimento, pelo menos ao meu mundo real. =)

Sou iniciante nesses processos e às vezes tenho dificuldade em fazer essas associações. Acho que esse livro de Projeto de Software que comprei me ajudará bastante na clarificação das minhas idéias. Claro, além destes tipos de respostas como a sua e a do Jgbt!

Obrigado mais uma vez!

#15

Er, o que tem de errado em perguntar pro cliente o que ele quer entrege primeiro? Mostre todas as estorias estimadas que voce pode entregar semana que vem, e pergunte qual delas eh mais importante.

#16

[quote=celso.martins]
Blz, vamos supor, para agilizar, que ele tenha decidido pelo processo das OSs. É o que me parece mais lógico, mas como eu disse, é uma suposição.

As entradas para fazer essa moenda funcionar precisam ser inseridas na unha. Isso é uma prática normal?[/quote]

Isso vai também do bom senso.

Existem casos que simplesmente inserir os dados diretamente no banco para ser usado funciona, mas existem casos que é necessário ter uma entrada (um cadastro por exemplo).

Mas lembre-se, se o mais importante é o OS, então você deve entregar o OS. No caso das entradas, você pode simplesmente implementar uma simples tela de cadastro, apenas com os campos úteis para sua OS e no futuro, quando for implementar outra estória referente aos cadastros, você “melhora” essas entradas.

#17

só para esclarecer possíveis equívocos: o que eu quis dizer é quem define e prioriza o que deve ser produzido e entregue é o cliente.

Aliás, é fundamental que o cliente tenha participação efetiva de forma periódica e constante.

#18

Opa… nada, nada mesmo…
Ainda mais que o cabra que está mais diretamente ligado ao processo, o Gerente do Dpto. Técnico, é um grande amigo, cursa a mesma cadeira, na mesma faculdade que eu e freqüenta normalmente a minha casa. Nosso diálogo é franco e aberto, sem problemas. Toda hora ele entra no meu dpto e fala, olha, pensei melhor naquele assunto e isso não está legal assim, melhor seria desse jeito. Argumento vai, argumento vem e chegamos à uma conclusão.

Essa parte está bem tranquila! =)

Abraços!

#19

[quote=ManchesteR][quote=celso.martins]
Blz, vamos supor, para agilizar, que ele tenha decidido pelo processo das OSs. É o que me parece mais lógico, mas como eu disse, é uma suposição.

As entradas para fazer essa moenda funcionar precisam ser inseridas na unha. Isso é uma prática normal?[/quote]

Isso vai também do bom senso.

Existem casos que simplesmente inserir os dados diretamente no banco para ser usado funciona, mas existem casos que é necessário ter uma entrada (um cadastro por exemplo).

Mas lembre-se, se o mais importante é o OS, então você deve entregar o OS. No caso das entradas, você pode simplesmente implementar uma simples tela de cadastro, apenas com os campos úteis para sua OS e no futuro, quando for implementar outra estória referente aos cadastros, você “melhora” essas entradas.[/quote]

Compreendido…
pensei até em fazer essas telas em Delphi. Conheço um pouco mais do Object Pascal e dessa IDE e consigo colocar meia dúzia de telas para funcionar em minutos. =)

#20

[quote=AvilaCS]só para esclarecer possíveis equívocos: o que eu quis dizer é quem define e prioriza o que deve ser produzido e entregue é o cliente.

Aliás, é fundamental que o cliente tenha participação efetiva de forma periódica e constante.[/quote]

Isto, inclusive, é uma das práticas da XP. Incluir efetivamente o cliente no processo de desenvolvimento. No meu caso, o processo de desenvolvimento está incluído no cliente. =)

Abraços!