Comments 65
И можно начинать с того, что Agile стал своего рода флагом, под который встала целая индустрия. Но, как ни странно, не индустрия разработки ПО, а индустрия Agile коучей, для которых Agile-хайп просто бизнес, и ничего личного.
И судя по тому что я вижу и читаю — этот флаг радужный… Соответственно все эти… коучи.)) Не ну серьезно… Бред это все. Метод работы сделали блин древнекитайской философией какой-то.
Официальной датой провала любой методологии можно считать день, когда на Амазоне появляется баннер «100 лучших книг о ...».
средний генеральный директор читает 60 книг в годНе верю! ©
В году 52 недели. Это или какие-то совсем тоненькие книжки или комиксы…
Ну он же не прямо сам читает, а делегирует.
Я совсем не менеджер и не скорочиталец, но для примера, я читал на днях проект феникс, киндл нарисовал мне 3.5 часа до конца книги. Я около часа еду на работу и обратно. За 2 дня я прочитал книгу. это уже больше 52 в год. Было бы желание.
Прочитать книгу за два дня — плевое дело. Читать по книге каждые два дня на протяжении года — совсем другая истоиря.
Оффтоп
«Проект Феникс» — это «Роман о том, как DevOps меняет бизнес к лучшему»? Как осиливать ~350 страниц за ~4 часа, при этом не будучи «скорочитальцем»? Я читал, наверное, пару недель, хотя тоже читаю по дороге, примерно 1,5 часа в день
Мне после прочтения «серьезной литературы» требуется еще день-два на усвоение прочитанного. В это время мой мозг способен воспринимать только литературу уровня попаданцев в ЛитРПГ (немного утрирую).
Кроме того Проект Феникс короткая и простая. Я ее тоже проглотил за пару часов, а вот Цель (The Goal) Голдрата заняла уже больше времени просто потому, что приходилось вникать и задумываться над прочитанным.
Кроме того Проект Феникс короткая и простая. Я ее тоже проглотил за пару часов, а вот Цель (The Goal) Голдрата заняла уже больше времени просто потому, что приходилось вникать и задумываться над прочитанным.
Статья излагает ошибочное мнение автора основанное на поверхностных знаниях предмета и собственных заблуждениях.
Сравнение скачет между туманными характеристиками водопада и гибкой. При этом упоминается только scrum и lean. Отсутствие упоминаний других распространённых методик (XP, Канбан, 6сигм и пр.) говорит, что автор пытался впихнуть невпиху… забивать шурупы и закручивать гвозди, что является источником разочарования в гибких методологиях. Т.е. в одних проектах нужен скрам, в других канбан, а где-то водопадим, господа(гос.проекты в моём субъективном случае).
Вот тут вообще не понял. Это вы про MVP?
Но с одной мыслью автора, я согласен. Встречается необычайное множество скрам фанатиков (поверхностные менеджеры), которые лепят скрам туда, где его лепить не стоит. Тогда и получается: «До 6ти работаем по скраму, а потом работаем по-настоящему»
В любом случае. Подобные изложения нужны, т.к. они инициируют правильные обсуждения и способствуют обмену опытом(болью)
Сравнение скачет между туманными характеристиками водопада и гибкой. При этом упоминается только scrum и lean. Отсутствие упоминаний других распространённых методик (XP, Канбан, 6сигм и пр.) говорит, что автор пытался впихнуть невпиху… забивать шурупы и закручивать гвозди, что является источником разочарования в гибких методологиях. Т.е. в одних проектах нужен скрам, в других канбан, а где-то водопадим, господа(гос.проекты в моём субъективном случае).
Это обнажает ещё один глубокий недостаток Agile. Он предполагает, что пользователей можно воспринимать как морских свинок: «Эй, просто используйте этот дерьмовый продукт, тогда мы улучшим его»
Вот тут вообще не понял. Это вы про MVP?
Но с одной мыслью автора, я согласен. Встречается необычайное множество скрам фанатиков (поверхностные менеджеры), которые лепят скрам туда, где его лепить не стоит. Тогда и получается: «До 6ти работаем по скраму, а потом работаем по-настоящему»
В любом случае. Подобные изложения нужны, т.к. они инициируют правильные обсуждения и способствуют обмену опытом(болью)
Канбан, 6сигм
Очень интересно как вы ети методики натянете на разработку ПО?
Реально интересно. Я реально видел ефект в произвотстве, но вразработке ПО?
Если команда адекватная, единственный путь сделать продукт — писать код, а не следовать учениям.
Да запросто, дорожки в джире переименовал и вот вам канбан!
Канбан применить просто — там где есть затраты времени на переход задачи между людьми или отделами — канбан помогает это находить и убирать узкие места. Хорошо работает с повторяющимися задачами или повторяющимися процессами.
писать код, а не следовать учениям.
Спасибо вам за эту фразу, честно, хоть ктото думает так же. Честно я уже устал удивляться с каким фанатизмом люди превращают все подряд в веру, будь то agile, scrum, mvc или что-то еще. Да в пень это все, давайте уже продукт создавать)
Чтобы его выкинуть. Что почти всегда неотвратимо, вопрос только в объемах выкидываемого.
Если вы точно знаете, что надо писать, то конечно вам Agile только мешать будет. Не знаю, как вы, я встречал такое нечасто.
Если вы точно знаете, что надо писать, то конечно вам Agile только мешать будет. Не знаю, как вы, я встречал такое нечасто.
Как по мне, эти все методики нужны для управления не командами, а случайными программистами, которих собрали для проекта.
Но если у вас команда — методики только мешают.
Объясню.
Например Бизнес непосредственно ставит задачу тимлиду или ищут решение проблеме (он разбирается в БП компании не хуже бизнеса ). Тимлид видит как интегрировать задачу в существующий продукт. Составляет план, и архитектуру решения.
Представляет задачу и архитектуру решения команде.
Далее команда критикует решение, и они обсуждают недочёты и альтернативные возможности. Пока не достигнут решения. При необходимости анализируются альтернатива и после етого встречаются повторно.
Дальше задача разбивается на более мелкие подзадачи. И при необходимости обсуждаются их детали. Важно, что б все в команде понимали что ми делаем, а не писали функцию или клас.
Дальше тимлид раздает подзадачи с учетом сильных и слабых сторон подчинённых, учитывая важность других текущих задач.(Не знаю как у вас, но редко бывает одна задача в работе.)
Во время работы, тимлид знает кого нужно спросить не нужна ли помощь, кого то нужно подстегнуть и тд. По ходу продвижения работ меняет при необходимости как подзадачи так и исполнителей. И да он тоже в задаче.
Если проект большой, можно раз в недельку собраться, но как правило все в одном месте и перекликнутся, или попросить о помощи куда ефективнее.
И да команда это не только работа, а и вместе дни рождения, футбол, пикники, поездки по грибы,…
И даже если в пылу разговора кто-то кого-то послал то это означает что нужно разойтись и через полчаса обсудить повторно.
Хотя я согласен, что в больших IT компаниях с большим числом заказчиков и продуктов, наверное по другому не работает.
Но если у вас команда — методики только мешают.
Объясню.
Например Бизнес непосредственно ставит задачу тимлиду или ищут решение проблеме (он разбирается в БП компании не хуже бизнеса ). Тимлид видит как интегрировать задачу в существующий продукт. Составляет план, и архитектуру решения.
Представляет задачу и архитектуру решения команде.
Далее команда критикует решение, и они обсуждают недочёты и альтернативные возможности. Пока не достигнут решения. При необходимости анализируются альтернатива и после етого встречаются повторно.
Дальше задача разбивается на более мелкие подзадачи. И при необходимости обсуждаются их детали. Важно, что б все в команде понимали что ми делаем, а не писали функцию или клас.
Дальше тимлид раздает подзадачи с учетом сильных и слабых сторон подчинённых, учитывая важность других текущих задач.(Не знаю как у вас, но редко бывает одна задача в работе.)
Во время работы, тимлид знает кого нужно спросить не нужна ли помощь, кого то нужно подстегнуть и тд. По ходу продвижения работ меняет при необходимости как подзадачи так и исполнителей. И да он тоже в задаче.
Если проект большой, можно раз в недельку собраться, но как правило все в одном месте и перекликнутся, или попросить о помощи куда ефективнее.
И да команда это не только работа, а и вместе дни рождения, футбол, пикники, поездки по грибы,…
И даже если в пылу разговора кто-то кого-то послал то это означает что нужно разойтись и через полчаса обсудить повторно.
Хотя я согласен, что в больших IT компаниях с большим числом заказчиков и продуктов, наверное по другому не работает.
Это работает только при массовом клепании Однотипных Форм (тм). Бизнес не знает, как решить проблему. Тимлид не видит (почему, кстати, тимлид?), как интегрировать в систему. Оценки, как всегда, ошибаются в 2,5 раза. Или вообще никто подобных задач не делал, конечный результат мало кто себе переставляет. Разработчики не хотят делать навязанные им задачи, а хотят развиваться. Джуны боятся сказать о проблеме и тянут до последнего. Результат всегда оказывается не тем, что все себе переставляли. Ничто не ново под луной, все прекрасно описано, на реальных примерах и со статистикой, Макконнеллом, Вигерсом, Фаулером и пр.
По моему опыту, Аджайл прекрасно работает как раз в продуктовых компаниях, особенно B2C, с сильными командами.
По моему опыту, Аджайл прекрасно работает как раз в продуктовых компаниях, особенно B2C, с сильными командами.
Это работает только при массовом клепании Однотипных Форм (тм).Уж точно нет.
Бизнес не знает, как решить проблему.Так значит и нет задач.
Тимлид не видит (почему, кстати, тимлид?)Согласен не тимлид. (но назовите как хотите архитектор+тимлид+ начальник оттела разработки, суть то не меняет )
как интегрировать в систему.
Ну уж если он не видит то усе… смисла в отделе нет. И тут уже ничто не поможет ни скрам ни Аджайл ни Менеджер.
Оценки, как всегда, ошибаются в 2,5 раза
Та ладно ви точноее даете оценку? если да то сколько занимает процес оценки? Или по скраму сбросились фантиками и большинство оценило?
Так от, если процес оценки занимает больше 1 часа команды или емеет допуск боле 50% есть ли смисл?
Или вообще никто подобных задач не делал,
И как в етом поможет Аджайл?
конечный результат мало кто себе переставляет
Если так, то какой смисл начинать?
И как в етом поможет Аджайл?
Разработчики не хотят делать навязанные им задачи, а хотят развиваться
то есть отсутствие каноничного Аджайл подразумевает по умолчанию бардак?
Интересная мысль.
Джуны боятся сказать о проблеме и тянут до последнего
Во время работы, тимлид знает кого нужно спросить не нужна ли помощь, кого то нужно подстегнуть и тд.
Результат всегда оказывается не тем, что все себе переставляли.Как я уже писал НЕЛЬЗЯ Начинать проек не представляя конечного результата. И ето железное правило.
на реальных примерах и со статистикойНу да есть Правда, Лож и Статистика. :)
У меня складывается впечатление, что вы не очень знакомы с развитием методологий разработки ПО, предпосылками появления Agile, какие проблемы он призван решать и как. Ответ на ваши вопросы потянет на добрую статью, и не одну. К счастью, вы можете найти все ответы прямо здесь, на Хабре, а так же кучу обоснованной критики Agile, в том числе от пользователь в комментариях.
К примеру:
Оценка неспроста рекомендуется в попугаях — она ничего не говорит о том, сколько задача займет времени. Есть множество работ про expert decision making, вкратце — не очень хорошо, особенно в условиях неопределенности (пару статей). Но если использовать статистический подход, то достоверность значительно повышается.
После планирования у вас есть скоуп из разномастных стори, оцененных в попугаях с большой погрешностью. Но ошибки оценки частично компенсируются и, все вместе, деленные на историческую производительность команды, полученную статистически, дают довольно достоверную оценку. ИМО, лучше не брать больше 80% поинтов в спринт: раз на раз не приходится, лучше в спокойном спринте команда поработает над задачами из бэклога на свое усмотрение, порефакторит или поэкспериментирует.
Отвечая на вопрос — нет, я не даю оценку точнее. Но это не имеет значения.
К примеру:
Та ладно ви точноее даете оценку? если да то сколько занимает процес оценки?До оценки всем членам команды должно быть понятно, что требуется иначе стори в спринт не пойдет. Если много задач уходит на доработку или груминг занимает много времени — значит или стори плохо проработаны, или процесс плохо организован (вот вам сразу и сигнал управления). Тайная оценка дает второй чек — что все действительно понимают задачу, минус authority bias, cognitive bias. От себя добавлю — еще и третий чек, что народ не спит и не дает оценки «как все».
Оценка неспроста рекомендуется в попугаях — она ничего не говорит о том, сколько задача займет времени. Есть множество работ про expert decision making, вкратце — не очень хорошо, особенно в условиях неопределенности (пару статей). Но если использовать статистический подход, то достоверность значительно повышается.
После планирования у вас есть скоуп из разномастных стори, оцененных в попугаях с большой погрешностью. Но ошибки оценки частично компенсируются и, все вместе, деленные на историческую производительность команды, полученную статистически, дают довольно достоверную оценку. ИМО, лучше не брать больше 80% поинтов в спринт: раз на раз не приходится, лучше в спокойном спринте команда поработает над задачами из бэклога на свое усмотрение, порефакторит или поэкспериментирует.
Отвечая на вопрос — нет, я не даю оценку точнее. Но это не имеет значения.
Из каждого утюга слышу про этот Аджайл уже много лет, а на практике ни разу его не видел. Многие гордо заявляют что «мы работаем по Аждайлу», но по факту вся эта аджайловщина оказывается каргокультом с унылыми митингами по утрам, давно выродившимися в ежедневные отчеты руководству. Код, который из-за бесконечных спринтов превратился в огромный воняющий кусок дерьма — некогда рефакторить, некогда писать тесты, надо истерично сколачивать костыли что-бы успеть на очередное демо, грязные хаки не просто допустимы — они приветствуются. Выгоревшие от постоянной штурмовщины программисты с потухшими глазами, мечтающие уже свалить куда-либо с этих долбаных галер… Вот что представляет из себя тот Аджайл, который я видел практически везде.
Ага, а альтернативой является водопад. В котором вы будете месяц читать пикабушечку пока готовится проектная документация. Потом будете усиленно по 12 часов в день лепить костыли, потому что сроки поджимают. А за неделю до релиза узнаете, что в документации серьезный косяк и половину проекта надо переделать.
Это напоминает типичный ответ сектантов от Аджайла на любую критику: «А вот водопад ууу...». Такое ощущение, что существует только белое и черное, и никаких оттенков посередине.
С Аджайлом как-то по-другому? Сначала аналитики точно так-же долго разбираются что там к чему, потом начинается спринтерский забег на костылях, разве что в отличие от водопада у вас не будет проектной документации и вообще уверенности в том что то что вы сейчас делаете не будет выброшено уже завтра. Да и разработчик на весь процесс не особо влияет, некогда ему просто.
А для разработчиков большинство воплощений всех этих практик так вообще беда. Тут хорошая аналогия, КМК, с ресторанным бизнесом. Есть повара, работающие в классических ресторанах, у них при приготовлении блюд есть определенная свобода, они могут как-то менять рецепт и даже придумывать что-то свое. Для бизнеса тут есть определенный риск, может оказаться что повар готовит плохо и клиент уйдет, но с другой стороны… многие клиенты в такие рестораны и ходят только оттого что им нравится как там готовят.
И есть фастфуд вроде Макдональдса, в котором «повар» и на кассе стоит и туалеты моет и котлеты жарит. Там идеально выстроенная потогонная система, в которой у дрессированной мартышки нет возможности сделать ничего не регламентированного. С одной стороны это для бизнеса очень хорошо — стабильное качество, стабильный вкус блюд, минимальный риск напортачить и отравить клиентов. Но с другой стороны — туда ходят что-бы просто быстро перекусить или не рисковать в незнакомом городе или стране, посидеть с друзьями ради удовольствия или поесть что-либо вкусного туда не ходят.
Вот и разработка постепенно приходит к этому макдачному принципу — «коллектив» «дрессированных макак» с суровым надсмотрщиком, производящий программы-гамбургеры для непритязательного потребителя. И менее многочисленные компании «рестораны» в которых разработчиков считают взрослыми и ответственными людьми, которым можно поручить задачи и не контролировать каждый их чих в процессе работы.
А для разработчиков большинство воплощений всех этих практик так вообще беда. Тут хорошая аналогия, КМК, с ресторанным бизнесом. Есть повара, работающие в классических ресторанах, у них при приготовлении блюд есть определенная свобода, они могут как-то менять рецепт и даже придумывать что-то свое. Для бизнеса тут есть определенный риск, может оказаться что повар готовит плохо и клиент уйдет, но с другой стороны… многие клиенты в такие рестораны и ходят только оттого что им нравится как там готовят.
И есть фастфуд вроде Макдональдса, в котором «повар» и на кассе стоит и туалеты моет и котлеты жарит. Там идеально выстроенная потогонная система, в которой у дрессированной мартышки нет возможности сделать ничего не регламентированного. С одной стороны это для бизнеса очень хорошо — стабильное качество, стабильный вкус блюд, минимальный риск напортачить и отравить клиентов. Но с другой стороны — туда ходят что-бы просто быстро перекусить или не рисковать в незнакомом городе или стране, посидеть с друзьями ради удовольствия или поесть что-либо вкусного туда не ходят.
Вот и разработка постепенно приходит к этому макдачному принципу — «коллектив» «дрессированных макак» с суровым надсмотрщиком, производящий программы-гамбургеры для непритязательного потребителя. И менее многочисленные компании «рестораны» в которых разработчиков считают взрослыми и ответственными людьми, которым можно поручить задачи и не контролировать каждый их чих в процессе работы.
> И есть фастфуд вроде Макдональдса, в котором «повар» и на кассе стоит и туалеты моет и котлеты жарит. Там идеально выстроенная потогонная система, в которой у дрессированной мартышки нет возможности сделать ничего не регламентированного.
> Вот и разработка постепенно приходит к этому макдачному принципу — «коллектив» «дрессированных макак» с суровым надсмотрщиком,
Разработка софта никогда не сможет стать просто кулинарией на конвейере: все задачи разные.
В оригинальной статье это уже сказано явно.
> Вот и разработка постепенно приходит к этому макдачному принципу — «коллектив» «дрессированных макак» с суровым надсмотрщиком,
Разработка софта никогда не сможет стать просто кулинарией на конвейере: все задачи разные.
В оригинальной статье это уже сказано явно.
Почему вам некогда рефакторить, некогда писать тесты, надо истерично сколачивать костыли? Почему грязные хаки допустимы? Как это проходит код-ревью? У вас вообще есть код-ревью? Зачем вы что-то штурмуете? При чем тут вообще Agile?
Почему вы задаете столько вопросов, ответы на которые есть в исходном сообщении?
Я еще раз внимательно посмотрел, и не нашел ответ. Вот вы написали код. Не написали тест. Двинули стори дальше. Почему вы двинули ее дальше?
Видимо не внимательно. Я не писал не о нынешней работе, я о тех что вообще видел и с чем сталкивался.
А написать код без теста — когда вам ваш наниматель напрямую говорит что никаких тестов не писать и двигать дальше, то у вас выбор небольшой — или не писать или уходить (что я по совокупности причин в таких местах и делал). Вы с вашими тестами и некостыльным подходом будете ковыряться с задачей неделю, а ваши товарищи по несчастью за это время наговнякают пяток задач на костылях и без тестов. Как вы думаете кем руководство будет недовольно?
Можете мне не объяснять что код покрытый тестами и написанный правильно в конечном итоге себя оправдает, я это и без вас знаю, попробуйте это донести до упертого «манагера», который видит что вы ковыряетесь, а остальная команда бодро рвет упряжку и вы на этих галерах самый тормоз.
А написать код без теста — когда вам ваш наниматель напрямую говорит что никаких тестов не писать и двигать дальше, то у вас выбор небольшой — или не писать или уходить (что я по совокупности причин в таких местах и делал). Вы с вашими тестами и некостыльным подходом будете ковыряться с задачей неделю, а ваши товарищи по несчастью за это время наговнякают пяток задач на костылях и без тестов. Как вы думаете кем руководство будет недовольно?
Можете мне не объяснять что код покрытый тестами и написанный правильно в конечном итоге себя оправдает, я это и без вас знаю, попробуйте это донести до упертого «манагера», который видит что вы ковыряетесь, а остальная команда бодро рвет упряжку и вы на этих галерах самый тормоз.
Обычно в таком случае много багов. Баг дошедший до продакшена стоит сравнительно дорого. Если менеджеру это важно то можно ему показать мере принятые в вашей команде процедуры обратной связи
Если вы не поняли, я вас к этому и подводил. Оказывается, вам не Agile мешает тесты писать, а «манагер». Зачем вы тогда говорите: — Agile?
Скорее это вы все-же не поняли.
У Аджайла та-же беда что и у коммунизма. Это отличная штука, требующая для своего воплощения идеальных людей. С реальными получается как-то не очень.
У Аджайла та-же беда что и у коммунизма. Это отличная штука, требующая для своего воплощения идеальных людей. С реальными получается как-то не очень.
Есть наниматели которые позволяют писать тексты, соглашаются с оценками команды и т.д. возможно вы с ними просто не сталкивались. Если вы сами понимаете что тесты нужны почему вы отказываете в этом другим людям?
Еще раз — я нисколько не сомневаюсь что где-то там в прекрасном мире коммунизма Аджайла, есть фирмы в которых радостные сотрудники весело и с драйвом общаются на ежедневных стендапах, пишут замечательный код, покрытый тестами, при этом у них нет никакой штурмовщины и не копится техдолг. Менеджмент понимает саму суть подхода и не пытается превратить его в потогонку. И прочие розовые единороги.
Я всего-лишь описал свои впечатления от того что видел лично я, возможно мне сильно не повезло, может быть, а может и нет, возможно технология эта в большинстве случаев просто не работает, вырождается в нечто иное, что не предполагалось ее создателями.
Я всего-лишь описал свои впечатления от того что видел лично я, возможно мне сильно не повезло, может быть, а может и нет, возможно технология эта в большинстве случаев просто не работает, вырождается в нечто иное, что не предполагалось ее создателями.
я нисколько не сомневаюсь что где-то там в прекрасном мире
И прочие розовые единороги.
Вот тут я не понимаю что именно вы хотите сказать — то, что такого не бывает, или у вас есть какие-то особенности, по которым именно у вас этого не будет?
возможно технология эта в большинстве случаев просто не работает
Лично меня обычно интересует, работает ли это в моем случае, а не в большинстве (достаточно ли у меня интеллекта, чтобы отличить от подделки, сделать самому или выбрать готовое). Возможно в большинстве случаев то, что люди называют словом "лекарство" не работает — меня интересует могу ли я отличить лекарства которые работают от тех, которые не работают.
Это не так.
UFO just landed and posted this here
А вот у меня самые приятные впечатления остались как раз от «водопада», но в небольшой фирме.
Был хороший баланс между формализацией задачи (было грамотное ТЗ) и свободой разработчика — фактически большая часть решений о реализации была оставлена мне.
Спокойная работа в том ритме который мне более всего комфортен, руководство не устранилось, но и не докучало ежедневным контролем, мне были поставлены сроки и время от времени я сообщал как дело движется. В случае сложностей или непонимания мне всегда было к кому обратиться и обсудить дело.
В итоге задача была сделана качественно, в срок и без стресса для разработчиков.
Аджайл же… даже в самом лучшем из опробованных мной вариантов это какой-то непрекращающийся стресс, когда ты постоянно чувствуешь себя какой-то лошадью в упряжке, которую все время нахлестывают что-бы быстрее бежала. Все решения принимаются наспех, какая-то свобода в планировании своей работы ограничивается выбором следующей задачи из небольшого списка вариантов. Времени не остается ни на спокойный анализ кода, ни на рефакторинг, ни на написание тестов хотя-бы в самых критичных местах.
С этим Аджайлом я уже раз пять выгорал до состояния — «а пошло оно все к ё… й матери», когда уже просто увольняешься не думая о последствиях, чего с «водопадом» у меня не было ни разу, потому что там всегда можно чуток тормознуть и перевести дух.
ИМХО все эти Аджайлы хороши когда надо поработать недолго в режиме штурма — слепить MVP за месяцок, что-бы продемонстрировать его потенциальному заказчику, потом после получения контракта выкинуть этот прототип на помойку и написать нормальную версию без всех эти ритуальных свистоплясок с митингами и прочим.
Был хороший баланс между формализацией задачи (было грамотное ТЗ) и свободой разработчика — фактически большая часть решений о реализации была оставлена мне.
Спокойная работа в том ритме который мне более всего комфортен, руководство не устранилось, но и не докучало ежедневным контролем, мне были поставлены сроки и время от времени я сообщал как дело движется. В случае сложностей или непонимания мне всегда было к кому обратиться и обсудить дело.
В итоге задача была сделана качественно, в срок и без стресса для разработчиков.
Аджайл же… даже в самом лучшем из опробованных мной вариантов это какой-то непрекращающийся стресс, когда ты постоянно чувствуешь себя какой-то лошадью в упряжке, которую все время нахлестывают что-бы быстрее бежала. Все решения принимаются наспех, какая-то свобода в планировании своей работы ограничивается выбором следующей задачи из небольшого списка вариантов. Времени не остается ни на спокойный анализ кода, ни на рефакторинг, ни на написание тестов хотя-бы в самых критичных местах.
С этим Аджайлом я уже раз пять выгорал до состояния — «а пошло оно все к ё… й матери», когда уже просто увольняешься не думая о последствиях, чего с «водопадом» у меня не было ни разу, потому что там всегда можно чуток тормознуть и перевести дух.
ИМХО все эти Аджайлы хороши когда надо поработать недолго в режиме штурма — слепить MVP за месяцок, что-бы продемонстрировать его потенциальному заказчику, потом после получения контракта выкинуть этот прототип на помойку и написать нормальную версию без всех эти ритуальных свистоплясок с митингами и прочим.
Был хороший баланс между формализацией задачи (было грамотное ТЗ) и свободой разработчика
У Вас не водопад)
Водопад потому и водопад, что если нужно что то гибко изменить, то нужно наверх по водопаду запрос посылать, пока не утвердили.
Водопад для того и создали и сейчас используют, чтобы получить на выходе то, что было на входе в тз. А не отсебятину программистов. Хорошо для медицины и космоса. Плохо для инет магазинов.
Возможно это не водопад в чистом виде, а что-то «водопадообразное». Как впрочем и тот Аджайл «не чистый», чаще всего.
Мы, видимо о разном немного. Вы про изменения в ТЗ, я про реализацию этого ТЗ. В реализации, обычно, у разработчика свободы много, в зависимости от детальности ТЗ, но обычно в нем не прописывают уж совсем мелкие подробности, если они не принципиально важны.
К примеру есть требование ТЗ — обеспечить некоторую минимальную скорость обработки данных — задача разработчика применить те технологии, которые эту скорость способны дать (ну или послать аларм руководству, если это невозможно в принципе или слишком дорого для проекта).
Мы, видимо о разном немного. Вы про изменения в ТЗ, я про реализацию этого ТЗ. В реализации, обычно, у разработчика свободы много, в зависимости от детальности ТЗ, но обычно в нем не прописывают уж совсем мелкие подробности, если они не принципиально важны.
К примеру есть требование ТЗ — обеспечить некоторую минимальную скорость обработки данных — задача разработчика применить те технологии, которые эту скорость способны дать (ну или послать аларм руководству, если это невозможно в принципе или слишком дорого для проекта).
Аджайл не бывает чистым. Не верьте сектантам. Это набор практик, помогающие при отсутствии строгого детального тз. То есть не делать жесткую структуру управления, а использовать гибкие методики под разные задачи и разные коллективы.
Родилась практика как ответ на отсутствие нормальных тз и их постоянное изменение.
ТЗ — это техническое задание, то есть о технической реализации.
Часто приходится работать без тз — по функциональному заданию.
То есть просто по описанию, что войдет, что выйдет — без деталей технической реализации — это проще получить от клиента и не нужно отдельного аналитика для создания ТЗ. Но такую работу уже никак нельзя отнести к водопаду.
По любому уже или хаос или что то гибкое)
Родилась практика как ответ на отсутствие нормальных тз и их постоянное изменение.
ТЗ — это техническое задание, то есть о технической реализации.
Часто приходится работать без тз — по функциональному заданию.
То есть просто по описанию, что войдет, что выйдет — без деталей технической реализации — это проще получить от клиента и не нужно отдельного аналитика для создания ТЗ. Но такую работу уже никак нельзя отнести к водопаду.
По любому уже или хаос или что то гибкое)
Скажите честно, поменяй методику и оставь тех же руководителей, что нибудь изменилось бы в этих компаниях?
А сколько аджайлов разных вы видели? Были это снговые или западные компании?
Наши, родные, посконные. Можно списать все на неверную реализацию и русский менталитет, конечно, но я вот уже не первый раз читаю переводную критику, в которой описано все то-же что и видел сам своими глазами.
Видел не так что-бы много что-бы можно было составить серьезную статистику, потому изначально и делал оговорки что это мое субъективное мнение.
Видел не так что-бы много что-бы можно было составить серьезную статистику, потому изначально и делал оговорки что это мое субъективное мнение.
UFO just landed and posted this here
Сам давно мечтаю опробовать хорошую и правильную реализацию Аджайла, но увы. Реальность такая что пока что я видел либо потогонку (причем дурную, работа ради работы) либо карго культ, когда все дружно исполняют ритуалы, как в какой-либо религиозной секте, не задумываясь над тем — а нафига оно все.
Сейчас в принципе в таком-же карго-аджайле, но культ у нас выродился фактически до утренних стендапов, потому оно еще как-то терпимо, нет ни потогонки ни безделья, просто спокойная размеренная работа.
Сейчас в принципе в таком-же карго-аджайле, но культ у нас выродился фактически до утренних стендапов, потому оно еще как-то терпимо, нет ни потогонки ни безделья, просто спокойная размеренная работа.
Наконец-то пробился луч света в наше тёмное царство!
Мы открываем более совершенные методы разработки программного обеспечения… Но дело в том, что когда люди говорят, что Agile относится ко всей организации, это альтернативная история. Это нечестноНе понял, что значит «альтернативная», полез в оригинал — "it’s revisionist history" — и для себя перевёл как "спорное переосмысление начального замысла",
Это нужно сказать: Agile есть и всегда был локальной оптимизацией для небольшого повышения эффективности системы.В самом начале внедрения многие пытались обращать внимание на эти особенности, что для крупной организации Agile плохо приспособлен, что искусственное создание «команд» малоэффективно, но… тогда поезд уже набрал ход и его было не остановить.
Ну и перевод… Через предложения приходиться буквально продираться (особенно в конце), страдая от англицизмов и периодически "переводя назад", чтобы понять что хотел донести автор
UFO just landed and posted this here
UFO just landed and posted this here
Автор говорил о взаимном доверии — наверно, о доверии в том, что каждый стремится к достижению общей цели, как мне кажется. Если цели у разработчика и у руководства разные, то свобода долгоиграющей и всеобщей пользы не принесёт.
Свобода разработчика — не совсем то. Свобода разработчика в условиях обоснованного взаимного доверия между руководством и исполнителями — да, безусловно. Нужно, правда, доверие. И основания для этого доверия. О доверии автор сказал. Основания для доверия — добросовестность разработчиков и единство целей — неявно предполагается (без этого, мне кажется, "Манифест" автоматически становится ложью). Вот об этом — да, говорят редко. Не знаю, почему.
Статью вполне можно выразить известным принципом: «Когда в руках молоток, весь мир состоит из гвоздей». Agile методики (кстати, автор как и много кто еще почему-то отождествляет между собой Agile и SCRAM, что неверно, т.к. кроме SCRAM есть еще много другого тоже Agile) очень даже хороши для определенных задач. Попытка же запихнуть их всюду (вероятно из-за наглядноо успеха в тех областях, где они реально работают) приводит к тому, что с одной стороны проектировать МБР или ПЛАРБ с использованием SCRAM (пример специально утрирован) как бы, мягко говоря, не самая хорошая идея, которая приводит к вполне ожидаемому финалу, а с другой стороны спрос рождает предложение, а потому мы можем наблюдать армию всевозможных консультантов, которые готовы рассказать любому, что именно он не так сделал во внедрении SCRAM, для того чтобы соорудить МБР.
«Путь вперёд — не «Agile против водопада». Это умная стратегическая работа сверху вниз (водопад) с эмпирически-ориентированными тактиками снизу вверх.» — да! об этом же писал недавно в своей статье habr.com/ru/post/458698
UFO just landed and posted this here
Отличная статья — настолько, что огрехи перевода не замечал, пока не прочёл в комментариях.
Каждый раз, как хотел подробно ответить на какой-то комментарий, оказывалось, что всё это уже есть в статье. Редко когда так получается.
Каждый раз, как хотел подробно ответить на какой-то комментарий, оказывалось, что всё это уже есть в статье. Редко когда так получается.
Sign up to leave a comment.
Дорогой Agile, мне надоело притворяться