tag:blogger.com,1999:blog-6940622.post3829624880176398564..comments2008-10-26T15:20:51.161-02:00Victor Hugo Germanohttp://www.blogger.com/profile/12030160604255283986noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-6940622.post-21691033395226112042008-10-25T20:59:00.000-02:002008-10-25T20:59:00.000-02:00Pois é, isso me veio à mente tb... Gostei da abordagem justamente pq ela eleva um pouco a discussao sobre até funcionalidades, dando uma visão de negócio ao produto. Talvez seja mais fácil para uma equipe de desenvolvimento entender o porque uma funcionalidade deva ser incorporada, ou ainda para que o cliente também entenda quando é a hora de investir mais em arquitetura de software, ou programar um release planning "seco", quer dizer, igual aos concorrentes...<BR/><BR/>Até mesmo no diagrama apresentado na apresentação, o david indicou um caminho interessante:<BR/>Produzir commodities inicialmente, e ir incorporando nas sprints cost reductors e spoiler...<BR/><BR/>Avaliar por números, na minha visao, seriam bastante complexo... e justamente por isso, Tudo é prioridade máxima para os clientes...<BR/>Essa abordagem pode ser mais uma na tentativa de esclarecer melhor "o que devemos produzir"Victor Hugo Germanohttp://www.blogger.com/profile/12030160604255283986noreply@blogger.comtag:blogger.com,1999:blog-6940622.post-52296038024311279002008-10-25T17:21:00.000-02:002008-10-25T17:21:00.000-02:00Nao me convenceu a abordagem das prioridades. Acho que mais geraria confusao que outra coisa. Algumas veces um redutor de custo pode ser mais importnte que um commodity ou vice-versa.<BR/><BR/>Me parece que as prioridades de cada funcionalidade devem ir de acordo com o retorno que elas irao oferecer: mais retorno = maior a prioridade.<BR/><BR/>E como se mede mais ou menos? Com numeros. Por tal motivo acho que priorizar com numeros e melhor.Diego Carrionhttp://www.mouseoverstudio.com/blog/noreply@blogger.com