Interfaces
Development Management
Project management
Agile
Product Management
Comments 65
+23
И можно начинать с того, что Agile стал своего рода флагом, под который встала целая индустрия. Но, как ни странно, не индустрия разработки ПО, а индустрия Agile коучей, для которых Agile-хайп просто бизнес, и ничего личного.
+1
И судя по тому что я вижу и читаю — этот флаг радужный… Соответственно все эти… коучи.)) Не ну серьезно… Бред это все. Метод работы сделали блин древнекитайской философией какой-то.
+3
Официальной датой провала любой методологии можно считать день, когда на Амазоне появляется баннер «100 лучших книг о ...».
+3
средний генеральный директор читает 60 книг в год
Не верю! ©
В году 52 недели. Это или какие-то совсем тоненькие книжки или комиксы…
+1
смотря что и как читать

сайты специальные есть — там краткое содержание таких книг приводится

увы, львиная доля современных книг «по бизнесу» это 1-2 страницы «полуторным интервалом в ворде» реальных мыслей. остальное всё — бесконечная вода, которая к делу не относится
+1
Я совсем не менеджер и не скорочиталец, но для примера, я читал на днях проект феникс, киндл нарисовал мне 3.5 часа до конца книги. Я около часа еду на работу и обратно. За 2 дня я прочитал книгу. это уже больше 52 в год. Было бы желание.
+3
Прочитать книгу за два дня — плевое дело. Читать по книге каждые два дня на протяжении года — совсем другая истоиря.
0
Читаю постоянно, 70% худ. литература, 30% всякое по айти. вполне хорошо себя чувствую. Час смотреть в окно, не ок.
+2
Оффтоп
«Проект Феникс» — это «Роман о том, как DevOps меняет бизнес к лучшему»? Как осиливать ~350 страниц за ~4 часа, при этом не будучи «скорочитальцем»? Я читал, наверное, пару недель, хотя тоже читаю по дороге, примерно 1,5 часа в день
+1
Мне после прочтения «серьезной литературы» требуется еще день-два на усвоение прочитанного. В это время мой мозг способен воспринимать только литературу уровня попаданцев в ЛитРПГ (немного утрирую).
Кроме того Проект Феникс короткая и простая. Я ее тоже проглотил за пару часов, а вот Цель (The Goal) Голдрата заняла уже больше времени просто потому, что приходилось вникать и задумываться над прочитанным.
0
Так никто и не спорит, что нужно пару дней обдумать, там в запасе после 2х еще 5. Я тоже не читаю подряд не художественные книги, бывает, что даже по главам разбиваю. Вопрос был в том, можно ли читать 52 книги в год, можно, даже больше.
-2
Статья излагает ошибочное мнение автора основанное на поверхностных знаниях предмета и собственных заблуждениях.

Сравнение скачет между туманными характеристиками водопада и гибкой. При этом упоминается только scrum и lean. Отсутствие упоминаний других распространённых методик (XP, Канбан, 6сигм и пр.) говорит, что автор пытался впихнуть невпиху… забивать шурупы и закручивать гвозди, что является источником разочарования в гибких методологиях. Т.е. в одних проектах нужен скрам, в других канбан, а где-то водопадим, господа(гос.проекты в моём субъективном случае).

Это обнажает ещё один глубокий недостаток Agile. Он предполагает, что пользователей можно воспринимать как морских свинок: «Эй, просто используйте этот дерьмовый продукт, тогда мы улучшим его»

Вот тут вообще не понял. Это вы про MVP?

Но с одной мыслью автора, я согласен. Встречается необычайное множество скрам фанатиков (поверхностные менеджеры), которые лепят скрам туда, где его лепить не стоит. Тогда и получается: «До 6ти работаем по скраму, а потом работаем по-настоящему»

В любом случае. Подобные изложения нужны, т.к. они инициируют правильные обсуждения и способствуют обмену опытом(болью)
+6
Канбан, 6сигм

Очень интересно как вы ети методики натянете на разработку ПО?
Реально интересно. Я реально видел ефект в произвотстве, но вразработке ПО?
Если команда адекватная, единственный путь сделать продукт — писать код, а не следовать учениям.

+5

Да запросто, дорожки в джире переименовал и вот вам канбан!

0
Канбан применить просто — там где есть затраты времени на переход задачи между людьми или отделами — канбан помогает это находить и убирать узкие места. Хорошо работает с повторяющимися задачами или повторяющимися процессами.
+3
писать код, а не следовать учениям.

