quarta-feira, 20 de maio de 2015

Boas Práticas, Padrões, Lições Aprendidas - Implantação Mobile Xamarin Forms


Boas Práticas, Padrões, Lições Aprendidas - Implantação  Mobile
 
Internalizar a tecnologia com sucesso é mais importante que inovar com que ela.

Não adianta procurar novos frameworks, IDE, linguagens, se não tiver ninguém dentro

da empresa que continue com o projeto. A equipe que irá manter a tecnologia precisa ser

gradativamente treinada nas novas descobertas homologadas.

Documentação  
Documentar o POC no final é a melhor estratégia.

Documente aquilo que deu certo, sem confusões, limpe o código, remova aquilo que não

é usado e no final documente como (Engenharia Reversa) o POC limpo.


Se comprometa a documentar no mesmo rigor da UML. Diagramas de Classe, Especificação

de Caso de Uso, Diagrama de Atividade, Diagrama de Sequência, Diagrama de Banco de

Dados.


O exercício desta documentação irá revisar seu código e deixar aquele “POC” tão bem
compreendido por quem o fez,  legível por quem irá utilizá-lo para iniciar um novo projeto.

 
Padrões técnicos
 
Utilize o padrão MVC para construção do seu aplicativo para facilitar a manutenção.

Os SDK´s são enormes e pouco conhecidos, e estrutura numa estrutura que lhe seja familiar

irá ajudar no futuro aos novos mantenedores do código a encontrar as divisões do sistema.

Apesar dos App Mobile serem tratados como produtos pequenos pelos usuários, seus códigos não o são e pode ser tornar tão complexos.

 Mantenha compatibilidade com versões anteriores de dispositivos, apesar de difícil,

se tratando de aplicativos Android, eles serão usados por N usuário da Internet.

Quanto mais tipo de celulares você suportar melhor. 

Ao definir uma nova tecnologia, cuidado ao querer redesenvolver todos os projetos.

O que realmente o usuário irá ganhar com isto? Vale realmente a pena para manutenção?

Redesenvolver o projeto exige primeiro, revisar a documentação.

 
Cuidado com preferência pessoais sobre linguagens de programação. Elas podem definir

erroneamente a tecnologia baseada em algo que a equipe conhece hoje, mas pode

ser um falsa realidade de mercado.

Lembre-se que mesmo que a proposta técnica tenha uma visão, a gerencia pode optar

por outra solução levando em consideração uma estratégia.

Conflitos 


Não imponha a nova tecnologia, construa junto a solução com a equipe que vai dar

a manutenção no projeto. Claro que a palavra final é da gerência. Mas não perca

tempo sugerindo N soluções, já tenha as preferidas com seus prós e contras.

É preciso ganhar o respeito da equipe que irá assumir a tecnologia, se eles não comparem

a ideia, irão rejeitar a solução e mesmo sendo um boa ideia, não será implantada.

O importante é que a equipe que irá assumir a tecnologia comece a especializar no

assunto por si própria. Isto só ocorre se os membros da equipe estão motivados no assunto

e se o tema “mobile´faz parte também dos seus objetivos pessoais. Se não, irão fazer

o básico e ficarão na posição de CLT faço minhas 8 horas e só.
Crie uma motivação, uma página de créditos no about do App, easter eggs, que valorize a posição que eles tem. Você pode fazer nada em 8 horas, ou fazer muitas coisas em 8 horas. 

Não faça as atividades de implantação pela equipe que irá assumira tecnologia, é

necessário que eles entendam que precisam caminhar por suas próprias pernas. Chega

ser um pouco contraditório, pois se o seu trabalho de tecnologia não for usado na implantação

é como não tivesse sentido ser feito

(a não ser que ele tenha apenas fomentado o nicho de tecnologia

que criou). É necessário que a equipe perceba que o você tem pronto é realmente útil

para criar aquela área, e não algo imposto. Faça com que eles criem soluções, pois assim

serão responsáveis por elas também.

 
Divisão de Tarefas

  
Como dividir tarefas antecipadamente em algo que você nem conhece?

Trabalhar em 2, 3, pode ser um problema.

O ideal é apenas um assumir a parte técnica e ir delegando atividades que

precise de ajuda. Isto ocorre por que os projeto mobile são altamente acoplados e

cheio de dependências, de difícil depuração. As atividades são técnicas e não conceituais

como na maioria dos sistemas O.O. Você é um programador de API, e sempre

precisará conhecer os detalhes de utilização.


Normalmente também trabalhará com o conceito de decoração de funcionalidades. Isto

