As Crônicas da Ilha Perdida – Parte II

Os jovens, ao retornarem da sua viagem duradoura, resolveram usar seus conhecimentos e abriram uma empresa na área de TI. Não vou falar de todos os jovens, mas queria ater as nossas atenções para dois amigos: Lucio e Sandro.
Todos achavam que o Lúcio dava para um excelente administrador. Ele ainda ficou um tempo na administração da empresa. Dizia sempre:
- Galera, temos que zelar pelo profissionalismo da gente. Vamos produzir software com qualidade. Vamos fazer o melhor para sermos reconhecidos como uma grande empresa de Desenvolvimento de Sistemas.
Já o Sandro era um excelente técnico. Aprendia rápido as coisas. E produzia muito também.
Mas, Lucio cansou da administração. Ele via seus amigos aprendendo novas coisas e queria estar alí com eles. Mas o que mais o desmotivava-o em relação a administração é que ele sempre falava as coisas, dava palpites, e ninguém o ouvia. O sonho que ele tinha de tornar a empresa dele em um marco para empresas de TI estava desmoronando. Os demais sócios não pensavam o mesmo que ele, e começaram a voltar o seu foco para projetos sociais.
Lucio não era contra projetos sociais. Ele era contra ser dependentes de esmolas. Ele pensava:
- Não quero ser reconhecido com uma ONG, quero ser reconhecido com uma empresa de TI.
Ele ainda conversou com alguns sócios, mas todos achavam que tava tudo bem, pois afinal, o Mago nao falava nada contra isso. Pra ser sincera com você leitor, foi o Mago quem teve essa idéia.
- Lucio, você está contra a palavra do Grande Mago?
- Não, só tô dizendo que primeiro a gente tem que ter dinheiro para pagar as contas, funcionários e os demais sócios. O social é consequência, pois se temos funcionários e sócios satisfeitos, teremos condições melhores para fazer o social, você não acha?
- É, mas esse é o sonho do Grande Mago!
- Eu entendo, mas infelizmente não é o meu.
Ele resolveu sair da administração e passou a ser técnico.

Devido a sua personalidade e caracter, resolveram coloca-lo como diretor do setor de software. Ele aceitou: “Essa é a minha vez de fazer isso valer a pena!”.

 

Software Livre no Pirambu

 

Cadê os posts

Para aqueles que sempre dão umas olhadas  no meu blog: galera, estou sem postar nada, pois estou a estudar para a certificação.

Mas depois que eu fizer a prova terei muitas novidades!!!

Aguardem.

 

Modificadores de Acesso – Java

Tive uma aula de programação OO essa quarta-feira. Meu professor foi falar sobre encapsulamento e meia volta, ele tinha que falar sobre os modificadores de acesso. Ele falou dos modificadores private e public corretamente, mas ao falar do protected e default ele explicou de uma forma diferente do que eu aprendi com os livros.
Então baseado nisso, resolvi postar algo para aqueles que tem dúvida quanto aos modificadores de acesso em Java.
Existem 3 modificadores de acesso, mas existem 4 níveis de acesso.
Os 3 modificadores são: private, public e protected.
Os 4 níveis de acesso são: private, public, protected e default.
Vamos começar pelo nível private. Quando vc define algum membro da classe com o modificador private vc quer dizer que aquele membro só poderá ser acessado pela classe que o contém.
Agora o public é o contrário do private. Ao marcar um membro com o modificador public, você quer dizer que ele pode ser acessado por qualquer classe. (Acesso este tanto por meio de uma instancia de uma classe, quanto por herança.)
Agora o mais complicado é entender o protected e default!
Primeiro: quando voce quiser marcar algum membro com o nível default, você não usa nenhum marcador para isso.
Segundo: protected e default tem o mesmo nivel de acesso, ou seja, a nível de pacote, com uma única diferença: posso acessar membros protegidos de uma classe em outro pacote somente por herança.
Vou dar um exemplo:
Tenho uma classe TestePai dentro de um pacote A. Tenho uma classe TesteFilho dentro do pacote B. Tenho uma classe TesteSolto dentro do pacote A.
A classe TestePai possui um membro protegido chamado nome do tipo String.
A classe TesteFilho herda a classe TestePai. A classe TesteFilho por herança acabará possuindo esse atributo nome. Se a classe TesteFilho possuir outras classes filhas, essas classes filhas herdarão esse atributo nome.
A classe TesteSolto está no mesmo pacote da classe TestePai.
Se você instanciar um objeto da classe TestePai, você poderá acessar ao atributo nome, pois eles sao do mesmo pacote.
Entendeu?
Então, resumindo: protected e padrão tem o mesmo nível de acesso, que é a nível de pacote. A diferença entre um e outro é que classes de outros pacotes só poderão acessar aquele membro protegido por meio de herança.

