Arquivo

Archive for junho \30\UTC 2011

30/06/2011 1 comentário

Olá pessoal.
Hoje escrevo sobre uma ferramenta que comecei a utilizar na atual empresa onde estou trabalhando. É a AWS (Amazon Web Services).  De cara já dá para perceber que é um serviço totalmente voltado para a nuvem (Cloud Computing).

O que achei muito interessante e estou mexendo atualmente é a criação de máquinas virtuais (VMs). Eles já tem inúmeros templates com Linux, Red Hat, Windows, banco de dados, aplicações, etc. e templates que você pode procurar online. A configurações são inúmeras, como por exemplo Subnets, Route Tables, Internet Gateway, DHCP, Elastic IPs, Security Groups, Cluster, …

O serviço é cobrado por utilização (assim como energia elétrica… hehehe… ) então se você deixar as VMs desligadas, não paga nada. A documentação é muito boa e ajuda até os mais leigos na configuração de rede (tem me ajudado bastante).

Além disso existe todo um controle de CloudWatch que monitora as suas máquinas virtuais e sua rede na nuvem, analisando processadores, volume de acesso, rede, etc. Uma configuração pró-ativa pode, por exemplo, colocar mais memória em uma máquina caso ela esteja no limite de utilização.

Existem SDKs para as mais conhecidas linguagens de programação para integração com seus sistemas. Informações podem ser encontradas na “Developer Center”.

Características gerais sobre os serviços podem ser encontrados em http://aws.amazon.com/what-is-aws/

Anúncios

scrumy.com

27/06/2011 4 comentários

Para quem não conhece o SCRUM, existe uma forma muito prática de controlar o andamento de um projeto, através do chamado “Dashboard”. Nada mais é do que você colocar as fases de um projeto em colunas (To Do, In Progress, Verify and Done) e escrever em “post-its” todas as tarefas (PBIs ou Product Backlog Itens)  desse projeto. A medida que o trabalho vai sendo desenvolvido, os “post-its” vão mudando de fases.

Já baixei vários DashBoards interessantes na internet, mas agora que comecei a trabalhar com o scumy.com, minha vida mudou… hehehe… Você pode criar User Stories, Tasks, PBIs, Bugs, Sprints, etc. Não é nenhum software sensacional, mas muito bom para controlar o andamento de um projeto, ainda mais quando as equipes trabalham fisicamente separadas. Vale a dica!!!

Categorias:Dicas, Ferramentas, Scrum

Log Parser 2.2

Olá pessoal.
Estou trabalhando em um projeto aonde precisamos fazer um teste de performance em cima da navegação atual do site. Para isso pegamos o log do IIS de um dia de navegação de um dos servidores. Então começou a pesquisa de como ler o arquivo e utilizá-lo no projeto.

A forma mais simples que encontramos foi utilizando o Log Parser 2.2. É uma ferramenta não homologada da miscrosft que lê o arquivo .log do IIS e transfere as informações para outra base de dados (XML, CSV, SQL, …).
No meu caso, como o site é desenvolvido em .net e pretendemos utilizar o próprio Visual Studio para o teste de performance, passamos os dados pra uma base de dados SQL. Sofri um pouco com a sintaxe do comando, mas no fim deu certo!

Abaixo segue  dois links com dicas de como utilizar a ferramenta:

Categorias:Dicas

Organizing a Scrum Team

O segundo capítulo do livro “Professional Scrum with Team Foundation 2010” trata de como organizar e qual o papel de cada profissional dentro de a equipe.  São eles:

    • Product owner – responsável por determinar as características / módulos do sistema e como deve funcionar
    • ScrumMaster – gerente de projeto, coordenador, responsável pela produtividade, entregas, comunicação.
      As duas principais tarefas dele é certificar-se da produtividade da equipe e dar feedback através dos release.
      Tarefas: fazer as reuniões diárias, envolver as pessoas necessárias, forçar a comunicação, determinar o tamanho do time.
    • TeamMembers – responsáveis por desenvolver/testar o sistema

    O capítulo comenta bastante sobre com coordenar o “Daily Scrum” todos os dias. A reunião diária deve ser para aquecer a equipe e forçar todos a lembrar o que está sendo desenvolvido, porque, e para que. Nesse momento cada profissional do time deve falar. Isso força o próprio desenvolvedor a se concentrar no que está fazendo e quais as suas atividades para aquele dia. O ScrumMaster deve organizar qualquer trabalho que esteja travando o desenvolvimento de alguma tarefa. Questões técnicas podem ser resolvidas na própria reunião ou durante o dia em conversar com os desenvolvedores. Questões de escopo, dúvidas de regras de negócio devem ser tratadas pelo ScrumMaster. Não que ele tenha que saber responder todas as questões, mas é responsável por correr atrás da solução, procurar o Product owner para discussões, etc.

