SCRUM в сфере разработки ПО

это ты бюрократ-теоретик со стандартами 24-го съезда кпсс. или эти госты ещё при Брежневе писались? цифирка 79 - это же год, няп. а я разработчик и в реальных проектах работала. и никакие «изменения» в ТЗ после согласования не вносятся. а если вдруг так сильно захотелось - через полный пересмотр всего контракта. и деньги никто не вернёт. потому что дураков писать под сиюминутные хотелки идиотов, которые сами не знают, чего им нужно, нет. да и самим заказчикам не надо дёргаться. им нужен рабочий продукт, а не поделка на коленке в гараже от каких-то хипстеров за неделю.

Я как человек опытный заключаю контракт на этап, который редко длится больше двух лет. Новый этап - новое ТЗ и не факт, что исполнителем опять будешь ты.

Я как человек опытный заключаю контракт на этап, который редко длится больше двух лет.

Чувствуется «рука мастера».

Владимира

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

В одной конторе, разорилась потом, конечно, скрам переизобретали каждые 3-4 месяца. Каждый раз с настроением «ну вот теперь то у нас всё получится, будем делать по теории, как в книжках написано». Пробовали аджайл коучей нанимать разных, но что-то как-то не взлетело.

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

Другие методики ведут к гарантированному немедленному провалу, а скрам — к гарантированному и очень медленному. Как говорил господин Сухов: «Лучше, конечно, помучаться». А там, глядишь, какая оказия случится.

Толпы гомеопатов тоже сказки рассказывают, веришь?

Тяп-ляп и без скрама прекрасно делается. Я в общем-то не против, не нужно только перегибать, прикрываясь медодичкой.

Технический долг не нужен никому, а эта срань только к этому и ведёт.

R&D — это не программирование по ТЗ, вряд ли тебя от чего-то сильно отвлекут. И отчётность будет заключаться в выступлениях на митингах, после которых тебе идей со стороны могут подкинуть, а не в бумажках.

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

удивительно, но если бы ты хоть немного разбирался в теме вопроса - ты знал бы что аджайл не приминяется при разработке медицинского прибора :)

А приминяется при стартапах, при разработке НОВЫХ продуктов, когда продумывать наперед ну никак нельзя.

Ты хочешь сделать второй фейсбук? Та без проблем, делай четкое ТЗ планируй на год вперед и все получится - вот только ты НИЧЕГО не заработаешь на этом. Каждый новый прибильный бизнес будет с НОВИЗНОЙ (где-то больше, где-то меньше).

Вот представь что ты основатель УБЕР - сможешь на год вперед планировать?

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

Конец этой фразы очень похож на оценку в сторипоинтах - который таки, относится к аджайлу :)

Погуглите сколько проектов закрыл гугл - неужели он не может планировать на год вперед?

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

Вот представь мы решили делать слегка ревозюционный проект, но все вроде понятно, наняли двух фронтов, двух бекендов. Описали им что хотим сделать - они сказали ну тут работы на 3 месяца.

Разбили мы значит проект на 30 фронтед тасок, и на 30 бекенд тасок. И предположим 10 фронтовых тасок зависят от бекендовых (зависимость может быть разной, например фронт должен ждать пока бекенд решит как именно будет выглядеть API).

Важность этих тасок тоже разная, какие-то нужно сделать обязательно, какие-то второстепенные.

Если будут спринты - любая проблема (например бек не может вообще сделать одну таску от которой зависит фронт) - будет решена на дейли, или при планировании следующего спринта. А как это без аджайла будет выглядеть?

как вообще можно планировать на месяц в вперед????

Добро пожаловать в реальный мир. Там иногда и на год вперёд планировать приходится.

Скажу два слова: управление рисками. Да, это сложно, но это именно та причина, по которой менеджеры получают больше денег.

Методика Agile довольно прямо противостоит планированию. Это не взаимодополняющие методы, а «или-или»: или мы работает по плану, или мы быстро релизим и переделываем заново.

Это неверно. У тебя может быть долгосрочный план и при agile. Методика agile заточена на то что 1) пока ты работаешь по этому плану ты сохраняешь гибкость и можешь что-то заменить в проекте не выкидывая весь проект (изменить план) 2) ты можешь приблизительно оценить прогресс в выполнении плана не в день финального дедлайна а по ходу разработки.

Грубо говоря, если у тебя в плане выпустить проект с десятью фичами, ты можешь пилить его в виде: сделаю сначала по 50 процентов от каждой, потом по 20 процентов от каждой, потом по семь, а потом придет дедлайн как всегда неожиданно и ничего не готово, а оценка выполнения оказалась неверной, потому что «последние 5 процентов» весят как всё предыдущее вместе взятое.

