Важно!
- В статье присутствует определенная доля иронии.
- Статья ни в коем случае не ущемляет чьи-либо интересы.
- В статье не противопоставляется SCRUM водопаду и не смешивается «мягкое с теплым».
- У каждого свое мнение на процесс разработки проектов, свой опыт или его отсутствие, свой счастливый клиент или свой провалившийся проект, выполненный по методологии, с помощью проектных методик, руководствуясь принципами или интуицией.
- Будьте добрее!
Scrum — это, конечно, хорошо, когда есть четкий набор задач на спринт, командный дух бесконечно поднят, клиент платит за спринты, потому что он уже привык это делать, а компания получает доход и верит, что проект никогда не закончится.
Водопад — это тоже здорово, клиент четко знает, что уложится в определенный бюджет, все шаги расписаны до мелочей, но до той поры, пока клиент не захочет что-то изменить в проекте или начинает понимать, что проект идет не туда, куда хотелось бы.
В условиях, когда клиент хочет четко знать свои затраты, команда хочет драйва и иметь возможность влиять на ход проекта, а компания хочет стабильно получать свой доход, менеджеру приходится маневрировать между всеми этими требованиями и выбирать подходящую методологию, метод, принципы, правила.
Именно поэтому можно проследить тенденцию к смешиванию методологий, правил и принципов.
Давайте поговорим о клиентах
Как правило, им хочется укладываться в первоначальный запланированный бюджет, иметь возможность регулярно видеть результаты проекта, влиять на ход проекта, вносить изменения в продукт.
Фиксированный бюджет всего проекта у нас предполагает, как пример, водопадная модель, возможность влиять на продукт и вносить изменения широко представлена в гибких методологиях, итерации и регулярные демонстрации характерны также для гибких методологий, документация, покрывающая все этапы проекта ярко представлена в PMI.
Получается такой очень милый клиентам Франкенштейн методологий и подходов к управлению.
Для проектной команды
Наибольший интерес представляют проекты, в которых можно вносить предложения по улучшению, т.е. участвовать в развитии продукта. Так, в процессе мозгового штурма можно придумать новую полезную опцию или использовать интересную технологию/язык программирования. В такой работе переплетается и творчество, и высокие риски, поэтому фиксированный бюджет здесь не подходит, он лишь будет тяжким грузом висеть и ограничивать простор для фантазии. Командам нравится работать на основе time and material, выбирать приоритеты задач в том порядке, в котором будет удобнее разрабатывать. При таком гибком подходе очень легко принимаются новые пожелания клиентов и меняются приоритеты задач.
Для компании
На мой взгляд, интересна водопадная модель. При таком подходе на старте проекта оговариваются и документируются все требования, выставляются рамки, четко видна цель проекта, легко сопоставить требования с актами приемки. Мы получаем минимум неожиданностей, минимум рисков, и при этом, четко прописанные даты и бюджеты. При использовании такой модели порядка больше, компания увереннее прогнозирует получение очередного транша.
Для менеджера
C точки зрения проектной работы идеальной моделью является водопадная модель. Тут на старте нужно постараться задокументировать продукт, предусмотреть все риски, а потом контролировать, что все идет согласно плану А вот с точки зрения командной работы — хочется креатива, хочется подсказывать, делиться опытом, менять курс. Командные обсуждения, brainstorm, daily митинги, меняющийся продукт – это все позволяет сделать Agile философия.
Что же делать в ситуации, когда:
— на глубокую аналитику в начале проекта нет времени или не выделяются финансы,
— есть жестко фиксированный бюджет и этапы сдачи, прописанные в договоре,
— в процессе проекта возникают новые пожелания, которые никоем образом не могут быть перенесены во вторую версию продукта и появляются другие незапланированные задачи?
Смешивать!
Можно работать по водопаду, но оставлять бюджет для маневров. В такой модели договор будет оформлен на основную функциональность продукта, а дополнительными соглашениями можно изменять рамки проекта. Таким образом будет решена задача фиксированного бюджета и добавления новшеств в продукте в процессе разработки.
Можно работать по SCRUM, но с фиксированным набором спринтов. Такая модель больше подойдет стартапам, когда хочется и видеть развитие продукта, и изменять его, и в то же время оставаться в рамках бюджета. До начала спринта отбираются задачи, оцениваются, клиенту предоставляется смета. Эта смета утверждается и уходит в работу, любые изменения переносятся в следующий спринт, при этом если изменение было на 8 часов, то из проекта удаляется любая другая задача на это же количество часов. Здесь и команда может эффективно работать над поставленными задачами, и клиент влияет на процесс, составляя задачи в спринт, и клиент контролирует свой бюджет. В таком случае продукт выходит в свет, даже с урезанной функциональностью.
Существует подход, при котором клиент платит ежемесячно фиксированную сумму, при этом команда обрабатывает различное количество задач из месяца в месяц. Иными словами клиент берет команду в аренду. Он может насыпать им задач на всю неделю, а может совсем не подготовить задач, при этом команда будет получать ежемесячно оговоренную сумму.
Такой подход не обязательно относится к проектам технической поддержки, он уместен и для разработки продукта.
Для клиента такой подход подразумевает фиксированные затраты и высокую заинтересованность в загрузке команды. Для компании, которая предоставляет такой сервис, гарантирована занятость сотрудников и стабильные пополнения бюджета.
В заключении хочу сказать, что каждая компания, клиент, проект – уникальны. Любой из существующих подходов может подойти именно для вашего проекта, а если нет — придумайте свой подход, и найдите того партнера, с которым вы сможете реализовать его.
Очень хочется услышать ваш опыт, получается ли у вас работать только в рамках одной методологии/методики?
Если вы работали по классической каскадной модели, писали концепцию/ТЗ/Рабочий проект/Спецификации/прочее, строили диаграммы Ганта, рисовали водопадные схемы, предусматривали реестр рисков, вели, так называемый, «out of scope» и только после окончания плановых работ вернулись к нему, уложились в плановый бюджет и срок, ваш клиент остался в восторге от проекта, ВЫ КРУТЫЕ и низкий вам поклон! Вы скрупулёзный менеджер, с чувствительными частями тела с одной стороны и железными частями с другой стороны, что помогло вам провидеть ход проекта и отстоять заключенные договоренности, как с командой, так и с клиентом. Напишите в комментариях «ВОДОПАД!», страна должна знать героев в лицо.
Если для своих проектов вы выбрали гибкую модель разработки, основанную на принципах Agile, вы знаете Agile Manifesto лучше, чем пароль от вашей почты, ваши команды высокоорганизованные, ваши Клиенты счастливы от результатов, которые они получают от итерации к итерации, вы чувствуете себя как рыба в воде, меня курс направления, ВЫ МОЛОДЫ! У вас гибкий ум, молниеносная реакция, низкая инертность и высокая говорливость. Вы очень очень очень много комуницируете. Напишите в комментариях «Agile» (пусть все знают, вы можете работать гибко и вы это делаете успешно!).
Если вы умете совмещать методологии с методиками, принципы с правилами и у вас получается, расскажите всем, как вы это делаете?
Что вам не позволяет работать в рамках строго одного метода/подхода/методологии? Клиенты такие разные? Обстоятельства? Менеджеры? Проектные решения? Принципы работы компаний? Неудобства и ограничения?
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (48)
S_A
04.03.2017 08:51+3ВОДОПАД! 20% процентов в бюджете, сроке и качестве. В остальных хотя бы что-то одно шло не так.
Я как-то на Хабре писал уже в чем разница между проектом, продуктом и услугой. Собственно от непонимания различий идут и холиворы, и проблемы в реальных проектах.
Клиенту начихать, Agile у вас, PMI PMBoK, PERT или FuckDownDrivenDevelopment. Ему нужен продукт, которым он решит свои задачи, пусть даже он купил outstaff.
Проблема номер один: у клиента что-то меняется -> должен поменяться продукт, но из этого автоматически не следует что должен поменяться проект. Решение юридическое, но из него вытекает…
Проблема номер два: проект оценивают как услугу (выполнение заказанных действий) -> значит если за уплаченный бюджет результат не достигнут, то это проблема клиента.
Разрешение этой курояичности не в балансе между Time/Material или Agile/Waterfall, это всё поиск ВНУТРИ проектов, ёшкина кошка. Ответ лежит в портфельном управлении (не в том как правильно делать проект, а в том чтобы делать правильный проект). Лучше клиенту потратить пусть чуть больше, но заработает намного-намного больше, и тогда вот эти все процессные штучки — развлекухи для праздных умов.S_A
04.03.2017 13:37Вдобавок, в чем самый LOL ситуации.
Клиентам, которые не считают выхлоп на затраты, Material — дорого и переплата, а Waterfall — не тот результат. В результате менеджеры проектов тратят зарплату на алкоголь (замена вазелина для вытраханных мозгов), а риски как гуляли между клиентом и заказчиком, так там и остаются.
lencom
04.03.2017 09:01+2Смешиваем, поступая интуитивно, ситуативно, с перевесом в ту или другую методологию, клиенты и проекты разные.
В чистом виде SCRUM не получается делать, т.к. приходится переключаться между проектами в середине спринта по разным причинам: то согласование дизайна страницы задержали, потому что клиент уехал в Китай по делам, то предоплату по спринту, то проектов несколько параллельно, приходится перебрасывать ресурсы. Поэтому, если это SCRUM, то SCRUM через Ж. Это всё не от хорошего управления, конечно.
Ещё практикуем, как мы называем, «Сайт за 3 встречи» — это водопад с минимальным задействованием клиента и максимальной самостоятельностью команды. 3 встречи — 1. интервью, чтобы узнать бизнес, задачу, видение клиента, задача максимально разговорить, 2. презентация и защита решения, 3. презентация и защита готового результата. Между 1 и 2 команда придумывает и проектирует решение. Между 2 и 3 реализует решение. Это рискованный формат, делаем только с некоторыми клиентами, в основном не с новыми, для некрупных проектов.
Подходит для клиентов, которым нужен результат, а не то, как мы его будем достигать. Плюс для клиента — он экономит время, ответственность на подрядчике. Плюс для нас — свобода выбора инструментов, нет череды длительных согласований (сначала ТЗ, потом контент-план, потом прототипы, потом дизайн).
povetkina_nastenka
04.03.2017 23:27Спасибо! Хотелось бы подробнее узнать, вся команда защищает решение (стадия 2)? По статистике готовый результат на стадии 3 удовлетворяет заказчиков?
lencom
05.03.2017 16:22Решение защищает его автор. Как правило, это менеджер проекта. На встрече присутствует МП, продавец, и иногда профильный специалист, если проект технически непростой.
По статистике — в целом удовлетворяет. На третьей встрече ведётся 2 списка: «окончательные правки» и «идеи». У нас есть 3 дня для мелкого проекта, чтобы закрыть пункты из первого списка, или неделя для среднего.
Наш лучший результат — 1 пункт в первом списке, который разработчик из офиса закрыл прямо во время встречи.
sshikov
04.03.2017 10:19+2ВОДОПАД! Но только я не менеджер ни разу. Просто участвовал в таком проекте.
Все было хорошо, но когда клиент захотел гибко менять требования в процессе — многое пошло не так.
VolCh
04.03.2017 11:05+5Ни разу не видел, чтобы на сколь-нибудь длительном проекте на договорных началах заказчика подрядчик, чёткое следование какой-то формальной методологии приводило к завершению проекта к взаимному удовольствию сторон и продолжению сотрудничества. В лучшем случае у сторон нет юридических претензий к друг другу из-за понимания их неперспективности. Но либо клиент считает, что сильно переплатил за незначительное отклонение от первоначального плана, либо исполнитель считает, что ему недоплатили за значительное отклонение от плана. Это даже если сроками удовлетворены. При анализе ситуации со стороны часто видно, что первоначальные оценки занижались исполнителем то ли сознательно ради большей привлекательности своего предложения, то ли из-за слабого понимания с чем реально придётся столкнуться. А признавали ошибку слишком поздно, чтобы найти компромиссный вариант, хотя бы в виде закрытия проекта в целом.
funca
04.03.2017 16:25+2Вообще комбинировать это весело. Недавно возле зоопарка видел мальчишку, сидящего верхом на лошадке. Он держал руки перед собой и воображал, что крутит руль. Выглядел вполне довольным.
Интересно, что было бы с лошадкой, будь у парня все мендежерские полномочия перестраивать так, как ему комфортнее управлять, ну там руль к голове прикрутить? Производство не лошадка, но когда сервисы начинают внедрять себе продуктовые методики управления (и наоборот), ментальная кровища хлещет во все стороны. Тут не важно, через ж… иру, или как.
SLenik
05.03.2017 09:39Читаю комментарии и вспоминаю свою первую контору, в которой я официально начал работать по специальности (то есть разработчиком).
- Начнём с того, что де-факто технический директор (далее ТД) Компании считала себя Project-менеджером данного проекта, а по факту была дочкой гендира компании-Заказчика со всеми вытекающими требованиями.
- Все разработчики исключая меня (то есть ещё 2 человека) были либо недавно выпустившимися студентами, либо ещё студентами и работали на полставки. И ни у кого из нас за плечами не было опыта промышленной разработки – при этом и наниматель, и ТД об этом знали, но удивлялись, почему же мы тормозим и почему у нас накапливаются задачи.
- Как следствие, ТД (как «единственный адекватный человек») решила ввести некое подобие code-review, на котором нам говорили, как надо было делать (то есть ввели проектирование кода после его написания). Причём по многим концептуальным вопросам ТД отправляла нас в Гугл («и вы ещё спрашиваете, что такое паттерн «репозиторий»?). Уже много позже я понял, что сама ТД скорее всего обучалась применению паттернов проектирования там же, куда посылала нас.
- Через 4 месяца после моего прихода по настоянию ТД (ибо «как-то медленно двигаемся») к проекту подключили аналитика, который в течение пары недель расписал ТЗ на пару месяцев вперёд (согласно вашей классификации – чёткое ТЗ со сроками = водопад).
До этого ТЗ составляла лично ТД через обсуждение, иногда описывая требования через Ж…. иру. - Если мы выполняли какую-то задачу не так, как хотела ТД или в коде были баги, мы наш код переписывали. После первой пары FAIL-ов время на переписывание нам перестали давать. А задачи надо было делать и сдавать по плану в рамках Контракта – в общем, от Заказчика начало доставаться и аналитику.
И самое вкусное – ТД была на 100% уверена и всем говорила, что у нас чётко отлаженный SCRUM с недельными спринтами через Ж…иру. При этом в самой Jira для скрама использовались KANBAN-доски; длина спринта менялсь в зависимости от частоты поездок ТД и анализика к Заказчику — а они в конце туда ездили каждые 3-4 дня.
Итог: 1 ушёл сам (по иронии судьбы за время этой работы он много раз прочитал Scrum Guide и на следующем месте научился его правильно понимать и применять), 1 уволили за профнепригодность (это был я). Третий на тот момент остался, что с ним стало далее не в курсе.
А компания, говорят, продолжает активно развиваться…
povetkina_nastenka
06.03.2017 15:26Спасибо, похожие истории уже читаю не первый раз, в том числе на habr. А сейчас вы как работаете над проектами?
SLenik
06.03.2017 22:56Разумеется!
Что самое забавное: исходные данные проекта, в котором я участвую сейчас, почти те же. Похожий контракт, плюс похожее ТЗ с прописанными сроками сдачи этапов и фиксированной стоимостью.
НО:
- В этот раз в команде семеро, из них 5 разработчиков (и лишь один уровня middle и с опытом менее 2-лет enterprise-разработки).
- В договоре заложены сроки с учётом возможных рисков, ибо сразу прописано: для части пунктов ТЗ будет проводиться дополнительное исследование, по результатам которого и будет понятно как сделать лучше. И время на исследование тоже выделено соответственно.
- В команде есть адекватный аналитик, который согласовывает с нами позицию «что и как мы в результате делаем» перед поездкой к заказчику.
- В команде есть Project Owner, который ездит с аналитиком к заказчику и в курсе всего, что требует от нас заказчик, и который также общается с разработчиками и в курсе того, с какими проблемами они сталкиваются.
- Компоненты системы изначально создаются вместе с тестами (конечно это не TDD, но мы стараемся). Мы все знаем и одинаково понимаем gitflow (обычный, не rebase). Имеется ограниченный code-review и включена поддержка merge-request’ов (gitlab). И, разумеется, сервер Teamcity помимо Continuous Build-а, гоняет созданные тесты перед мерджем в dev (сейчас, правда, при каждом коммите, а не перед мерджем, но мы работаем чтобы это поправить).
- В самом начале этапа разработки было потрачено время на «платформу»: сделали базовые сервисы для работы с БД, с окнами и вкладками (UI), и прочим (т.е. Infrastructural Service) – чтобы даже вновь пришедший junior в течение недели мог понять, как создать вкладку (не разбираясь в Prism), как вызвать хранимку с параметрами из БД и получить в ответ коллекцию объектов (опять же, даже ничего не зная про Dapper), и т.д.
Так что надежда, что мы выполним задачу в срок, достаточно сильна, чего и желаю всем хабрачитателям.
Bvp254
05.03.2017 20:41Пока проекты были маленькими, задачи легко просчитывались, и работа была «на потоке», мы купались в водопадах и все были счастливы.
Когда стало ясно, что отношения с заказчиком «не на одну ночь», и нам с ним работать много месяцев, поддерживая и улучшая сделанное, гибкость пришла сама.
isironn
05.03.2017 20:41Начали с водопада. Прописали ТЗ. Сроки. Условия. Через полгода заказчик попросил нас работать у него и на него. В итоге мы втроём уволились и перешли работать к заказчику. В итоге концепцию crm, которую мы пишем, поменяли настолько сильно, что ТЗ составляет 20% от уже сделанного…
povetkina_nastenka
06.03.2017 15:27А сейчас вы поддерживаете этот проект? Как обрабатываете новые требования?
isironn
06.03.2017 18:11Сейчас мы его развиваем, т.к. он только-только начал выходить из тестирования в продакшн.
В плане новых требований тяжело, т.к. вместо планомерного развития системы мы незакончив одну часть перекидываемся на обновленные пожелания директора. И это не его прихоть, а внезапные обновленные требования регуляторов, законодателей и пр…
Как это происходит (нас трое: я ПМ и QA, двое фулстек кодеры):
У нас есть общий план развития системы. Что было в начале (зоопарк) и что будет в конце ( единое webapp)
Мы планомерно движемся вперед, например, разрабатываем автоматизацию заказов. Тут приходит поручение директора: надо автоматизировать одно из направлений деятельности, которое планировалось где-то через полгода. И это необходимо сделать, т.к. использовать существующий софт невозможно по причине отсутствия обновлений. Окей. Прикидываю срок от плана до продакшена, озвучиваю 5 месяцев. Получаю ответ, что надо сильно быстрее, но «что стоишь, иди уже, пишите». Дальше очень муторный процесс сбора необходимых данных для первых шагов и вперед на отладку частей. Новое задание не реализуется до конца, пока не будет частично сделан блок «задачи» и пр. Поэтому заложен срок 5 месяцев- для частичного исполнении других блоков до состояния «чтобы работало». При всем при этом, успеваем доделывать ( менее быстрыми темпами, правда) то, что делали до этого.
Меня только в таком подходе смущает 2 вещи: сырой продакшен (слишком много ньюансов в работе пользователей о которых они вспоминают после того как все сделано), рефакторинг кода (некогда делать, получается говнокод в стиле, лишь бы работало)povetkina_nastenka
13.03.2017 10:23А клиент платит по фиксу за фичи или почасовая работа? Очень интересно, как продается «рефакторинг»?
isironn
13.03.2017 10:30Клиент просто платит зарплату. Мы у него по ТК оформлены. Зарплата для нашего города очень хорошая.
povetkina_nastenka
13.03.2017 10:49А как вы объясняете клиенту, что часть часов ушло не на разработку фич, а на рефакторинг?
isironn
13.03.2017 11:52А мы и не объясняем. У нас есть цель. Мы сами определяем задачи для реализации. Я, как ПМ, говорю директору срок реализации, увеличив реальный срок на три, директор уменьшает его до Х2. И мы спокойно приступаем к реализации. Сейчас реализация небольших задач длится неделю+ неделя на отладку. Параллельно этому тихонько рефакторится код и делается параллельный проект. До дедлайна обычно все сделано.
forester11
05.03.2017 21:26Эти все рассуждения и споры в плане как будет работать маленькая команда — вотерфол, агиле и так далее — по сути не имеет особого значения. Как можете так и работайте. Если у вас весь продукт делают 3-5 человека то скорее всего у вас уже гибкая методология, и вы выбираете формальности или обряды — во что одеватся, что слушать с утра — менеджера или стэндап митинг. Просто забавно. Ненадо делать религии на ровном месте и потом сравнивать что же работает — молитвы с утра или вечером. Религии нет смысла сравнивать, для каждого работает своя.
С точки зрения компании большее значение имеет то как работает вся организация в общем, и как масштабируется кол-во команд/людей на скорость развития продукта. Agile и Lean нужен больше большим компаниям чтобы масштабироватся, грубо делать продукт не с 40ка человеками за год а с 10тью за половину. И вот тут уже начинает иметь смысл все то что предлагает agile и особенно его следующая итерация — lean и конкретно DevOps. Это просто прагматичное решение определенных проблем, достижение определенных целей/метрик, и методики собрали в один фреймворк, назвали его DevOps (например).
Вы никогда не замечали футбола между командами, когда например девелоперы что-то сделали, и должны отдать результат другой команде, та команда отдать назад, так несколько раз, потом в QA, и наконец оно доползает до IT/инфраструктуру кастомера, и там еще варится в стадии «еще не взлетело, но мы трудимся»? Не замечали что внутренний дизайн продукта начинает повторять то как организованы команды, а не как было бы лутше с точки зрения клиента/компании?
Вот если замечали, и осознали что в процессе тратится огромное кол-во времени в пустоту/бюрократию/обряды — то вы созрели для гибких методологий, и есть возможность роста. Недавно вышла хорошая книга по DevOps кстати, там расписано как это работает и почему (ключевые слова DevOps Handbook). С точки зрения организации lean/agile есть смысл внедрять, с точки зрения одной команды — это фетишизм, для команды важнее свобода чем навязывание обрядов… Для внедрения гибких методологий по существу должно быть понимание зачем это и к чему надо прийти сверху а не снизу, т.е. верх (президент, VP) ставит задачи и выдает инструменты, низы (тимы) их решают (но свободно, без микроменеджмента).
serega011
06.03.2017 21:18Простите, какое отношение DevOps имеет к теме статьи?
forester11
07.03.2017 12:42Потому что DevOps это lean расширенный на всю организацию (в частности IT). DevOps может использовать agile практики (scrum). Это пример глобального применения гибкой методологии. Поэтому есть смысл изучить даже тем кто с IT напрямую не связан. И вообще книг по software development lean не так уж и много.
serega011
07.03.2017 12:59Вы точно термины не путаете? Можно ссылку на тот DevOps о котором говорите Вы?
forester11
10.03.2017 11:26Моя интерпретация DevOps видимо похожа на данную в упомянутой книге — https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002
vadim1406
06.03.2017 09:18Agile-водопад! Или итеративная разработка. Поясню.
Приходит клиент — говорит, хочу систему, требования как всегда где-то в облаках, но не хочу T&M, только Fix Price. Мы — ОК, давай ТЗ на первый этап. Клиент — ОК, есть ТЗ, срок — месяц-два. Делаем — принимаем, в конце двухнедельный UAT (грубо говоря продаем команду на две недели, в рамках 80 ч-часов*на количество членов команды клиент может делать все что угодно). В процессе текущего релиза — аналитик прорабатывает требования на следующий релиз (релиз 0 — работал только аналитик). Дальше — опять — оцениваем, делаем, UAT, profit. Вероятность того, что посередине проекта понадобиться «менять архитектуру» минимальна, потому что 90% enterprise проектов тупые как пробки :)
Да, внутри релиза-спринта пробовали и SCRUM, и Kanban (хотя все одно и тоже) — работает только «микроменеджмент» — приходит тим-лид/ПМ и говорит кому что делать, потому что самоорганизующиеся команды — они только в книжках и на картинках бывают. Обычно разработчику по фигу на проект, на компанию, на ПМ, на заказчика — ему главное, чтобы деньги регулярно поступали на карту.
PS Имю опыт попытки внедрения SCRUM в 10 проектах — нормально получилось только в одном, когда команда сама этого захотела (было модно, середина 2000-х и решили попробовать), и еще на заре карьеры, когда будучи студентами сами писали игру (только не знали, что это SCRUM). В 9 проектах — получал в лоб от девелоперов «Нам плевать на SCRUM, Agile, проект, заказчика и пр. Если что — работу найдем на раз-два, а ты говори что делать, а сам я себе задачи выбирать не буду». Вот…povetkina_nastenka
06.03.2017 15:33спасибо за отзыв. А вы внедряли в 10 проектах SCRUM в чистом виде? (Как написано в соответствующих книгах?)
vadim1406
07.03.2017 00:06В большинстве — да, в чистом виде. Правда 4 проекта были с удаленными командами. Аналитик в качестве Product Owner'а, я как SCRUM Master. Сначала stand up митинги превращаются в обычные статус-митинги (закрыл 2 баги, буду закрывать еще 3, проблем нет), потом команда говорит — «А смысл?» и собирается раз в два дня, а потом совсем перестает. На ретроспективе кто в телефоне, кто зевает и прочее. Единственный митинг, где можно расшевелить — это sprint planning. Тут все брызжат идеями, как построить звездолет для похода в соседнюю булочную (а вдруг конец света, а мы тут раз и в космос), Product Owner пытается сказать, что надо все быстро и просто, но так же не круто, что этот бизнесмен понимает в АРХИТЕКТУРЕ ПО :)
White_Scorpion
10.03.2017 12:08Я дико извиняюсь, а размер команды у вас какой?
vadim1406
10.03.2017 21:32Ну разные были. От 5 до 10 человек (да-да, 10 человек много). Не зависит успешность от размера команды. Сейчас в наследство передали часть команды и сказали — внедряй SCRUM (не зеленый банк). В сумме 10 человек, надо делить команду и проект. Но осложняется тем, что часть команды — чистые ораклисты, что в SCRUM'е не приветствуется. НУ а команда мне честно сказала — нам на проект плевать, пока ипотеку не выплатим, будем сидеть и тихо пилить :)
Прорвемся :)
KiloLeo
06.03.2017 09:18За 20 лет карьеры в основном практиковал Водопад. Почти всегда укладывался в сроки и бюджет. Но подход тяжёлый и угрюмый, приводит к жёстким разборкам с заказчиком, который сначала боится подписывать требования, чуя, что толком не понимает чего хочет, а потом, когда понимает, что не зря боялся и требования изменились — ищет зацепки чтобы вывернуться из своих же требований и выставить подрядчика дураком и не профессионалом. Зато реально позволяет придти к цели за запланированное время и запланированный бюджет. Беда, однако, в том, что понимание цели может сильно измениться.
Эджайл хорош всем кроме того, что бюджета и сроков никто не понимает. При этом заказчик скорее всего продавит вас на фиксированный бюджет и сроки.
И вот тут появляется та самая гигантская Ж! Вы будете делать НЕ фиксированный объём за фиксированные деньги. Я в таком участвовал и никому не пожелаю.povetkina_nastenka
06.03.2017 15:36Ситуация, когда «с заказчиком, который сначала боится подписывать требования, чуя, что толком не понимает чего хочет, а потом, когда понимает, что не зря боялся и требования изменились — ищет зацепки чтобы вывернуться из своих же требований и выставить подрядчика дураком и не профессионалом» видится мне знакомой.
Действительно, Клиент хочет знать, сколько он заплатит из своего кармана и когда получит результат, только вот видение результата у него нет. Хорошо, когда команда помогает сформировать видение и углубляется в бизнес этого клиента настолько, что может ему действительно помочь. Беда в том, что и за это платить не каждый готов.KiloLeo
12.03.2017 23:44Осознание цели приходит как правило уже на этапе демонстрации прототипа или позднее — на этапе опытной эксплуатации. К тому моменту могут смениться уже и персоналии заказчика, формулировавшие когда-то требования. И компания Заказчика может измениться, и бизнес и рынок. Команда, конечно помогает осознать цель, но она же тоже не может всего этого предвидеть и угадать кому где будет жать, когда костюмчик уже сшит, а у кого-то вырос живот.
White_Scorpion
06.03.2017 11:54Где то читал, что если в хотя бы в одну какую-то часть итерации Agile вкрадывается сторонняя модель (Waterfall) — то всё — сливаем воду — это больше НЕ Agile. Суть в том, что ключевая фишка Agile как ни странно — в гибкости (Капитан Очевидность детектед). И эта гибкость требуется на всех итерациях скопа, но если скажем на этапе бизнес планирования — начинаются "ватерфальные согласования и откаты на предыдущие шаги для дополнительного согласования", то это ватерфал с элементами аджайла, который теряет до 90% эффективности всего аджайла. Т.е. в большинстве случаев, это ватерфалл в котором "для галочки" присутствует аджайл, но на самом деле — это присутствие ограничивается "чувством собственной вовлечённости" у "
дефективныхэффективных менеджеров", которые "успешно внедрили" этот суррогат и убожество: они то думают, что достаточно внедрить аджайл в команду разработки и всё — у них работает модерновый процесс, а на самом деле — всю эффективность аджайла тормозят остальные отделы, которые продолжают работать "по старинке".forester11
06.03.2017 13:10Все правильно, а Agile который идет только из dev комманды без стратегии свыше превращается в фетиш, имхо. Тотже смысл DevOps это натянуть lean на всю организацию (включая IT), и тогда это начинает нести практический смысл.
А когда в организации по старинке созданы команды по леерам (а не кросс-функциональные таск форсы) то agile по сути и нет, есть обряды чтобы это выглядело "круто" и мол мы продвинуто работаем. Ха-ха.
KiloLeo
12.03.2017 23:47Я комбинировал Scrum и водопад, ничего, нормально. Водопад использовался в целом, в большом проекте. А в команде разработки внутри был Scrum. Одно другому не мешало. Кроме того, что никто не понимал когда закончится разработка вообще, а не конкретного спринта.
Smirninini
06.03.2017 21:28Всё зависит от проекта и от ПМ в команде. У нас сейчас вредный заказчик, мало того, что я комбинирую методологии, так я помимо стараюсь ими гибко управлять. Используем SCRUM и waterfall.
SCRUM
В зависимости от настроения заказчика, которое по моим наблюдениям меняется периодически, то хотят видеть долгосрочный план проекта, перед этим начитавшись и пересказав книги по SCRUM. В данном случае разработчики довольны, ПМ доволен, заказчик доволен. Есть время прогнозировать риски. Работы выполняются по плану. Все с хорошим настроением.
Waterfall или Kanban (в зависимости от ситуации. Если возможно решение только в чёткой последовательности, то waterfall)
Приходит время, часть системы введена в эксплуатацию. Заказчику всё нравится, но он начинает осознавать, что многих фич, которые были убраны из базового функционала изобретаемого в первую очередь и перенесены в долгий ящик в самый низ бэклога, катастрофически не хватает, доказывая что без этого никак нельзя, и это нужно вчера, но согласен чтобы это было завтра, игнорируя все составленные и утверждённые планы. В кратчайшие сроки теперь требуется получить множество мелкого дополнительного(не важного)функционала, мы временно переходим на waterfall, сдвигая спринты и сроки по задачам заложенным в них, до тех пор пока заказчик не будет удовлетворён. Таким образом забывая SCRUM, мы бережём нервы всех заинтересованных лиц, участвующих в проекте, отбрасывая споры и воспоминания о каких-либо договорённостях и инструкциях.
SCRUM и Waterfall(Kanban).
Но в большинстве случаев на приходится комбинировать 2 методологии, подстраивая JIRA под интересы всех сторон. С некоторыми игрушками запущенными в продакшене, заказчик не успевает наиграться и считает, что это помогает бизнесу, поэтому требует выполнить определённое количество задач оставленных в беклоге, которые должны были делаться в последнюю очередь, но соблюдая и двигаясь по поставленным задачам заложенным в спринты минимально сдвигая сроки. В этом случае для меня по практике является выделение одного или нескольких разработчиков на задачи по kanban и перенося или сдвигая задачи которые были запланированы в спринтах. Таким образом создаётся возможность контролировать оперативную работу, задачи, а также следовать составленному плану с минимальными изменениями.
В заключение хочу сказать, что нет идеальной методологии. Есть много факторов влияющих на работу, включая погоду. Нужно просто подбирать оптимальные и действенные инструменты, лавировать между запросами, предупреждать и обсуждать цели и задачи своевременно с заинтересованными сторонами.
Спасибо за интересную статью!
lay_niko
06.03.2017 21:28Знающие друзья, подскажите, как вышеперечисленные методы можно соединить с проектно-управленческим софтом типа Basecamp, Битрикс и т.д.?
bacminuscab
07.03.2017 13:01Поделитесть, где можно изучить настоящий страшный и ужасный Waterfall?
PMI, к примеру, в PMBoK упоминает много раз гибкие методологии как один из вариантов реализации проектов (включая частые итерации, прототипирование, метод набегающей волны в уточнении требований). И это не говоря про отдельную специализацию PMI-Agile.
Igor_O
10.03.2017 21:22Завидую людям, у которых в проектах методики работают…
У меня, хоть и занимаюсь последние лет 15-20 тяжелыми железками в основном, заказчиков с проектами, у которых меньше 15 пятниц в неделю, пока не встречалось… И это при том, что трудно внести изменения в цели и задачи проекта, когда проект согласован, 230 тонн оборудования уже оплачено, отгружено и едет, а в помещениях уже красят стены… Но они пытаются.
SlavikF
Самая засада с Agile у меня была, когда я работал QA менеджером в медицинской компании (выпускали медицинский софт). Специфика была такая, что:
— Наше направление деятельности довольно серьёзно регулируется федеральными и штатовскими законами (США), такими как HIPAA, FDA Title 21
— У нас сертификация ISO, так что всё должно идти в соответствии с процессами
— От штата и от ISO к нам аудиторы приезжают и проверяют.
Поэтому, что бы писать софт по всем правилам, были такие вещи:
— У нас были чётко описанные WI (Work Instructions) и SOP (Standard Operating Instructions), в которых довольно детально описывалось, как должно проходить тестирование, как проверяются баги и т.д.
— Мы должны были выдавать (или принимать участие) горы документации, включая: требования, трассировку требований, тест план, тест протоколы, анализ рисков и т.д.
В общем по моему мнению, у нас был водопад. Да, было несколько забюрократизировано, но в общем вменяемо.
Но потом, похожа какая-то муха укусило начальство, и нам стали говорить, что мы «недостаточно agile»… Наняли начальника разработки специально, чтобы выстраивать agile-процесс.
Я всё никак не мог взять в толк: как можно совместить agile-процесс со всей бюрократией и процессами специфичными для наших продуктов?
Вот и натягивали сову на глобус… Сначало ушло несколько разработчиков. Потом ушёл я. Что было потом — не знаю, но сейчас настраиватель agile-процессов уже там не работает.
А вот сейчас я работаю в компании, где у нас SaaS, не связанный с медицинской сферой. У нас — практически чистый Agile, и всё идёт, как надо.
Вывод: Для каждой работы — свой инструмент.
povetkina_nastenka
Спасибо за то, что поделились. Особенно повеселило «натягивание совы на глобус» :)
FedjaNew
SlavikF> федеральными и штатовскими законами (США), такими как HIPAA, FDA Title 2
SlavikF> У нас сертификация ISO,
Во-первых, нет «законов» FDA. Это всего лишь ассоциация (товарищество), которое выдает лицензии.
Во-вторых, ISO — это Европа. Точнее, сдача медицинского изделия по FDA не означает работу по ISO со сдачей изделия для CE. И наоборот.
Естественно, как и для всех изделий, связанных с возможным не финансовым ущербом, жестко определены процессы разработки.
НО! В них нет понятий «водопад», «срам» и так далее.
Компания «просто» должна доказать, что она может выпускать качественное изделие, выпускает его, и управляет рисками этого изделия.