Especificar e priorizar características a serem desenvolvidas são um trabalho do product owner. Ele escreve o que é chamado de “User Stories”, que são pequenas descrições das funcionalidades que o produto precisa ter. Internamente a equipe cria os products backlog itens (PBIs) que são pequenas tarefas a serem desenvolvidas.
Fala-se sobre a “Prioridade das tarefas” vs “Valor de negócio (Business Value) vs Esforço”. A prioridade das tarefas é diferente do valor de negócio. Uma tarefa pode ser imprescindível, mas só pode ser desenvolvida nos últimos sprints pois depende de outras tarefas. E também é diferente da dificuldade e esforço necessário para entregar cada uma das tarefas.

Uma coisa que achei bem interessante e que gera bastante discussão é como é organizada uma equipe com Scrum. Normalmente são equipes pequenas, com poucos desenvolvedores, 1 ScrumMaster e 1 Product Owner. Mas isso não é uma regra. Podem existir mais de 1 Product Owner na equipe, cada um com uma responsabilidade. Por exemplo, um responsável pela área de Marketing e outro na área Comercial.
Em grandes projetos, pode-se criar várias pequenas equipes (que contém 1 ScrumMaster, 1 Prodcut Owner e os membros da equipe). A melhor forma de separar em várias equipes segue a seguintes prioridades:

    • Separar por característica
      • Vantagem: Reduz a dependência entre outros times, foca em desenvolver as características do projeto, promove aceitação de testes.
      • Desvantagens: Solução da arquitetura e design podem se perder durante o processo, aumentando o custo de suporte e cada time precisa “reinventar a roda”
    • Separar por preocupações transversais(Ex: um time cuida do desenvolvimento do cache de objetos, outro da segurança do sistema):
      • Vantagens: Reduz o custo e aumenta a qualidade técnica do projeto, promove arquitetura consistente das features.
      • Desvantagens: Não é uma divisão boa para o cliente, time não consegue visualizar o escopo geral do projeto, necessita definir a interface primeiro, mudanças são custosas.
    • Separar por tecnologia
      • Vantagens: Maximiza habilidade do especialista/desenvolvedor, promove testes unitários dentro de cada tecnologia.
      • Desvantagens: Aumenta a dependência entre as equipes, ninguém é responsável pelas entregas de funcionalidades, cada equipe está focada em entregar a sua parte, mas não presta atenção na complexidade técnica do produto.

Depois de toda essa separação em várias equipes, é necessário organizar a comunicação entre elas na “Scrum of Scrum Meeting”. É uma reunião aonde podem participar um membro de cada equipe que tenha capacidade de dar o feedback sobre o andamento das atividades. Não necessariamente precisa ser o ScrumMaster.

Quando existem várias equipes, cada uma delas tem seus próprios sprints. Mas lembrando que normalmente ela depende de trabalhos e entregas de outras equipes, então o trabalho precisa ser muito bem coordenado. Uma coisa que o capítulo não comentou é como organizar para que isso ocorra sem maiores problemas. E o mais importante… como gerar Releases entregáveis para o Product Owner??? Essa é uma boa discussão, não!?

Então existe uma grande comparação entre os papéis/responsabilidades entre SCRUM e MSF. Em resumo, como é possível perceber, o SCRUM tem equipes menores e existe mais responsabilidade. Ou seja, é necessária uma equipe com mais conhecimento. O MSF tem responsabilidades bem definidas e separadas, aonde existe uma equipe de testes/QA, o papel do Gerente de Projeto se compara ao PMI. Não vou entrar em detalhes, mas as comparações no livro são muito bem organizadas.

Trechos do livro que grifei:

“The ScrumMaster has two primary responsibilities: ensure team productivity and tracking  Project status through release. These are not easy task, but when treated as top-line job  responsibilities, they are quite achievable.”

“The product owner is responsible for ensuring that product features meet customer expectations. The product owner can be a leader in the user community, someone from marketing, a business analyst with the IT arena, or any other individual who can effectively communicated business needs.”

“The primary responsibility of the team members is to build the product. They determines the architecture, component design, and user experience. They work within boundaries of time and coast and are empowered to make trade-offs to build the best possible product within those limits. Both development and testing occur within the team. Because is no separate QA group, the team members are both empowered and responsible for their own testing.”

“Four resources are required to ship great software: time, money, people an technology.”

“The architect role, regardless of project management methodology , is to manage the complexity of component parts of the system. Developers write the code, but the architect must be able to see the forest for the trees. ”

 Abaixo achei uma charge sobre equipes de SCRUM… hehehe..

Categorias:Scrum

VSTS Cube

A algum tempo atrás eu tive problemas na geração de relatórios com VSTS. Gerei builds e eles não apreciam nos relatórios!
O VSTS trabalha em um formato de BI (Cubo) e é necessário analisar inúmeras questões. No link abaixo consegui achar a solução para o problema, então acho interessante documentar. É trabalhoso mas resolveu!

http://social.msdn.microsoft.com/Forums/en-US/tfsreporting/thread/9cfe51fd-10a0-4076-ab4c-6c844cd8c592/

Mude suas Palavras, Mude seu Mundo

Um curto filme que ilustra o poder das palavras e a mudança radical da sua mensagem e seu efeito sobre o mundo.

 

Categorias:Off-Topic

Scrum – Shipping Software

