Baseado em alguns autores, há uma diferença entre grupos e times. Times devem ser idealmente compostos por menos de dez pessoas.

De acordo com Katzenbach e Smith, em The Discipline of Teams, seis razões porque grandes grupos não são times:

1. grandes grupos não podem facilmente ou freqüentemente reunir-se juntos;
2. grandes grupos são tendenciosos a respeito de reuniões eficientes;
3. grandes grupos são tendenciosos com liderança hierárquica;
4. grandes grupos são tendenciosos para estabilidade de papéis;
5. grandes grupos geralmente falham para ter entendimento e comprometimento comum;
6. grandes grupos geralmente dividem-se para criar pequenos times.

Queria apenas desvendar dois mitos que ouço falar muito. O primeiro é que ser ágil é usar iterações. O simples fato de usar iterações não significa que é ágil. Metodologia baseada em iterações foi criada por Boehm muitos anos atrás (não tenho a data certa), sei que foi antes do manifesto ágil.

O segundo mito é que RUP é waterfall. É uma metodologia baseada em iterações, mas só por isto não quer dizer que é ágil.

Interessante ver duas opiniões de dois lados opostos sobre computação em núvem.

Stallman (veja o orinal - em inglês)

“É uma estupidez. É pior do que estupidez: é uma campanha de marketing”

“A razão pela qual você não deveria usar aplicações na internet é que você perde o controle. É simplesmente um mau programa proprietário. Se você utilizar um programa proprietário ou o servidor de alguém, você fica indefensável. Você está colocando nas mãos de outra pessoa o seu trabalho. Use softwares livres respeitados.”

 Larry Ellison (veja o original - em inglês)

“A indústria da computação é a única indústria que é mais guiada por moda que a própria indústria de moda feminina”

“Isso são só rabiscos. Isso é uma insanidade. Quando essa idiotice vai parar?”

Não deixa de ser interessante, apesar de opiniões divergentes.

Palestras sobre Scrum, Kanban e Lean dias 23 e 24 em São Paulo:

http://www.caelum.com.br/falando-em-agile/index.jsp

O objetivo deste blog pode parecer estranho para muitos. Há muita crença que metodologias ágeis consistem em não gerar documentação, ou, se houver alguma, será apenas o mínimo minimorum. Sempre ouço o lema “a documentação é o código”. Por outro lado, arquitetura lembra muitas vezes documentação. Então se uma vertente remonta a não documentação e a outra à documentação, qual a relação entre elas?

Scrum tem a ver com gerência de projetos, não podendo ser confundido com uma metodologia para desenvolvimento de software como XP. Esta comparação é similar a alguém PMI e UML. Ele foi pensado em equipes de até oito pessoas. Ou seja, são projetos relativamente pequenos. Existe uma estimativa que em torno de 83% dos projetos são feitos por equipes de até oito pessoas. Um ótimo exemplo para a documentação ser apenas o código é em projetos feitos com até oito pessoas e sem muita esperança de manutenção - corretiva ou evolutiva.

Para projetos maiores existe o conceito de Scrum Escalável. Nesse tipo de projeto haverá mais papéis além do tradicional - equipe, scrum master e product owner, haverá também arquiteto e DBA. Aqui reside a principal relação entre arquitetura e Scrum.

Mas há outra situação que não é muito comentada. Considere o seguinte lema: “ao finalizar o desenvolvimento de um sistema, ele já é legado”. Sistemas legados costumam ter alguns problemas como: dificuldade de compreensão das regras de negócio, desconhecimento das razões que levaram a determinadas decisões, problemas na estruturação dos módulos de código, miscelânea de estilos de programação, obsolescência das ferramentas de desenvolvimento e impossibilidade de reaproveitamento dos equipamentos nos quais são executados para execução de softwares mais atuais.

Assim, se há possibilidade de o sistema ser utilizado por vários anos, há possibilidade de manutenção de qualquer espécie. Nesses casos é altamente aconselhável ter uma boa documentação do sistema além do código. Note que o desconhecimento das razões que levaram a determinadas decisões é muito comum, e por isso é muito importante ter em sua arquitetura uma descrição de seus raciocínios. 

É comum as pessoas se referirem à arquitetura como uma coleção de caixinhas, algumas empilhadas e outras lado a lado. Eis um exemplo desta descrição:

