Comments 18
1. Компании имеющие собственный продукт продающийся как есть. Тогда в случае невыполнения спринта мы просто пишем список новых фич и не включаем туда какую-то анонсированную которую не успели выпустить. А дальше пусть менеджмент разгребает, нечего было обещать и поднимать шумиху раньше времени (для этого кстати и нужна секретность и утечки информации, чтобы не делать официальных заявлений).
2. Компания интегратор часто имеющая собственную систему которую она старается всячески везде интегрировать. Если клиент заплатил за интеграцию и не получил ее в указанные сроки то это плохо для интегратора, так делать нельзя.
3. Тоже самое для производителя индивидуальных решений, компания клепает сайты-визитки. Если запланировано 3 сайта на спринт, и один не доделан то нужно выкручиваться, ведь обычно деньги получены заранее.
4. Компания не IT направления имеющая собственное подразделение разработки для внутренних нужд, например банк. Банкиры создали бизнес — проект, проект ориентирован на незанятую нишу и нужно ее срочно занять и выйти на рынок с новым финансовым продуктом в установленные сроки. Если разработка эти сроки завалит то банк просто не успеет выйти с продуктом и вся разработка это просто — деньги в шредор.
Системный анализ проблемы не подходит там где нужен комплексный. В данном случае проблема в планировании, нужна статья о том как планировать факапы. Ни разу не видел в IT чтобы кто-то сформировал график с трендом ожиданий и границами суммы погрешности оценок, для того чтобы отслеживать картину отклонений, собирать статистику и подбирать подходящий размер спринтов или иным способом регулировать работу команд.
Для прослойки ключевые ценности — количество закрытых задач в условных единицах и предсказуемый процесс, потому что именно по этим факторам будет оцениваться их работа. И прослойка будет всеми силами добиваться оптимизации именно этих метрик, даже в ущерб истинным целям компании, например тем что вы описали. Итого в проигрыше могут оказаться и те же то платят, и те кто делают.
В нашем случае, например, проект индивидуальный, но длительный — текущая версия разрабатывалась где-то четыре месяца и ещё почти год находится на поддержке и дополнении. Получается что-то среднее между первым и третьим? На практике от нас ждут фичи в порядке приоритетов с примерно оценёнными сроками (либо вовремя сообщаем, что возникли непредвиденные затруднения), "срыа спринта" обычно не грозит, но и просто сказать "мы сделали вот это" и умолчать о несделанном — так себе вариант.
У нас с вами однозначно разное понимание того что значит "заморозить спринт". Заморозить спринт в моём понимании не означает что в принципе нельзя брать новые задачи или что полностью исключен вариант с тем что какие-то запланированные задачи не успели сделать. И то и другое в принципе вполне себе легитимно.
В моём понимании заморозить спринт в первую очередь означает что имеющиеся задачи нельзя изменять в течении спринта и что нельзя брать новые задачи если ещё не сделаны запланированные. То есть если вы вдруг выясняете что ваши задачи не имеют смысла или просто "неправильны", то в такой ситуации вы не начинаете их менять на ходу. И если команда ещё не готова с запланированными фичами, то нельзя пихать в спринт новые "более приоритетные" потому что кто-то вдруг этого захотел.
И если без этого не обойтись, то тогда надо обрывать спринт и начинать новый.
Договорившись, можно делать всё что угодно, ради достижения целей.
Очевидно, что множество компаний внедрили какие-то практики, но не поняли или не приняли смысла.
Многие адепты пытаются возвести фреймворки, типа Scrum, в абсолют, забывая об основной концепции.
Не так давно все пинали микроменеджмент. Технология управления изменилась, а люди остались.
В принципе, ничего нового.
В итоге статья выглядит как «Стрелять себе в ногу — плохая идея. Вы стреляете себе в ногу, вам становится больно, у вас течет кровь. Возможно вам потребуется госпитализация, а может даже и ампутация! Попробуйте не стрелять себе в ногу! Это очень хорошее решение — вы просто берете — и не стреляете в ногу!!! Но если все-таки надо стрельнуть — попробуйте холостые патроны, вдруг будет получше? А просто так стрелять себе в ногу — так себе идея».
Методология разработки должна устанавливаться непосредственно командой разработки, как предмет общественного соглашения, для достижения общих целей.
Когда процессом разработки владеет менеджмент, не принимающий непосредственного участия в разработке, возникает конфликт интересов, приводящий к искаженной интерпретации принципов и выборочному их злоупотреблению, как например в данной статье.
К сожалению, Agile, как и «демократия», — заангажированный термин, значение которого в большей степени определяется тем, кто его озвучивает. Для некоторых, внезапно, Agile, как и демократия, — это лишь метод управления людьми.
Методология разработки должна устанавливаться непосредственно командой разработки, как предмет общественного соглашения, для достижения общих целей.
Это как бы интересный подход и он вполне имеет свои плюсы. Но и свои минусы он тоже имеет. И один из основных минусов это то, что "команда разработки" далеко не всегда хочет забивать себе голову такими вещами как методология разработки. А даже если и хочет, то далеко не всегда обладает необходимой компетенцией в этом вопросе.
Это существенное отличие Скрам-мастера от традиционных ролей проектного менеджера или тимлида. Благодаря повышенному уровню самоуправления команда разработчиков в Скрам не нуждается в дополнительных менеджерах. Основная миссия Скрам-мастера — создать условия для зарождения самоуправления в команде, потом не дать ей погаснуть из-за микроменджмента или жесткого директивного способа управления. То есть Скрам-мастер — защитник Скрам-ценностей. Это большая часть его работы.
— Команда должна организовываться самостоятельно.
— Тогда какая же задача у Scrum мастера, если команда должна сама организовываться?
— Как это какая? Создавать атмосферу конечно-же!
Вы конечно извините, но чтобы иметь в распоряжении этого самого Scrum-мастера кто-то сначала должен принять решение его нанять и вообще делать Scrum, а не скажем какой-нибудь Kanban или водопад. То есть как минум здесь сначала кто-то из менeджмента должен принять такое решение.
Другое дело что если уже решили делать Scrum, то это конечно подразумевает под собой что команда сама может устанавливать себе свои правила в рамках этого самого Scrum и в рамках адекватного взаимодействия с другими командами(если есть такая необходимость).
Требовать в срок вообще совершенно не ясно. Как можно умственную, да и вообще любую человеческую деятельность ускорить? Нервы потрепать-да. Или получить вариант тяп ляп-тоже пожалуйста. И это не про то, когда требуют от менеджера и он добавляет людей в проект, или когда у исполнителя есть возможность отказаться от менее приоритетных задач.
если инженеры главные в компании (старый гугл) — то все процессы будут заточены под их комфорт и производительный труд.
если продавцы главные — тогда все будет по желанию продажников/клиентов на сегодняшний день (а завтра может быть что-то другое).
если главные не технари, а гуманитарии, или что еще хуже операционные директоры (люди привыкшие управлять заводами или фабриками) — то будет фокус на процессах и заполнению бумажек, закрыванию тикетов и т.д. а сама суть не будет волновать — до тех пор пока можно гнат лапшу наверх руководству уровнем выше
т.е. дедлайны плохо, но причина этому плохой коллектив/руководство и это не меняется никак, кроме как либо вашим увольнением, либо увольнением большого начальника
www.youtube.com/watch?v=QVBlnCTu9Ms
И статься на эту же тему
habr.com/ru/company/skbkontur/blog/444484
Кого вы пытаетесь впечатлить своими дедлайнами?