Спасибо вам за эту фразу, честно, хоть ктото думает так же. Честно я уже устал удивляться с каким фанатизмом люди превращают все подряд в веру, будь то agile, scrum, mvc или что-то еще. Да в пень это все, давайте уже продукт создавать)
0
Чтобы его выкинуть. Что почти всегда неотвратимо, вопрос только в объемах выкидываемого.
Если вы точно знаете, что надо писать, то конечно вам Agile только мешать будет. Не знаю, как вы, я встречал такое нечасто.
-1
Как по мне, эти все методики нужны для управления не командами, а случайными программистами, которих собрали для проекта.
Но если у вас команда — методики только мешают.
Объясню.
Например Бизнес непосредственно ставит задачу тимлиду или ищут решение проблеме (он разбирается в БП компании не хуже бизнеса ). Тимлид видит как интегрировать задачу в существующий продукт. Составляет план, и архитектуру решения.
Представляет задачу и архитектуру решения команде.
Далее команда критикует решение, и они обсуждают недочёты и альтернативные возможности. Пока не достигнут решения. При необходимости анализируются альтернатива и после етого встречаются повторно.
Дальше задача разбивается на более мелкие подзадачи. И при необходимости обсуждаются их детали. Важно, что б все в команде понимали что ми делаем, а не писали функцию или клас.

Дальше тимлид раздает подзадачи с учетом сильных и слабых сторон подчинённых, учитывая важность других текущих задач.(Не знаю как у вас, но редко бывает одна задача в работе.)

Во время работы, тимлид знает кого нужно спросить не нужна ли помощь, кого то нужно подстегнуть и тд. По ходу продвижения работ меняет при необходимости как подзадачи так и исполнителей. И да он тоже в задаче.

Если проект большой, можно раз в недельку собраться, но как правило все в одном месте и перекликнутся, или попросить о помощи куда ефективнее.

И да команда это не только работа, а и вместе дни рождения, футбол, пикники, поездки по грибы,…
И даже если в пылу разговора кто-то кого-то послал то это означает что нужно разойтись и через полчаса обсудить повторно.

Хотя я согласен, что в больших IT компаниях с большим числом заказчиков и продуктов, наверное по другому не работает.

0
Это работает только при массовом клепании Однотипных Форм (тм). Бизнес не знает, как решить проблему. Тимлид не видит (почему, кстати, тимлид?), как интегрировать в систему. Оценки, как всегда, ошибаются в 2,5 раза. Или вообще никто подобных задач не делал, конечный результат мало кто себе переставляет. Разработчики не хотят делать навязанные им задачи, а хотят развиваться. Джуны боятся сказать о проблеме и тянут до последнего. Результат всегда оказывается не тем, что все себе переставляли. Ничто не ново под луной, все прекрасно описано, на реальных примерах и со статистикой, Макконнеллом, Вигерсом, Фаулером и пр.
По моему опыту, Аджайл прекрасно работает как раз в продуктовых компаниях, особенно B2C, с сильными командами.
0
Это работает только при массовом клепании Однотипных Форм (тм).
Уж точно нет.
Бизнес не знает, как решить проблему.
Так значит и нет задач.
Тимлид не видит (почему, кстати, тимлид?)
Согласен не тимлид. (но назовите как хотите архитектор+тимлид+ начальник оттела разработки, суть то не меняет )
как интегрировать в систему.

Ну уж если он не видит то усе… смисла в отделе нет. И тут уже ничто не поможет ни скрам ни Аджайл ни Менеджер.
Оценки, как всегда, ошибаются в 2,5 раза

Та ладно ви точноее даете оценку? если да то сколько занимает процес оценки? Или по скраму сбросились фантиками и большинство оценило?
Так от, если процес оценки занимает больше 1 часа команды или емеет допуск боле 50% есть ли смисл?
Или вообще никто подобных задач не делал,

И как в етом поможет Аджайл?
конечный результат мало кто себе переставляет

Если так, то какой смисл начинать?
И как в етом поможет Аджайл?
Разработчики не хотят делать навязанные им задачи, а хотят развиваться

то есть отсутствие каноничного Аджайл подразумевает по умолчанию бардак?
Интересная мысль.

