Ваш опыт удаленной работы в командах

[grigori]

Это все работает и крупные софтверные корпорации давно этим пользуются. Если хотите серьезной разработки по аджайлу/скраму - смело идите в международную компанию типа делла, нокии, нвидии. Они не нужнаются в рекламе, но там вы 100% получите нормальный аджайл.

Мне сложно подобрать выражения, чтобы прокомментировать это без мата.
Нет, это не так. Scrum иногда работает. Пилить большой стабильный продукт, когда в беклоге 100500 багов и фич по мелочи, стабильная архитектура, известны паттерны нагрузки, и N разработчиков среднего уровня - скрам сработает. И без скрама тоже сработает.
Когда у продукта или специфичные требования, для которых нужен research, или проблемы на уровне архитектуры, или надо менять API, или сильно изменилась нагрузка (было 5 тысяч юзеров, стало 50 тысяч) и надо найти решение совместно с админами под существующее железо, или конфликт в менеджменте, или... любые проблемы, когда senior в 23 не справятся - SCRUM неприменим.
Был у меня один манагер Женя, который уверовал в агил, и говорил, что главное - начинать писать, потом надо отрефакторить, code first, и вперед. Приходит так, говорит, начинайте - а ребята отвечают: "а что писать-то? какой протокол надо реализовать?" Я молча ржал. А чувак неплохой, но вообще без юмора. Просто в ступор впал от такого. Слишком много тогда смешного было, конечно, надоело.

 

[whirlwind]

Ну, знаешь,такой себе пример. Если скрам не заходит, то начинать надо с внедрения инженерных практик. Когда базовая культура владения кодом появится, можно будет работать над долгосрочным планированием. А все, что ты говоришь, похоже на стихийное бедствие. Если у тебя сильно выросла нагрузка, значит хреново спланировали работу отделов. Сделали вид, что маркетинг отдельно от разработки. Но это даже не беда. Вы бы сделали выводы на первой ретроспективе и в следующие разы приглашали на планинг из смежных отделов. Подстилать надо. Причем, перед каждым релизом. А если вы просто фичи потоком делаете, то как вы знаете к чему вам готовиться после патча и кто вообще за это отвечает?

Про 100500 багов вообще интересная ремарка. В 1С, помнится, в каждом релизе был план по багам, что бы всей сети было чем кормиться. 100500 багов в беклоге стоят дороже, чем самое замороченное TDD. Зачем столько багов писать, я не знаю

 

[Adelf]

Слова @whirlwind звучат намного логичнее и красиво, но мой опыт говорит в поддержку @grigori .
В крупных компаниях огромный бардак. Куча людей, которых вроде бы и не уволишь, но они страшно неэффективны.
Придумываются разные процессы, аджайлы, просто чтобы хоть видимость порядка создать. В итоге все скрамы, которые я видел, а это штук 10 разных команд, от стартапов до корпораций - это просто игра в скрам. Вроде бы планируют спринт, но потом: если не успели, то таски перетекают в следующий, а если сделали раньше - верно, взять из бэклога. Были попытки проводить анализ спринта...( как он там называется? Постмортем? )) очень быстро про них забывали, из-за полезности стремящейся к минус бесконечности. В итоге это превращалось в просто обычную разработку, но раз в неделю или две планировали нечто, называемое спринтом. Некоторые менеджеры, которые поумнее, осознавали всю бесполезность, но говорили, что так требует начальство. Быть гибкими!

Если у тебя сильно выросла нагрузка, значит хреново спланировали работу отделов.

Вероятно, ты работаешь в какой-то идеальной конторе, где нагрузка вырастает исключительно если «в эту неделю маркетологи предсказали рост нагрузки», но обычно все неожиданнее. Например, один раз наше приложение стало страшно популярным среди чёрного населения Америки. Нагрузка выросла в разы. Быстро поняли, что кеш надо получше бы организовать. S3 стал возвращать ошибку, что мы слишком часто создаём обьекты. Модераторов стало не хватать, огрехи в процессе их работы тоже нашлись. Разумеется, пришлось все бросить и бороться с этим.

 

[fixxxer]

Придумываются разные процессы, аджайлы, просто чтобы хоть видимость порядка создать. В итоге все скрамы, которые я видел, а это штук 10 разных команд, от стартапов до корпораций - это просто игра в скрам. Вроде бы планируют спринт, но потом: если не успели, то таски перетекают в следующий, а если сделали раньше - верно, взять из бэклога.

Если скрам не получается, имеет смысл перейти на канбан или какой-нибудь микс из разряда scrumban-ов.

Скрам не всегда подойдет, он работает, когда все остальные процессы нормально выстроены. А когда все сводится к поддержанию легаси в работоспособном состоянии, и серьезный рефакторинг просто не окупится (например, задача в том, чтобы пофиксить баги, "поставить чекбоксы" по фичам и продать проект), в нем смысла никакого.

 

[Adelf]

Если скрам не получается, имеет смысл перейти на канбан или какой-нибудь микс из разряда scrumban-ов.

А для чего? Канбан доска какая-то есть - это уже стало стандартом. В джире, трелле. Менеджер назначает разработчику задачи, тот выполняет. Общение в команде надо налаживать - это ясно и без скрамобанов...

 

[fixxxer]

Для work-in-progress limits, остальное, конечно, и так везде в каком-то виде есть.

 

[grigori]

