О методологиях, best practices, и процессах
М-да.
Что такое процессы - знают все или практически все. Многие критикуют процессы, и настаивают, что главное - люди. Однако, и они на самом деле при разработке следуют каким-то процессам, формализованным или нет. Хороший процесс позволяет освободить исполнителей от рутины, поставить деятельность на поток, не думая постоянно об организации работ, а думая об их содержательной части - это удобно. Это просто некий оговоренный порядок выполнения работ, плюс распределение обязанностей людей, кто выполняет работы. Процессы применяют практически все.
Что такое best practices - тоже знают почти все. Что это такое? Скажем - code и design review - это хорошо. Или, скажем, многие считают - юнит-тесты - это хорошо. Или ежедневные билды и автоматические тесты - это хорошо. Все перечисленные вещи - best practices, пользу которых не отрицает никто и более того, значительная часть людей соглашаются относительно одного и того же набора best practices.
А вот теперь методологии. Что такое методологии? Это некий коктейль рекомендуемых процессов и best practices, предварительно замешанный и приготовленный, причем есть один компонент коктейля, без которого этот коктейль не будет методологией. Это - некая объединяющая философия, которая объясняет, что именно данная методология позволит нириально ускорить разработку.
Что интересно - практически все методологии опираются на один и тот же или близкий набор best practices, с небольшими отклонениями :). Поэтому - чтобы создать впечатление больших отличий друг от друга - они переназывают все новыми терминами (а то все очень быстро распознают эти всем известные best practices, и вся магия методологии сразу улетучится), и немного перетасовывают процессы разработки, чтобы еще больше усилить впечатление новызны.
Зачем это делается? Смотрите. Best practices - это опыт разработчиков, и выводы, что такое хорошо, и что такое плохо. Они относительно объективны, и именно поэтому их не так много и многие сходятся на одних и тех же best practices. Процессы - это конкретные способы организации работ в конкретных компаниях, которые претворяют best practices в жизнь, и решают проблемы конкретных компаний. Все понятно, и логично. Что ж такое эти Методологии, и какое место во всем этом занимают они?
А это - продукт, уважаемые коллеги, который хотят вам впарить. Есть третьи компании и личности, которые зарабатывают тем, что учат остальных жить. Но чтобы заставить вас заплатить им, они должны как-то убедить вас, что есть что-то такое помимо известных вам best practices. Но ничего нового придумать тут все равно невозможно, вот они и идут на хитрость. Делают некий коктейль, после чего пытаются вас убедить, что все херня кроме пчел, и это они знают, как вам лучше работаеть - а не вы. Читая описание методологий, вы видите, что все черт возьми логично, но переназывание терминов и косметические перетасовки процессов не дают вам понять, что это воздушный пузырь.
В чем пошли дальше разработчики методологий agile? Они оказались еще наглее, чем старое поколение консультантов, которые, скажем, изобрели RUP. Они сильнее налегли на философию, более агрессивно занялись переименованием терминов, значительно перетряхнули процессы, - короче, подошли к процессу впаривания методологии как продукта и затуманиванию мозгов куда профессиональнее "стариков". При этом - они еще сильно упростили сами процессы, превратив свои методологии в жвачку, что должно упростить формирование условных рефлексов и в конечном счете - впаривание. Потому что "старички" слишком много внимания сути вопроса уделяют, не понимают они, дурачки, что это - бизнес.
Короче - agile это коммерческий термин, это бренд, придуманный маркетологами. Я смотрел FDD, чтобы посмотреть - а вдруг это хороший шаблон процесса, как никак впечатляющий набор best practices в описании заявлен. Хрен там. Очевидные места на поверхности, неочевидные и сложные места, которые как раз неплохо бы решить - аккуратно обойдены вниманием. В результате - выглядит логично и красиво, не специалист по процессам разработки не поймет подвоха, зато при попытке самостоятельного внедрения это стопорнется и работать не будет. Тут-то люди и обратятся к консультантам. Умно придумано.
Короче говоря, я собираюсь больше внимания обращать на best practices, свой опыт, и текущие проблемы, как я делал и раньше - и обходить эти "методологии" стороной, особенно agile. Нахуй-нахуй, к терапевту.
Что такое процессы - знают все или практически все. Многие критикуют процессы, и настаивают, что главное - люди. Однако, и они на самом деле при разработке следуют каким-то процессам, формализованным или нет. Хороший процесс позволяет освободить исполнителей от рутины, поставить деятельность на поток, не думая постоянно об организации работ, а думая об их содержательной части - это удобно. Это просто некий оговоренный порядок выполнения работ, плюс распределение обязанностей людей, кто выполняет работы. Процессы применяют практически все.
Что такое best practices - тоже знают почти все. Что это такое? Скажем - code и design review - это хорошо. Или, скажем, многие считают - юнит-тесты - это хорошо. Или ежедневные билды и автоматические тесты - это хорошо. Все перечисленные вещи - best practices, пользу которых не отрицает никто и более того, значительная часть людей соглашаются относительно одного и того же набора best practices.
А вот теперь методологии. Что такое методологии? Это некий коктейль рекомендуемых процессов и best practices, предварительно замешанный и приготовленный, причем есть один компонент коктейля, без которого этот коктейль не будет методологией. Это - некая объединяющая философия, которая объясняет, что именно данная методология позволит нириально ускорить разработку.
Что интересно - практически все методологии опираются на один и тот же или близкий набор best practices, с небольшими отклонениями :). Поэтому - чтобы создать впечатление больших отличий друг от друга - они переназывают все новыми терминами (а то все очень быстро распознают эти всем известные best practices, и вся магия методологии сразу улетучится), и немного перетасовывают процессы разработки, чтобы еще больше усилить впечатление новызны.
Зачем это делается? Смотрите. Best practices - это опыт разработчиков, и выводы, что такое хорошо, и что такое плохо. Они относительно объективны, и именно поэтому их не так много и многие сходятся на одних и тех же best practices. Процессы - это конкретные способы организации работ в конкретных компаниях, которые претворяют best practices в жизнь, и решают проблемы конкретных компаний. Все понятно, и логично. Что ж такое эти Методологии, и какое место во всем этом занимают они?
А это - продукт, уважаемые коллеги, который хотят вам впарить. Есть третьи компании и личности, которые зарабатывают тем, что учат остальных жить. Но чтобы заставить вас заплатить им, они должны как-то убедить вас, что есть что-то такое помимо известных вам best practices. Но ничего нового придумать тут все равно невозможно, вот они и идут на хитрость. Делают некий коктейль, после чего пытаются вас убедить, что все херня кроме пчел, и это они знают, как вам лучше работаеть - а не вы. Читая описание методологий, вы видите, что все черт возьми логично, но переназывание терминов и косметические перетасовки процессов не дают вам понять, что это воздушный пузырь.
В чем пошли дальше разработчики методологий agile? Они оказались еще наглее, чем старое поколение консультантов, которые, скажем, изобрели RUP. Они сильнее налегли на философию, более агрессивно занялись переименованием терминов, значительно перетряхнули процессы, - короче, подошли к процессу впаривания методологии как продукта и затуманиванию мозгов куда профессиональнее "стариков". При этом - они еще сильно упростили сами процессы, превратив свои методологии в жвачку, что должно упростить формирование условных рефлексов и в конечном счете - впаривание. Потому что "старички" слишком много внимания сути вопроса уделяют, не понимают они, дурачки, что это - бизнес.
Короче - agile это коммерческий термин, это бренд, придуманный маркетологами. Я смотрел FDD, чтобы посмотреть - а вдруг это хороший шаблон процесса, как никак впечатляющий набор best practices в описании заявлен. Хрен там. Очевидные места на поверхности, неочевидные и сложные места, которые как раз неплохо бы решить - аккуратно обойдены вниманием. В результате - выглядит логично и красиво, не специалист по процессам разработки не поймет подвоха, зато при попытке самостоятельного внедрения это стопорнется и работать не будет. Тут-то люди и обратятся к консультантам. Умно придумано.
Короче говоря, я собираюсь больше внимания обращать на best practices, свой опыт, и текущие проблемы, как я делал и раньше - и обходить эти "методологии" стороной, особенно agile. Нахуй-нахуй, к терапевту.