А agile говорит тебе что делать надо сначала 100 процентов первой фичи, потом 100 процентов второй и т.д. И если что-то пошло не так, ты остаёшься с шесть фичами из десяти но сделанными, а не с десятью заготовками, ни одна из которых не доведена до ума.

Технический долг намного лучше, чем идеальный технически продукт, который к моменту выхода устарел, отстал от рынка и ничего не принес, кроме убытков на годы разработки по идеальному плану

Так тут он из воздуха берётся. Мотодичка позволяет нкгибать здравый смысл в угоду сеюминутному профиту. В конечном итоге и в лучшем случае это приведёт к переписыванию, в худшем к полному подвалу.

Мотодичка позволяет нкгибать здравый смысл в угоду сеюминутному профиту

Яйца, двери, щемить.

И как же, интересно, планировать весь проект, если требования к нему могут меняться хоть на противоположные в любой момент времени? Agile это учитывает, ваши «планы» - нет

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

А приминяется при стартапах, при разработке НОВЫХ продуктов, когда продумывать наперед ну никак нельзя

Глупости не говори. Тебе выше истребитель в качестве примера от ТС был.

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

Вот представь что ты основатель УБЕР - сможешь на год вперед планировать?

ЛОЛ. Так то планировать надо на столько, на сколько хватит денег инвестором.

любые требования к продукту в соответствии с ситуацией на рынке, конкурентами, бюджетами, пожеланиями заказчиков

Обычно у этих процессов изменчивость порядка года-двух и больше, с редкими резкими поворотами из-за кризиса/войны/аварии. Потому в норме «максимально быстро адаптировалась к измененииям» означает «поменять картинку».

А как это без аджайла будет выглядеть?

Люди не будут отвлекаться на чепуху и будут заниматься разработкой.

Погуглите сколько проектов закрыл гугл - неужели он не может планировать на год вперед?

Гугл не использует аджайл, там есть грамотный менеджмент в отличии от третьесортных веб-бодишопов с некомпетентными обезьянами, которых набрали по объявлениям.

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

Квалифицированные аналитики стоят больших денег, и при этом среди них мало ясновидящих -> никаких гарантий, что требования не придется менять из-за внешних причин. Банально: пока пилили для новой версии продукта фичу А, конкуренты анонсировали фичу Б, которая покрывает все то, что и А, только намного лучшее и приятнее для пользователя. Если не переписать требования к А, скопировав и улучшив Б, то с учетом более позднего выхода на рынок обеспечен провал.

А agile говорит тебе что делать надо сначала 100 процентов первой фичи, потом 100 процентов второй и т.д.

Вот только при чем тут аджайл?

1. пока ты работаешь по этому плану ты сохраняешь гибкость и можешь что-то заменить в проекте не выкидывая весь проект (изменить план)

Мы не в совке. Бизнес, если в нем нет ушибленных бюрократов, в любом случае имеет достаточно гибкости для выполнения своих задач.

2. ты можешь приблизительно оценить прогресс в выполнении плана не в день финального дедлайна а по ходу разработки.

Стадии-ворота - не, не слышали…

А, конкуренты анонсировали фичу Б, которая покрывает все то, что и А, только намного лучшее и приятнее для пользователя.

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

никакая серьезная длительная разработка невозможна, когда требования постоянно меняются на противоположные

Это само собой. Но ведь на противоположные и не надо — достаточно обнаружить новое требование, которое не вписывается в текущий дизайн даже с трехлитровой банкой вазелина.

Если есть деньги, то над проектом работают две и более групп параллельно:

Одна - говнякает прототип и потом сопровождает его, до момента вывода из эксплуатации.

Вторая - после условнго выхода проекта на самоокупаемость - делает продукт так, как надо, используя прототип в качестве ТЗ (ну типа набор фич).

Дальше продукт идет в прод а прототип - на помойку.

У нас тут таких уже двое: она и чел с обезьянкой и морковкой на аватарке. Оба, если их послушать, ахринеть какие крутые, только вместо того чтоб на личных бизнес-джетах летать, просиживают штаны на региональном флудофоруме.

Твое заблуждение заключается в том, что ты меряешь людей скалярной величиной «размер счета в банке». Люди, которые всю жизнь занимаются воровством и мошенничеством, летают на бизнес-джетах - они, я так понимаю, крутые для тебя? А что делать с людьми, которые эти деньги печатают? Вот у меня сейчас есть 100% проверенный способ вытаскивать с того света людей с некой болезнью - как ты думаешь, сколько это знание стоит? Люди были бы согласы отдавать квартиры и машины за то, чтобы не сдохнуть - но эту услугу нужно продать, а я прям вообще никакой продажник. Да, ты правильно заметил, что я зря упускаю такую важную сферу жизни, как торговлю - но я бы все-таки заметил, что в современном обществе этой сфере уделяется чрезмерная роль. Настолько чрезмерная, что мне аж противно в нее вкатываться.

