Comments 40
Классная статья!
Может, напишите ещё и английский вариант? А то у нас в команде маловато тех, кто русский знает... )))
Не, у меня с английским не настолько хорошо. Google Translate It.
Вот на английском https://habr.com/ru/post/664938/
Куда донатить?
И вот, наконец, я нашел эту статью.
Выражаю автору максимально возможную в рамках сайта благодарность за написанное.
Перефразируя известную поговорку, красиво продавать не запретишь. Вообще, когда только начал знакомиться с этой религией, не мог понять, зачем же делать процесс планирования хуже, а архитектуру системы фактически не прорабатывать, но потом как понял. Шедевральная статья.
Жирный плюс в карму!
Спасибо автору за шедевр! Живой язык и прекрасная подача!
Спасибо!!! Более интересной и дельной статьи придумать было бы невозможно... Респект и уважуха!
Это же гениально! Получил истинное наслаждение от прочтения. И материал, и подача, всё супер! Присоединюсь к комментаторам выше, это однозначно тот случай, когда русскоязычная статья на Хабре достойна быть переведённой на английский, а не наоборот. Спасибо автору!
Аджайл, как и оргазм имитировать нельзя. Иначе за...долбанными будут все
Надеюсь, в статье сарказм, а не руководство к действию.
:))))))))))
https://pubmed.ncbi.nlm.nih.gov/19707929/
Research shows that many women pretend or "fake" orgasm, but little is known about whether men pretend orgasm. The purpose of this study was to investigate (a) whether, how, and why men pretend orgasm and (b) what men's and women's reports of pretending orgasm reveal about their sexual scripts and the functions of orgasms within these scripts. Participants were 180 male and 101 female college students; 85% of the men and 68% of the women had experienced penile-vaginal intercourse (PVI). Participants completed a qualitative questionnaire anonymously. Both men (25%) and women (50%) reported pretending orgasm (28% and 67%, respectively, for PVI-experienced participants). Most pretended during PVI, but some pretended during oral sex, manual stimulation, and phone sex. Frequently reported reasons were that orgasm was unlikely, they wanted sex to end, and they wanted to avoid negative consequences (e.g., hurting their partner's feelings) and to obtain positive consequences (e.g., pleasing their partner). Results suggest a sexual script in which women should orgasm before men, and men are responsible for women's orgasms.
Теперь про водопад в том же стиле?)
Как имитировать водопад? По-моему, он не требует имитации, достаточно такой ОШС, при которой архитекторы, аналитики, разработчики, тестировщики и технические писатели сидят по своим отделам и общение между ними и с заказчиком происходит только на уровне начальников отделов.
Я не уверен, но кажется цель статьи не только постебаться над Agile, а проявить некоторые бессмысленные на практике моменты.
Мне после прочтения захотелось прочесть аналогичный текст по другим подходам, чтобы увидеть общую картину и понять, где/что можно заимствовать друг в друге или определить, когда/что сподручнее применить.
Или зайти в тему с другой стороны (наверняка это уже делали, но если это сделает автор этой статьи - будет более едино) и раскрыть вопрос - почему Agile стал таким популярным?
Да, статья не для того, чтобы постебаться, а чтобы показать реальность.
где/что можно заимствовать друг в друге или определить, когда/что сподручнее применить.
Вряд ли это можно сделать по такого рода текстам. Лучше самим определять проблему, а затем выбирать способ, которой может ее решить. Но обычно есть проблема даже с самим определением проблемы.
А водопадом еще кто-то пользуется?
Все кто работает по 34 ГОСТу
Когда задачи не выглядят как "Поменять цвет кнопки" и не влезают в 2 недели разработки?
Тогда это не задачи, недонарезанные задачи и тд. Что то же за 5 дней * 2 недели * 7 человек = 3.5 человекомесяца можно собрать, что показать заказчику не стыдно.
Ну и не забываем анекдот/карикатуру:
— А ведь атомную станцию по эджайл не построишь.
— Но ты то формочки на сайт клепаешь.
И дальше бутылка водки и безысходность.
Проблема с внедрением agile-практик в том, что мало кто задумывается о том, почему они возникли и какие проблемы призваны решать.
Agile не лучше традиционного водопада, это просто другой подход, и его смысл не в том, чтобы собираться на ретро или дейлики, а в том, чтобы успешно работать в условиях неопределённости.
Пятьдесят лет назад работа программиста заключалась в том, чтобы реализовать конкретную задачу для конкретной железки. Железка чаще всего была специализированной, её функциональность, технические возможности и сценарии использования были подробно спроектированы и задокументированы ещё до того, как программисты узнавали о работе, поэтому все работали по ТЗ в понятном цикле "анализ-проектирование-код-тестирование-эксплуатация" и всё было хорошо.
Но времена меняются и постепенно появилось очень много проектов, конечный результат в которых до конца неизвестен - по разным причинам. Тут и переменчивость рынка, и стремительное изменение технологического ландшафта, и необходимость работы с неопределённым кругом пользователей, и невозможность до конца определить этот круг пользователей и их проблемы. В общем, причин много и такова жизнь. Важно, что работа в таких условиях не позволяет задокументировать все требования с нужной степенью детализации до начала работы, и поэтому периодические откаты к предыдущим этапам и переделка уже сделанной работы неизбежны. Это обходится дорого и по деньгам, и по времени, потому что влечёт за собой огромное количество накладных расходов - переделка техзаданий, технической и проектной документации, роадмапов и прочих планов, диаграмм ганта и технико-экономических обоснований.
Поэтому и возник Agile - практики существования в условиях, когда цели, как и методы их достижения - туманны и известны лишь постольку-поскольку. Главная суть любого аджайла - сделать откаты и переделки максимально безболезненными.
За это приходится платить бОльшей конечной стоимостью продукта, и отказом от некоторых гарантий: сроков или функциональности. Это особенно важно понимать потому, что в первую очередь эту цену должны заплатить не разработчики, а руководство организации. Именно в там в первую очередь нужно внедрять agile, ещё до того, как на созвон подключится скрам-мастер и начнёт назначать еженедельные груминги.
Если руководство не готово постоянно участвовать в поиске баланса между стоимостью/сроками и функциональностью продукта, а хочет по привычке требовать "дату завершения проекта" и дрючить за опоздание - никакого agile здесь никогда не получится.
За это приходится платить бОльшей конечной стоимостью продукта, и отказом от некоторых гарантий: сроков или функциональности.
Вообще-то нет. Agile позволяет сосредоточиться только на той функциональности, которая нужна, и гарантировать ее, возможно за счет сроков. И при этом конечная стоимость продукта необязательно увеличится. Она может даже уменьшиться по сравнению с водопадом, т.к. не будут потрачены усилия на функциональность, которая потом окажется не востребована.
На мой взгляд, если уж есть возможность отказаться от части функциональности, то от неё можно отказаться и при водопаде, заранее, и потом пойти к конечному результату сфокусированно, кратчайшим путём, не тратя время на постоянные груминги и прочую корректировку курса.
Так, я понял в чем проблема - в моем неправильном использовании слова "гарантия". Я имею в виду, что PO все же получит как раз нужную ему функциональность, но не может управлять сроками. Но что входит в "нужную ему", он в начале проекта не знает, и в Agile выясняет в процессе.
В случае водопада РО тоже в начале не знает, что ему нужно, поэтому обычно не может отказаться от какой-либо части функциональности, потому что еще не знает, что важно, а что нет. А еще потому, что бюджет выделяется один раз, PO обычно заказывает максимум всего, что может понадобиться. Ну, и в результате после водопада имеем монстра, который песни поет и гипнозом занимается, а нужен только для того, чтобы пивные банки открывать.
Конечно, здесь проблема не в водопаде, а в бюрократии и в неумении PO сдерживать свои желания. Если в водопаде сокращать инкремент, сделать водопад итеративным (как предполагалось изначально), то получится почти Agile.
В случае водопада РО тоже в начале не знает, что ему нужно, поэтому обычно не может отказаться от какой-либо части функциональности, потому что еще не знает, что важно, а что нет.
А почему не знает? Что делали те, кто занимался анализом требований и проектированием?
Еще ничего. Анализ требований и проектирование это первая часть водопада. А бюджет и сроки все хотят до начала проекта.
На этом этапе есть только пол-палец-потолок оценки стоимости и чуть лучшие оценки отдачи, если это проект по уменьшению издержек или еще худшие оценки прибыли если проект класса "вот мы как ворвемся на рынок, которого нет, поэтому без конкурентов"
Еще ничего. Анализ требований и проектирование это первая часть водопада.
Не первая. Первой частью идет анализ проекта. С выяснением, что примерно нужно и как примерно можно сделать и сколько денег примерно потребуется. А заодно — и с выяснением того, не поменяются ли эти требования за врея разработки до неузнаваемости. И если требования имеют склонность поменяться — то это не для какадной разработки, нужна какая-то альтернатива (которые эджайлом отнюдь не исчерпываются), предусматривающая процессы управления изменениями и управления рисками в процессе разработки.
Ну, и лишь потом, когда оценки получены и есть надежда на их стабильность, наступает время анализа требований и проектирования. Но даже на этих этапах разработка ещё не началась, код ещё не пишется, а потому возможные переделки не обходятся слишком дорого.
А бюджет и сроки все хотят до начала проекта.
Хотеть не вредно. Но не всегда это возможно чисто по объективным причинам.
Вы описываете идеальный, совершенный водопад. Да еще с возможностями возврата на предыдущие шаги. Да еще в котором объективные причины ставятся выше субъективных.
Жаль, что в реальном мире я с таким не сталкивался.
Часто чисто объективными причинами является срок подачи заявки на бюджет на следующий год. И в каком состоянии никем еще не забюджетированный, а не только не оплаченный анализ проекта — казначеям не совсем интересно.
А тут как раз нет противоречий.
Бюджет будет на следующий год - заложите зарплату команды на следующий год плюс 20...30% запаса. За этот год возьмите обязательства понять затраты на следующий или на пару следующих лет. За этот год привяжите платящего к проекту, и дальше факт того, то проект уже есть и что-то по нему делается, не позволит не профинансировать его дальше.
По теме статьи ребята из КОДА КОДА записали подкаст https://podcast.ru/e/.qgaNw9WJB_
А вы точно Agile тренер? :-) Я хочу от тебя Scrumm! (c)
В agile изначально закладывалась идея, что мы стараемся что-то делать хорошо, оно даже работает в конце месяца, а Топ решает, когда готовность готова к продаже. Не должно быть сроков, GA. В реале имеем кровь из носа продукт с такими фичама должен быть через 9 месяцев иначе крупный заказчик от нас откажется(ему надо до нового фин цикла), или Продукты скажут, что нишу займет конкурент, который уже через месяц выходит. И по факту ты думаешь, что воткнуть за этот периуд времени, придумывая оправдания почему ты потом выкинешь, что не успеешь. Любые изменения по факту никого не волнуют, GA не двигается, иначе фейл. (мы же уже пообещали, возможно даже продали заранее)
Как правильно имитировать Agile?