Джуны боятся сказать о проблеме и тянут до последнего
Во время работы, тимлид знает кого нужно спросить не нужна ли помощь, кого то нужно подстегнуть и тд.

Результат всегда оказывается не тем, что все себе переставляли.
Как я уже писал НЕЛЬЗЯ Начинать проек не представляя конечного результата. И ето железное правило.
на реальных примерах и со статистикой
Ну да есть Правда, Лож и Статистика. :)

0
У меня складывается впечатление, что вы не очень знакомы с развитием методологий разработки ПО, предпосылками появления Agile, какие проблемы он призван решать и как. Ответ на ваши вопросы потянет на добрую статью, и не одну. К счастью, вы можете найти все ответы прямо здесь, на Хабре, а так же кучу обоснованной критики Agile, в том числе от пользователь в комментариях.
К примеру:
Та ладно ви точноее даете оценку? если да то сколько занимает процес оценки?
До оценки всем членам команды должно быть понятно, что требуется иначе стори в спринт не пойдет. Если много задач уходит на доработку или груминг занимает много времени — значит или стори плохо проработаны, или процесс плохо организован (вот вам сразу и сигнал управления). Тайная оценка дает второй чек — что все действительно понимают задачу, минус authority bias, cognitive bias. От себя добавлю — еще и третий чек, что народ не спит и не дает оценки «как все».
Оценка неспроста рекомендуется в попугаях — она ничего не говорит о том, сколько задача займет времени. Есть множество работ про expert decision making, вкратце — не очень хорошо, особенно в условиях неопределенности (пару статей). Но если использовать статистический подход, то достоверность значительно повышается.
После планирования у вас есть скоуп из разномастных стори, оцененных в попугаях с большой погрешностью. Но ошибки оценки частично компенсируются и, все вместе, деленные на историческую производительность команды, полученную статистически, дают довольно достоверную оценку. ИМО, лучше не брать больше 80% поинтов в спринт: раз на раз не приходится, лучше в спокойном спринте команда поработает над задачами из бэклога на свое усмотрение, порефакторит или поэкспериментирует.
Отвечая на вопрос — нет, я не даю оценку точнее. Но это не имеет значения.
+23
Из каждого утюга слышу про этот Аджайл уже много лет, а на практике ни разу его не видел. Многие гордо заявляют что «мы работаем по Аждайлу», но по факту вся эта аджайловщина оказывается каргокультом с унылыми митингами по утрам, давно выродившимися в ежедневные отчеты руководству. Код, который из-за бесконечных спринтов превратился в огромный воняющий кусок дерьма — некогда рефакторить, некогда писать тесты, надо истерично сколачивать костыли что-бы успеть на очередное демо, грязные хаки не просто допустимы — они приветствуются. Выгоревшие от постоянной штурмовщины программисты с потухшими глазами, мечтающие уже свалить куда-либо с этих долбаных галер… Вот что представляет из себя тот Аджайл, который я видел практически везде.
-1
Ага, а альтернативой является водопад. В котором вы будете месяц читать пикабушечку пока готовится проектная документация. Потом будете усиленно по 12 часов в день лепить костыли, потому что сроки поджимают. А за неделю до релиза узнаете, что в документации серьезный косяк и половину проекта надо переделать.
+4
Это напоминает типичный ответ сектантов от Аджайла на любую критику: «А вот водопад ууу...». Такое ощущение, что существует только белое и черное, и никаких оттенков посередине.
0
Думаю, все зависит от того, откуда растут руки (и где находится мозг) у менеджера. А мы знаем как обстоит дело в большинстве случаев.
Я просто в ответ на плохой сценарий в аджайле хотел показать плохой сценарий при водопаде.
+2
С Аджайлом как-то по-другому? Сначала аналитики точно так-же долго разбираются что там к чему, потом начинается спринтерский забег на костылях, разве что в отличие от водопада у вас не будет проектной документации и вообще уверенности в том что то что вы сейчас делаете не будет выброшено уже завтра. Да и разработчик на весь процесс не особо влияет, некогда ему просто.

