Renato, boa sugestão, então, segue uma breve transcrição do que na minha opinião foi mais importante:
Agile Imersion - Manoel Pimentel
Foi um workshop de aproximadamente 6 horas, onde foram passados os conceitos e valores dos métodos ágeis e depois uma breve conceituação de SCRUM, seguida de um exercício prático onde todos os conceitos e práticas do SCRUM foram utilizados. Um dos pontos altos foi a dinâmica de encerramento que nos evidenciou o quanto equipes alto gerenciadas podem ser mais produtivas e eficientes.
Gerenciamento de Projetos com Scrum - Rodrigo Yoshima
Este foi outro workshop de 6 horas sobre SCRUM. Foi um pouco mais conceitual que o Agile Immersion, no entanto foi bem completo e focou em situações corriqueiras
do dia a dia da utilização do SCRUM, como:
- atuação do Scrum Master conjuntamente com o product owner na identicação dos itens do Product backlog
- atuação do Scrum Master e do time nas reuniões de planejamento da sprint,
- negociação e definição da prioridade de itens com o product owner
- estimativa de itens do product backlog;
- daily meeting;
- tratamento de impedimentos;
- reuniões de Sprint review e Sprint retrospective;
Enfim foi uma abordagem teórica, só que calcada na grande experiência e vivência prática que o Rodrigo possui.
Minhas conclusões
Para mim, o evento cumpriu o que propôs: falar sobre práticas e métodos ágeis com um foco especial em SCRUM.
Com isto consegui identificar que tudo que venho aplicando nos últimos meses estão aderentes as tendências de mercado, e principalmente que a adoção de práticas ágeis na gestão, concepção, design e desenvolvimento não são mais tendências e sim uma grande e sonora realidade.
Vi também que devemos romper algumas barreiras em relação a alguns pontos e conceitos:
-
Prestamos um serviço intelectual e não repetitivo o que caracteriza a necessidade de utlizarmos abordagens de um processo empírico pois o software é um organismo vivo e temos que parar de achar que os requisito são imutáveis pois não o são;
-
Portanto, o software está em constante evolução e por este motivo trabalhar com escopo, prazo e custo fechado é loucura;
-
Temos que envolver o cliente no processo de produção do software, ou seja, temos que estreitar e tornar periódica esta comunicação;
-
Temos que entregar software pronto (para entrar em produção) e que agregue valor de negócio ao cliente, pois pesquisas comprovam que 45% das funcionalidades de um sistema nunca são utilizadas;
-
Devemos documentar, mas somente aquilo que for necessário para garantir a qualidade interna do produto e conseqüentemente a fácil evolução e manutenção do mesmo.
Bem, esta é minha humilde opinião e espero que ela possa, de alguma forma, contribuir.
