Июнь, 2017
#Тезисы
Выбор методологии проекта
Я считаю, что проектная команда должна всегда вырабатывать свою внутреннюю технологию ведения проекта. Конечно же можно и нужно смотреть на уже существующие методологии, но при этом учитывать специфику участников проектной команды и требования проектов, на которыми такая команда работает.
В качестве иллюстрации я хочу показать доклад одного из авторов Agile-манифеста – Дейва Томаса, в котором он спустя много лет делится своим впечатлением о подходе. У этого видео много комментариев, мне понравился этот:
"Agile" has never worked for designers or anyone that likes to know what are they building. Designing in small steps is like driving in a pitch dark. No vision, no architecture, agile is good for very small teams, not sure what product they are doing. The industry created around agile is really disgusting too, and i always despised those agile experts that come with the confidence they know better whats good or bad for our team and product, just because they are certified or "they have been doing it for years". They do not even bother spending time learning about the particular problems we are solving or know the people in the team... they just come and start trying to fit the team in to The Methodology! Setup repeating meeting, waste everyones's time, arrive with useless velocity graphs that tells nothing about the amount or quality of the work done, kill features that will "take too long" to fit in one release.. There must be a better way to build products, and agility is only part of the answer, not the whole story.
"Agile" has never worked for designers or anyone that likes to know what are they building. Designing in small steps is like driving in a pitch dark. No vision, no architecture, agile is good for very small teams, not sure what product they are doing. The industry created around agile is really disgusting too, and i always despised those agile experts that come with the confidence they know better whats good or bad for our team and product, just because they are certified or "they have been doing it for years". They do not even bother spending time learning about the particular problems we are solving or know the people in the team... they just come and start trying to fit the team in to The Methodology! Setup repeating meeting, waste everyones's time, arrive with useless velocity graphs that tells nothing about the amount or quality of the work done, kill features that will "take too long" to fit in one release.. There must be a better way to build products, and agility is only part of the answer, not the whole story.