А для разработчиков большинство воплощений всех этих практик так вообще беда. Тут хорошая аналогия, КМК, с ресторанным бизнесом. Есть повара, работающие в классических ресторанах, у них при приготовлении блюд есть определенная свобода, они могут как-то менять рецепт и даже придумывать что-то свое. Для бизнеса тут есть определенный риск, может оказаться что повар готовит плохо и клиент уйдет, но с другой стороны… многие клиенты в такие рестораны и ходят только оттого что им нравится как там готовят.
И есть фастфуд вроде Макдональдса, в котором «повар» и на кассе стоит и туалеты моет и котлеты жарит. Там идеально выстроенная потогонная система, в которой у дрессированной мартышки нет возможности сделать ничего не регламентированного. С одной стороны это для бизнеса очень хорошо — стабильное качество, стабильный вкус блюд, минимальный риск напортачить и отравить клиентов. Но с другой стороны — туда ходят что-бы просто быстро перекусить или не рисковать в незнакомом городе или стране, посидеть с друзьями ради удовольствия или поесть что-либо вкусного туда не ходят.
Вот и разработка постепенно приходит к этому макдачному принципу — «коллектив» «дрессированных макак» с суровым надсмотрщиком, производящий программы-гамбургеры для непритязательного потребителя. И менее многочисленные компании «рестораны» в которых разработчиков считают взрослыми и ответственными людьми, которым можно поручить задачи и не контролировать каждый их чих в процессе работы.
0
> И есть фастфуд вроде Макдональдса, в котором «повар» и на кассе стоит и туалеты моет и котлеты жарит. Там идеально выстроенная потогонная система, в которой у дрессированной мартышки нет возможности сделать ничего не регламентированного.
> Вот и разработка постепенно приходит к этому макдачному принципу — «коллектив» «дрессированных макак» с суровым надсмотрщиком,

Разработка софта никогда не сможет стать просто кулинарией на конвейере: все задачи разные.
В оригинальной статье это уже сказано явно.
-2
Почему вам некогда рефакторить, некогда писать тесты, надо истерично сколачивать костыли? Почему грязные хаки допустимы? Как это проходит код-ревью? У вас вообще есть код-ревью? Зачем вы что-то штурмуете? При чем тут вообще Agile?
+3
Почему вы задаете столько вопросов, ответы на которые есть в исходном сообщении?
-1
Я еще раз внимательно посмотрел, и не нашел ответ. Вот вы написали код. Не написали тест. Двинули стори дальше. Почему вы двинули ее дальше?
+1
Видимо не внимательно. Я не писал не о нынешней работе, я о тех что вообще видел и с чем сталкивался.
А написать код без теста — когда вам ваш наниматель напрямую говорит что никаких тестов не писать и двигать дальше, то у вас выбор небольшой — или не писать или уходить (что я по совокупности причин в таких местах и делал). Вы с вашими тестами и некостыльным подходом будете ковыряться с задачей неделю, а ваши товарищи по несчастью за это время наговнякают пяток задач на костылях и без тестов. Как вы думаете кем руководство будет недовольно?
Можете мне не объяснять что код покрытый тестами и написанный правильно в конечном итоге себя оправдает, я это и без вас знаю, попробуйте это донести до упертого «манагера», который видит что вы ковыряетесь, а остальная команда бодро рвет упряжку и вы на этих галерах самый тормоз.
0

Обычно в таком случае много багов. Баг дошедший до продакшена стоит сравнительно дорого. Если менеджеру это важно то можно ему показать мере принятые в вашей команде процедуры обратной связи

-2
Если вы не поняли, я вас к этому и подводил. Оказывается, вам не Agile мешает тесты писать, а «манагер». Зачем вы тогда говорите: — Agile?
+3
Скорее это вы все-же не поняли.
У Аджайла та-же беда что и у коммунизма. Это отличная штука, требующая для своего воплощения идеальных людей. С реальными получается как-то не очень.
0

Есть наниматели которые позволяют писать тексты, соглашаются с оценками команды и т.д. возможно вы с ними просто не сталкивались. Если вы сами понимаете что тесты нужны почему вы отказываете в этом другим людям?

+2
Еще раз — я нисколько не сомневаюсь что где-то там в прекрасном мире коммунизма Аджайла, есть фирмы в которых радостные сотрудники весело и с драйвом общаются на ежедневных стендапах, пишут замечательный код, покрытый тестами, при этом у них нет никакой штурмовщины и не копится техдолг. Менеджмент понимает саму суть подхода и не пытается превратить его в потогонку. И прочие розовые единороги.
Я всего-лишь описал свои впечатления от того что видел лично я, возможно мне сильно не повезло, может быть, а может и нет, возможно технология эта в большинстве случаев просто не работает, вырождается в нечто иное, что не предполагалось ее создателями.
0
я нисколько не сомневаюсь что где-то там в прекрасном мире
И прочие розовые единороги.