Ты хочешь сделать второй фейсбук? Та без проблем, делай четкое ТЗ планируй на год вперед и все получится - вот только ты НИЧЕГО не заработаешь на этом.

Паша Дуров смеется над тобой.

Погуглите сколько проектов закрыл гугл - неужели он не может планировать на год вперед?

Может. Сделали по плану, проект сочли невыгодным/ненужным, закрыли. Можно спланировать кодописание, но нельзя спланировать рыночный успех.

Разбили мы значит проект на 30 фронтед тасок, и на 30 бекенд тасок. И предположим 10 фронтовых тасок зависят от бекендовых (зависимость может быть разной, например фронт должен ждать пока бекенд решит как именно будет выглядеть API).
Если будут спринты - любая проблема (например бек не может вообще сделать одну таску от которой зависит фронт) - будет решена на дейли, или при планировании следующего спринта. А как это без аджайла будет выглядеть?

Я тебе скажу, как это делаю я:
- Вася, модульнеймом ты занимаешься?
- Нет, это Коля.

- Коля, модульнейм твой? Я тут столкнулся с проблемой, всё правильно делаю, а модуль неправильно работает.
- Окай, посмотрю.

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

Настолько чрезмерная, что мне аж противно в нее вкатываться

Согласен.
Что за радость иметь десять мешков денег без достижения того, что считал важным.
А у каждого из нас имеется желанная цель.
Такие люди ИМХНО подобны «зомби» /хотя внешне у них все Ok/.

Владимир

Я не меряю так людей, ты ошибся.

Я смеюсь над тобой и айрон_баг не оттого, что якобы у вас нет бизнес-джетов, а оттого, что, чисто интуитивно, вы выглядите как типичные фантазеры/балаболы/недооцененные гении.

Послушать айрон баг - так она величайшая кодересса всех времен и народов. При этом живёт в Ёбурге, и работает, вроде, в Qrator. Ты не находишь, что Ёбург и Qrator как-то не очень сочитаются с уровнем её апломба? А, ах да. Её апломб вообще в любых сферах.

Послушать тебя - так ты теперь, то ли целитель, то ли создатель уникального лекарства. Это очень круто, я серьезно. Но опять же, я попросту не очень-то тебе верю. Интуиция и жизненный опыт подсказывают, что твое сидение тут с твоей историей про «вытаскивать с того света» не очень сочитаются. Попросту, я считаю что ты сильно фантазируешь, обманываешь себя или нас. А если предположить что всё это прям-таки правда на 146%, то я бы сказал, ты ведешь не очень морально, тратя своё время столь бездарно. Но я тебе не моральный ориентир, естественно, а просто какой-то хрен.

По этой же причине, я не поверю россказням здесь, например, какого-нибудь Дон Жуана. Дон Жуаны не сидят на форумах, так уж жизнь устроена. В «лучшем» случае это будет какой-нибудь сбитый лётчик.

пока ты работаешь по этому плану ты сохраняешь гибкость и можешь что-то заменить в проекте не выкидывая весь проект (изменить план)

При чем тут Agile?

ты можешь приблизительно оценить прогресс в выполнении плана не в день финального дедлайна а по ходу разработки.

Для этого не нужны частые релизы. То есть, опять таки, при чем тут Agile?

если у тебя в плане выпустить проект с десятью фичами, ты можешь пилить его в виде: сделаю сначала по 50 процентов от каждой, потом по 20 процентов от каждой, потом по семь, а потом придет дедлайн как всегда неожиданно и ничего не готово, а оценка выполнения оказалась неверной, потому что «последние 5 процентов» весят как всё предыдущее вместе взятое.

Это планируется. Разрабы дают оценку срока разработки нового кода, руководители проекта прикидывают, сколько потом это нужно будет еще отлаживать. Обычно это примерно х2-х3 от исходной оценки разраба.

А agile говорит тебе что делать надо сначала 100 процентов первой фичи, потом 100 процентов второй и т.д. И если что-то пошло не так, ты остаёшься с шесть фичами из десяти но сделанными, а не с десятью заготовками, ни одна из которых не доведена до ума.

Рассказываю, как эта модель работает в реальности: пишется первая фича на 100%, пишется вторая фича 100%, начинает писаться третья, выясняется, что первые две должны были быть написаны по другому и работают не до конца правильно в целой системе, и таким образом они были написаны только на половину, потому что доработка и отладка - это довольно тяжелые вещи

Технический долг намного лучше, чем идеальный технически продукт, который к моменту выхода устарел, отстал от рынка и ничего не принес, кроме убытков на годы разработки по идеальному плану

Две крайности. Вам не приходит в голову, что можно иметь проект с контролируемым долгом, который идет в ногу со временем?

Квалифицированные аналитики стоят больших денег, и при этом среди них мало ясновидящих -> никаких гарантий, что требования не придется менять из-за внешних причин.