Esta é uma forma amplamente utilizada. Não há dúvida que Browser não acessa ODBC. Mas várias questões ficam sem respostas. Web Services não tem nenhuma relação com Security? (Posso assumir que não há segurança direta no Web Service nem DCOM?) Posso considerar que Business não acessa a ODBC em nenhum momento? Se aparentemente Business não tem nenhuma relação com OS, este sistema é portável para qualquer sistema operacional?

E o que significam exatamente estas caixinhas? Programas inteiros? Módulos? Ou é dependência de compilação? E como fica o fluxo de informação?

Uma arquitetura de um sistema pode ser algo muito complexo e não há apenas uma forma de representá-la. O ideal é haver várias visões, sendo que cada visão da arquitetura tem um objetivo. Para isso existe uma forma de descrever arquiteturas através de visões conhecida como “4+1″ (lê-se four by one). Esta abordagem foi adotada como uma das fundações do RUP.

Estas visões arquiteturais se resumem em quatro visões mais uma, onde a última tem como função “fechar” a idéia exposta nas outras quatro. Utilizando um pequeno subconjunto de cenários importantes - instâncias de casos de uso - para mostrar que os elementos das quatro visões trabalham juntos, sem emendas. Esta é a visão “+1″, redundante com as outras, mas servindo com um objetivo distinto.

Estas visões arquiteturais se resumem em quatro visões mais uma, onde a última tem como função “fechar” a idéia exposta nas outras quatro. Utilizando um pequeno subconjunto de cenários importantes - instâncias de casos de uso - para mostrar que os elementos das quatro visões trabalham juntas sem emendas. Esta é a visão “+1″, redundante com as outras, mas servindo com um objetivo distinto.

As quatro visões são:

• Visão lógica: suporta primariamente requisitos comportamentais, os serviços que o sistema deve prover para os usuários finais. Projetistas decompõem o sistema em um conjunto de abstrações chaves, obtidas principalmente do domínio do problema. Essas abstrações são objetos ou classes de objeto que expõem os princípios de abstração, encapsulamento, e herança. Além de colaborar na análise funcional, a decomposição identifica mecanismos e elementos de projeto que são comuns ao longo do sistema;
• Visão de processo: endereça concorrência e distribuição, integridade de sistema e tolerância à falhas. Esta visão também especifica quais threads de controle executam cada operação de cada classe identificada na visão lógica. A visão de processo pode ser vista como um conjunto independente de rede lógicas executando programas - processos - que são distribuídos através de um conjunto de recursos de hardware, os quais são conectados a um barramento ou LAN ou WAN;
• Visão de desenvolvimento: foca na organização dos módulos de software no ambiente de desenvolvimento. As unidades dessa visão são pequenos pedaços de software - bibliotecas ou subsistemas - que podem ser desenvolvidos por um ou mais desenvolvedores. Esta visão suporta a alocação de requisitos e trabalho para times e suporta avaliação de custos, planejamento, monitoramento do progresso de projetos e raciocínio sobre reutilização de software, portabilidade e segurança;
• Visão física: leva em conta os requisitos do sistema, como disponibilidade, confiabilidade, desempenho e escalabilidade. Esta visão mapeia os vários elementos identificados nas visões lógicas, processos e desenvolvimento - redes, processos, tarefas e objetos - em nós de processamento.

Já participei de entrevistas de emprego nas quais onde me foi perguntado se eu conhecia design patterns e com quais eu já havia trabalhado. O conceito por trás dessa pergunta é quanto mais design patterns eu já trabalhei, mais pontos eu ganho. Ou seja, o critério é quantidade, não houvendo em nenhum momento nenhuma dúvida com relação à qualidade.

Paralelamente a isso existem também duas práticas conhecidas como KISS (Keep It Sweet & Simple) e YAGNI (You Ain’t Gonna Need It). A primeira consiste em fazer as coisas mais simples, sem complicações desnecessárias.
Mas lembre, não devemos confundir simples com simplista. Simples consiste em evitar ornamentos dispensáveis, enquanto simplista consiste em considerar apenas um aspecto das coisas. O desejável é ter uma arquitetura simples, não simplista.