Fiz um código ilustrando isso:

 

Papéis no Scrum

Assim como qualquer outra metodologia é baseada em papéis e responsabilidades, porém, os papéis do SCRUM são bem abrangentes e direcionados para um propósito comum: O SUCESSO DO PROJETO.

Os papéis são:

• Product Owner: Pode ser o financiador ou um importante interessado no projeto. Suas principais responsabilidades são: define as funcionalidades do produto; concentra as informações vindas de usuários, stakeholders ou do mercado de maneira que se obtenha uma visão única dos requisitos do sistema; sua maior responsabilidade é ROI do projeto; prioriza o Product Backlog; pode alterar as prioridades fora do Sprint; aceita ou rejeita os resultados dos trabalhos.
• O Time (Team): O Time é mais bem definido como um grupo de pessoas do que um papel. É o grupo de pessoas diretamente ligadas ao trabalho a ser feito que garantirá que o projeto seja entregue com todas as funcionalidades necessárias. Suas características são: multi-funcional; formado por 7 pessoas; define o objetivo do Sprint e especifica os resultados dos trabalhos; faz aquilo que é necessário dentro das diretrizes do projeto para alcançar o objetivo do Sprint; auto-organizável; demonstram o resultado do Sprint para o Product Owner e outros Stakeholders. O time deve ter a capacidade e o conhecimento técnico sobre todo o processo de desenvolvimento do produto. No desenvolvimento de software, o time deve ter pessoas capazes de analisar a solução, codifica-la e testa-la sem necessitar de outros times ou outras pessoas.
• SCRUM Master: Desempenha um papel de liderança, gerenciando os interesses do Product Owner mediante o Time. Numa abordagem tradicional de gerenciamento de projetos, o SCRUM Master seria um Gerente de Projetos, porém, essa nomenclatura foi substituída para diferenciar o foco de liderança necessário par que um processo empírico funcione. Um SCRUM Master eficiente deve: melhorar a vida e a produtividade do time de desenvolvimento promovendo a criatividade e o conhecimento; estimular uma comunicação e cooperação muito próxima entre todas as pessoas do time; proteger o time de interferências externas; remover Impedimentos (Impediments); garantir que o processo seja respeitado; convidar pessoas apropriadas para as reuniões de acompanhamento (Daily SCRUM, Sprint Rewiew e Sprint Retrospective); remover barreiras entre o desenvolvimento e o cliente par agarantir que realmente é o cliente que está direcionando as funcionalidades desenvolvidas; auxilia o Product Owner a maximizar o ROI atingindo os seus objetivos com o SCRUM; promover práticas de engenharia para que cada pedaço de funcionalidade seja potencialmente implantável.

Além desses três personagens, há também a figura dos pigs e chicken.

Há um site (clique aqui) que explica sobre essa nomenclatura. Em linhas gerais: os pigs são os que estão totalmente comprometidos com o desenvolvimento do produto (no nosso caso software) enquanto que os chickens só estão envolvidos. Se você olhar o site poderá entender melhor.

 

As Crônica da Ilha Perdida – Parte I