Вот тут я не понимаю что именно вы хотите сказать — то, что такого не бывает, или у вас есть какие-то особенности, по которым именно у вас этого не будет?


возможно технология эта в большинстве случаев просто не работает

Лично меня обычно интересует, работает ли это в моем случае, а не в большинстве (достаточно ли у меня интеллекта, чтобы отличить от подделки, сделать самому или выбрать готовое). Возможно в большинстве случаев то, что люди называют словом "лекарство" не работает — меня интересует могу ли я отличить лекарства которые работают от тех, которые не работают.

+1
Автор — профессиональный болтун, чья «рабочая» деятельность протекает между бесчисленными митингами и кафетерием. Повидал я подобных «UX researcher»-ов изрядно за свою жизнь… В разработке он понимает, как свинья в апельсинах; а про реальный «эджайл» в Интеле и говорить смешно!

Зачем переводить и постить этот бред — непонятно; проще сразу отправлять в Африку, там с водой «напряженка».

«Гибкая» разработка — это то, что так или иначе внедряет (или пытается внедрить) большинство компаний, испытывающих в этом нужду (но нужно заметить, что далеко не всем компаниям нужна гибкость! Некоторым она, скорее, вредна). Если это делается «с умом», без бездумного следования шаблонам и бумажным практикам, то работать в таком коллективе — одно удовольствие (если, конечно, вы любите и умеете работать. Для бездарей, лентяев и бездельников agile смерти подобен!)! Все знают, что делают, что будут делать, большинство проблем решается налету, вместо тупых многочасовых митингов — короткие стендапы, на которых конкретные вопросы решаются быстро и эффективно. Возможность самому планировать свою работу (за редкими исключениями), а также эффективно отслеживать и планировать время — это must have. И как сложно, поработав в нормальной scrum-команде, работающей по современным и эффективным методикам, погружаться в ад классического waterfall-а «компании, уже 50 лет сохраняющей лидерство на рынке» — сужу по собственному, к сожалению, опыту :(
+5
А вот у меня самые приятные впечатления остались как раз от «водопада», но в небольшой фирме.
Был хороший баланс между формализацией задачи (было грамотное ТЗ) и свободой разработчика — фактически большая часть решений о реализации была оставлена мне.
Спокойная работа в том ритме который мне более всего комфортен, руководство не устранилось, но и не докучало ежедневным контролем, мне были поставлены сроки и время от времени я сообщал как дело движется. В случае сложностей или непонимания мне всегда было к кому обратиться и обсудить дело.
В итоге задача была сделана качественно, в срок и без стресса для разработчиков.
Аджайл же… даже в самом лучшем из опробованных мной вариантов это какой-то непрекращающийся стресс, когда ты постоянно чувствуешь себя какой-то лошадью в упряжке, которую все время нахлестывают что-бы быстрее бежала. Все решения принимаются наспех, какая-то свобода в планировании своей работы ограничивается выбором следующей задачи из небольшого списка вариантов. Времени не остается ни на спокойный анализ кода, ни на рефакторинг, ни на написание тестов хотя-бы в самых критичных местах.
С этим Аджайлом я уже раз пять выгорал до состояния — «а пошло оно все к ё… й матери», когда уже просто увольняешься не думая о последствиях, чего с «водопадом» у меня не было ни разу, потому что там всегда можно чуток тормознуть и перевести дух.

ИМХО все эти Аджайлы хороши когда надо поработать недолго в режиме штурма — слепить MVP за месяцок, что-бы продемонстрировать его потенциальному заказчику, потом после получения контракта выкинуть этот прототип на помойку и написать нормальную версию без всех эти ритуальных свистоплясок с митингами и прочим.
+2
Был хороший баланс между формализацией задачи (было грамотное ТЗ) и свободой разработчика

У Вас не водопад)
Водопад потому и водопад, что если нужно что то гибко изменить, то нужно наверх по водопаду запрос посылать, пока не утвердили.
Водопад для того и создали и сейчас используют, чтобы получить на выходе то, что было на входе в тз. А не отсебятину программистов. Хорошо для медицины и космоса. Плохо для инет магазинов.

+1
Возможно это не водопад в чистом виде, а что-то «водопадообразное». Как впрочем и тот Аджайл «не чистый», чаще всего.

