Comments 29
Всмысле? Тут же прямо написано, что каждый разработчик должен ещё помнить о том, что кому-то надо таки организовать встречу и в свободное время сначала выполняет у себя в голове скрипт "а не пора ли запустить митинг".
… каждый разработчик должен ещё помнить о том, что кому-то надо таки организовать встречу ...
Интересная подмена понятий. Я работал в трех IT-компаниях в CAD индустрии. Ни в одной я не сталкивался с тем, что разработчики «должны» помнить. Каждый почему-то понимал и ценил каждую активность, которая у нас проводилась и сам напоминал, если кто-то в потоке забывал о времени. Бывало, что из-за потока забывали о совещаниях, но было это редко и проблем не доставляло.
И да, разработчикам, с которыми я работаю и работал, в радость созывать народ для обсуждения какой-то фичи или архитектуры. Ведь каждый профессионал понимает, что, как правило!, только в разговоре и споре рождается лучший вариант решения.
Но я, например, разработчик, и я хочу писать код и продумывать архитектуру приложения, а не заниматься организационными вопросами. Так что пусть лучше менеджеры остаются.
У вас, видимо, просто не было опыта работы с нормальным менеджером.
Черт, сколько бы я отдал, лишь бы посмотреть, что получится, если применить данный подход к разработке программного обеспечения, например, для системы управления ракеты Falcon 9. Например как бы планировалась и реализовалась в спринтах фича "автоматического возвращения первой ступени на платформу в океане". Включая демо и ретро.
Реально вопрос — что получилось бы в итоге — базы на Марсе к 2025 или полный факап?
Вроде ж ракеты у SpaceX имеют версии — 1.0, 1.1 и т.д. Значит возможен софтовый подход?
Скорее всего mission critical software так разрабатывать не стоит. Цена ошибки в бизнесе измеряется деньгами, а если накосячить в по для самолета, могут погибнуть люди.
Falcon 9 пока людей не возит, поэтому цена ошибки там тоже пока оценивается, в основном, в деньгах.
Но при разработке того же банковского или IoT программного обеспечения цена ошибки тоже может стоить весьма больших денег, а в IoT, если судить по статьям, которые я читаю в том числе и условно ухудшением здоровья людей.
Но методология к которой в итоге пришли Ай-Тишники — требования — разработка — тестирование — все-же сходна с V-моделью разработки, применяемой для ответственного ПО для авиа и автомобильной отрасли. Поэтому, по идее, количество ошибок и качество ПО можно держать под контролем и в Agile. Вопрос в основном в том, что будет с планированием и ресурсами.
Как правило, критерием становится именно цена ошибки. Самая простая ошибка — потеря $. Самые сложные — смерть людей, вред экологии, уничтожение других материальных ценностей (памятники культуры, например). Поэтому самолеты, атомные электростанции и дома не производят по agile…
Есть отличный пример компании, которая работает без менеджеров в железной отрасли: http://www.favi.com/en/about-favi/
Подробно она описана, как и другие такие компании, в книге Лалу «Открывая организации будущего» (Reinventing organizations)
Основной ответ: нет, факапа не будет. Все люди взрослые и прекрасно понимают свою ответственность. Более того, в таких командах брак намного ниже.
Сбер, Альфа, ВкусВилл экспериментируют с безменеджерским подходом в России и получается неплохо.
Круто иметь два дополнительных выходных между спринтами.
Два выходных между спринтами и 5 "боевых" рабочих часов в день. Т.е. где-то 46 часов в месяц из 176 каждый разработчик не разрабатывает, а занимается оргвопросами. Страшно умножать это на количество разработчиков, но по-моему секрет вашего успеха не в эффективности распределения рабочего времени.
P.S.
Я к автору статьи не имею никакого отношения, исключительно мой личный опыт и опыт коллег.
Я намекал, что 1702 часа оргвопросов в месяц (размер команды х 46 — примерно как 9,5 человек фулл-тайм) это повод задуматься об эффективности данной модели. Например что-то придумать, чтобы не всю команду вовлекать в эти процессы.
По чистому времени выходит около 0.4 часа на стендапы, 5 часов на планирование, 2 часа на ретро, 2 часа на демо. 28*0.4*10 + 5*28 + 2*28 + 2*28= 364 человеко-часа в 12 на 28 человек или 1 час в день на одного человека. Я не учел активности вроде code-review, архитектурных обсуждений, потому что считаю их неотделимой частью процесса разработки.
Поделитесь, сколько времени интегрально у Ваших программистов уходит на активности помимо разработки? На мой взгляд, 1 час в день на разговоры — очень небольшая плата за распространение знаний и рефлексию команд.
Зачем вы изобретали велосипед? Описанный подход (за исключением некоторых кривых интерпретаций) называется Скрам и с ним можно познакомиться на любом сертификационном курсе или через книги Сазерленда и Книберга. Если вы знаете про SAFe, то сами должны видеть как решать озвученные проблемы. И да прибудет с вами Lean.
Подозревая ответ: команда.
А кто тогда следит за соблюдением/применением правил, принципов и подходов? И в том числе, пользуясь авторитетом, может однозначно задать какое-либо направление?
Тем не менее, они не осуществляют контроль за разработкой, не контролируют в общем смысле процессы. Сами команды выстраивают процессы, тимлиды и все заинтересованные периодически (обычно сразу после релиза) обсуждают, что можно улучшить в процессах. Сильно помогает кросс-командное ретро релизов. Направления для улучшений у нас возникает изнутри и может вноситься кем угодно, имеющим достаточно смелости, чтобы не просто рассказать о клевой идее в процессах, а донести ее до всех. Каждый спринт мы привносим что-то новое в нашу работу сами, но это ни в коей мере не умаляет роли продуктовиков в контроле сроков.
Команда разработчиков Renga: как мы достигли идиллии, работая без менеджеров