Em uma ilha tão, tão distante, havia um povo. Esse povo estudava, trabalhava e tinha muita coisa boa por lá, tipo tecnologia e outras coisas mais. Mas um certo sábio, resolveu fazer algo diferente.
Ele pensou: “Vou mandar alguns jovens da minha Ilha para fora, para eles conhecerem um mundo diferente dessa ilha. Pode ser que alguns voltem, outros não. Mas os que voltarem poderão ser de muita utilidade.”
E assim fez esse sábio. Ele nao escolheu os melhores e nem os mais fracos. Ele nao escolheu aqueles mais lindos e nem os mais feios. Ele simplesmente mandou mensagens via celular, ou e-mail em todos os pontos da ilha, nos bosques, nos lagos, rios e riachos, por entre as pedras e até no mais profundo dos mares que um velho sábio recrutava aqueles que gostariam de conhecer um outro mundo, longe da ilha.
Muitas pessoas foram ao lugar onde morava aquele sábio e ele ficou feliz que muitos desejassem ir, mas ele só poderia levar alguns e nao todos.
Como ele era o grande sábio da ilha, ele pensou: nao poderei levar todos no meu barco para poderem conhecer outros lugares distantes, só poderei levar alguns. O que posso fazer? Já sei, farei um teste básico de resistencia. Lá fora o mundo é cruel, mas só resistem aqueles que se adaptam, então aqueles que conseguirem se adaptar a uma determinada situação, eu levarei comigo.
E assim foi feito.
Depois de uma semana de seleção, o sábio levou alguns jovens para conhecer outros lugares, outros mundos.
Esse período durou mais ou menos dois anos. Nesses outros lugares, esses jovens aprenderam sobre tecnologia, gerencia e pensavam: Ao concluir essa viagem, poderei morar em outros lugares mais distantes daquela ilha maldita. Mas outros nao sabiam o que fazer. Enquanto que outros só pensavam em voltar para a casa.
Então o sábio resolveu fazer uma pequena vídeo-conferencia com seus jovens.
- Olá meus jovens. Tenho notícias a dar sobre a nossa ilha.
- Olá sábio, como você está?
- Bem, mas queria ter com voces pessoalmente, mas nao dá. Infelizmente ainda nao conseguiram inventar um aparelho que fizesse teletransporte. Mas deixa eu dizer o que realmente me interessa: A viagem de vocês a esse mundo desconhecido está para se findar e tenho uma missão para vos dar.
- Missão? Que tipo de missão? – perguntaram os jovens se entreolhando.
- Bom, vocês sabem que aqui na nossa ilha existe muita coisa boa e sei que vocês aprenderam muita coisa boa também, entao a missão é: vocês aplicarem o que conheceram neste mundo aonde voces estão aqui na ilha.
Os jovens acharam uma boa idéia e começaram a se reunir e discutir sobre o assunto.
Depois de muita discussão, e com a ajuda do sábio, os jovens pensaram em montar uma organização de produção de sistemas computacionais (em outras palavras, empresa de produçao de software).
E a aventura continua…

 

Uma idéia, uma tentativa que nao sei se será de sucesso!

Depois do grande sucesso das Crônicas de Nárnia (C. S. Lewis) e devido a alguns problemas organizacionais do qual eu estou passando, resolvi escrever as Cronicas da Ilha Perdida.
Por meio dela, conto alguns problemas que aconteceram na ilha, mas problemas semelhantes com o ambiente de trabalho em uma empresa de TI.
Espero que o meu lado criativo flua, mas que por meio deste eu venha ajudar alguns com problemas organizacionais.

As Crônicas da Ilha Perdida – Parte I

 

Férias!!!

Kramba!!! Semana q vem já começará as minhas aulas. Semestre q  vem na faculdade vai ser muito legal!

Na faculdade terei as cadeiras de Análise OO, Programação OO, Banco de Dados -  Modelagem, Teoria Geral de Sistemas e Projeto Integrado – Sistema OO.

