Комментарии 48
Самая засада с Agile у меня была, когда я работал QA менеджером в медицинской компании (выпускали медицинский софт). Специфика была такая, что:
— Наше направление деятельности довольно серьёзно регулируется федеральными и штатовскими законами (США), такими как HIPAA, FDA Title 21
— У нас сертификация ISO, так что всё должно идти в соответствии с процессами
— От штата и от ISO к нам аудиторы приезжают и проверяют.
Поэтому, что бы писать софт по всем правилам, были такие вещи:
— У нас были чётко описанные WI (Work Instructions) и SOP (Standard Operating Instructions), в которых довольно детально описывалось, как должно проходить тестирование, как проверяются баги и т.д.
— Мы должны были выдавать (или принимать участие) горы документации, включая: требования, трассировку требований, тест план, тест протоколы, анализ рисков и т.д.
В общем по моему мнению, у нас был водопад. Да, было несколько забюрократизировано, но в общем вменяемо.
Но потом, похожа какая-то муха укусило начальство, и нам стали говорить, что мы «недостаточно agile»… Наняли начальника разработки специально, чтобы выстраивать agile-процесс.
Я всё никак не мог взять в толк: как можно совместить agile-процесс со всей бюрократией и процессами специфичными для наших продуктов?
Вот и натягивали сову на глобус… Сначало ушло несколько разработчиков. Потом ушёл я. Что было потом — не знаю, но сейчас настраиватель agile-процессов уже там не работает.
А вот сейчас я работаю в компании, где у нас SaaS, не связанный с медицинской сферой. У нас — практически чистый Agile, и всё идёт, как надо.
Вывод: Для каждой работы — свой инструмент.
— Наше направление деятельности довольно серьёзно регулируется федеральными и штатовскими законами (США), такими как HIPAA, FDA Title 21
— У нас сертификация ISO, так что всё должно идти в соответствии с процессами
— От штата и от ISO к нам аудиторы приезжают и проверяют.
Поэтому, что бы писать софт по всем правилам, были такие вещи:
— У нас были чётко описанные WI (Work Instructions) и SOP (Standard Operating Instructions), в которых довольно детально описывалось, как должно проходить тестирование, как проверяются баги и т.д.
— Мы должны были выдавать (или принимать участие) горы документации, включая: требования, трассировку требований, тест план, тест протоколы, анализ рисков и т.д.
В общем по моему мнению, у нас был водопад. Да, было несколько забюрократизировано, но в общем вменяемо.
Но потом, похожа какая-то муха укусило начальство, и нам стали говорить, что мы «недостаточно agile»… Наняли начальника разработки специально, чтобы выстраивать agile-процесс.
Я всё никак не мог взять в толк: как можно совместить agile-процесс со всей бюрократией и процессами специфичными для наших продуктов?
Вот и натягивали сову на глобус… Сначало ушло несколько разработчиков. Потом ушёл я. Что было потом — не знаю, но сейчас настраиватель agile-процессов уже там не работает.
А вот сейчас я работаю в компании, где у нас SaaS, не связанный с медицинской сферой. У нас — практически чистый Agile, и всё идёт, как надо.
Вывод: Для каждой работы — свой инструмент.
ВОДОПАД! 20% процентов в бюджете, сроке и качестве. В остальных хотя бы что-то одно шло не так.
Я как-то на Хабре писал уже в чем разница между проектом, продуктом и услугой. Собственно от непонимания различий идут и холиворы, и проблемы в реальных проектах.
Клиенту начихать, Agile у вас, PMI PMBoK, PERT или FuckDownDrivenDevelopment. Ему нужен продукт, которым он решит свои задачи, пусть даже он купил outstaff.
Проблема номер один: у клиента что-то меняется -> должен поменяться продукт, но из этого автоматически не следует что должен поменяться проект. Решение юридическое, но из него вытекает…
Проблема номер два: проект оценивают как услугу (выполнение заказанных действий) -> значит если за уплаченный бюджет результат не достигнут, то это проблема клиента.
Разрешение этой курояичности не в балансе между Time/Material или Agile/Waterfall, это всё поиск ВНУТРИ проектов, ёшкина кошка. Ответ лежит в портфельном управлении (не в том как правильно делать проект, а в том чтобы делать правильный проект). Лучше клиенту потратить пусть чуть больше, но заработает намного-намного больше, и тогда вот эти все процессные штучки — развлекухи для праздных умов.
Я как-то на Хабре писал уже в чем разница между проектом, продуктом и услугой. Собственно от непонимания различий идут и холиворы, и проблемы в реальных проектах.
Клиенту начихать, Agile у вас, PMI PMBoK, PERT или FuckDownDrivenDevelopment. Ему нужен продукт, которым он решит свои задачи, пусть даже он купил outstaff.
Проблема номер один: у клиента что-то меняется -> должен поменяться продукт, но из этого автоматически не следует что должен поменяться проект. Решение юридическое, но из него вытекает…
Проблема номер два: проект оценивают как услугу (выполнение заказанных действий) -> значит если за уплаченный бюджет результат не достигнут, то это проблема клиента.
Разрешение этой курояичности не в балансе между Time/Material или Agile/Waterfall, это всё поиск ВНУТРИ проектов, ёшкина кошка. Ответ лежит в портфельном управлении (не в том как правильно делать проект, а в том чтобы делать правильный проект). Лучше клиенту потратить пусть чуть больше, но заработает намного-намного больше, и тогда вот эти все процессные штучки — развлекухи для праздных умов.
Вдобавок, в чем самый LOL ситуации.
Клиентам, которые не считают выхлоп на затраты, Material — дорого и переплата, а Waterfall — не тот результат. В результате менеджеры проектов тратят зарплату на алкоголь (замена вазелина для вытраханных мозгов), а риски как гуляли между клиентом и заказчиком, так там и остаются.
Клиентам, которые не считают выхлоп на затраты, Material — дорого и переплата, а Waterfall — не тот результат. В результате менеджеры проектов тратят зарплату на алкоголь (замена вазелина для вытраханных мозгов), а риски как гуляли между клиентом и заказчиком, так там и остаются.
Смешиваем, поступая интуитивно, ситуативно, с перевесом в ту или другую методологию, клиенты и проекты разные.
В чистом виде SCRUM не получается делать, т.к. приходится переключаться между проектами в середине спринта по разным причинам: то согласование дизайна страницы задержали, потому что клиент уехал в Китай по делам, то предоплату по спринту, то проектов несколько параллельно, приходится перебрасывать ресурсы. Поэтому, если это SCRUM, то SCRUM через Ж. Это всё не от хорошего управления, конечно.
Ещё практикуем, как мы называем, «Сайт за 3 встречи» — это водопад с минимальным задействованием клиента и максимальной самостоятельностью команды. 3 встречи — 1. интервью, чтобы узнать бизнес, задачу, видение клиента, задача максимально разговорить, 2. презентация и защита решения, 3. презентация и защита готового результата. Между 1 и 2 команда придумывает и проектирует решение. Между 2 и 3 реализует решение. Это рискованный формат, делаем только с некоторыми клиентами, в основном не с новыми, для некрупных проектов.
Подходит для клиентов, которым нужен результат, а не то, как мы его будем достигать. Плюс для клиента — он экономит время, ответственность на подрядчике. Плюс для нас — свобода выбора инструментов, нет череды длительных согласований (сначала ТЗ, потом контент-план, потом прототипы, потом дизайн).
В чистом виде SCRUM не получается делать, т.к. приходится переключаться между проектами в середине спринта по разным причинам: то согласование дизайна страницы задержали, потому что клиент уехал в Китай по делам, то предоплату по спринту, то проектов несколько параллельно, приходится перебрасывать ресурсы. Поэтому, если это SCRUM, то SCRUM через Ж. Это всё не от хорошего управления, конечно.
Ещё практикуем, как мы называем, «Сайт за 3 встречи» — это водопад с минимальным задействованием клиента и максимальной самостоятельностью команды. 3 встречи — 1. интервью, чтобы узнать бизнес, задачу, видение клиента, задача максимально разговорить, 2. презентация и защита решения, 3. презентация и защита готового результата. Между 1 и 2 команда придумывает и проектирует решение. Между 2 и 3 реализует решение. Это рискованный формат, делаем только с некоторыми клиентами, в основном не с новыми, для некрупных проектов.
Подходит для клиентов, которым нужен результат, а не то, как мы его будем достигать. Плюс для клиента — он экономит время, ответственность на подрядчике. Плюс для нас — свобода выбора инструментов, нет череды длительных согласований (сначала ТЗ, потом контент-план, потом прототипы, потом дизайн).
Спасибо! Хотелось бы подробнее узнать, вся команда защищает решение (стадия 2)? По статистике готовый результат на стадии 3 удовлетворяет заказчиков?
Решение защищает его автор. Как правило, это менеджер проекта. На встрече присутствует МП, продавец, и иногда профильный специалист, если проект технически непростой.
По статистике — в целом удовлетворяет. На третьей встрече ведётся 2 списка: «окончательные правки» и «идеи». У нас есть 3 дня для мелкого проекта, чтобы закрыть пункты из первого списка, или неделя для среднего.
Наш лучший результат — 1 пункт в первом списке, который разработчик из офиса закрыл прямо во время встречи.
По статистике — в целом удовлетворяет. На третьей встрече ведётся 2 списка: «окончательные правки» и «идеи». У нас есть 3 дня для мелкого проекта, чтобы закрыть пункты из первого списка, или неделя для среднего.
Наш лучший результат — 1 пункт в первом списке, который разработчик из офиса закрыл прямо во время встречи.
ВОДОПАД! Но только я не менеджер ни разу. Просто участвовал в таком проекте.
Все было хорошо, но когда клиент захотел гибко менять требования в процессе — многое пошло не так.
Все было хорошо, но когда клиент захотел гибко менять требования в процессе — многое пошло не так.
Ни разу не видел, чтобы на сколь-нибудь длительном проекте на договорных началах заказчика подрядчик, чёткое следование какой-то формальной методологии приводило к завершению проекта к взаимному удовольствию сторон и продолжению сотрудничества. В лучшем случае у сторон нет юридических претензий к друг другу из-за понимания их неперспективности. Но либо клиент считает, что сильно переплатил за незначительное отклонение от первоначального плана, либо исполнитель считает, что ему недоплатили за значительное отклонение от плана. Это даже если сроками удовлетворены. При анализе ситуации со стороны часто видно, что первоначальные оценки занижались исполнителем то ли сознательно ради большей привлекательности своего предложения, то ли из-за слабого понимания с чем реально придётся столкнуться. А признавали ошибку слишком поздно, чтобы найти компромиссный вариант, хотя бы в виде закрытия проекта в целом.
Вообще комбинировать это весело. Недавно возле зоопарка видел мальчишку, сидящего верхом на лошадке. Он держал руки перед собой и воображал, что крутит руль. Выглядел вполне довольным.
Интересно, что было бы с лошадкой, будь у парня все мендежерские полномочия перестраивать так, как ему комфортнее управлять, ну там руль к голове прикрутить? Производство не лошадка, но когда сервисы начинают внедрять себе продуктовые методики управления (и наоборот), ментальная кровища хлещет во все стороны. Тут не важно, через ж… иру, или как.
Интересно, что было бы с лошадкой, будь у парня все мендежерские полномочия перестраивать так, как ему комфортнее управлять, ну там руль к голове прикрутить? Производство не лошадка, но когда сервисы начинают внедрять себе продуктовые методики управления (и наоборот), ментальная кровища хлещет во все стороны. Тут не важно, через ж… иру, или как.
Читаю комментарии и вспоминаю свою первую контору, в которой я официально начал работать по специальности (то есть разработчиком).
- Начнём с того, что де-факто технический директор (далее ТД) Компании считала себя Project-менеджером данного проекта, а по факту была дочкой гендира компании-Заказчика со всеми вытекающими требованиями.
- Все разработчики исключая меня (то есть ещё 2 человека) были либо недавно выпустившимися студентами, либо ещё студентами и работали на полставки. И ни у кого из нас за плечами не было опыта промышленной разработки – при этом и наниматель, и ТД об этом знали, но удивлялись, почему же мы тормозим и почему у нас накапливаются задачи.
- Как следствие, ТД (как «единственный адекватный человек») решила ввести некое подобие code-review, на котором нам говорили, как надо было делать (то есть ввели проектирование кода после его написания). Причём по многим концептуальным вопросам ТД отправляла нас в Гугл («и вы ещё спрашиваете, что такое паттерн «репозиторий»?). Уже много позже я понял, что сама ТД скорее всего обучалась применению паттернов проектирования там же, куда посылала нас.
- Через 4 месяца после моего прихода по настоянию ТД (ибо «как-то медленно двигаемся») к проекту подключили аналитика, который в течение пары недель расписал ТЗ на пару месяцев вперёд (согласно вашей классификации – чёткое ТЗ со сроками = водопад).
До этого ТЗ составляла лично ТД через обсуждение, иногда описывая требования через Ж…. иру. - Если мы выполняли какую-то задачу не так, как хотела ТД или в коде были баги, мы наш код переписывали. После первой пары FAIL-ов время на переписывание нам перестали давать. А задачи надо было делать и сдавать по плану в рамках Контракта – в общем, от Заказчика начало доставаться и аналитику.
И самое вкусное – ТД была на 100% уверена и всем говорила, что у нас чётко отлаженный SCRUM с недельными спринтами через Ж…иру. При этом в самой Jira для скрама использовались KANBAN-доски; длина спринта менялсь в зависимости от частоты поездок ТД и анализика к Заказчику — а они в конце туда ездили каждые 3-4 дня.
Итог: 1 ушёл сам (по иронии судьбы за время этой работы он много раз прочитал Scrum Guide и на следующем месте научился его правильно понимать и применять), 1 уволили за профнепригодность (это был я). Третий на тот момент остался, что с ним стало далее не в курсе.
А компания, говорят, продолжает активно развиваться…
Спасибо, похожие истории уже читаю не первый раз, в том числе на habr. А сейчас вы как работаете над проектами?
Разумеется!
Что самое забавное: исходные данные проекта, в котором я участвую сейчас, почти те же. Похожий контракт, плюс похожее ТЗ с прописанными сроками сдачи этапов и фиксированной стоимостью.
НО:
- В этот раз в команде семеро, из них 5 разработчиков (и лишь один уровня middle и с опытом менее 2-лет enterprise-разработки).
- В договоре заложены сроки с учётом возможных рисков, ибо сразу прописано: для части пунктов ТЗ будет проводиться дополнительное исследование, по результатам которого и будет понятно как сделать лучше. И время на исследование тоже выделено соответственно.
- В команде есть адекватный аналитик, который согласовывает с нами позицию «что и как мы в результате делаем» перед поездкой к заказчику.
- В команде есть Project Owner, который ездит с аналитиком к заказчику и в курсе всего, что требует от нас заказчик, и который также общается с разработчиками и в курсе того, с какими проблемами они сталкиваются.
- Компоненты системы изначально создаются вместе с тестами (конечно это не TDD, но мы стараемся). Мы все знаем и одинаково понимаем gitflow (обычный, не rebase). Имеется ограниченный code-review и включена поддержка merge-request’ов (gitlab). И, разумеется, сервер Teamcity помимо Continuous Build-а, гоняет созданные тесты перед мерджем в dev (сейчас, правда, при каждом коммите, а не перед мерджем, но мы работаем чтобы это поправить).
- В самом начале этапа разработки было потрачено время на «платформу»: сделали базовые сервисы для работы с БД, с окнами и вкладками (UI), и прочим (т.е. Infrastructural Service) – чтобы даже вновь пришедший junior в течение недели мог понять, как создать вкладку (не разбираясь в Prism), как вызвать хранимку с параметрами из БД и получить в ответ коллекцию объектов (опять же, даже ничего не зная про Dapper), и т.д.
Так что надежда, что мы выполним задачу в срок, достаточно сильна, чего и желаю всем хабрачитателям.
Пока проекты были маленькими, задачи легко просчитывались, и работа была «на потоке», мы купались в водопадах и все были счастливы.
Когда стало ясно, что отношения с заказчиком «не на одну ночь», и нам с ним работать много месяцев, поддерживая и улучшая сделанное, гибкость пришла сама.
Когда стало ясно, что отношения с заказчиком «не на одну ночь», и нам с ним работать много месяцев, поддерживая и улучшая сделанное, гибкость пришла сама.
Начали с водопада. Прописали ТЗ. Сроки. Условия. Через полгода заказчик попросил нас работать у него и на него. В итоге мы втроём уволились и перешли работать к заказчику. В итоге концепцию crm, которую мы пишем, поменяли настолько сильно, что ТЗ составляет 20% от уже сделанного…
А сейчас вы поддерживаете этот проект? Как обрабатываете новые требования?
Сейчас мы его развиваем, т.к. он только-только начал выходить из тестирования в продакшн.
В плане новых требований тяжело, т.к. вместо планомерного развития системы мы незакончив одну часть перекидываемся на обновленные пожелания директора. И это не его прихоть, а внезапные обновленные требования регуляторов, законодателей и пр…
Как это происходит (нас трое: я ПМ и QA, двое фулстек кодеры):
У нас есть общий план развития системы. Что было в начале (зоопарк) и что будет в конце ( единое webapp)
Мы планомерно движемся вперед, например, разрабатываем автоматизацию заказов. Тут приходит поручение директора: надо автоматизировать одно из направлений деятельности, которое планировалось где-то через полгода. И это необходимо сделать, т.к. использовать существующий софт невозможно по причине отсутствия обновлений. Окей. Прикидываю срок от плана до продакшена, озвучиваю 5 месяцев. Получаю ответ, что надо сильно быстрее, но «что стоишь, иди уже, пишите». Дальше очень муторный процесс сбора необходимых данных для первых шагов и вперед на отладку частей. Новое задание не реализуется до конца, пока не будет частично сделан блок «задачи» и пр. Поэтому заложен срок 5 месяцев- для частичного исполнении других блоков до состояния «чтобы работало». При всем при этом, успеваем доделывать ( менее быстрыми темпами, правда) то, что делали до этого.
Меня только в таком подходе смущает 2 вещи: сырой продакшен (слишком много ньюансов в работе пользователей о которых они вспоминают после того как все сделано), рефакторинг кода (некогда делать, получается говнокод в стиле, лишь бы работало)
В плане новых требований тяжело, т.к. вместо планомерного развития системы мы незакончив одну часть перекидываемся на обновленные пожелания директора. И это не его прихоть, а внезапные обновленные требования регуляторов, законодателей и пр…
Как это происходит (нас трое: я ПМ и QA, двое фулстек кодеры):
У нас есть общий план развития системы. Что было в начале (зоопарк) и что будет в конце ( единое webapp)
Мы планомерно движемся вперед, например, разрабатываем автоматизацию заказов. Тут приходит поручение директора: надо автоматизировать одно из направлений деятельности, которое планировалось где-то через полгода. И это необходимо сделать, т.к. использовать существующий софт невозможно по причине отсутствия обновлений. Окей. Прикидываю срок от плана до продакшена, озвучиваю 5 месяцев. Получаю ответ, что надо сильно быстрее, но «что стоишь, иди уже, пишите». Дальше очень муторный процесс сбора необходимых данных для первых шагов и вперед на отладку частей. Новое задание не реализуется до конца, пока не будет частично сделан блок «задачи» и пр. Поэтому заложен срок 5 месяцев- для частичного исполнении других блоков до состояния «чтобы работало». При всем при этом, успеваем доделывать ( менее быстрыми темпами, правда) то, что делали до этого.
Меня только в таком подходе смущает 2 вещи: сырой продакшен (слишком много ньюансов в работе пользователей о которых они вспоминают после того как все сделано), рефакторинг кода (некогда делать, получается говнокод в стиле, лишь бы работало)
А клиент платит по фиксу за фичи или почасовая работа? Очень интересно, как продается «рефакторинг»?
Клиент просто платит зарплату. Мы у него по ТК оформлены. Зарплата для нашего города очень хорошая.
А как вы объясняете клиенту, что часть часов ушло не на разработку фич, а на рефакторинг?
А мы и не объясняем. У нас есть цель. Мы сами определяем задачи для реализации. Я, как ПМ, говорю директору срок реализации, увеличив реальный срок на три, директор уменьшает его до Х2. И мы спокойно приступаем к реализации. Сейчас реализация небольших задач длится неделю+ неделя на отладку. Параллельно этому тихонько рефакторится код и делается параллельный проект. До дедлайна обычно все сделано.
Эти все рассуждения и споры в плане как будет работать маленькая команда — вотерфол, агиле и так далее — по сути не имеет особого значения. Как можете так и работайте. Если у вас весь продукт делают 3-5 человека то скорее всего у вас уже гибкая методология, и вы выбираете формальности или обряды — во что одеватся, что слушать с утра — менеджера или стэндап митинг. Просто забавно. Ненадо делать религии на ровном месте и потом сравнивать что же работает — молитвы с утра или вечером. Религии нет смысла сравнивать, для каждого работает своя.
С точки зрения компании большее значение имеет то как работает вся организация в общем, и как масштабируется кол-во команд/людей на скорость развития продукта. Agile и Lean нужен больше большим компаниям чтобы масштабироватся, грубо делать продукт не с 40ка человеками за год а с 10тью за половину. И вот тут уже начинает иметь смысл все то что предлагает agile и особенно его следующая итерация — lean и конкретно DevOps. Это просто прагматичное решение определенных проблем, достижение определенных целей/метрик, и методики собрали в один фреймворк, назвали его DevOps (например).
Вы никогда не замечали футбола между командами, когда например девелоперы что-то сделали, и должны отдать результат другой команде, та команда отдать назад, так несколько раз, потом в QA, и наконец оно доползает до IT/инфраструктуру кастомера, и там еще варится в стадии «еще не взлетело, но мы трудимся»? Не замечали что внутренний дизайн продукта начинает повторять то как организованы команды, а не как было бы лутше с точки зрения клиента/компании?
Вот если замечали, и осознали что в процессе тратится огромное кол-во времени в пустоту/бюрократию/обряды — то вы созрели для гибких методологий, и есть возможность роста. Недавно вышла хорошая книга по DevOps кстати, там расписано как это работает и почему (ключевые слова DevOps Handbook). С точки зрения организации lean/agile есть смысл внедрять, с точки зрения одной команды — это фетишизм, для команды важнее свобода чем навязывание обрядов… Для внедрения гибких методологий по существу должно быть понимание зачем это и к чему надо прийти сверху а не снизу, т.е. верх (президент, VP) ставит задачи и выдает инструменты, низы (тимы) их решают (но свободно, без микроменеджмента).
С точки зрения компании большее значение имеет то как работает вся организация в общем, и как масштабируется кол-во команд/людей на скорость развития продукта. Agile и Lean нужен больше большим компаниям чтобы масштабироватся, грубо делать продукт не с 40ка человеками за год а с 10тью за половину. И вот тут уже начинает иметь смысл все то что предлагает agile и особенно его следующая итерация — lean и конкретно DevOps. Это просто прагматичное решение определенных проблем, достижение определенных целей/метрик, и методики собрали в один фреймворк, назвали его DevOps (например).
Вы никогда не замечали футбола между командами, когда например девелоперы что-то сделали, и должны отдать результат другой команде, та команда отдать назад, так несколько раз, потом в QA, и наконец оно доползает до IT/инфраструктуру кастомера, и там еще варится в стадии «еще не взлетело, но мы трудимся»? Не замечали что внутренний дизайн продукта начинает повторять то как организованы команды, а не как было бы лутше с точки зрения клиента/компании?
Вот если замечали, и осознали что в процессе тратится огромное кол-во времени в пустоту/бюрократию/обряды — то вы созрели для гибких методологий, и есть возможность роста. Недавно вышла хорошая книга по DevOps кстати, там расписано как это работает и почему (ключевые слова DevOps Handbook). С точки зрения организации lean/agile есть смысл внедрять, с точки зрения одной команды — это фетишизм, для команды важнее свобода чем навязывание обрядов… Для внедрения гибких методологий по существу должно быть понимание зачем это и к чему надо прийти сверху а не снизу, т.е. верх (президент, VP) ставит задачи и выдает инструменты, низы (тимы) их решают (но свободно, без микроменеджмента).
Спасибо за развернутый ответ и за рекомендацию по книге!
Простите, какое отношение DevOps имеет к теме статьи?
Потому что DevOps это lean расширенный на всю организацию (в частности IT). DevOps может использовать agile практики (scrum). Это пример глобального применения гибкой методологии. Поэтому есть смысл изучить даже тем кто с IT напрямую не связан. И вообще книг по software development lean не так уж и много.
Вы точно термины не путаете? Можно ссылку на тот DevOps о котором говорите Вы?
Моя интерпретация DevOps видимо похожа на данную в упомянутой книге — https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002
Agile-водопад! Или итеративная разработка. Поясню.
Приходит клиент — говорит, хочу систему, требования как всегда где-то в облаках, но не хочу T&M, только Fix Price. Мы — ОК, давай ТЗ на первый этап. Клиент — ОК, есть ТЗ, срок — месяц-два. Делаем — принимаем, в конце двухнедельный UAT (грубо говоря продаем команду на две недели, в рамках 80 ч-часов*на количество членов команды клиент может делать все что угодно). В процессе текущего релиза — аналитик прорабатывает требования на следующий релиз (релиз 0 — работал только аналитик). Дальше — опять — оцениваем, делаем, UAT, profit. Вероятность того, что посередине проекта понадобиться «менять архитектуру» минимальна, потому что 90% enterprise проектов тупые как пробки :)
Да, внутри релиза-спринта пробовали и SCRUM, и Kanban (хотя все одно и тоже) — работает только «микроменеджмент» — приходит тим-лид/ПМ и говорит кому что делать, потому что самоорганизующиеся команды — они только в книжках и на картинках бывают. Обычно разработчику по фигу на проект, на компанию, на ПМ, на заказчика — ему главное, чтобы деньги регулярно поступали на карту.
PS Имю опыт попытки внедрения SCRUM в 10 проектах — нормально получилось только в одном, когда команда сама этого захотела (было модно, середина 2000-х и решили попробовать), и еще на заре карьеры, когда будучи студентами сами писали игру (только не знали, что это SCRUM). В 9 проектах — получал в лоб от девелоперов «Нам плевать на SCRUM, Agile, проект, заказчика и пр. Если что — работу найдем на раз-два, а ты говори что делать, а сам я себе задачи выбирать не буду». Вот…
Приходит клиент — говорит, хочу систему, требования как всегда где-то в облаках, но не хочу T&M, только Fix Price. Мы — ОК, давай ТЗ на первый этап. Клиент — ОК, есть ТЗ, срок — месяц-два. Делаем — принимаем, в конце двухнедельный UAT (грубо говоря продаем команду на две недели, в рамках 80 ч-часов*на количество членов команды клиент может делать все что угодно). В процессе текущего релиза — аналитик прорабатывает требования на следующий релиз (релиз 0 — работал только аналитик). Дальше — опять — оцениваем, делаем, UAT, profit. Вероятность того, что посередине проекта понадобиться «менять архитектуру» минимальна, потому что 90% enterprise проектов тупые как пробки :)
Да, внутри релиза-спринта пробовали и SCRUM, и Kanban (хотя все одно и тоже) — работает только «микроменеджмент» — приходит тим-лид/ПМ и говорит кому что делать, потому что самоорганизующиеся команды — они только в книжках и на картинках бывают. Обычно разработчику по фигу на проект, на компанию, на ПМ, на заказчика — ему главное, чтобы деньги регулярно поступали на карту.
PS Имю опыт попытки внедрения SCRUM в 10 проектах — нормально получилось только в одном, когда команда сама этого захотела (было модно, середина 2000-х и решили попробовать), и еще на заре карьеры, когда будучи студентами сами писали игру (только не знали, что это SCRUM). В 9 проектах — получал в лоб от девелоперов «Нам плевать на SCRUM, Agile, проект, заказчика и пр. Если что — работу найдем на раз-два, а ты говори что делать, а сам я себе задачи выбирать не буду». Вот…
спасибо за отзыв. А вы внедряли в 10 проектах SCRUM в чистом виде? (Как написано в соответствующих книгах?)
В большинстве — да, в чистом виде. Правда 4 проекта были с удаленными командами. Аналитик в качестве Product Owner'а, я как SCRUM Master. Сначала stand up митинги превращаются в обычные статус-митинги (закрыл 2 баги, буду закрывать еще 3, проблем нет), потом команда говорит — «А смысл?» и собирается раз в два дня, а потом совсем перестает. На ретроспективе кто в телефоне, кто зевает и прочее. Единственный митинг, где можно расшевелить — это sprint planning. Тут все брызжат идеями, как построить звездолет для похода в соседнюю булочную (а вдруг конец света, а мы тут раз и в космос), Product Owner пытается сказать, что надо все быстро и просто, но так же не круто, что этот бизнесмен понимает в АРХИТЕКТУРЕ ПО :)
Я дико извиняюсь, а размер команды у вас какой?
Ну разные были. От 5 до 10 человек (да-да, 10 человек много). Не зависит успешность от размера команды. Сейчас в наследство передали часть команды и сказали — внедряй SCRUM (не зеленый банк). В сумме 10 человек, надо делить команду и проект. Но осложняется тем, что часть команды — чистые ораклисты, что в SCRUM'е не приветствуется. НУ а команда мне честно сказала — нам на проект плевать, пока ипотеку не выплатим, будем сидеть и тихо пилить :)
Прорвемся :)
Прорвемся :)
За 20 лет карьеры в основном практиковал Водопад. Почти всегда укладывался в сроки и бюджет. Но подход тяжёлый и угрюмый, приводит к жёстким разборкам с заказчиком, который сначала боится подписывать требования, чуя, что толком не понимает чего хочет, а потом, когда понимает, что не зря боялся и требования изменились — ищет зацепки чтобы вывернуться из своих же требований и выставить подрядчика дураком и не профессионалом. Зато реально позволяет придти к цели за запланированное время и запланированный бюджет. Беда, однако, в том, что понимание цели может сильно измениться.
Эджайл хорош всем кроме того, что бюджета и сроков никто не понимает. При этом заказчик скорее всего продавит вас на фиксированный бюджет и сроки.
И вот тут появляется та самая гигантская Ж! Вы будете делать НЕ фиксированный объём за фиксированные деньги. Я в таком участвовал и никому не пожелаю.
Эджайл хорош всем кроме того, что бюджета и сроков никто не понимает. При этом заказчик скорее всего продавит вас на фиксированный бюджет и сроки.
И вот тут появляется та самая гигантская Ж! Вы будете делать НЕ фиксированный объём за фиксированные деньги. Я в таком участвовал и никому не пожелаю.
Ситуация, когда «с заказчиком, который сначала боится подписывать требования, чуя, что толком не понимает чего хочет, а потом, когда понимает, что не зря боялся и требования изменились — ищет зацепки чтобы вывернуться из своих же требований и выставить подрядчика дураком и не профессионалом» видится мне знакомой.
Действительно, Клиент хочет знать, сколько он заплатит из своего кармана и когда получит результат, только вот видение результата у него нет. Хорошо, когда команда помогает сформировать видение и углубляется в бизнес этого клиента настолько, что может ему действительно помочь. Беда в том, что и за это платить не каждый готов.
Действительно, Клиент хочет знать, сколько он заплатит из своего кармана и когда получит результат, только вот видение результата у него нет. Хорошо, когда команда помогает сформировать видение и углубляется в бизнес этого клиента настолько, что может ему действительно помочь. Беда в том, что и за это платить не каждый готов.
Осознание цели приходит как правило уже на этапе демонстрации прототипа или позднее — на этапе опытной эксплуатации. К тому моменту могут смениться уже и персоналии заказчика, формулировавшие когда-то требования. И компания Заказчика может измениться, и бизнес и рынок. Команда, конечно помогает осознать цель, но она же тоже не может всего этого предвидеть и угадать кому где будет жать, когда костюмчик уже сшит, а у кого-то вырос живот.
Где то читал, что если в хотя бы в одну какую-то часть итерации Agile вкрадывается сторонняя модель (Waterfall) — то всё — сливаем воду — это больше НЕ Agile. Суть в том, что ключевая фишка Agile как ни странно — в гибкости (Капитан Очевидность детектед). И эта гибкость требуется на всех итерациях скопа, но если скажем на этапе бизнес планирования — начинаются "ватерфальные согласования и откаты на предыдущие шаги для дополнительного согласования", то это ватерфал с элементами аджайла, который теряет до 90% эффективности всего аджайла. Т.е. в большинстве случаев, это ватерфалл в котором "для галочки" присутствует аджайл, но на самом деле — это присутствие ограничивается "чувством собственной вовлечённости" у "дефективныхэффективных менеджеров", которые "успешно внедрили" этот суррогат и убожество: они то думают, что достаточно внедрить аджайл в команду разработки и всё — у них работает модерновый процесс, а на самом деле — всю эффективность аджайла тормозят остальные отделы, которые продолжают работать "по старинке".
Все правильно, а Agile который идет только из dev комманды без стратегии свыше превращается в фетиш, имхо. Тотже смысл DevOps это натянуть lean на всю организацию (включая IT), и тогда это начинает нести практический смысл.
А когда в организации по старинке созданы команды по леерам (а не кросс-функциональные таск форсы) то agile по сути и нет, есть обряды чтобы это выглядело "круто" и мол мы продвинуто работаем. Ха-ха.
спасибо за отзыв!
Я комбинировал Scrum и водопад, ничего, нормально. Водопад использовался в целом, в большом проекте. А в команде разработки внутри был Scrum. Одно другому не мешало. Кроме того, что никто не понимал когда закончится разработка вообще, а не конкретного спринта.
Всё зависит от проекта и от ПМ в команде. У нас сейчас вредный заказчик, мало того, что я комбинирую методологии, так я помимо стараюсь ими гибко управлять. Используем SCRUM и waterfall.
SCRUM
В зависимости от настроения заказчика, которое по моим наблюдениям меняется периодически, то хотят видеть долгосрочный план проекта, перед этим начитавшись и пересказав книги по SCRUM. В данном случае разработчики довольны, ПМ доволен, заказчик доволен. Есть время прогнозировать риски. Работы выполняются по плану. Все с хорошим настроением.
Waterfall или Kanban (в зависимости от ситуации. Если возможно решение только в чёткой последовательности, то waterfall)
Приходит время, часть системы введена в эксплуатацию. Заказчику всё нравится, но он начинает осознавать, что многих фич, которые были убраны из базового функционала изобретаемого в первую очередь и перенесены в долгий ящик в самый низ бэклога, катастрофически не хватает, доказывая что без этого никак нельзя, и это нужно вчера, но согласен чтобы это было завтра, игнорируя все составленные и утверждённые планы. В кратчайшие сроки теперь требуется получить множество мелкого дополнительного(не важного) функционала, мы временно переходим на waterfall, сдвигая спринты и сроки по задачам заложенным в них, до тех пор пока заказчик не будет удовлетворён. Таким образом забывая SCRUM, мы бережём нервы всех заинтересованных лиц, участвующих в проекте, отбрасывая споры и воспоминания о каких-либо договорённостях и инструкциях.
SCRUM и Waterfall(Kanban).
Но в большинстве случаев на приходится комбинировать 2 методологии, подстраивая JIRA под интересы всех сторон. С некоторыми игрушками запущенными в продакшене, заказчик не успевает наиграться и считает, что это помогает бизнесу, поэтому требует выполнить определённое количество задач оставленных в беклоге, которые должны были делаться в последнюю очередь, но соблюдая и двигаясь по поставленным задачам заложенным в спринты минимально сдвигая сроки. В этом случае для меня по практике является выделение одного или нескольких разработчиков на задачи по kanban и перенося или сдвигая задачи которые были запланированы в спринтах. Таким образом создаётся возможность контролировать оперативную работу, задачи, а также следовать составленному плану с минимальными изменениями.
В заключение хочу сказать, что нет идеальной методологии. Есть много факторов влияющих на работу, включая погоду. Нужно просто подбирать оптимальные и действенные инструменты, лавировать между запросами, предупреждать и обсуждать цели и задачи своевременно с заинтересованными сторонами.
Спасибо за интересную статью!
SCRUM
В зависимости от настроения заказчика, которое по моим наблюдениям меняется периодически, то хотят видеть долгосрочный план проекта, перед этим начитавшись и пересказав книги по SCRUM. В данном случае разработчики довольны, ПМ доволен, заказчик доволен. Есть время прогнозировать риски. Работы выполняются по плану. Все с хорошим настроением.
Waterfall или Kanban (в зависимости от ситуации. Если возможно решение только в чёткой последовательности, то waterfall)
Приходит время, часть системы введена в эксплуатацию. Заказчику всё нравится, но он начинает осознавать, что многих фич, которые были убраны из базового функционала изобретаемого в первую очередь и перенесены в долгий ящик в самый низ бэклога, катастрофически не хватает, доказывая что без этого никак нельзя, и это нужно вчера, но согласен чтобы это было завтра, игнорируя все составленные и утверждённые планы. В кратчайшие сроки теперь требуется получить множество мелкого дополнительного
SCRUM и Waterfall(Kanban).
Но в большинстве случаев на приходится комбинировать 2 методологии, подстраивая JIRA под интересы всех сторон. С некоторыми игрушками запущенными в продакшене, заказчик не успевает наиграться и считает, что это помогает бизнесу, поэтому требует выполнить определённое количество задач оставленных в беклоге, которые должны были делаться в последнюю очередь, но соблюдая и двигаясь по поставленным задачам заложенным в спринты минимально сдвигая сроки. В этом случае для меня по практике является выделение одного или нескольких разработчиков на задачи по kanban и перенося или сдвигая задачи которые были запланированы в спринтах. Таким образом создаётся возможность контролировать оперативную работу, задачи, а также следовать составленному плану с минимальными изменениями.
В заключение хочу сказать, что нет идеальной методологии. Есть много факторов влияющих на работу, включая погоду. Нужно просто подбирать оптимальные и действенные инструменты, лавировать между запросами, предупреждать и обсуждать цели и задачи своевременно с заинтересованными сторонами.
Спасибо за интересную статью!
Знающие друзья, подскажите, как вышеперечисленные методы можно соединить с проектно-управленческим софтом типа Basecamp, Битрикс и т.д.?
Поделитесть, где можно изучить настоящий страшный и ужасный Waterfall?
PMI, к примеру, в PMBoK упоминает много раз гибкие методологии как один из вариантов реализации проектов (включая частые итерации, прототипирование, метод набегающей волны в уточнении требований). И это не говоря про отдельную специализацию PMI-Agile.
PMI, к примеру, в PMBoK упоминает много раз гибкие методологии как один из вариантов реализации проектов (включая частые итерации, прототипирование, метод набегающей волны в уточнении требований). И это не говоря про отдельную специализацию PMI-Agile.
Завидую людям, у которых в проектах методики работают…
У меня, хоть и занимаюсь последние лет 15-20 тяжелыми железками в основном, заказчиков с проектами, у которых меньше 15 пятниц в неделю, пока не встречалось… И это при том, что трудно внести изменения в цели и задачи проекта, когда проект согласован, 230 тонн оборудования уже оплачено, отгружено и едет, а в помещениях уже красят стены… Но они пытаются.
У меня, хоть и занимаюсь последние лет 15-20 тяжелыми железками в основном, заказчиков с проектами, у которых меньше 15 пятниц в неделю, пока не встречалось… И это при том, что трудно внести изменения в цели и задачи проекта, когда проект согласован, 230 тонн оборудования уже оплачено, отгружено и едет, а в помещениях уже красят стены… Но они пытаются.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
FixPrice Agile или SCRUM через Ж… иру