Pull to refresh

Comments 29

Ну так роль менеджера у вас все равно есть, только каждый разработчик взял на себя 1/10 менеджера (условно) и теперь только на 9/10 разработчик
Прям ответ стандартного менеджера))) Прям как на картинке про непрерывный набор текста…

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

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

Интересная подмена понятий. Я работал в трех IT-компаниях в CAD индустрии. Ни в одной я не сталкивался с тем, что разработчики «должны» помнить. Каждый почему-то понимал и ценил каждую активность, которая у нас проводилась и сам напоминал, если кто-то в потоке забывал о времени. Бывало, что из-за потока забывали о совещаниях, но было это редко и проблем не доставляло.

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

Если возник вопрос по работе, Вы


  • идёте к коллеге и говорите с ним?
  • или Вы просите менеджера организовать официальный митинг?
А зачем ради такого менеджера привлекать? Пусть он своей работой занимается, а такие вещи быстрее напрямую решить.

Черт, сколько бы я отдал, лишь бы посмотреть, что получится, если применить данный подход к разработке программного обеспечения, например, для системы управления ракеты Falcon 9. Например как бы планировалась и реализовалась в спринтах фича "автоматического возвращения первой ступени на платформу в океане". Включая демо и ретро.
Реально вопрос — что получилось бы в итоге — базы на Марсе к 2025 или полный факап?
Вроде ж ракеты у SpaceX имеют версии — 1.0, 1.1 и т.д. Значит возможен софтовый подход?

Скорее всего mission critical software так разрабатывать не стоит. Цена ошибки в бизнесе измеряется деньгами, а если накосячить в по для самолета, могут погибнуть люди.

Вспоминается «Бойцовский клуб» с историей героя (вроде бы основанной на реальных событиях) об автомобильной компании, которая подсчитала что ей выгоднее ежегодно выплачивать компенсации за несколько жертв ДТП, произошедших по вине неудачной тормозной системы, чем отзывать и модернизировать десятки тысяч автомобилей.

Falcon 9 пока людей не возит, поэтому цена ошибки там тоже пока оценивается, в основном, в деньгах.
Но при разработке того же банковского или IoT программного обеспечения цена ошибки тоже может стоить весьма больших денег, а в IoT, если судить по статьям, которые я читаю в том числе и условно ухудшением здоровья людей.


Но методология к которой в итоге пришли Ай-Тишники — требования — разработка — тестирование — все-же сходна с V-моделью разработки, применяемой для ответственного ПО для авиа и автомобильной отрасли. Поэтому, по идее, количество ошибок и качество ПО можно держать под контролем и в Agile. Вопрос в основном в том, что будет с планированием и ресурсами.

Ничего не получится при таком подходе, т.к. слишком большое кол-во влияющих ЗЛ. А в статье мы видим, что все диктует PO, что и как он сказал — так и запилят…
Сомневаюсь, что внедрение lean и agile связано именно с количеством стейкхолдеров.
Как правило, критерием становится именно цена ошибки. Самая простая ошибка — потеря $. Самые сложные — смерть людей, вред экологии, уничтожение других материальных ценностей (памятники культуры, например). Поэтому самолеты, атомные электростанции и дома не производят по agile…
Ну такое, всё же нужна твёрдая рука, ибо ладно программа по проектированию, но жизни людей. Это довольно ответственно.

Есть отличный пример компании, которая работает без менеджеров в железной отрасли: http://www.favi.com/en/about-favi/


Подробно она описана, как и другие такие компании, в книге Лалу «Открывая организации будущего» (Reinventing organizations)


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


Сбер, Альфа, ВкусВилл экспериментируют с безменеджерским подходом в России и получается неплохо.

Круто иметь два дополнительных выходных между спринтами.

Два выходных между спринтами и 5 "боевых" рабочих часов в день. Т.е. где-то 46 часов в месяц из 176 каждый разработчик не разрабатывает, а занимается оргвопросами. Страшно умножать это на количество разработчиков, но по-моему секрет вашего успеха не в эффективности распределения рабочего времени.

Это правильно считать, что эффективное время будет 5 часов в день. 8 часов в день — это пришел и не отвлекаясь занимаешься задачей, обед и снова занимаешься задачей уже до конца рабочего дня. Ни каких телефонных разговоров или чатов. Ни каких взаимодействий между коллегами. Так редко когда получается. Или кто-нибудь позвонит, или кто-то что-то спросит. Спросить может и по рабочим вопросам, например, по ранее реализованной фичи, является ли странное поведение багом или фичей. А может кто-то из коллег попросит помощи. Так что если человек не проводит на работе 10 — 12 часов, то 8 часов тратить на задачу постоянно — не получится. В конце концов, человек может себя в какой-нибудь день плохо чувствовать и работать менее эффективно. Так что и без орг вопросов не получится тратить по 8 часов в день.

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.

Из-за рекламы, автор все таки немного лукавит. Кто отвечает за доставку фичи, кто решает управленческие вопросы из серии вот вэтом продукте мы приняли такой и такой принцип, подход и практику.
Подозревая ответ: команда.
А кто тогда следит за соблюдением/применением правил, принципов и подходов? И в том числе, пользуясь авторитетом, может однозначно задать какое-либо направление?
Простите мое лукавство. Конечно, наши Product Owner'ы озабочены тем, что команды не успевают или доставляют баги в продакшн. Они даже часто говорят об этом на синхронизациях и обсуждениях темпов разработки.

Тем не менее, они не осуществляют контроль за разработкой, не контролируют в общем смысле процессы. Сами команды выстраивают процессы, тимлиды и все заинтересованные периодически (обычно сразу после релиза) обсуждают, что можно улучшить в процессах. Сильно помогает кросс-командное ретро релизов. Направления для улучшений у нас возникает изнутри и может вноситься кем угодно, имеющим достаточно смелости, чтобы не просто рассказать о клевой идее в процессах, а донести ее до всех. Каждый спринт мы привносим что-то новое в нашу работу сами, но это ни в коей мере не умаляет роли продуктовиков в контроле сроков.
Ретро, скрам, спринт, бэклог, разгрумленные фичи, ежедневные стендапы…
Sign up to leave a comment.