Мы, видимо о разном немного. Вы про изменения в ТЗ, я про реализацию этого ТЗ. В реализации, обычно, у разработчика свободы много, в зависимости от детальности ТЗ, но обычно в нем не прописывают уж совсем мелкие подробности, если они не принципиально важны.

К примеру есть требование ТЗ — обеспечить некоторую минимальную скорость обработки данных — задача разработчика применить те технологии, которые эту скорость способны дать (ну или послать аларм руководству, если это невозможно в принципе или слишком дорого для проекта).
0
Аджайл не бывает чистым. Не верьте сектантам. Это набор практик, помогающие при отсутствии строгого детального тз. То есть не делать жесткую структуру управления, а использовать гибкие методики под разные задачи и разные коллективы.
Родилась практика как ответ на отсутствие нормальных тз и их постоянное изменение.

ТЗ — это техническое задание, то есть о технической реализации.
Часто приходится работать без тз — по функциональному заданию.
То есть просто по описанию, что войдет, что выйдет — без деталей технической реализации — это проще получить от клиента и не нужно отдельного аналитика для создания ТЗ. Но такую работу уже никак нельзя отнести к водопаду.
По любому уже или хаос или что то гибкое)
+2
Скажите честно, поменяй методику и оставь тех же руководителей, что нибудь изменилось бы в этих компаниях?
+1
На этот вопрос сложно ответить, потому что адекватное руководство применяет ту технологию, которая не мешает и дает результат, если бы они там применили Аджайл, то это скорее всего не было-бы тем руководством.
0

А сколько аджайлов разных вы видели? Были это снговые или западные компании?

+1
Наши, родные, посконные. Можно списать все на неверную реализацию и русский менталитет, конечно, но я вот уже не первый раз читаю переводную критику, в которой описано все то-же что и видел сам своими глазами.
Видел не так что-бы много что-бы можно было составить серьезную статистику, потому изначально и делал оговорки что это мое субъективное мнение.
0
Это у вас были «неправильные пчелы». Agile вообще, и Scrum в частности вовсе не означают «беспрерывную потогонку» с «непрекращающимся стрессом», из-за того, что Scrum master недоволен метриками последнего спринта и вообще желает видеть постоянно увеличивающуюся velocity на протяжении года. «Слепить MVP» тут тоже ни при чем — это с успехом делается и без «эджайла» (а иногда процесс «лепки» затягивается на годы и миллионы долларов).

Все беды и плохие впечатления — от неверно примененной методологии, непонимания основных принципов, да и просто от непрофессионализма. Я проработал полтора года в команде, исповедовавшей «правильный» Scrum, но без фанатизма; работать было — одно удовольствие, никакой «штурмовщины», никаких дедлайнов, закрыл задачи текущего спринта в среду — хочешь, «выгребай» потихоньку backlog, хочешь — ваяй свои fun projects (даже хоть из дому), хоть вообще не работай (хотя для контрактора сложно к такому привыкнуть, но менеджер специально обговорил этот пункт еще на интервью).

Проблемы, которые в «водопадных» компаниях, работающих по старинке (даже когда задачи требуют быстрого реагирования) решаются неделями, или даже месяцами, у нас решались за считанные часы, иногда за минуты.

