Arquivo da categoria ‘Processos de Software’
Práticas de Processo. Um Processo é uma coleção de práticas ágeis!
A IBM Rational, divisão de software da IBM que cuida da governança do ciclo de vida do desenvolvimento e entrega de softwares, fez o lançamento da nova versão do RMC (Rational Method Composer), um software que permite a criação e publicação de processos em portais Web. A nova versão 7.5 traz como grande novidade o conceito de práticas. Uma prática pode ser entendida como uma abordagem documentada para resolver problemas recorrentes no desenvolvimento de sistemas e possui as seguintes características:
- Uma prática pode ser adotada independentemente de outras práticas. Isso permite uma implementação de processos muito mais facilitada, suportada por pequenas ondas de implementação de um programa de melhoria contínua da maturidade de processsos.
- A adoção de uma prática pode ser medida. Este aspecto traz como raiz os conceitos de BPM, onde qualquer processo implementado deve ser medido para avaliar a sua efetividade.
- Uma prática está alinhada diretamente a uma melhoria no negócio. Novamente, os conceito de BPM estão aqui permeando a concepção do novo processo unificado.
As práticas centrais estão descritas abaixo:
As práticas estão agrupadas nas seguintes categorias:
- Gerência de Requisitos
- Práticas Ágeis
- Gerência de Arquitetura
- Gerência de Qualidade
- Controle de Mudanças e Entregas
- Governança e Regulamentações (Governance and Compliance)
Ao lermos esta documentação, percebemos uma grande dose de humildade ao reconhecer o valor das práticas ágeis. Virtualmente toda prática traz elementos das escolas ágeis. Pragmaticamente, isso é devido à grande influência do Scott Ambler no desenho desta nova arquitetura de processo. Outra forte influência foi o OpenUP, processo ágil baseado no UP e criado originalmente por um brasileiro, o Ricardo Balduíno!
Um ponto (negativo) no novo processo é que o corpo de conhecimento destas práticas ainda está isolado da documentação do RUP 7.0.1, como podemos observar na figura abaixo:
A documentação das práticas traz novos artefatos e tarefas que não estão presentes na outra documentação do RUP. Esperamos que no futuro estes corpos de conhecimentos sejam mesclados para maior simplicidade da leitura do processo.
Em artigos futuros iremos detalhar estas práticas e o seu valor real para o desenvolvimento de projetos de software.
Pensamento do Dia: “Continue Faminto, Continue Tolo”, Steve Jobs.
Scrum It Now - na Prática
A metodologia ágil de gestão de projetos e demandas SCRUM tem se tornado cada vez mais popular e praticada no mercado Brasileiro. Embora este método possa ser implementado em quadro brancos e post-its, ferramentas ágeis podem ser usadas para implementá-lo também. Uma interessante ferramenta lançada este ano, o Rational Team Concert, gratuita para times de até 3 pessoas, possui um suporte completo e personalizável do SCRUM. Li recentemente um excelente paper de como tornar o SCRUM executável, disponível aqui. Este paper discute o uso do Rational Team Concert para implementar o SCRUM na prática.
Para quem ainda não conhece o SCRUM, recomendo um vídeo que recebi recentemente. O vídeo é do Ken Schwabber, um dos seus criadores. Este autor também mantém um excelente blog sobre o SCRUM aqui.
Finalmente, para não banalizar o método, uma entrevista bacana do nosso guru Martin Fowler foi disponibilizada recentemente no InfoQ com informações interessantes sobre como não deturpar esta metodologia
1 comentário »Uma (Excelente) Biblioteca de Engenharia de Software e SOA à Sua Disposição
A Internet nos trouxe as bibliotecas digitais. Bibliotecas digitais são excelentes mecanismos para conhecer novos assuntos, nos aprofundarmos em assuntos já conhecidos ou mesmo aumentar a nossa produtividade enquanto engenheiros de software.
Melhor ainda se a biblioteca digital puder ser usada sem a violação de direitos autorais, fato que infelizmente não ocorre com outras “bibliotecas” de endereço e reputação duvidosa.
Em particular, recorro sempre à um biblioteca de excelente qualidade chamada RedBooks. O RedBooks (http://www.redbooks.ibm.com) é uma biblioteca pública de livros diversos de TI. O download dos livros em formato digital é gratuito e os livros podem eventualmente ser comprados em formato impresso.
O segredo do Redbooks é que esta é uma rede social, i.e., qualquer pessoa com conhecimento técnico suficiente pode se inscrever e participar de um projeto que irá escrever um novo livro. Vários Brasileiros participam ativamente deste processo, inclusive.
Existem vários domínios (assuntos) dentro desta bibliotecas. Destaco três em particular:
- RedBooks para Desenvolvimento de Aplicações.
- Software Rational (Ferramentas para Governança do Desenvolvimento e Entrega de Aplicações)
- Software WebSphere (Ferramentas para Operações de Aplicações e SOA)
A qualidade dos RedBooks, de forma geral, é muito boa. É possível, inclusive, votar na qualidade e criticar os livros, que eventualmente são melhorados ao longo do tempo. Dados de pesquisa da IBM junto a seus clientes mostraram dados interessantes do aumento de produtividade no uso dos RedBooks. Coloco aqui um fragmento desta pesquisa.
Para não perder o hábito de falar sobre SOA, coloco aqui as dezenas de ocorrências que encontrei sobre SOA no RedBooks Online.
- Redbooks de SOA
Uma introdução ao MSF - Microsoft Solutions Framework - e por que ele não conflita com o RUP ou CMMI
O MSF (Microsoft Solutions Framework) tem sido usado pela Microsoft como o seu “método” para desenvolvimento de soluções de software dentro da Microsoft e também para os milhares de clientes e parceiros da Microsoft em todo o mundo.
A disseminação deste método, agora na versão 4.0 no Visual Studio 2005, normalmente induz as pessoas a compará-lo com outros “métodos” da indústria, como o RUP, CMMI ou XP, entre outros. É importante entender, entretanto, o que são estes elementos antes de compará-los.
O MSF, por exemplo, não é um processo de software (de acordo com a própria Microsoft). Ao invés, o MSF é um conjunto de boas práticas provadas em projetos da Microsoft e em seus parceiros e clientes. Por exemplo, a MSF é agnóstica do uso de técnicas de análise essencial ou análise orientada por objetos ou do uso da UML ou outra linguagem de notação. A MSF pode ser rapidamente entendida através de seus oito princípios fundamentais, que são:
- Manter a comunicação aberta.
“Schedule disaster, functional misfits, and system bugs all arise because the left hand doesn’t know what the right hand is doing…. How, then, shall teams communicate with one another? In as many ways as possible.”, Frederick P. Brooks, Jr.
- Trabalhar com uma visão compartilhada.
“Before the project gets rolling, a team needs to buy in to a common vision. Without such a shared vision, high-performance teamwork cannot take place. A study of 75 teams found that in every case in which the team functioned effectively, the team had a clear understanding of its objective.”, Steve McConnell
- Fornecer mais poderes aos membros do time.
“On the best teams, different individuals provide occasional leadership, taking charge in areas where they have particular strengths. No one is the permanent leader, because that person would then cease to be a peer and the team interaction would begin to break down. The structure of a team is a network, not a hierarchy.”, —Tom DeMarco and Timothy Lister
- Estabelecer responsabilidades compartilhadas.
“Each [team] member’s relationship to the team must be defined in terms of the role to be assumed and the results the role is to produce. Eventually, any team effort boils down to the assumption of individual responsibilities and accountabilities.”, Carl Larson and Frank LaFasto
- Focar na entrega de valor no negócio.
“Experience had taught Thomas Edison to combine commercial and technical considerations. The ‘electric vote recorder,’ the first invention for which Edison received a patent, tallied votes quickly and was intended for use within legislatures. But when he approached a congressional committee about sales, the committee chairman told him, ‘Young man, that is just what we do not want.” (It would infringe on the sacred institution of the filibuster.) His machine was never produced, and he resolved not to devote his attention to the invention of anything
that lacked ‘commercial demand.’”, Randall E. Stross - Manter a agilidade e esperar mudanças.
“Agile managers understand that demanding certainty in the face of uncertainty is dysfunctional. They set goals and constraints that provide boundaries within which creativity and innovation can flourish.”, Jim Highsmith.
- Focar em qualidade continuamente.
“Quality improvement is a never-ending journey. There is no such thing as a top-quality product or service. All quality is relative. Each day, each product or service is getting relatively better or relatively worse, but it never stands still.”, Tom Peters.
- Aprender com a experiências passadas
“Those who do not remember the past are condemned to repeat it.”, George Santayana
Estes princípios são universais e podem sem dúvidas ser aplicados ao RUP, CMMI, XP, PSP ou qualquer outro modelo.
O MSF conta hoje com duas personalizações; o MSF Agile (para projetos com menos rigor de processo) e o MSF CMMI (para empresas aderentes à praticas do CMMI).
O MSF ainda apresenta na sua estrutura os seguintes conceitos:
- Modelo de Times - Uma estrutura de papéis e as suas responsabilidades dentro de um projeto. O MSF define seis papéis centrais em uma estrutura de rede (não hierárquica!): Gerente de Produto, Gerente de Projeto, Desenvolvedor, Testador, Gerente de Implantação, Gerente de Usabilidade e Eficiência de Usuários.
- Modelo de Processos - Uma estrutura de organização de atividades nos ciclos de vida de um projeto
- Disciplina de Gerência de Riscos.
- Disciplina de Gerência de Projetos
- Disciplina de Gerência de “Readiness” (Foco no reuso de conhecimento e habilidades para prover soluções de software).
A estrutura de times do MSF, o modelo de processo e suas disciplinas são descritos nos documentos oficiais da Microsoft sempre como um conjunto de boas práticas, guias de orientação e aplicação e não como um processo prescritivo e dogmático de software. Dito isto, podemos definir e comparar o MSF, RUP e CMMI brevemente.
- MSF: Conjunto de boas práticas para desenvolvimento de software.
- RUP: Framework de processo de software.
- CMMI-Dev: Modelo de avaliação de maturidade no desenvolvimento de software.
Um comparação sobre o MSF e RUP pode ser encontrada no artigo a seguir daRational Edge - MSF and RUP.
Mais informações sobre o MSF podem ser encontradas no site oficial do MSF da Microsoft, disponível aqui.
2 comentários »PSP (Personal Software Planning) com o Eclipse - Parte 0: PSP para Leigos!
O PSP (Personal Software Planning) é uma disciplina (ou método de trabalho) que permite que desenvolvedores se tornem altamente eficientes. Independente se o seu time ou organização tenham já um processo definido (ex: RUP, Cascata, XP) ou ainda não tenham um processo definido (ex: Conserta e Remenda), o grande benefício do PSP é permitir que indivíduos melhorem continuamente em suas práticas de desenvolvimento de software.
Conceitualmente, o PSP foi derivado a partir das áreas de processos do CMM/ e adequados para o trabalho individual com eficiência e a premissa de pouca burocracia.
Os benefícios primários do PSP para cada pessoa são:
No método PSP, cada pessoa:
Quando fui apresentado ao PSP, em 1995, comecei a praticá-lo experimentalmente em um projeto de mercado. Infelizmente, percebi que me faltavam ferramentas adequadas para exercitá-lo. Naquele tempo, usava formulários extraídos do livro chave do PSP (Watts S. Humphrey, A Discipline for Software Engineering. Addison-Wesley, 1995, ISBN 0201546108), mas a forma de preecher os dados era tediosa e a análise nestes dados ainda mais demorada. A consequência é que nunca consegui atingir níveis maiores de maturidade PSP. (Cada pessoa que pratica o PSP pode estar nos níveis de maturidade 1 a 5). A premissa de pouca burocracia, em 1995, não foi verdadeira na minha experiência.
Estamos em 2006, felizmente. Nestes onze anos houve muita melhoria em TI e nas ferramenas de apoio a processo de software. O Eclipse, em particular, possui hoje plugins que permitem que as práticas de medição do PSP sejam realizadas com nenhuma ou pouquíssima burocracia.
Compilo aqui de pequenos artigos onde descrevo como implementar o PSP com plugins para o Eclipse e em particular com ênfase para o plugin Mylar.
Artigos:
Recomendo, entretanto, que o leitor entenda os princípios centrais do PSP com mais calma antes de prosseguir para os artigos específicos. Uma literatura introdutória sobre o PSP pode ser encontrada aqui.
(*) Nota: Os links para estes artigos serão colocados nos próximos dias…
2 comentários »Melhores Práticas para Implantação de Processos de Software - Palestra para o III SMSI
O terceiro SMSI (Simpósio Mineiro de Sistemas de Informação) foi organizado pela PUC-Minas em Setembro de 2006, com valiosas discussões sobre engenharia de software e apresentação de cases e tecnologias pertinentes a sistemas de informação. Dentro deste evento, tive a oportunidade de apresentar uma palestra sobre implantação de processos de software, onde discutimos práticas e anti-práticas para implantação de processos. O PDF da apresentação se encontra em anexo aqui para download.
Sem comentários »Processos de Software Devem ser Simples!
A imagem tradicional sobre processos de software é que eles são burocráticos, pesados e só aplicáveis em empresas paquidérmicas. Contrariamente, processos devem ser simples e ajustados como uma roupa feita sob medida em um alfaiate. Observo que a maioria dos projetos do nosso mercado são pequenos (< 1000 horas) e realizados por poucas pessoas (entre 3 e 6 pessoas) e que a maioria dos exemplos colocados em livros, artigos e consultorias são inadequados à estas realidades. Esta dicotomia gera uma sensação de frustração dos leitores destes livros, incapacidade de tangibilizar estes conceitos em suas realidades e consequente volta ao mundo real em processos conserta e remenda.
Mesmo processos como o IBM RUP, por exemplo, podem (e devem) ser adequados sem problemas a projetos de pequeno porte. Infelizmente isso requer expertise em engenharia de processos de software. Uma alternativa a isso é o Open UP-Basic Version (Basic Unified Process), parte do esforço de conhecimento livre compartilhado pela Rational ao projeto Eclipse Beacon. O BUP pode ser entendido como uma personalização muito simples do RUP, ajustado para projetos de pequeno porte e times pequenos co-locados fisicamente.
Recomendo o artigo em anexo acima para desmitificar a visão clássica de processos e melhorar a qualidade dos pequenos projetos, infelizmente carentes de métodos e processos de qualidade.
O projeto Beacon, conhecido oficialmente como Eclipse Process Framework Process, nasceu da doação de parte do IBM RUP (Rational Unified Process), processo unificado da Rational. Este projeto ainda está em fase embrionária, mas já oferta boas idéias e produtos de custo de aquisição zero para quem quer melhorar a qualidade de seus projetos . Sem comentários »
Ferramentas Freeware
É possivel hoje realizar o desenvolvimento de software com bastante qualidade e auxílio de ferramentas livres de custo de aquisição. Estas ferramentas, em sua grande maioria, não fornecem toda a robustez e funcionalidades de ferramentas de ciclos de desenvolvimento de software de fornecedores como IBM, Microsoft, Borland e Oracle, mas são um excelente ponto de início e aclimatação em boas práticas de engenharia de software.
A lista seguinte apresenta algumas ferramentas sem custo de licença que podem apoiar neste processo.
É importante lembrar, entretanto, que uma ferramenta freeware não é uma ferramenta sem custo, pois o modelo mental de cada ferramenta exige capacitação, treinamento e personalizações na realidade de cada empresa.
1 comentário »