Комментарии 10
Кажется, вы описали классическую водопадную модель с последовательным конвейером стадий: сначала чёткое ТЗ в виде документа, потом разработка строго по ТЗ, потом внедрение получившегося. Никто не спорит, что при возможности чётко описать требования waterfall это плохо. Водопад идеален для условий чётких требований, однако очень редко вообще возможно создать ТЗ. Если вы, например, автоматизируете документооборот на предприятии, то никто не может сказать, как надо это делать. Есть люди со стороны заказчика, которые знают, как это работало раньше, но они не знают, как это реализовать, потому что не являются специалистами по разработке ПО. Если им дать задание делать ТЗ, то ничего хорошего они не напишут. Даже аналитики и менеджеры не помогут, пока не будет представления заказчиком образа результата, а для этого нужен результат сразу, который будет постепенно улучшаться.
И вы зря сомневаетесь в гибкости программного кода. Это не штукатурка, которую не снять, код может быть изменяемым. А agile говорит, что не надо штукатурить, не надо делать работу, необходимость которой прямо сейчас не очевидна.
И вы зря сомневаетесь в гибкости программного кода. Это не штукатурка, которую не снять, код может быть изменяемым. А agile говорит, что не надо штукатурить, не надо делать работу, необходимость которой прямо сейчас не очевидна.
Не не, я не настаиваю на ТЗ. В XP и Agile должны быть люди, знающие ответы на вопросы предметной области — Customer Representative. В Scrum эту роль играет Product Owner. Вопрос в том, что иногда эти люди не могут ответить на вопросы.
Ну и проработав несколько лет по Agile и Scrum в ряде компаний и увидев, как заваливаются проекты по причине слабости команд или нарушений в проектировании — немного разочаровался в гибких методологиях. Они хороши для простых систем… да.
Проработал в нескольких компаниях которые при приеме на работу уверяли что работают по agile. По факту только одна их них понимала и правильно применяла agile. Во всех остальных присутствовали не основные признаки скрама и, соответственно, он не работал. Вероятно вы разочарованны гибкими методиками потому что принимаете их за что-то другое и ни когда не работали в настоящем скраме.
«причине слабости команд или нарушений в проектировании» — эти причины не производное от скрама. Но. Если используется скрам, то, по идее, со временем эти причины должны исчезнуть, либо сильно уменьшить свое влияние на процесс.
Мое личное мнение: Очень часто команды разочаровываются в скраме потому что не умеют его использовать.
«причине слабости команд или нарушений в проектировании» — эти причины не производное от скрама. Но. Если используется скрам, то, по идее, со временем эти причины должны исчезнуть, либо сильно уменьшить свое влияние на процесс.
Мое личное мнение: Очень часто команды разочаровываются в скраме потому что не умеют его использовать.
Я не согласен, что автор в статье описывает водопад, хочу заметить, за пределами agile есть много чего, не только водопад (простите мне немного саморекламы).
Я, также, полностью поддержу предыдущие комментарии автора статьи.
На мой взгляд, agile сейчас очень моден, но этот подход предназначен для решения некоторого, ограниченного класса задач, при всем моем к нему уважению и любви. К сожалению, увлекаясь agile, разработчики, зачастую, не обращают внимание на другие методики. Этим они лишают себя возможности выбора инструмента, наилучшим образом подходящего для решения конкретной задачи. Хотя, надо признать, хорошие специалисты при необходимости от agile отходят очень далеко.
Я, также, полностью поддержу предыдущие комментарии автора статьи.
На мой взгляд, agile сейчас очень моден, но этот подход предназначен для решения некоторого, ограниченного класса задач, при всем моем к нему уважению и любви. К сожалению, увлекаясь agile, разработчики, зачастую, не обращают внимание на другие методики. Этим они лишают себя возможности выбора инструмента, наилучшим образом подходящего для решения конкретной задачи. Хотя, надо признать, хорошие специалисты при необходимости от agile отходят очень далеко.
Сложно не согласиться с полезностью хорошей аналитики. Мне понятно, что это очень важная, но, в то же самое время, очень затратная статья бюджета. Поэтому есть мнение, что ее очень трудно продавать. А делать себе в убыток не очень хочется. Как быть?
Оффтопик: аналогичная проблема, по моему мнению, актуальна и для таких замечательных вещей как система контроля версий, написание программистами документации, автотестов. Очень сложно продавать.
Оффтопик: аналогичная проблема, по моему мнению, актуальна и для таких замечательных вещей как система контроля версий, написание программистами документации, автотестов. Очень сложно продавать.
Тут наверно вопрос экстренной необходимости. Для многих проектов, которые довольно просты и прямолинейны — вникать с суть предметной области не обязательно, по скраму, фича за фичей и дом будет построен. Но в некоторых проектах, анализ критически важен — иначе шатл эффектно взорвется на глазах журналистов — вопрос устойчивости бизнеса.
процессы вторичны, как и сам agile :)
во первых в проекте должен быть кто-то, кто знает ЧТО он хочет получить (обычно Product Owner)
потом должен быть сильный PM, тот который знает КАК этого можно добиться и что точно не надо делать (например тыкать вилкой в разетку)
если проект большой и сложная предметная область, то нужен аналитик, который должен работать в том направлении, что укажет PM, а не генерить свои требования и замедлять процесс
разработчики должны быть командой (вне зависимости от их квалификации) — скорость и компетеции можно тюнить и в процессе
общение важнее требований, вся команда должна жить в режиме «стартапа» и понимать что и зачем они делают — это создает общность, скорость в принятии решений и возможность разработчику самому решить мелкие вопросы по аналогии с тем, что реализовывается рядом.
и все надо экономить — поставить цель и идти к ней минимальной дорогой с максимальной скоростью
— написать статью? :)
во первых в проекте должен быть кто-то, кто знает ЧТО он хочет получить (обычно Product Owner)
потом должен быть сильный PM, тот который знает КАК этого можно добиться и что точно не надо делать (например тыкать вилкой в разетку)
если проект большой и сложная предметная область, то нужен аналитик, который должен работать в том направлении, что укажет PM, а не генерить свои требования и замедлять процесс
разработчики должны быть командой (вне зависимости от их квалификации) — скорость и компетеции можно тюнить и в процессе
общение важнее требований, вся команда должна жить в режиме «стартапа» и понимать что и зачем они делают — это создает общность, скорость в принятии решений и возможность разработчику самому решить мелкие вопросы по аналогии с тем, что реализовывается рядом.
и все надо экономить — поставить цель и идти к ней минимальной дорогой с максимальной скоростью
— написать статью? :)
Кстати, так у кого искать ответа?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сложная предметная область — у кого искать ответы?