Комментарии 65
средний генеральный директор читает 60 книг в годНе верю! ©
В году 52 недели. Это или какие-то совсем тоненькие книжки или комиксы…
Кроме того Проект Феникс короткая и простая. Я ее тоже проглотил за пару часов, а вот Цель (The Goal) Голдрата заняла уже больше времени просто потому, что приходилось вникать и задумываться над прочитанным.
Сравнение скачет между туманными характеристиками водопада и гибкой. При этом упоминается только scrum и lean. Отсутствие упоминаний других распространённых методик (XP, Канбан, 6сигм и пр.) говорит, что автор пытался впихнуть невпиху… забивать шурупы и закручивать гвозди, что является источником разочарования в гибких методологиях. Т.е. в одних проектах нужен скрам, в других канбан, а где-то водопадим, господа(гос.проекты в моём субъективном случае).
Это обнажает ещё один глубокий недостаток Agile. Он предполагает, что пользователей можно воспринимать как морских свинок: «Эй, просто используйте этот дерьмовый продукт, тогда мы улучшим его»
Вот тут вообще не понял. Это вы про MVP?
Но с одной мыслью автора, я согласен. Встречается необычайное множество скрам фанатиков (поверхностные менеджеры), которые лепят скрам туда, где его лепить не стоит. Тогда и получается: «До 6ти работаем по скраму, а потом работаем по-настоящему»
В любом случае. Подобные изложения нужны, т.к. они инициируют правильные обсуждения и способствуют обмену опытом(болью)
Канбан, 6сигм
Очень интересно как вы ети методики натянете на разработку ПО?
Реально интересно. Я реально видел ефект в произвотстве, но вразработке ПО?
Если команда адекватная, единственный путь сделать продукт — писать код, а не следовать учениям.
Да запросто, дорожки в джире переименовал и вот вам канбан!
писать код, а не следовать учениям.
Спасибо вам за эту фразу, честно, хоть ктото думает так же. Честно я уже устал удивляться с каким фанатизмом люди превращают все подряд в веру, будь то agile, scrum, mvc или что-то еще. Да в пень это все, давайте уже продукт создавать)
Если вы точно знаете, что надо писать, то конечно вам Agile только мешать будет. Не знаю, как вы, я встречал такое нечасто.
Но если у вас команда — методики только мешают.
Объясню.
Например Бизнес непосредственно ставит задачу тимлиду или ищут решение проблеме (он разбирается в БП компании не хуже бизнеса ). Тимлид видит как интегрировать задачу в существующий продукт. Составляет план, и архитектуру решения.
Представляет задачу и архитектуру решения команде.
Далее команда критикует решение, и они обсуждают недочёты и альтернативные возможности. Пока не достигнут решения. При необходимости анализируются альтернатива и после етого встречаются повторно.
Дальше задача разбивается на более мелкие подзадачи. И при необходимости обсуждаются их детали. Важно, что б все в команде понимали что ми делаем, а не писали функцию или клас.
Дальше тимлид раздает подзадачи с учетом сильных и слабых сторон подчинённых, учитывая важность других текущих задач.(Не знаю как у вас, но редко бывает одна задача в работе.)
Во время работы, тимлид знает кого нужно спросить не нужна ли помощь, кого то нужно подстегнуть и тд. По ходу продвижения работ меняет при необходимости как подзадачи так и исполнителей. И да он тоже в задаче.
Если проект большой, можно раз в недельку собраться, но как правило все в одном месте и перекликнутся, или попросить о помощи куда ефективнее.
И да команда это не только работа, а и вместе дни рождения, футбол, пикники, поездки по грибы,…
И даже если в пылу разговора кто-то кого-то послал то это означает что нужно разойтись и через полчаса обсудить повторно.
Хотя я согласен, что в больших IT компаниях с большим числом заказчиков и продуктов, наверное по другому не работает.
По моему опыту, Аджайл прекрасно работает как раз в продуктовых компаниях, особенно B2C, с сильными командами.
Это работает только при массовом клепании Однотипных Форм (тм).Уж точно нет.
Бизнес не знает, как решить проблему.Так значит и нет задач.
Тимлид не видит (почему, кстати, тимлид?)Согласен не тимлид. (но назовите как хотите архитектор+тимлид+ начальник оттела разработки, суть то не меняет )
как интегрировать в систему.
Ну уж если он не видит то усе… смисла в отделе нет. И тут уже ничто не поможет ни скрам ни Аджайл ни Менеджер.
Оценки, как всегда, ошибаются в 2,5 раза
Та ладно ви точноее даете оценку? если да то сколько занимает процес оценки? Или по скраму сбросились фантиками и большинство оценило?
Так от, если процес оценки занимает больше 1 часа команды или емеет допуск боле 50% есть ли смисл?
Или вообще никто подобных задач не делал,
И как в етом поможет Аджайл?
конечный результат мало кто себе переставляет
Если так, то какой смисл начинать?
И как в етом поможет Аджайл?
Разработчики не хотят делать навязанные им задачи, а хотят развиваться
то есть отсутствие каноничного Аджайл подразумевает по умолчанию бардак?
Интересная мысль.
Джуны боятся сказать о проблеме и тянут до последнего
Во время работы, тимлид знает кого нужно спросить не нужна ли помощь, кого то нужно подстегнуть и тд.
Результат всегда оказывается не тем, что все себе переставляли.Как я уже писал НЕЛЬЗЯ Начинать проек не представляя конечного результата. И ето железное правило.
на реальных примерах и со статистикойНу да есть Правда, Лож и Статистика. :)
К примеру:
Та ладно ви точноее даете оценку? если да то сколько занимает процес оценки?До оценки всем членам команды должно быть понятно, что требуется иначе стори в спринт не пойдет. Если много задач уходит на доработку или груминг занимает много времени — значит или стори плохо проработаны, или процесс плохо организован (вот вам сразу и сигнал управления). Тайная оценка дает второй чек — что все действительно понимают задачу, минус authority bias, cognitive bias. От себя добавлю — еще и третий чек, что народ не спит и не дает оценки «как все».
Оценка неспроста рекомендуется в попугаях — она ничего не говорит о том, сколько задача займет времени. Есть множество работ про expert decision making, вкратце — не очень хорошо, особенно в условиях неопределенности (пару статей). Но если использовать статистический подход, то достоверность значительно повышается.
После планирования у вас есть скоуп из разномастных стори, оцененных в попугаях с большой погрешностью. Но ошибки оценки частично компенсируются и, все вместе, деленные на историческую производительность команды, полученную статистически, дают довольно достоверную оценку. ИМО, лучше не брать больше 80% поинтов в спринт: раз на раз не приходится, лучше в спокойном спринте команда поработает над задачами из бэклога на свое усмотрение, порефакторит или поэкспериментирует.
Отвечая на вопрос — нет, я не даю оценку точнее. Но это не имеет значения.
А для разработчиков большинство воплощений всех этих практик так вообще беда. Тут хорошая аналогия, КМК, с ресторанным бизнесом. Есть повара, работающие в классических ресторанах, у них при приготовлении блюд есть определенная свобода, они могут как-то менять рецепт и даже придумывать что-то свое. Для бизнеса тут есть определенный риск, может оказаться что повар готовит плохо и клиент уйдет, но с другой стороны… многие клиенты в такие рестораны и ходят только оттого что им нравится как там готовят.
И есть фастфуд вроде Макдональдса, в котором «повар» и на кассе стоит и туалеты моет и котлеты жарит. Там идеально выстроенная потогонная система, в которой у дрессированной мартышки нет возможности сделать ничего не регламентированного. С одной стороны это для бизнеса очень хорошо — стабильное качество, стабильный вкус блюд, минимальный риск напортачить и отравить клиентов. Но с другой стороны — туда ходят что-бы просто быстро перекусить или не рисковать в незнакомом городе или стране, посидеть с друзьями ради удовольствия или поесть что-либо вкусного туда не ходят.
Вот и разработка постепенно приходит к этому макдачному принципу — «коллектив» «дрессированных макак» с суровым надсмотрщиком, производящий программы-гамбургеры для непритязательного потребителя. И менее многочисленные компании «рестораны» в которых разработчиков считают взрослыми и ответственными людьми, которым можно поручить задачи и не контролировать каждый их чих в процессе работы.
> Вот и разработка постепенно приходит к этому макдачному принципу — «коллектив» «дрессированных макак» с суровым надсмотрщиком,
Разработка софта никогда не сможет стать просто кулинарией на конвейере: все задачи разные.
В оригинальной статье это уже сказано явно.
А написать код без теста — когда вам ваш наниматель напрямую говорит что никаких тестов не писать и двигать дальше, то у вас выбор небольшой — или не писать или уходить (что я по совокупности причин в таких местах и делал). Вы с вашими тестами и некостыльным подходом будете ковыряться с задачей неделю, а ваши товарищи по несчастью за это время наговнякают пяток задач на костылях и без тестов. Как вы думаете кем руководство будет недовольно?
Можете мне не объяснять что код покрытый тестами и написанный правильно в конечном итоге себя оправдает, я это и без вас знаю, попробуйте это донести до упертого «манагера», который видит что вы ковыряетесь, а остальная команда бодро рвет упряжку и вы на этих галерах самый тормоз.
Обычно в таком случае много багов. Баг дошедший до продакшена стоит сравнительно дорого. Если менеджеру это важно то можно ему показать мере принятые в вашей команде процедуры обратной связи
У Аджайла та-же беда что и у коммунизма. Это отличная штука, требующая для своего воплощения идеальных людей. С реальными получается как-то не очень.
Есть наниматели которые позволяют писать тексты, соглашаются с оценками команды и т.д. возможно вы с ними просто не сталкивались. Если вы сами понимаете что тесты нужны почему вы отказываете в этом другим людям?
Я всего-лишь описал свои впечатления от того что видел лично я, возможно мне сильно не повезло, может быть, а может и нет, возможно технология эта в большинстве случаев просто не работает, вырождается в нечто иное, что не предполагалось ее создателями.
я нисколько не сомневаюсь что где-то там в прекрасном мире
И прочие розовые единороги.
Вот тут я не понимаю что именно вы хотите сказать — то, что такого не бывает, или у вас есть какие-то особенности, по которым именно у вас этого не будет?
возможно технология эта в большинстве случаев просто не работает
Лично меня обычно интересует, работает ли это в моем случае, а не в большинстве (достаточно ли у меня интеллекта, чтобы отличить от подделки, сделать самому или выбрать готовое). Возможно в большинстве случаев то, что люди называют словом "лекарство" не работает — меня интересует могу ли я отличить лекарства которые работают от тех, которые не работают.
Был хороший баланс между формализацией задачи (было грамотное ТЗ) и свободой разработчика — фактически большая часть решений о реализации была оставлена мне.
Спокойная работа в том ритме который мне более всего комфортен, руководство не устранилось, но и не докучало ежедневным контролем, мне были поставлены сроки и время от времени я сообщал как дело движется. В случае сложностей или непонимания мне всегда было к кому обратиться и обсудить дело.
В итоге задача была сделана качественно, в срок и без стресса для разработчиков.
Аджайл же… даже в самом лучшем из опробованных мной вариантов это какой-то непрекращающийся стресс, когда ты постоянно чувствуешь себя какой-то лошадью в упряжке, которую все время нахлестывают что-бы быстрее бежала. Все решения принимаются наспех, какая-то свобода в планировании своей работы ограничивается выбором следующей задачи из небольшого списка вариантов. Времени не остается ни на спокойный анализ кода, ни на рефакторинг, ни на написание тестов хотя-бы в самых критичных местах.
С этим Аджайлом я уже раз пять выгорал до состояния — «а пошло оно все к ё… й матери», когда уже просто увольняешься не думая о последствиях, чего с «водопадом» у меня не было ни разу, потому что там всегда можно чуток тормознуть и перевести дух.
ИМХО все эти Аджайлы хороши когда надо поработать недолго в режиме штурма — слепить MVP за месяцок, что-бы продемонстрировать его потенциальному заказчику, потом после получения контракта выкинуть этот прототип на помойку и написать нормальную версию без всех эти ритуальных свистоплясок с митингами и прочим.
Был хороший баланс между формализацией задачи (было грамотное ТЗ) и свободой разработчика
У Вас не водопад)
Водопад потому и водопад, что если нужно что то гибко изменить, то нужно наверх по водопаду запрос посылать, пока не утвердили.
Водопад для того и создали и сейчас используют, чтобы получить на выходе то, что было на входе в тз. А не отсебятину программистов. Хорошо для медицины и космоса. Плохо для инет магазинов.
Мы, видимо о разном немного. Вы про изменения в ТЗ, я про реализацию этого ТЗ. В реализации, обычно, у разработчика свободы много, в зависимости от детальности ТЗ, но обычно в нем не прописывают уж совсем мелкие подробности, если они не принципиально важны.
К примеру есть требование ТЗ — обеспечить некоторую минимальную скорость обработки данных — задача разработчика применить те технологии, которые эту скорость способны дать (ну или послать аларм руководству, если это невозможно в принципе или слишком дорого для проекта).
Родилась практика как ответ на отсутствие нормальных тз и их постоянное изменение.
ТЗ — это техническое задание, то есть о технической реализации.
Часто приходится работать без тз — по функциональному заданию.
То есть просто по описанию, что войдет, что выйдет — без деталей технической реализации — это проще получить от клиента и не нужно отдельного аналитика для создания ТЗ. Но такую работу уже никак нельзя отнести к водопаду.
По любому уже или хаос или что то гибкое)
А сколько аджайлов разных вы видели? Были это снговые или западные компании?
Видел не так что-бы много что-бы можно было составить серьезную статистику, потому изначально и делал оговорки что это мое субъективное мнение.
Сейчас в принципе в таком-же карго-аджайле, но культ у нас выродился фактически до утренних стендапов, потому оно еще как-то терпимо, нет ни потогонки ни безделья, просто спокойная размеренная работа.
Мы открываем более совершенные методы разработки программного обеспечения… Но дело в том, что когда люди говорят, что Agile относится ко всей организации, это альтернативная история. Это нечестноНе понял, что значит «альтернативная», полез в оригинал — "it’s revisionist history" — и для себя перевёл как "спорное переосмысление начального замысла",
Это нужно сказать: Agile есть и всегда был локальной оптимизацией для небольшого повышения эффективности системы.В самом начале внедрения многие пытались обращать внимание на эти особенности, что для крупной организации Agile плохо приспособлен, что искусственное создание «команд» малоэффективно, но… тогда поезд уже набрал ход и его было не остановить.
Ну и перевод… Через предложения приходиться буквально продираться (особенно в конце), страдая от англицизмов и периодически "переводя назад", чтобы понять что хотел донести автор
Автор говорил о взаимном доверии — наверно, о доверии в том, что каждый стремится к достижению общей цели, как мне кажется. Если цели у разработчика и у руководства разные, то свобода долгоиграющей и всеобщей пользы не принесёт.
Свобода разработчика — не совсем то. Свобода разработчика в условиях обоснованного взаимного доверия между руководством и исполнителями — да, безусловно. Нужно, правда, доверие. И основания для этого доверия. О доверии автор сказал. Основания для доверия — добросовестность разработчиков и единство целей — неявно предполагается (без этого, мне кажется, "Манифест" автоматически становится ложью). Вот об этом — да, говорят редко. Не знаю, почему.
Каждый раз, как хотел подробно ответить на какой-то комментарий, оказывалось, что всё это уже есть в статье. Редко когда так получается.
Дорогой Agile, мне надоело притворяться