ao implementar um BroadCastReceiver, deverá fazer com que todas as telas conheçam ele.


Delegar tarefas não é eximir das suas responsabilidades, se algo der errado, cabe ao

programador principal corrigir rapidamente pois é ele que tem a visão geral do sistema.


Liderança 

Muito marketing está associado a novas tecnologias, mas o que se lê não é sempre

verdadeiro. Para separar o joio do trigo é necessário testar e ver se a solução se aplica

a sua realidade. A Empresa pode ter uma realidade diferente de empresas de consultoria

e multinacionais. Outro ponto é que aquilo que funciona bem para “você” não funciona bem

para quem vai assumir a tecnologia. Leve sempre em consideração os recursos humanos

e as habilidades que a equipe já tem. Não descarte a possibilidade que elas podem também

ser treinadas para novas tecnologias sozinhas Ex: Objective-C iOS.

O papel do líder é natural, não formal, geralmente parte daquele que vai resolver

o problema tecnicamente e sabe os detalhes da implementação, pois este é o primeiro

a ser convencido quando se escolhe uma nova plataforma. Claro que um desenvolvedor não

decide o que fazer, mas decide como fazer. Ao invés de promover acirradas competições

técnicas sobre o o uso de ferramentas, melhores práticas, utilize a equipe técnica

para construir juntos uma solução (fazendo). Que vai ser preenchida com certeza,

mas dificilmente lida, pois as técnicas já estarão internalizadas.



 
Informações Gerenciais

 
Não confunda a gerência com jargões técnicos e discussões técnicas. Promova estes

debates antes de ir a gerência. Lotar a gerência com informações técnica é trazer

informações desnecessárias para a pauta da reunião. Jogue limpo, se reúna com

o corpo técnico repasse a apresentação entre a equipe ex: Mobile e Tecnologia

acerte os pontos e leve algo decisório para gerência. Claro, se a gerência quiser entrar

em detalhes, ai sim você aborta os pontos técnicos.


Faça com que a gerência decida. O papel em propor soluções é diferente do papel de

impor soluções, chegue munido de mais de 1 solução. Aqui a imparcialidade é vital.

Exponha os prós e contras, e caso seja requisitado, exponha o voto de todos os envolvidos.

Pois corre se o risco de algo ser escolhido, e ser um fracasso de implantação.

O segredo está nos detalhes. Quanto mais informação você tiver para ajudar a orientar na

escolha melhor.

A apresentação não pode ser surpresa para ninguém, você deverá ter repassada ela varias

vezes de forma colaborativa para enriquecê-la e principalmente alinhas as expectativas.



 iOS

O fato dos envolvidos não terem experiência com o iOS/OSX e  pela falta de equipamento

para desenvolver esta habilidades, fez com que fosse inviável a criação do POC.


Estudar apenas pela documentação é algo perigo, pois muito Marketing está associado

as soluções desta plataforma.


Assim que a Empresa comprar os equipamentos com MAC OS, deverá ser refeito o POC

do Sistema para deixar código legado e explorar o padrões técnicos.
Com o Xamarim Form fizemos o POC, básico e estamos testando as soluções.

Na prática


 
Antes de algo ser definido,  uma demanda para o redesenvolvimento do software

Android foi solicitada a recém criada a equipe Mobile, só que tivemos que fazer para iOS também.


Uma tarefa árdua, para os membros que não passaram por um estágio inicial de desenvolver

seu primeiro aplicativo. Nossa recomendação foi o não redesenvolvimento, e sim manter

o software atual, com pequenas melhorias internas. Idéia vetada, o redesenvolvimento

ficou decidido.


Para auxiliar a equipe, produzimos algumas documentações do projeto POC

, explicando os padrões para que o mesmos fossem orientados a seguir o mesmo

 padrão no redesenvolvimento do App, mostrando as vantagens que obtivemos

no produto final.


Agora estamos monitorando o primeiro projeto App Cross Mobile, e torcendo para que a equipe

encontre as soluções por si só, e não crie um vinculo desnecessário de consultoria e suporte

que será insuficiente para atingir suas demandas.


Devemos lembrar que o App irá ser redesenvolvido só para Android e iOS,

Acreditamos que esta plataforma ainda é algo que precisamos

melhor explorar para atingir no futuro, pois está sempre fora do nosso alcance construir

um produto para ela.

"Só adianto que é meio difícil fazer uma análise
sem acesso ao software: o site que apresenta e vende o produto só irá
falar bem dele. Quem tem de listar os pontos fracos são os usuários."








 
Postar um comentário