Comments 9
Попытки найти место Аналитику в мире Agile, с аргументацией непонимания в принципе сути Agile. :)
У меня сложилось такое же мнение. К сожалению. Я как и автор работаю аналитиком в компании, где разработка идёт на основе Эджайл подходов, и могу сказать, что описанное практически не имеет связи с реальностью, во всяком случае нашей )) К примеру, ответственный за контроль качества — QA Engineer (inho это догма), ответственный за взаимодействие с командой — PM или Team Lead, ответственный за продукт — Product Owner. У BA свои обязанности, но в статье они раскрыты слабо. И слишком мало особенностей работы аналитика в Эджайл.
Например, если взять тот же Scrum, то в целом обязанности аналитика размазаны между PO и командой разработки. Теоретически-то человек с компетенциями Аналитика вполне может вписаться в команду разработки в случае, если команда разработки не справляется самостоятельно.
А который из Agile-подходов у вас используется?
А который из Agile-подходов у вас используется?
Lean, Scrum, свои наработки. Ничего не размазывается. Аналитик в команде.
У вас дикий какой-то замес получается. :)
Просто исходя из поверхностной оценки складывается впечатление, что была когда-то классическая иерархическая система, на которую решили натянуть «модни-молодёжни» Agile, без понимания того, что при этом должны быть произведены в том числе и структурные изменения (не говоря о способе мышления в целом), а не некоторые событийные в виде Дейли скрамов и Спринтов, чтобы новые процессы привнесли свою пользу)
Меня просто смущает, например, наличие одновременно и PO и PM — какие у PM обязанности? Lean повлиять на такую ситуацию не мог, а в Scrum подобного нет.
Просто исходя из поверхностной оценки складывается впечатление, что была когда-то классическая иерархическая система, на которую решили натянуть «модни-молодёжни» Agile, без понимания того, что при этом должны быть произведены в том числе и структурные изменения (не говоря о способе мышления в целом), а не некоторые событийные в виде Дейли скрамов и Спринтов, чтобы новые процессы привнесли свою пользу)
Меня просто смущает, например, наличие одновременно и PO и PM — какие у PM обязанности? Lean повлиять на такую ситуацию не мог, а в Scrum подобного нет.
В своё время в ТВ-рекламе стиральный порошок «Тайд» сравнивали с «Обычным стиральным порошком». Что это за «зверь» такой — было непонятно, кроме одного — «Обычный стиральный порошок» обладает всеми мыслимыми и немыслимыми недостатками.
Прочитав эту статью, я понял, что автор ставит «Водопад» (а по мне так — нормальный процесс разработки ПО) на место «Обычного стирального порошка» и приписывает ему всевозможные недостатки. При этом, судя по качеству аргументации, возникает сомнение, что автор когда-либо работал по т.н. «водопаду».
Если говорить о конкретных неточностях в статье, то вот это утверждение:
«В тяжеловесных методологиях аналитик похож на слабопроницаемую стену между командой разработчиков и представителями заказчика/бизнеса»
— является полностью недостоверным и непонятно, на основе каких данных автор делает такой вывод.
Следующее за ним утверждение:
«Чтобы сделать хороший продукт, приходится тратить кучу сил на «ковыряние дырок» в этой стене»
— тоже не является истиной.
А вот это утверждение:
«Кроме того, ужасно высоки риски, связанные с ошибками аналитика. Команде разработчиков при этом отводится роль второго плана»
— справедливо для любой методологии разработки ПО, т.к. неправильное описание бизнес-процесса может привести к существенной переделки бизнес-приложения.
Общая рекомендация автору — поработать в продуктовой компании с поставленным процессом разработки ПО, т.е. приобрести реальный опыт в т.н. «водопаде», а потом уже сравнивать хаос аутсорсинговой разработки, выдаваемый почему-то за аджайл, с качественным процессом.
Прочитав эту статью, я понял, что автор ставит «Водопад» (а по мне так — нормальный процесс разработки ПО) на место «Обычного стирального порошка» и приписывает ему всевозможные недостатки. При этом, судя по качеству аргументации, возникает сомнение, что автор когда-либо работал по т.н. «водопаду».
Если говорить о конкретных неточностях в статье, то вот это утверждение:
«В тяжеловесных методологиях аналитик похож на слабопроницаемую стену между командой разработчиков и представителями заказчика/бизнеса»
— является полностью недостоверным и непонятно, на основе каких данных автор делает такой вывод.
Следующее за ним утверждение:
«Чтобы сделать хороший продукт, приходится тратить кучу сил на «ковыряние дырок» в этой стене»
— тоже не является истиной.
А вот это утверждение:
«Кроме того, ужасно высоки риски, связанные с ошибками аналитика. Команде разработчиков при этом отводится роль второго плана»
— справедливо для любой методологии разработки ПО, т.к. неправильное описание бизнес-процесса может привести к существенной переделки бизнес-приложения.
Общая рекомендация автору — поработать в продуктовой компании с поставленным процессом разработки ПО, т.е. приобрести реальный опыт в т.н. «водопаде», а потом уже сравнивать хаос аутсорсинговой разработки, выдаваемый почему-то за аджайл, с качественным процессом.
Сам по себе Agile — это набор ценностей и принципов, а не подход к разработке. Ну и не говоря о том, что, не смотря на форму и качество, существует не только в аутсорсе. :)
И водопад и гибкие подходы в разработке хороши каждый в своём случае и когда неверно делают выбор процесса — вот тогда и начинается неразбериха и недовольство выбранным подходом.
У автора и с Agile тоже не всё будь здоров, так что статья и вышла половинчатой какой-то, с точки зрения знаний и правды :)
Я так понимаю вы очень много работали по водопаду, а по какому-нибудь из Agile подходов вы работали?
И водопад и гибкие подходы в разработке хороши каждый в своём случае и когда неверно делают выбор процесса — вот тогда и начинается неразбериха и недовольство выбранным подходом.
У автора и с Agile тоже не всё будь здоров, так что статья и вышла половинчатой какой-то, с точки зрения знаний и правды :)
Я так понимаю вы очень много работали по водопаду, а по какому-нибудь из Agile подходов вы работали?
Поясню свою ремарку про аутсорс. Исходя из моего 19-летнего опыта работы, аутсорсер не обладает методологиями управления проектами. В аутсорсинговых компаниях проекты либо ведутся как попало, либо на проекте устанавливаются процессы заказчика. Если заказчик — продуктовая компания с богатым опытом разработки и выпуска ИТ-продуктов, то процессы на проекте поставлены хорошо. Если заказчик иной, то процессы не выстроены, и разработка ведётся как попало. Все же разговоры про «гибкие методологии» в данном случае ведутся с целью оправдания такого проектного бардака и нежеланием ставить процессы разработки.
Если Вы понимаете под «водопадом» последовательность Концепция -> Дизайн -> Технический дизайн -> Реализация -> Тестирование и исправление ошибок, то мой ответ — «да». Хотя мой заказчик считает, что применяет «гибкие методологии». Что касается меня, то я считаю такую последовательность этапов обычным инженерным подходом.
Если Вы понимаете под «водопадом» последовательность Концепция -> Дизайн -> Технический дизайн -> Реализация -> Тестирование и исправление ошибок, то мой ответ — «да». Хотя мой заказчик считает, что применяет «гибкие методологии». Что касается меня, то я считаю такую последовательность этапов обычным инженерным подходом.
Sign up to leave a comment.
Бизнес-аналитики в Agile — зачем, почему, как