К сожалению, по независящим от меня причинам, пришлось сменить компанию; но, доложу я вам, после того, как поработал по нормальным, современным технологиям (Scrum+GitHub+Trello+Slack+CI/CD и т.д.), возвращаться к допотопным методам ну очень тяжело :( Плюс еще такой ньюанс: я весьма щепитильно отношусь к своему рабочему времени (а при часовой стоимости моих контрактов «украденные» или потерянные часы составляют весьма круглую сумму), приходится в буквальном смысле искать себе работу у людей, привыкших решать задачу, на которую у меня уходит день, за две недели… Это очень напрягает, к сожалению.
+1
Сам давно мечтаю опробовать хорошую и правильную реализацию Аджайла, но увы. Реальность такая что пока что я видел либо потогонку (причем дурную, работа ради работы) либо карго культ, когда все дружно исполняют ритуалы, как в какой-либо религиозной секте, не задумываясь над тем — а нафига оно все.

Сейчас в принципе в таком-же карго-аджайле, но культ у нас выродился фактически до утренних стендапов, потому оно еще как-то терпимо, нет ни потогонки ни безделья, просто спокойная размеренная работа.
+1
Наконец-то пробился луч света в наше тёмное царство!
Мы открываем более совершенные методы разработки программного обеспечения… Но дело в том, что когда люди говорят, что Agile относится ко всей организации, это альтернативная история. Это нечестно
Не понял, что значит «альтернативная», полез в оригинал — "it’s revisionist history" — и для себя перевёл как "спорное переосмысление начального замысла",
Это нужно сказать: Agile есть и всегда был локальной оптимизацией для небольшого повышения эффективности системы.
В самом начале внедрения многие пытались обращать внимание на эти особенности, что для крупной организации Agile плохо приспособлен, что искусственное создание «команд» малоэффективно, но… тогда поезд уже набрал ход и его было не остановить.
0

Ну и перевод… Через предложения приходиться буквально продираться (особенно в конце), страдая от англицизмов и периодически "переводя назад", чтобы понять что хотел донести автор

0
На вскидку — похоже на древне-еврейский алфавит.
Картинка
image

Но я не специалист, могу ошибаться.
UFO landed and left these words here
0

Автор говорил о взаимном доверии — наверно, о доверии в том, что каждый стремится к достижению общей цели, как мне кажется. Если цели у разработчика и у руководства разные, то свобода долгоиграющей и всеобщей пользы не принесёт.


Свобода разработчика — не совсем то. Свобода разработчика в условиях обоснованного взаимного доверия между руководством и исполнителями — да, безусловно. Нужно, правда, доверие. И основания для этого доверия. О доверии автор сказал. Основания для доверия — добросовестность разработчиков и единство целей — неявно предполагается (без этого, мне кажется, "Манифест" автоматически становится ложью). Вот об этом — да, говорят редко. Не знаю, почему.

0
Статью вполне можно выразить известным принципом: «Когда в руках молоток, весь мир состоит из гвоздей». Agile методики (кстати, автор как и много кто еще почему-то отождествляет между собой Agile и SCRAM, что неверно, т.к. кроме SCRAM есть еще много другого тоже Agile) очень даже хороши для определенных задач. Попытка же запихнуть их всюду (вероятно из-за наглядноо успеха в тех областях, где они реально работают) приводит к тому, что с одной стороны проектировать МБР или ПЛАРБ с использованием SCRAM (пример специально утрирован) как бы, мягко говоря, не самая хорошая идея, которая приводит к вполне ожидаемому финалу, а с другой стороны спрос рождает предложение, а потому мы можем наблюдать армию всевозможных консультантов, которые готовы рассказать любому, что именно он не так сделал во внедрении SCRAM, для того чтобы соорудить МБР.
0
«Путь вперёд — не «Agile против водопада». Это умная стратегическая работа сверху вниз (водопад) с эмпирически-ориентированными тактиками снизу вверх.» — да! об этом же писал недавно в своей статье habr.com/ru/post/458698
0
Для разных задач нужны свои инструменты

Когда я чётко понимаю, какой конечный продукт я должен создать, то нужен водопад. Например я строитель, и мне архитектор даёт проработанный план здания, где до сантиметра расписано каким он должен быть. Конечно я смогу чётко спланировать свои действия по этапам, чтобы его построить

А вот когда к архитектору пришёл пузатый дядька с чемоданом бабла и сказал «а постройка мне такой дом с прибабахами чтобы все братки обзавидовались», вот тут нужен аджайл, нужно делать макеты прототипы, показывать их дядьке, выслушивать маты, и бесконечно переделывать, пока дядька не скажет ок
0
ха-ха-ха… вы плохо себе представляете себе строительство…
когда бетон уже залили, но тут пришли изменения в плане, ибо до этого системы вентиляции в нем не было (другие подрядчики не успели в срок, а сроки же горят). да-да, начинают долбить бетон.
Ну или как в нашем городе долго и упорно делали дорогу и мост, а перед сдачей вдруг обнаружилось, что в проекте не была предусмотрена ливневка.
короче, пообщавшись с архитекторами всякими, понимаешь, что там это ещё веселее, блин. канкан на граблях.
+1
Отличная статья — настолько, что огрехи перевода не замечал, пока не прочёл в комментариях.
Каждый раз, как хотел подробно ответить на какой-то комментарий, оказывалось, что всё это уже есть в статье. Редко когда так получается.
Only those users with full accounts are able to leave comments., please.