Ты удивишься, когда узнаешь, за какие деньги работают люди, способные настроить пользователю систему, написать небольшой скрипт, общаться с заказчиками и пользователями, и превращать их неадекватный бред в более-менее понятное и стабильное техническое задание. Да, есть дорогие люди, которые лучше заказчика знают, что и как нужно сделать, при этом безупречно спланируют выполнение, и они очень дорого стоят, но некоторые неточности задания зачастую вполне приемлимы.

Банально: пока пилили для новой версии продукта фичу А, конкуренты анонсировали фичу Б, которая покрывает все то, что и А, только намного лучшее и приятнее для пользователя.

Выше давали ссыль на более реальный сценарий: пока пилили для новой версии продукта фичу А, гибкие конкуренты перписывали продукт под фичу Б, раньше выпустили продукт с сырыми фичами А и Б, а когда «негибкий» конкурент доработал свою систему под фичи А и Б, то весь рынок перешел именно на этот продукт. Есть куча примеров, когда ранний выход приводил к провалу - я не знаю, откуда ты взял, что он может давать только победу.

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

Тогда переписывать. А что еще делать - хоть так, хоть так переписывать придется.

а как, простите, без ТЗ что-то разрабатывать?

Ну вот считай, что у тебя каждую неделю/две приезжает новое тз. А конечная цель формулируется как: «шоб заказчик был счастлив».

Есть почти безошибочный способ, но ты не девочка…

Послушать тебя - так ты теперь, то ли целитель,

Так он же говорил иносказательно … /типа «вот если бы»/.

Владимир

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

Как найдешь с мной поделись.

Песенка альпинистов.

Ты на пятой точке съехал, как лавина, прямо вниз.
Над тобой смеется эхо, не печалься, альпинист!
Ты лежишь, как сыр на блюде, а красивый твой скелет
Может быть отыщут люди через пару тысяч лет.

Владимир

Главное петь погромче, я так понимаю.

хоть так, хоть так переписывать придется.

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

Послушать айрон баг - так она величайшая кодересса всех времен и народов. При этом живёт в Ёбурге, и работает, вроде, в Qrator. Ты не находишь, что Ёбург и Qrator как-то не очень сочитаются с уровнем её апломба? А, ах да. Её апломб вообще в любых сферах.

Да, есть перегибы. Я только не понимаю, при чем они тут ко мне?

чисто интуитивно, вы выглядите как типичные фантазеры/балаболы/недооцененные гении.

Люди, которые создают правила игры для региональной/глобальной экономики/политики, не летают на бизнес джетах и выглядят как типичные фантазеры/балаболы. Дальше что? Кидание понтов не входит в их область компетенции, а многие руководители - вполне себе экономные люди, например, посмотри на чем передвигается тот же Цукенберг: VW гольф, хонда фит.

А если предположить что всё это прям-таки правда на 146%, то я бы сказал, ты ведешь не очень морально, тратя своё время столь бездарно. Но я тебе не моральный ориентир, естественно, а просто какой-то хрен.

Во как, о людишках внезапно начал беспокоиться. А я вот беспокоюсь о себе. Как ты думаешь, что со мной будет, если фарма решит, что я мешаю их бизнесу? И как мне помогут благодарные люди, которым я помог? Например, меня найдут после самоубийства ружьем в грудь, как того врача из США. Как Иисус, на крест за грехи.

Да, абсолютно точно я трачу время здесь без толку - вот, наслаждаюсь свободой. Могу взять и ничего не делать. Авось, попустит, и буду чем-то другим заниматься.

https://www.youtube.com/watch?v=OOenupPvb4Q Песня альпинистов

Владимир

хоть так, хоть так переписывать придется.

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

Давай разберемся: не вписывается даже с вазелином, или же все-таки можно вписать? При чем тут Agile к однократной правке плана/кода?

не вписывается даже с вазелином, или же все-таки можно вписать

В текущий План не вписывается.

При чем тут Agile к однократной правке плана/кода?

Ахаха, однократной.

Твоё сообщение как раз и показывает, что ты балабол и фантазёр.

Может быть, это и не так. Но показывает оно именно это, и не только мне.

Вспомнил, кстати. Есть тут на форуме один чел, выдает себя за «инветсора, предпримателя, и чё-то-там-ещё». Уровень апломба тоже высокий. Я его немного потроллил, так он в 2 счёта сорвался в истерику с помоечной лексикой уровня школьников, косящих под уголовников, смайлики, и истеричное стирание своих собственных сообщений, которые порой выглядели совсем уж джико смешно.

Даже и не знаю, к чему я жто вспомнил. (Нет.)

Это же форум …
На нем пятиклассники, шестиклассники, … и выше по иерархии учат всех «уму разуму».

Владимир