> Если у тебя сильно выросла нагрузка, значит хреново спланировали работу отделов.
это красивые слова, а реальность была такая: фича была нужна одному клиенту из сотен по имени Ricoh с 4к users, но тут внезапно приходит Toshiba, и просит конкретную фичу для 10k, а на этом числе сервер лежит, чтобы не лежал - надо переписать, а без этой фичи контракт не будет подписан, и планируй что хочешь

> Если скрам не получается, имеет смысл перейти на канбан или какой-нибудь микс из разряда scrumban-ов.
а пофиг - хоть канбан, хоть скрамбан, когда решение задачи неочевидно - agile отменяется вообще

> А когда все сводится к поддержанию легаси в работоспособном состоянии, и серьезный рефакторинг просто не окупится
почитай, что говорит инженер facebook: основная задача сервиса - работать, а если при этом он делает еще что-то полезное, это просто побочный эффект.
не то чтобы ты неправ, просто это мнение субьективно, иногда объем кода не позволяет переписать отрефакторить быстрее, чем за несколько лет

> Когда базовая культура владения кодом появится, можно будет работать над долгосрочным планированием. А все, что ты говоришь, похоже на стихийное бедствие.
так я про большой реальный живой SAAS с сотнями разработчиков из верхней десятки брендов, долгосрочное планирование там есть, стихийное бедствие - это наш реальный мир

 

[whirlwind]

стихийное бедствие - это наш реальный мир

Да я в общем-то и не спорю. Сразу сказал, что это не серебрянная пуля и область применения может быть ограничена. И даже пример привел где. Просто безапелляционно заявлять что это не работает и без мата не могу, ну это, согласись, перебор. Примеров где успешно работает, полно. Везде свои нюансы. Если отдельный контракт это типа белый лебедь с маркета, то никакой sprint-by-sprint невозможен по определению. Потому, что такой режим работы похож на гостиничный бизнес: либо жопа горит, либо помираем от безделья. И таких проектов много. Но есть и другие, где планирование важнее хотелок одного клиента, даже крупного. Потому что база пользователей. И если новый клиент это еще не точно, то вот существующие точно повалят, если вы напортачите. И даже большой SAAS с сотнями разработчиков вовсе не показатель. В сильно крупных компаниях ставки ниже, а оверхеда и индусов больше. Ну вот оно и работает, как платят - довольно средненько. Аджайл - это способ снизить энтропию. Если есть желание. Если нет желания, ну и работайте как привыкли, кто ж запрещает? Хаос - естественное положение вещей )

 

[AmdY]

Практика показывает, что для успеха любая методология подходит, главное чтобы она была и команда понимала как они работают. В том числе можно и легко договориться как быть с беклогом, когда есть горящие таски.

Но аджайл и срам зачастую выступают как затычка для неумелого менеджмента.

 

[Adelf]

Но аджайл и срам зачастую выступают как затычка для неумелого менеджмента.

Именно так.

 

[whirlwind]

говорит инженер facebook: основная задача сервиса - работать, а если при этом он делает еще что-то полезное, это просто побочный эффект.

Прочитал. Интересное чтиво, но завязывай с обобщениями. Сайтики-чатики с котиками и сиськами это конечно жесть хайлоад и все такое, достойное всяческого уважения (не сарказм), но давай рассмотрим любой финансовый софт. Такого инженера, заявляющего про побочный эффект продукта, из отрасли выметут поганой метлой в первый же день независимо от того, какое соотношение просранных котиков к показанным он обеспечивал на предыдущем месте работы. И будут совершенно правы. Торги на бирже останавливаются не только во время сбоев (там то уж без вариантов), а просто при резком росте волатильности. Потому, что предсказать результы и разгребать миллионы миллионных исков никто не в состоянии. Кастомеры будут недовольны и они будут ругаться, но многие из них выберут 33% простоя в сутки, чем 33% счета.

 

[grigori]

Это мы уже уходим в обсуждение bounded context. Остановка торгов на бирже во время волатильности - штатный режим, определенный законодательством и правилами торгов. Судебные иски - это тоже штатный режим для системы. Есть штатный режим отката результатов торгов за период.
В финансовых системах стабильность работы важнее реализации некоторых фич, в этом нет никаких отличий.

Везде свои нюансы. Если отдельный контракт это типа белый лебедь с маркета, то никакой sprint-by-sprint невозможен по определению. Потому, что такой режим работы похож на гостиничный бизнес: либо жопа горит, либо помираем от безделья. И таких проектов много. Но есть и другие, где планирование важнее хотелок одного клиента, даже крупного.
Ну вот оно и работает, как платят - довольно средненько. Аджайл - это способ снизить энтропию. Если есть желание. Если нет желания, ну и работайте как привыкли, кто ж запрещает? Хаос - естественное положение вещей )

вот с этим со всем я согласен

Потому что база пользователей. И если новый клиент это еще не точно, то вот существующие точно повалят, если вы напортачите. И даже большой SAAS с сотнями разработчиков вовсе не показатель.

Есть проекты типа enterprise, где нескольких крупных клиентов облизывают и становятся в любую позу.
Есть retail - "мужчина, не задерживайте очередь".
Есть SAAS уровня Amazon/MS/Oracle - когда к enterprise-клиентам относятся как в retail
А проблема "существующие точно повалят, если вы напортачите" называется SPOF и решается через 12-факторную методологию. Не смешиваем мухи с котлетами, это разные проблемы.

 

[whirlwind]

Представил картинку где к Nokia, Dell, NVidia стоят в очереди к вредной жирной тетке за меленьким окошком с табличкой AWS )))