Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
Спасибо, но такое надо в пятницу выкладывать ;-)
Классно! Спасибо!
Рассказ прикольный, только имхо он в первую очередь про то, как можно испортить полезную вещь, забывши про RTFM… :)
Почему «Agile мотивирует нас принимать… легковесные решения»? Быстрые — да. А легковесные-то почему? Кто запрещает ещё и думать при этом? :) Если нужное решение не нашлось — ну перенесли задачу на следующий спринт, а на текущем выделили время на её дополнительную проработку в виде отдельной подзадачи…
Про краткосрочность проектов тоже не очевидно. Знаю проекты по рефакторингу крупных систем, которые месяцами, если не годами, живут по аджайлу, и вроде нормально живут: заказчики довольны, фичи новые внедряются…
Аджайл — это просто принцип, и отключение головы в нём не предусмотрено :) Если нужен на проекте архитектор — значит нужно, чтобы команда была им укомплектована. Если разработчиков много — значит нужны лиды в необходимом количестве и время у них на то, чтобы менторить и ревьюить всё, что надо. И надо, чтобы каждый понимал, за что отвечает лично он, и за что — его смежник. И чтобы матрица эта была без пустот… И всё норм будет… :)
Почему «Agile мотивирует нас принимать… легковесные решения»? Быстрые — да. А легковесные-то почему? Кто запрещает ещё и думать при этом? :) Если нужное решение не нашлось — ну перенесли задачу на следующий спринт, а на текущем выделили время на её дополнительную проработку в виде отдельной подзадачи…
Про краткосрочность проектов тоже не очевидно. Знаю проекты по рефакторингу крупных систем, которые месяцами, если не годами, живут по аджайлу, и вроде нормально живут: заказчики довольны, фичи новые внедряются…
Аджайл — это просто принцип, и отключение головы в нём не предусмотрено :) Если нужен на проекте архитектор — значит нужно, чтобы команда была им укомплектована. Если разработчиков много — значит нужны лиды в необходимом количестве и время у них на то, чтобы менторить и ревьюить всё, что надо. И надо, чтобы каждый понимал, за что отвечает лично он, и за что — его смежник. И чтобы матрица эта была без пустот… И всё норм будет… :)
Вы всё правильно говорите. Только я ведь не про Аджайл писал, в общем-то. Неважно, какая технология разработки используется, главное – чтобы решения принимались продуманно и ответственно.
Да я понимаю. Статья — про внедрятелей новых методологий с дефицитом ресурса на «подумать» :)
Вот за «дефицит подумать» совсем не факт, кстати.
Кейзы типа «у нас все сложно, нам нужно больше людей, а поскольку я манагер, то с большим количеством людей я буду более важным манагером с большими бюджетами» или «наши пару куюэев вообще не справляются, но тут есть фирмочка (к котороя я и моя маленькая южная семья не имеет никакого отнощения) и там буквальна за 5 мин (максимум за пару лет) 300 загорелых спартанцев все потестят» — их никто не отменял ;)
Кейзы типа «у нас все сложно, нам нужно больше людей, а поскольку я манагер, то с большим количеством людей я буду более важным манагером с большими бюджетами» или «наши пару куюэев вообще не справляются, но тут есть фирмочка (к котороя я и моя маленькая южная семья не имеет никакого отнощения) и там буквальна за 5 мин (максимум за пару лет) 300 загорелых спартанцев все потестят» — их никто не отменял ;)
Аджайл это не быстро, это гибко и дорого!
Документация должна быть. точка. И не важно это аджаил, водопад или что-то другое.
Должна быть. И на холивары ушло больше времени чем на написание самой документации. Только читая манифест Agile люди, переиначивают пункт «Рабочий софт важнее всеобъемлющей документации» по своему, просто обрезая до «документация не нужна».
Везде где я работал, документация была краеугольным камнем + дополнительно всегда требовалось документировать код продукта и тестов. У меня даже привычка выработалась, начинаю писать функцию, сразу пишу ее шапку в которой описываю для чего она нужна, все входные и выходные параметры. В итоге это занимает минимум времени, зато потом если возврщаюсь к ней — все прозрачно. Поэтому страннослышать, что где-то нет документации. Но это скорее мой опыт и у кого-то может быть другой. Не скрою часто встречал документацию для галочки особенно на наших оборонных предприятиях и приходилось из них ее клещами вытаскивать с тех пор зарекся работать в проектах с такими закзчиками.
Отличная статья! Разделяю боль. Я как и вы не против Agile. Да только настоящего. Прямо по манифест плюс естественно свои мысли. И мысли могут и полностью отменить все догмы. Или поддержать и дополнить. Или для одного проекта поддержать, а для другого разнести в пух и прах. Agile ведь. А как вы думали? Четыре чувака собрались и сказали это хорошо… И все? Да фиг им просто из чувства противоречия. Причем если я скажу свои хотели, то меня тапками закидают.… И будут правы!
Нет и не может быть единственно верной "методологии программирования". История та же, что и с теорией музыки. Вроде работает. Но если хочется, то и нарушить не грех.
Я не совсем, понял причем тут Agile. Если product owner девочка (ну или мальчик, всё равно), которая не может ответить на простой пример. Если скрам-мастер, не может обеспечить данными для тестирования, то это скорее говорит о полной некомпетентности людей. И не важно по какой системе они работают. Такие люди любой проект превратят в балаган, только будут его называть не Agile/Scrum, а «иновационной методологией, основанной на интеграции концепций»
Да, вы правы, конечно.
Я, собственно, не про технологии писал. Я хотел сказать, что в отличие от бизнеса, для разработчика самым важным критерием является качество. Это то, чем человек может гордиться в будущем. Когда вам приходится скрепя сердце выполнять решение, калечащее ваш проект, вам ведь нелегко, правда? Поэтому разработчик должен по возможности противиться непродуманным решениям.
Я, собственно, не про технологии писал. Я хотел сказать, что в отличие от бизнеса, для разработчика самым важным критерием является качество. Это то, чем человек может гордиться в будущем. Когда вам приходится скрепя сердце выполнять решение, калечащее ваш проект, вам ведь нелегко, правда? Поэтому разработчик должен по возможности противиться непродуманным решениям.
А разве входит в роль скрам-мастера обеспечение тестовыми данными? Как мне казалось, его основная задача — модерирование скрам-процессов, следит за тем, чтобы далеко не отклонялись от соглашений без формального их пересмотра.
Главное, чтобы проект из agile не стал fragile.
Есть цели, требования, задачи и здравый смысл.
Процесс должен быть такой, чтобы достигались цели (на разных уровнях), требования удовлетворялись по максимуму, а задачи — делались. Но не в ущерб здравому смыслу.
Все остальное второстепенно.
Процесс должен быть такой, чтобы достигались цели (на разных уровнях), требования удовлетворялись по максимуму, а задачи — делались. Но не в ущерб здравому смыслу.
Все остальное второстепенно.
Есть цели, требования, задачи и здравый смысл
Это точка зрения бизнеса. Конечная цель – максимум прибыли. И это правильно. Мне, как разработчику, эта цель тоже близка, потому что я тоже заинтересован в успехе продукта.
Но у меня есть и другая цель. Мне важно, чтобы мой проект был гармоничным, я хочу стремиться к совершенству. Я хочу, чтобы я мог гордиться тем, что сделал, чтобы люди могли сказать: «О, смотрите, этот парень сделал крутую вещь! ».
И тут порой бывает так, что мои интересы противоречат интересам бизнеса. Бизнесу может быть нужно сделать что-то вот прямо сейчас. Бизнес не интересуют мои амбиции. Бизнес может не волновать внутреннее качество продукта, если в данный момент удовлетворение клиента важнее возможных противоречий и несогласованностей в системе.
Про этот конфликт интересов я и хотел сказать. Судя по всему, мне это не очень удалось. Если подскажете, как можно переработать статью и стоит ли вообще это делать – буду признателен.
Порой решения принимаются по организационным мотивамКлассика же — закон Конвея.
Организация которая разрабатывает систему… вынуждена делать систему, по структуре повторяющую структуру коммуникаций внутри организации
В том то и дело, что «вынуждена». Но вот правильно ли это — большой вопрос…
Я считаю, что правильно. Чем более команды разделены организационно, тем более необходимо разделение кода, который они пишут. Иначе разработка не будет управляемой.
Если требуется рефакторить приложение, нужно рефакторить и орг. структуру компании.
Если требуется рефакторить приложение, нужно рефакторить и орг. структуру компании.
Вот тут-то и возникает тот конфликт интересов, о котором я писал.
Готов понять обоснованность такого решения, но когда вижу, что проект разрублен топором по живому, для меня это что нож в сердце. Да, в организационном плане, возможно, выиграли, но гармония уже нарушена.
А потом вдруг организационная структура изменится, так что, опять кромсачить будем?
Готов понять обоснованность такого решения, но когда вижу, что проект разрублен топором по живому, для меня это что нож в сердце. Да, в организационном плане, возможно, выиграли, но гармония уже нарушена.
А потом вдруг организационная структура изменится, так что, опять кромсачить будем?
По-хорошему, надо орг. структуру кромсать под архитектуру программы. Но поскольку люди не особо желают бегать между командами и руководителями, можно просто передавать реализацию функциональности команде, которая ответственна за модуль, где эта функциональность должна быть архитектурно.
Хотя, тут снова конфликт интересов — команда, которая не заинтересована в навязанной ей ф-сти, может сделать её криво или не в те сроки, которые ожидаются. Так что да, рубить проект на корявые куски может быть лучшим решением. Что делать, если бы разрабатывалось в одиночку и для себя, можно сколько угодно корпеть над идеальными решениями. Но при разработке большими командами — только так (мой модуль — не лезь в него), иначе ты можешь долго всё вылизывать, а соседи-индусы завтра навалят говнокода.
Хотя, тут снова конфликт интересов — команда, которая не заинтересована в навязанной ей ф-сти, может сделать её криво или не в те сроки, которые ожидаются. Так что да, рубить проект на корявые куски может быть лучшим решением. Что делать, если бы разрабатывалось в одиночку и для себя, можно сколько угодно корпеть над идеальными решениями. Но при разработке большими командами — только так (мой модуль — не лезь в него), иначе ты можешь долго всё вылизывать, а соседи-индусы завтра навалят говнокода.
Однозначного ответа точно нет. Это сильно зависит от важности системы для компании. Одно дело если это компания одного продукта, и совсем другое если эта система лишь одна из сотен, которых компания делает.
Когда изучаешь новомодные технологии, надо понимать, что там очень мало нового (обычно вообще ничего) и очень много маркетинга. Ведь за любым брендом стоят лекции, вебинары, курсы, книги: и все это приносит хороший доход. Поэтому на Западе очень любят взять старую идею и выдать ее за что-то новое.
Насчет, является ли Agile новым подходом. На любом заводе был опытный цех, где работали фактически по Agile. Но готовые изделия уже по документации готовили. И еще: городской человеческой цивилизации как минимум несколько тысяч лет. Построено за эти века очень много: и пирамиды, и каналы, и корабли, и в космос летали. А это все — управление проектами. И только наивные могут полагать, что можно изобрести действительно новый метод управления
Насчет, является ли Agile новым подходом. На любом заводе был опытный цех, где работали фактически по Agile. Но готовые изделия уже по документации готовили. И еще: городской человеческой цивилизации как минимум несколько тысяч лет. Построено за эти века очень много: и пирамиды, и каналы, и корабли, и в космос летали. А это все — управление проектами. И только наивные могут полагать, что можно изобрести действительно новый метод управления
Согласен. Во многих новомодных технологиях производства часто больше идеологической мишуры, чем дела. А примеры самоорганизующихся команд-артелей можно найти и в глубокой древности.
Так Agile это не про управление классическими проектами. В классических проектах изменения, как минимум, скоупа работ, требований — форс-мажорное обстоятельство.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дневник разработчика или Плохие решения