Como primeiro resumo do capítulo 1, “Shipping Software” do livro “Professional Scrum with Team Foundation Server 2010”, os autores falam sobre o projeto como um todo e como organizar o desenvolvimento com Scrum. Como sou leigo no assunto, acabei discutindo algumas questões com a equipe que atualmente coordeno na empresa.

Scrum é uma metodologia de desenvolvimento de software com processo iterativo, aonde existe um escopo inicial do que deve ser desenvolvido e as entregas são divididas em “sprints” que consequentemente são compostas de novos módulos, melhorias, correção de bugs. Scrum prevê que sempre haverá alterações no escopo do projeto (como acontece na maioria das vezes), e que o projeto vai criando valor no decorrer do seu desenvolvimento.

Scrum é baseado em desenvolvimento Agil (Agile) aonde o objetivo é entregar a maior quantidade de “features” sem perder tanto tempo documentando. A idéia é planejar e executar.

As metodologias MSF (Microsoft Solution FrameWork) e WaterFall são comparadas com Scrum.

Microsoft Solution FrameWork

O MSF é uma metodologia parecida com Scrum, aonde existe iteratividade no desenvolvimento. Ele prega que o projeto pode mudar seu escopo, profissionais, tecnologia depois de iniciado. A ideia é desenvolver vários releases, sendo que cada um deles passa por um processo de visão/escopo, aprovação do plano de projeto, desenvolvimento, validação do release e entrega.

Diferente do Scrum, teoricamente um release não pode ser entregue com Bugs, ou seja, dentro de uma entrega existem várias iterações para que o produto seja entregue com a qualidade esperada.

WaterFall

É o método que vejo ser mais utilizado dentro das empresas e que foi uma das primeiras metodologias a serem especificadas. Acredito até que os profissionais ficam “preso” nessa forma de trabalho.

Essa metodologia prega a necessidade de um grande trabalho de planejamento e documentação (algumas  vezes chamado de blueprint). Prazos são especificados, cronogramas (característica para o Gráfico de Gantt) são desenvolvidos e então se inicia o desenvolvimento. Qualquer alteração de escopo implica em um grande trabalho de gerenciamento de mudança, aonde é necessário analisar documentação, escopo, prazo, custo, risco, comunicação. Dependendo do tamanho do projeto, existe um comitê de mudanças para avaliar a viabilidade das tarefas.

Essa metodologia é indicada para projetos que tem um escopo bem definido, aonde o cliente sabe exatamente como deve ser desenvolvido. Será que existe algum cliente assim? Eu não conheço! 🙂

Vejo que o PMI prega muito essa metodologia, procurando controlar todas as suas áreas para que nada saia do controle

Citações

Sublinhei no livro conceitos que achei importante nesse capítulo e repasso para fortificar esse post.

“The fundamental concept is to put customer value at the center of everything you do. While maximizing customer value, you also maximize your team´s productivity and predictability with each release, create a sustainable team environment for shipping great software.”

“It´s one thing you have great vision; it´s quite another to turn that vision into a great product.”

“The product owner, who fills the product management role in Scrum, is embedded in the Scum team and is counted on to know the user intimately. This person must know the user´s likes and dislikes, tolerances, and aspirations. The product owner  must know what the users love, what they don´t like, and what they don´t care about. Essentially, the product owner´s insight into user needs is essential.”

“Iterative nature – The product features are defined iteratively and frequently. They come in and out of scope based on product owner decisions, whish directly impact the value of the product.”

“For instance, planning a project using a traditional software development methodology involves allocating time for requirement definition, design, development, testing, user acceptance, release management, and support.”

“Because of these unknowns and the fixes constraints in the triangle, you simply cannot offer a fixed-cost commitment for a fixed-feature product. You therefore have two alternatives: Vary the cost or vary the features. If you must deliver a fixed budget, then the answer is simple: Vary de features.”

“The geometry of the project management triangle, with constant angles, dictates the fact that you cannot change just one side of the triangle without adjusting the others. If you increase de features, then you´ll in increase the time and coast lines. If you increase time, then you´ll get more features, but it will cost more. If you want to decrease cost, you´ll spend less time and get fewer features.”

“Scrum is a iterative software development process. In a iterative process, a product undergoes many release, some major and some minor, with each release adding more value to the product. This type of process enable a team do delivery value to the customer early and to get feedback that can be quickly incorporated into future product development.”

Conclusão

Com essa definição do Scrum, eu entrei em um conflito pessoal ( 🙂 ) pois sempre trabalhei fortemente com escopo e prazo. Discutindo com minha equipe a respeito da metodologia, e com profissionais experientes que já trabalharam em vários projetos de muitas empresas eles comentaram:

– Vejo que o Scrum é muito bem aplicado em uma fábrica de software aonde a demanda é pela entrega de um produto específico, melhorias, correção de bugs. O Scrum Master é responsável por visualizar o andamento do projeto e se reportar para o cliente/chefe.

– Scrum não é aplicável, por exemplo, dentro de uma empresa financeira como bancos. Essas empresas tem o perfil de documentar e deixar claro o que deve ser desenvolvido e entregue. Qualquer alteração deve ser documentada e discutida.