Vai ser muito legal.

 

SCRUM – Introdução

Já fazia um bom tempo que eu havia prometido algo falando sobre SCRUM. Então lá vai!

O SCRUM é um processo ágil e leve que pode ser utilizado para gerenciar e controlar o desenvolvimento de software utilizando práticas iterativas e incrementais. É uma metodologia ágil. Eis alguns valores do MANIFESTO ÁGIL:
1.    Pessoas e iterações são mais importantes que processos e ferramentas;

2.    Software funcionando é mais importante que uma documentação extensa;

3.    O relacionamento com o cliente é mais importante que a negociação do contrato;

4.    Responder às mudanças é mais importante que seguir o planejamento;

Processos e ferramentas são importantes, mas muito mais que isso, pessoas e iterações são mais importantes. É importante ter uma excelente documentação, mas muito mais importante é o software funcionando. É importante a negociação do contrato, mas muito mais importante é o relacionamento com o cliente. É importante seguir o que foi planejado, mas muito mais importante é responder às mudanças.

O SCRUM aumenta significativamente a produtividade e reduz o tempo para obter resultados, pois facilita a adaptação a processos empíricos de desenvolvimento de sistemas.

Foi adotado como ferramenta padrão de gerencia de projetos nas metodologias MSF do Agile e OpenUP e atende aos padrões CMMI e PMBOK.

Mas… Porque seguir essa metodologia para gerenciar o desenvolvimento de sistemas?

Imagine a construção de uma ponte. Primeiro é feito todo o planejamento da construção, depois é feita a engenharia e depois é passado para construção definitiva da mesma. A cada passo que você avança no ciclo MENOR é a sua incerteza, pois você pode avaliar aquele passo como válido.

Embora para desenvolvimento de software tenhamos os procedimentos de análise, arquitetura, programação, testes, implantação, manutenção; não temos passos verificáveis que possam ser verificáveis como válidos durante o ciclo de vida do software. Você não sabe se aquela captura de requisitos solucionará as necessidades do negócio (o cliente não sabe qual é a sua real necessidade, os analistas são como médicos e os clientes como pacientes). A eleição da arquitetura, o código desenvolvido, os testes efetuados nos geram incertezas. A incerteza só reduz quando o usuário olha a aplicação, mas em determinadas aplicações, a incerteza só reduz depois que ela está em produção a mais de dois anos.

RESUMINDO: DESENVOLVIMENTO DE SOFTWARE = GERENCIAMENTO DE INCERTEZAS

Outro grande problema é a mal definição da palavra Retrabalho no meio do desenvolvimento de sistemas. Temos o costume de dizer se o projeto está em andamento ou não se foram implementadas várias telas ou se já foram feitas várias atividades. Mas o que determina o andamento de um projeto é o cumprimento dos objetivos.

Então, no desenvolvimento de sistemas, quando o cliente diz que quer uma nova funcionalidade ou quer mexer em algo já implementado, temos o costume de dizer que isso é um retrabalho, mas no processo ágil não existe retrabalho, pois SOFTWARE = IDÉIA. As idéias são coisas que amadurecem.

Então o SCRUM é uma das maneiras empíricas de se controlar o gerenciamento da produção de um software baseado em alta produtividade e satisfação dos envolvidos.

 

Promoção: Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso e concorra a um Eee PC!

Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!
…e também a pen drives, card drives, camisetas geeks, livros e mais! O BR-Linux e o Efetividade lançaram uma campanha para ajudar a Wikimedia Foundation e outros mantenedores de projetos que usamos no dia-a-dia on-line. Se você puder doar diretamente, ou contribuir de outra forma, são sempre melhores opções. Mas se não puder, veja as regras da promoção e participe – quanto mais divulgação, maior será a doação do BR-Linux e do Efetividade, e você ainda concorre a diversos brindes!

Ajudem. Pois o Wikipédia é muito bom como meio de pesquisa.