O outro conceito – YAGNI – sugere que o arquiteto não deve adicionar funcionalidades até que sejam necessárias. A tentação para escrever código que não é necessário no momento (mas que pode ser útil no futuro) tem muitas desvantagens: tempo perdido, aumento de bugs, código grande e complicado, entre outras.

Então fica a questão, como alguém pode saber o que adicionar em uma arquitetura? Como posso ter certeza que não estou sendo simplista? Como sei do que vou precisar ou não? A resposta a isso são as metas arquiteturais, que provêem motivação e análise racional para decisões. Estas são geralmente orientadas aos requisitos do software.

Questões respondidas pelas metas arquiteturais:

• Qual a expectativa de vida do sistema?
• O sistema deve responder a trocas tecnológicas ao longo da vida?
• Com que freqüência o sistema deve adaptar-se a mudanças?
• Quais mudanças podem ser antecipadas, e qual a maneira mais fácil de acomodá-las?

Após definidas as metas arquiteturais, o arquiteto tem capacidade de saber quais as melhores estratégias para a arquitetura, quais patterns são mais apropriados. Se não houver metas arquiteturais não é arquitetura de sistema, mas apenas descrição de sistema.

Em Scrum a promessa de bons frutos é grande, mas o caminho para chegar lá é sinuoso. Uma das razões que torna a adoção de Scrum mais difícil é a estimativa do tempo necessário para o desenvolvimento.

Técnicas waterfall costumam ter uma previsão muito apurada da data que o desenvolvimento termina. Esta previsão dá uma sensação muito boa para os gerentes de controle, além de simplificar a geração de relatórios para a direção. Assim, seguindo o cronograma original, será possível ter o sistema pronto para ser utilizado pelo usuário na data exata.

Nesta estimativa os gestores fazem hipóteses sobre o futuro, estimam o tempo necessário para cada requisito e analisam dependências entre atividades de desenvolvimento. O resultado é colocado em um gráfico de Gantt. Para dar mais credibilidade às estimativas alguns gestores adicionam um tempo à data  de lançamento, afinal imprevistos acontecem.

Ao longo do projeto os imprevistos são maiores que se podia imaginar. Dificuldades de implementação vão aparecendo. Requisitos antes considerados importantes agora são irrelevantes, e outros requisitos são adicionados. O gráfico de Gantt perde credibilidade. É comum projetos de dezoito meses durarem trinta e seis meses.

Ao final, se o sistema não estiver pronto para ser utilizado pelo cliente na data certa, é porque houve um erro de estimativa ou na gerência do projeto. Alguns argumentos que seguem ao atraso são: que é preciso melhorar nossas estimativas, é necessário melhorar as técnicas de gerenciamento de projeto.

Para resolver este problema, considere algumas suposições. Se os requisitos iniciais (upfront) obtidos possivelmente serão alterados radicalmente, um sistema que adapte rapidamente para alterações possivelmente trabalhará melhor. Se as estimativas dos desenvolvedores são ruins, encontre um jeito de mapear estimativas de desenvolvedores no tempo de desenvolvimento atual. Se o planejamento caro e adiantado dá resultados levemente melhores ou piores que não planejar nada, então o plano sobre pequenos horizontes é melhor que longos.

Scrum é gerenciamento de software e técnicas de planejamento que balanceiam estas metas:

• stakeholder pode re-priorizar ao menos mensalmente;
• quem vem de fora pode fazer experimentos com implementações parciais de primeira mão;
• desenvolvedores podem prever datas de liberação baseados em um conjunto de características;
• stakeholders podem prever datas de liberação baseados em um conjunto de características;
• desenvolvedores podem focar em trabalho ininterrupto, enquanto estão comunicando simultaneamente em reuniões estruturadas e altamente controladas;
• desenvolvedores podem refinar seus processos e trabalhar atividades através de retroinformação e auto-organização.

Scrum é uma técnica de gerência de software com alta transparência, controle adaptivo, previsão de lançamento razoavelmente apurada e alta produtividade. Entretanto, como Scrum expõem marketing e desenvolvedores a uma grande visibilidade e responsabilidade que abordagens tradicionais como waterfall, e porque requer estruturas de gerenciamento diferentes, algumas organizações encontram resistência para implementá-lo. Scrum foca na gerência, então pode combinar com técnicas de desenvolvimento ágeis.