Comments 214
Это усложняет нам взаимодействие с гуманитариямиОпять это потливое противопоставление «нас, программистов» против «них, гуманитариев». Откуда это вообще?
В оригинале
«This makes working with non-technical people harder for us than it needs to be»«Non-technical» переводится не так.
Поздравляю вас, гражданин, соврамши!
Опять это потливое противопоставление «нас, программистов» против «них, гуманитариев». Откуда это вообще?
Представьте себе — это из реальной жизни.
На самом деле, действительно, употреблять термин «гуманитарий» в таком случае — неверно. Те, о ком идет речь, опираются в принятии решений на ощущения, чувства, а не на логику, абстрактное мышление и систематизацию. Гуманитарные науки вполне могут требовать использовать логику и систематизацию. А тех, кому эти инструменты недоступны, называть «гуманитариями» — это поднимать их на уровень выше с их уровня слабого развития абстрактного мышления.
crmMaster сильно перегнул в одну сторону, попробую это компенсировать. Да, не «бизнес-ориентированной» стороны обычно не существует. Исключений не так много: можно разрабатывать собственные опенсорс проекты или участвовать в существующих (но за это обычно не платят), изредка попадаются чисто исследовательские/научные задачи, можно открыть собственный бизнес (это даст возможность самому определять "бизнес-ориентированность", но совмещать это с программированием вряд ли получится)… но самый реальный вариант, за который и деньги платят, и "бизнес-ориентированность" присутствует минимально — внутренние проекты компании.
Ещё один вариант, достаточно специфический, это совмещать роли архитектора и бизнес-аналитика. Это даёт достаточно рычагов воздействия на бизнес, чтобы в значительность степени влиять на определение "бизнес-ориентированности" на этом проекте. А если ты что-то контролируешь — всё выглядит уже совсем не так плохо, как когда оно контролирует тебя.
Смотря какие языки. Многие разрабатывались как опенсорс-проекты, и из разработку никто не оплачивал. Либо разработчик имел невероятно прокачанные софт-скилы и умудрялся "продать" своему начальнику идею, что позволить ему тратить рабочее время на разработку нового ЯП — это хорошая мысль. Некоторые языки, например Go, разрабатывались вполне осознанно под нужды конкретного бизнеса.
Научные разработки обычно спонсируются, поэтому есть возможность и деньги получить и работать без особого давления бизнес-ориентированности (хотя нельзя сказать, что давления вообще нет — если долго не будет хоть каких-то полезных результатов, то финансирование прикроют).
Поскольку Go не продается, а раздается — его бизнес-ориентированность не больше, чем у линукса.
если долго не будет хоть каких-то полезных результатов, то финансирование прикроют).Про термояд забыли. :-)) Впрочем, философский камень искали ещё дольше.
Фишка в том, что фундаментальные исследования, лишь изредка давая применимый в бизнесе результат, все равно выгодны. Точно так же с НИР и НИОКР, включающими в себя написание кода. Пишется оно по госзаказу и пишется. Вроде и госзаказ дурацкий и пишется в стол. А потом бац — оп-па, а у нас для бизнеса все кирпички готовы. Перекомпоновали — и можно продавать.
Ещё пример — автовождение. Да, будет бизнес, но не через год, а лет через 5. Но куча команд работает. Мы, например, случайно автовождение комбайна сделали. Хотя для нас основное — это высокоточный GPS.
Творчество (которого много в «программировании»)
Откуда ему там взяться? У вас есть алгоритм, который вам нужно закодить. Все! От того, что он зачастую размытый и данных у вас сильно меньше чем надо, творческой работа не становится.
Иногда никакого алгоритма нет, и вообще область не исследована, с пару-тройкой публикаций на тему.
Ну всю эту движуху что мол на конвейере у вас не совсем уж дураки стоят начали еще в 70-х и далеко не в IT. Мол, зачем надсмотрщики, выдайте людям секундамеры и ответственности о они сами будут пытаться оптимизировать свой участок работы.
Ну там всякие книжки на эту тему вроде знаменитого The Goal и всякие там книжки про безотходное производство (toyota way, lean)…
Долгие истории означают что вы не умеете планировать. «долгая» задача без детализации, без обсуждения с коллегами, без понимания трейд оффов — это кот в мешке и детский сад (рискованно и непрофессионально). А еще, за время выполнения, требования слегка изменились, и теперь нужно еще половина времени, чтобы ее подогнать. А еще мастер-ветка за пол-года изменилась до неузнаваемости. За более чем 10 лет опыта разработки я видел буквально единицы «долгих» историй, которые хотя бы не выбрасывали на помойку.
Идем дальше, Скрам-мастер не лидер, а фасилитатор и коуч. Лидером же в скрам-команде является продукт овнер.
Для того чтобы команда понимала что они делают и зачем, в скраме существуют несколько механизмов — участие стейк-холдеров в грумингах, бизнес поинты на задачах, демо…
Если у тебя инженерное/архитектурное улучшение или ресёрч — обсуди его на груминге вместе с командой и положи в беклог. Ещё ни разу не видел, чтобы полезные для продукта задачи там залёживались.
P.S.: Прошу прощения за транслит английских терминов.
Я без стёба, просто мне действительно интересно, а вы сказали, что разбираетесь в скраме.
Помимо планирования, можно по стори-поинтам прямо между спринтами смотреть, насколько мы укладываемся в распланированное расписание и, соответственно выкидывать/докидывать необязательные фичи, сдвигать релизы и так далее.
R&D отлично ложится на скрам. Вот у нас шаблон примерно такой: Сначала у тебя история ресёрча — 1-2 спринта под уточнение что конкретно хочет бизнес, пруф оф концепт, время сравнить разные варианты имплементации и записать алгоритм. Затем — история дизайна (согласовал контракты API, хранения данных с другими командами), и, наконец, имплементация — у тебя уже почти всё есть, просто надо вставить в существующую систему, протестировать и выкатить в прод.
1. Как отличить необходимость проделывать этот самый R&D силами текущей команды от необходимости нанять человека, который уже знает все, что надо?
2. Как перейти от стадии «понять, что хочет бизнес» к стадии «proof of concept»? Распространенная проблема — конечные исполнители не могут начать делать этот «proof of concept», поскольку вообще не знают, как это делается, а других нет. И ответственный за «распиливание» задачи (т.е. за детализацию эпика) ровно в том же положении.
3. Как отличить «мы не знаем, как это делается» от «никто не знает» и от «это невозможно на текущем уровне развития технологии»? Кто вообще может принять решение отказаться от непонятной мегазадачи?
Как надуманный пример — команда раньше вообще не занималась алгоритмами цифровой обработки звука, и тут с бухты-барахты стоит задача автоматически убрать излишнее эхо (не то, которое от попадания звука от динамиков в микрофон, а которое от многократных отражений от стен комнаты) из архива звукозаписей. Реализации этого дела в принципе есть, но (условно) под неприемлемыми лицензиями, поэтому надо писать свою. Научные работы в открытом доступе есть, но их еще надо понять, и они ссылаются друг на друга (т.е. для каждой статьи еще непонятно, сколько ссылок надо прочитать, чтобы понять конкретно эту статью), и там заумная алгебра, с которой проблемы.
Как такой эпик заскрамить?
> не должна создаваться так рано
Тут все упирается в то сколько у вас сейчас есть денег, сколько вы можете вложить и как быстро сможете понять стоит ли оно того дополнительных вливаний средств или нет.
Если вам удалось найти специалиста и вы условились скажем в 2 недели на R&D дабы по результатам уже смотреть окупится ли дальнейшая разработка данной фичи — ну сделайте так. Если денег много и потенциальный профит перевешивает плюсы, и вы можете взять специалиста на пол года, почему нет.
Все же R&D с точки зрения планирования проще организовывать за счет фиксированных итераций, ибо оценить такие задачи адекватно невозможно. две недели ресерч, анализ результата, решение копать дальше или забить.
И на эту бюрократию все время тратится. На проработку эпиков на квартал вперед тоже куча времени уходит.
А потом через месяц выясняется, что всю эту работу можно сливать в унитаз потому что по результатам реальной разработки все оказалось не таким как казалось в спайках.
Я уже молчу про то что очень часто возникают мелкие задачи, которые решаются за время меньшее, чем возня с бюрократией.
А в случае с r&d вообще может оказаться, что нужно делать совсем другую задачу, чем в спринте описана.
В общем если работа чуть более сложная чем гребля на галере, то это все только снижает эффективность и приводит к эмоциональному выгоранию.
В случае со скрамом мы платим цену «бюрократии», потому что хочется какой-то предсказуемости, реальных метрик, сбывающихся прогнозов и так далее. А скрам это предоставляет с обновлениями на двухнедельной основе.
Далее по тексту: Если в результате спайка нет пруф-оф-концепта и документации, заапрувленой аналитиком, значит работа не сделана.
В случае с R&D без скрама, ты узнаешь, что нужно делать другую задачу не через 2 недели, а через 4 месяца (и я много раз это наблюдал).
Минимум 90% разработки любого продукта — это «гребля на галере» причем весьма тупым способом. Остальное — плод работы скорее системного аналитика с архитектором в попытке решить бизнес-задачу с минимально приемлемым результатом.
Вот в случае когда в целом работа не попадавет в эти 90 процентов галерного типа, это все не работает. Не работает еще и потому что сам аналитик не может все предсказать и знать на перед.
Результаты спайков приводят к PoC, но он совсем не похож на реальный продукт. Слишком много подводных камней за один спринт не увидишь.
Вообще вся эта схема плохо работает когда их много.
Проработка эпиков на полгода вперед больше на waterfall по своей сути похожа.
Есть такой принцип, который явно показывает, где ответственный человек, а где — поболтать пришел.
Критикуешь — предлагай. Предлагаешь — делай.
Но нужно быть поваром, чтобы советовать что изменить.
Так вы сравните вкус в итоге?
Но да, я спокойно попробую вторую попытку.
И да, она всё еще может быть подгоревшей.
он не получает фидбэк, потому в целом какая разница? В этом же собственно основная проблема ватерфола, а не в том что «нет спринов». Нет фидбэка — приоритизация происходит на основе «я так вижу». А при таком раскладе можно и более ватерфольные штуки использовать (FDD то же)
Ну и опять же — если у оунера есть готовность слить результаты работы в унитаз — не понятно зачем так детально это прорабатывать.
У него может не хватить квалификации все проработать.
Так вот — Аджайл (как и демократия) сам по себе не очень, но лучше пока ничего не придумали. Важно только не превращать его в карго-культ (что происходит во многих местах) — когда вроде все по книге, но и программисты и бизнес ходят недовольные. Отличная школа Аджайла — это стартапы вообще, особенно когда вас уже 10-20 человек и есть один-два клиента.
— офис должен быть многокомнатным для команд максимум до 5-7 человек
Думается что 5-7 это неверный критерий. Мне видится критерий «скрам-команда в своем офисе» более верным. Скрам команда обычно небольшая, чтобы накормить 2-мя пиццами :-)
Как правило наблюдал такой феномен когда вся пирамида эджайла после неудавшегося релиза приходила к разработчику и распинала его на эшафоте при этом никто из пирамиды сверху не ответил за неверные сроки, за не правильную идею, за не точную постановку, за не верный дизайн и многое другое — потому что нет этого в эджайле по-определению :) это технология управления РЕСУРСАМИ а не людьми.
Вся пирамида аджайла как раз устроена таким образом, чтобы:
1) контролировать фокус. Я заметил что после 3-х недель фокус людей начинает смещаться в сторону от первоначальной идеи. Как правило после 4-х недель от первоначальной идеи не остается и следа: программист сам придумывает себе задачу, сам творчески с ней справляется и бодро рапортует о проделанной работе. В большинстве случаев та проблема которую он себе придумал не имеет никакого практического значения: либо экономия 1% ресурсов, либо решение несуществующей проблемы.
2) Контролировать прогресс: ежедневные стендапы направлены на то чтобы контролировать прогресс и не терять фокуса проблемы. Если ваши задачи разбиты на 2-х дневные участки, то вы легко сможете контролировать прогресс, а значит раньше отреагировать на возможные проблемы. Пример из жизни: разработчик потратил полтора дня на разворачивания environment для имплементации функции. Моя вина — на стендах он про это молчал. В результате вместо 4-х часов на задачу было потрачено 2 дня. Как инсайт — никого не уволили, договорились что на стендапах рано рапортуем о проблемах. Кстати, ретроспективы для этого и предназначены, чтобы выявлять внутренние проблемы, мешающие работе.
3) Груминг (или декомпозиция) предназначены для того, чтобы все участники процесса получили правильное понимание того, что разрабатываем. Для этого на груминг собираются не только программисты, но и продуктологи. Продуктологи рассказывают что они хотят получить, а программисты предлагают простые решения этой проблемы. Там же легко выявить «неточную постановку» просто потому, что мы неточную постановку в разработку не берем (у нас встроено определение «ready for development» без формального соблюдения которого задача в работу не идет).
Из преведенной мною цитаты я могу сделать вывод, что, к сожалению, вы попали как раз на карго культ скрама, а не на скрам. Скрам — это как раз про людей, про то как они взаимодействуют, как они планируют свое время (а вот это уже ресурс) и договоренность о том что же они делают. Для меня скрам — это механизм самоуправления в команде, когда команда сама принимает решения о том что и как делать.
— в коллективе где есть хоть 2 разработчика 3м обязательно должен быть психолог!
меня поражает детсадовский подход в так называемом карьерном росте разработчиков во всех IT компаниях — типа из разработчика в тимлиды. Да ни за что! без вердикта психолога о том что человек по своей психологии является лидером и руководителем ни в коем случае такое делать нельзя — иначе потом горе тому коллективу.
В тех случаях когда тимлида назначают как правило так и происходит. В моем опыте лучшими тимлидами становятся внутренние лидеры — те, кого выбирает команда. Именно поэтому я никогда не нанимаю сразу в тимлиды. Беру разработчиком. Показал лидерство, уважение команды — велкам, промутим в тимлиды после испытательного срока. Не показал — сорян. Те кто ориентирован на карьерный рост в быструю сразу отсеиваются. Те кто чего-то стоит и уверены в себе — те соглашаются.
предотвращает прием на работу людей с опасными отклонениями — типа психопатии
То есть геем или даже, прости господи, женщиной, быть можно, а психопатом нельзя? Похоже у вас что-то не так с дайвёрсити. Мы идём к вам.
— в коллективе где есть хоть 2 разработчика 3м обязательно должен быть психолог!
меня поражает детсадовский подход в так называемом карьерном росте разработчиков во всех IT компаниях — типа из разработчика в тимлиды. Да ни за что! без вердикта психолога о том что человек по своей психологии является лидером и руководителем ни в коем случае такое делать нельзя — иначе потом горе тому коллективу.
Это вы работающую успешно методику сейчас рекомендуете или просто за жизнь?
За мои скромные 18 лет работы в IT, я не видел ни одной компании (РФ + EU + US), где можно было выделить отдельного «психолога», который бы вердикт выносил — быть ли кому-то тим-лидом.
(отмечу еще, что у психологии, как науки есть серьезные проблемы, так что на поверку, все ваши «мамы коллектива» работают на интуиции и чутье в социальных отношениях, что никак не гарантирует хороших результатов...)
Но по мере чтения понял, что материал шикарный и понял, что надо будет перечитать ещё раз на свежую голову.
Ох, уж это стремительное накопление технического долга, которым никто и никогда не будет заниматься, и героическое решение миллиона проблем, после сырого релиза. Проблем, которые вообще не имеют права и возможности возникнуть, если хоть чуть лучше все продумать и реализовать. Но некогда.
Психиатрическая лечебница просто какая-то.
Вот чем отличается психиатрическая лечебница от какого-либо другого учреждения? Ведь не здание же самое главное… наверное главное это персонал и контингент.
Так и тут, дело не в названии и не в методологии, любую идею можно испохабить…
У нас вообще даже слова не подберу — чистый сюр какой то… Один новый «эффективный менеджер» внедряет agile и scrum вообще вне контекста разработки it-продукта.
Представьте себе — фирма не IT, производство печатной продукции, из it отдела несколько сисадминов, 3 на бакенде — PHP в основном, и я один на фронтенде. Чисто для поддержки своих сайтов и веб шопов. И вот данный субъект приходит со скрамом, вернее, приезжает на коне. Создают команду: 1 бак,1 фронт, 1 вообще контент с точки зрения СЕО и один практикант. Плюс скрам мастер — младшая секретарша компании, в IT как свинья в помидорах. Тема — оптимизация — разная — данных сайтов. Что творится в процессе, что на daily, что в конце концов выходит — без содрогания не рассказать. Да и не надо.
Важно что — вот поменяю я скажем в каком то обозримом будущем работу на чисто it-ную, и возможно и команда будет компететная, и методология будет ей подходить, но я уже ненавижу все это лютой ненавистью…
пс. И это не Россия (Европа, мать ее..)
— Не умею!
— Агиль как умеешь!
— Scrum, Scrum, Scrum…
Какой-то странный у автора scrum. Смысл ежедневных митингов и ревью по итерациям не в том, чтобы кто-то кого-то оценивал, а в том, чтобы как можно быстрее донести до команды и менеджмента факт возникновения какой-либо проблемы и, с-но, в возможности потом максимально оперативно на эту проблему отреагировать. То есть это не сдача физических нормативов с результатом "Вася мало отжался и слишком медленно пробежал кросс", а опрос вида "как здоровье? температура нормальная, никто не кашляет? ок, продолжаем работу".
Если же митинги воспринимать как какие-то "отчеты" — тут, конечно, будет все плохо.
Ок, есть команда из 10 человек. Предположим каждому выделяется 5 минут на утреннем собрании. Все отчитались о том что проблем нет, кроме человека выступающего последним. В итоге у первых 9 людей час потрачен впустую, а о проблеме сообщено с запозданием.
Там где я работал ввели типа скрам. Т.к. время прихода на работу не фиксированное, то собрания назначались на время, когда все должны уже быть на месте. В итоге люди, приходившие за час, два до начала встречи фактически работой не занимались, потому что смысл глубоко погружаться в работу, если все равно потом вставать и на долго прерываться. На самой встрече выступление человека занимало около пяти минут, потому что это же настоящий скрам(!) и надо доложить о том как идут дела. Вот каждый натужно и выдавал что он сделал вчера.
В итоге стоишь и просто теряешь время. Особый привкус бесполезно потерянного времени придавало то, что продукт состоял из двух частей, связанных между собой неким API, и мне было абсолютно не интересно что происходит внутри чужой стороны, повлиять я на это все равно не мог, так же как и они на происходящее внутри моей.
А все проблемы связи между двумя половинками решались вне этих встреч, напрямую между мной и человеком, ответственным за внешний интерфейс.
Ну и конечно же таски в Джире никто не отменял, так же как и ежедневные отчеты по проделанной работе.
И да, каждая вторая пятница, а иногда и каждая первая, у той половины команды была не рабочая. Они весело проводили время за большим столом «играя» в скрам-покер и называя это планированием спринта.
Я подтверждаю: чатик и/или 30 секунд на человека.
Чатик очень удобен тем, что каждый может скинуть свой отчёт когда ему это удобно, а так же в ситуациях когда на митинг не успеваешь.
30 секунд на человека вполне достаточно, чтобы убедиться, что у всех единое понимание текущих задач и приоритетов, что никто не свернул нечаянно делать что-то не то или не так, плюс проконтролировать, что в команде нет коммуникационных проблем (а-ля когда один ждёт другого, а тот и не в курсе).
Если на митинге вскрывается проблема, и её не удаётся решить минутным (буквально!) обсуждением — её дальнейшее обсуждение переносится на отдельный митинг, на котором уже присутствуют только те, кого эта проблема реально затрагивает, и на котором уже нет жёстких временных рамок на обсуждение.
При таком подходе исчезает описанная Вами проблема, когда люди не погружаются в работу из-за того, что ждут начала митинга — описываемый мной вариант митинга не требует ни заметного времени (обычно укладывается в 5 минут), ни траты внимания (если отчёт о вчерашней работе/сегодняшних задачах и проблемах сложный то его проще заранее отправить в чатик и выкинуть из головы). В результате митинг слушается краем уха, и отвлекает от текущей задачи не сильнее, чем не вовремя заданный коллегой вопрос.
Тем не менее, не смотря на "краем уха" и быстро-формальный процесс — польза от таких митингов есть. Впрочем, я лично их практикую далеко не всегда — если команда небольшая и адекватная, то проблемы, для выявления/решения которых используется этот митинг, проще решать по ходу в чатике, без митингов.
Ок, есть команда из 10 человек. Предположим каждому выделяется 5 минут на утреннем собрании. Все отчитались о том что проблем нет, кроме человека выступающего последним. В итоге у первых 9 людей час потрачен впустую, а о проблеме сообщено с запозданием.
С опозданием по сравнению с чем? Практика показывает, что без митинга о проблеме бы узнали спустя несколько дней, после просранных дедлайнов.
Потому что обычно о проблемах никто не сообщает.
И именно по-этому на скрам-митингах рассказывают что сделано, а не отвечают на вопрос "какие были проблемы?", потому что если спросить явно про проблемы, то все сообщат, что все хорошо прекрасная маркиза, даже когда все плохо.
А вот в случае с вопросом "что сделано" придется обосновывать, почему ничего не сделано, то есть называть актуальную проблему.
Вместо это я (скорее всего ещё ДО дейлика) напомню Васе о проблеме, попрошу оценку времени выполнения. Если Вася отреагирует адекватно — буду ждать или предложу помощь, если нет — подключу к обсуждению нашего общего менеджера (да, это тоже лучше, чем мордой в грязь перед всей командой). А потом мы все пойдём на дейлик, где дальше будем рассказывать друг другу сказки.
Долгосрочная работа в проекте требует предусматривать возможности протягивать людям руку помощи, а также давать им возможность сохранять лицо. Скрам таких возможностей не предусматривает.
Подниму ли я эту проблему на дейли-митинге? Нет, не подниму, поскольку это означает обвинить Васю перед всей командой, поставить его в неловкое положение, вынудить оправдываться и надолго (навсегда?) ухудшить отношения с ним.
… если в вашей команде принято искать виноватых. А если проблемы принято решать, то Вася скажет, почему его функция заняла больше чем спрогнозировано и вы вместе подумаете как исправить ситуацию.
Сейчас прозвучит непопулярное мнение, но: лучший способ сохранить лицо — делать свою работу хорошо, чтобы не приходилось потом заметать под ковёр недоделки и скрывать потенциально важную информацию от команды (тем более, что скрыть по-настоящему что-то довольно сложно — коммиты-то в репо видят все). А если кто-то делает свою работу плохо, то не стоит помогать ему сохранить лицо — этим Вы только покажете, что его плохая работа Вас полностью устраивает, и он может и дальше работать в том же стиле (а это значит, что если он работает меньше, то всем остальным либо придётся работать больше, либо огребать за его факапы всей командой).
Я лично никогда не стесняюсь на митинге говорить, что я вчера что-то не делал вообще или что-то не успел доделать. И причина очень проста — я делаю свою работу достаточно хорошо, и если я что-то не сделал из запланированного, то это обычно означает, что либо запланировали плохо, либо задача оказалась сложнее ожидаемого… либо у меня тупо не работала голова и я не работал вообще — тоже случается, все мы люди, главное, чтобы не очень часто. В общем, на это есть веская причина, а вот лично моей вины в этом, чаще всего, нет. И даже когда она есть — тоже ничего страшного, лажают все, и я тоже не робот.
Если в ответ на мою честность кто-то перевозбудится, и полезет с претензиями — он пойдёт лесом, потому что во-первых я всё это говорил не для того, чтобы меня в ответ покритиковали, а чтобы у команды было корректное понимание текущего состояния проекта, и во-вторых — не нравится как я работаю — сначала сделай лучше (или найди того, кто сделает лучше — если претензии высказывает менеджер), а потом вернёмся к вопросу критики.
Но обычно ничего такого не происходит, все реагируют вполне адекватно — либо просто принимают к сведению, либо поднимают вопрос что нужно поправить в наших процессах чтобы такие проблемы в будущем не повторялись. Собственно, именно в этом смысл отчёта о текущем прогрессе и проблемах.
Если Вам так принципиально сохранить Васю в команде, при том, что он не в состоянии ни работу нормально делать, ни честно об этом рассказывать… что тут скажешь, бывает, может у Вас с ним любовь — тогда работайте и за себя и за него, делая двойной объём работы за то же время, потому что из-за Вашей любви к Васе остальная команда и проект страдать, по-хорошему, не должны. Если более реалистично — нужно перестать грузить Васю работой, с которой он не справляется, и подобрать ему такие задачи, с которыми он будет справляться… но чтобы это сделать сначала нужно выяснить, что он не справляется с текущими задачами, а вы с ним, пытаясь сохранить ему лицо, эту информацию скрываете, и тем самым закапываете его ещё глубже.
Я с этим и не спорил. Люди важнее. Но это вовсе не означает, что они могут творить вообще любую фигню, а окружающие должны им в этом помогать.
Если есть проблема — можно помочь человеку её решить, и вовсе не обязательно сопровождать эту помощь моральными издевательствами в процессе. Но чтобы проблему решить — сначала её надо выявить и признать. Ваш подход "сохранить лицо" направлен на противоположное — сопротивляться выявлению и признанию проблемы. Говоря проще — я считаю что Ваши действия в этой ситуации больше всего вредят самому Васе. Не обижать людей из-за каких-то мелких текущих проблем с очередным проектом — это абсолютно правильно. Закапывать проблемы, пусть даже мелкие и относящиеся только к текущему проекту — не правильно.
Если у Васи серьёзные проблемы с психикой (или он вырос в Японии, например, и ещё не адаптировался в нашей культуре), и публичное признание своих проблем для него категорически неприемлемо, и приведёт к гораздо худшим проблемам в его жизни и/или работе, чем сейчас — то проблемой является именно этот факт, и Васю нужно или переводить на другую работу (где не будет скрама), или отправлять к психологу решать эту проблему.
насколько я понимаю из комментариев, люди (программисты) в основном сейчас оторваны от своего кода (максимум месяц или несколько месяцев, чтоли?). а править чужой код, который кроме того писал не 1 человек, а много, каждый по 2 неделе — это ужас по-моему. понятно, откуда так много багов вокруг
Никакого ужаса, просто использование линтера (заодно контролирующего код-стайл), юнит-тестов и ревью кода перед мержем чего-либо в master является обязательным для всех, без исключений. Если к этому добавить нормальную архитектуру, на поддержание которой периодически выделять время, и практиковать фоновый рефакторинг (нужно изменить что-то в существующем коде для текущей задачи — оставь изменяемый кусочек кода после себя в чуть лучше виде, чем он был) — кодом становится легко управлять, никакой проблемы набежать в часть кода, которую никто не помнит, и быстро и качественно что-то там пофиксить или дописать — нет.
А без всего этого мы, в лучшем случае, получаем незаменимого рок-стар разработчика, который единственный знает что происходит в коде, и только он может с ним что-то сделать достаточно эффективно и ничего не ломая. Для работы проекта этого может быть достаточно, но для бизнеса такие незаменимые разработчики — большой риск.
P.S. Совсем забыл упомянуть про документацию — в Go её наличие контролирует линтер, вот я и расслабился.
Я успел заглянуть к Вам в профиль, так что ждал подобного ответа. :) Моё мнение — это Вам пока так кажется, потому что пока это работает.
Если что-то случится, и Вы потеряете на время возможность активно работать с кодом (не будем рассматривать реально плохие вещи, допустим, банально зима-гололёд-очнулся-гипс — не смертельно, и через пару месяцев всё пройдёт, но вот эти пару месяцев код писать будет проблематично), либо компания начнёт хорошо зарабатывать и Вы увлечётесь гоночными машинами вместо программирования, либо компания разрастётся и один, даже очень крутой и замотивированный, разработчик в Вашем лице будет физически не в состоянии выполнять требуемый для поддержания бизнеса объём работ… вот тогда Вы увидите, что "риск для бизнеса" — это вполне объективная штука, даже в Вашей ситуации.
либо компания начнёт хорошо зарабатывать и Вы увлечётесь гоночными машинами вместо программирования
это же мой истинный интерес, как такое может случиться?
гололед-гипс — вы имеете в виду случай самотравматизации. в большинстве случаев я наблюдал психологический контекст этой самотравматизации, и за собой такого не замечаю. если вы имеете в виду другую внезапную смерть — на этот случай есть отдельный сценарий. у меня кроме того работает программист удаленно
я против разрастания компании при наличии больших денег, это не моя цель
то, что работает у меня — работает годами. я хорошо инвестировал в свое время в архитектуру
Эти обвиняшки таким образом будут блокировать вам любое общее обсуждение. Вне зависимости, скрам это или нет.
Вместо того, чтобы использовать таймслот, предназначенный для синхронизации команды вы прервете Васю отдельно, в то время когда он не готов к этому, и не сможете использовать головы остальной команды для решения задачи (Петя может знать тул, алгоритм, кусочек кода или Мишу, который это знает). Вам придется Петю отвлекать от его задачи в еще какой-то момент времени, либо вы можете даже не подозревать что он что-то знает.
С моей точки зрения вот это «это означает обвинить Васю перед всей командой, поставить его в неловкое положение, вынудить оправдываться и надолго (навсегда?) ухудшить отношения с ним.» будет вам вредить хоть при скраме хоть при канбане хоть при водопаде, хоть при «фигач, блин, код»
Простите, а чего вы ожидали? Скрам — это вам не детально проработанный процесс, это фреймворк на базе которого вы должны выстраивать свои процессы. Он вам дает основу для ведения итеративной разработки. Дальше уж извольте додумывать процессы самостоятельно, для этого вам даются ретроспективы. Хотите инструмент для выявления проблем — добавьте к скраму канбан (ограничения на колонки) и многие проблемы будут вылазить сами по себе. Опять же если команда будет соблюдать выбранные ограничения.
Ну и опять же — у вас поквартальное планирование, вы не собираете фидбэк после каждой итерации, вы не анализируете приносит ли функционал ценности? Может вам вовсе не нужен скрам?
Описанная же вами ситуация — это исключительно про взаимодействие людей в команде. Ибо в целом так смысла в дэйли нету, если все вопросы можно тэт-а-тэт порешать. Скрам у вас, XP, FDD или RUP — проблема остается.
Если вы спросите у Васи на дэйли в чем проблема, то это ни сколечки не «обмакнет» его в глазах команды. Всегда будут люди, которые будут до последнего пытаться решить проблемы своими силами. Скрам или не скрам — климат вы выстраиваете тот который выстраиваете, выбранный фреймворк для ваших процессов на это не влияет (не должен влиять)
Скрам — это вам не детально проработанный процесс
Ох, как я люблю этот аргумент. В каждом первом проекте по скраму получается одно из двух: если проект удался — «ну, это потому, что скрам!», если не удался — «ну, это потому, что скрам это не детально проработанный процесс, нужно выстраивать процессы, ля-ля-ля». С тем же успехом можно предложить методологию разработки «писать код ночью голым в лесу при полной луне» — и точно так же можно будет объяснять успешные результаты — следованию методологии, а провалы — тем, что «ну, процессы были неправильно выстроены».
В каждом первом проекте по скраму получается одно из двух
Заметили ли вы что обычно когда все идет хорошо процессы хвалят те кто их внедрял, а в случае неудачи ругают те кто по ним работал? Если да — тогда наша статистика в целом совпадает (такая же у меня например в случае с kanban)
Но все же, повторюсь. Описанная вами ситуация будет воспроизводиться и в случае с каким-нибудь RUP, как минимум потому что речь идет о проблема коммуникаций между людьми в рамках одной задачи. Ну то есть я не понимаю почему для вас спросить на дэйли у человека в чем проблема и как ему помочь — это мокнуть его перед командой.
можно будет объяснять успешные результаты
главное не попасться в классическую ошибку выжевшего.
p.s. если что, я не особо люблю скрам, в основном потому что обычно его применяют бездумно и просто так, мне больше по душе какой-нибудь канбан или FDD. Но менеджмент обычно даже не вкурсе про существование чего-бы то ни было еще помимо скрама.
Почитал комментарии… странно. У меня сложилось прямо противоположное впечатление: статья токсична, автор толком не понимает ни скрам ни аджайл, описанные проблемы либо надуманы, либо невероятно утрированы, либо проистекают от непонимания методологий, и я дико сочувствую компании, которая наймёт автора на должность "не ниже директорской".
Но, судя по другим комментариям, существуют очень разные "заповедники".
Автору и многим комментаторам явно не повезло попасть в один тип заповедников, в котором скрам внедрили без понимания его смысла и сути, а точнее в попытке натянуть "сову на глобус" — применить технические приёмы скрама для исполнения мечты многих менеджеров о превращении неуправляемых творческих программистов в винтики конвейера.
А мне повезло попадать в другой тип заповедников, где скрам или канбан применяются для облегчения жизни и программистов и менеджеров, причём ровно в том объёме, в котором вред от них не начинает перевешивать пользу.
Чисто для примера, на моих проектах применение методологий схематично выглядит примерно таким образом:
- Начинается всё со стадии проектирования, обычно включающей бизнес-анализ, архитектуру, возможно R&D и/или мелкого прототипирования по самым сомнительным элементам. В лучших традициях… водопада. Точнее, водопадика. Очень маленького такого, не страшного. Маленького потому, что эта часть работы изначально и принципиально ограничена небольшим объёмом — у этой стадии на выходе принятые решения и документы (крайне редко — алгоритмы и кусочки кода), причём только те, которые нет возможности отложить на потом без явного ущерба для архитектуры проекта. Если для проекта подходит микросервисная архитектура, то сначала эта стадия выполняется для всего проекта в целом, чтобы определить какие микросервисы нужны, а потом повторяется для каждого микросервиса. Получается кучка небольших водопадов, которые не отбирают так уж много времени, неплохо распараллеливаются, и очень положительно сказываются на дальнейшем развитии проекта.
- Дальше обычно начинается работа по простому канбану, чтобы избежать траты ресурсов на более тяжёлый скрам и просто посмотреть, какие у нас типы задач, как команда их выполняет, какие возникают проблемы.
- Используя данные, полученные за пару-тройку недель простого канбана, дальше разделяем задачи и/или команды на разные группы: кто-то остаётся на простом канбане, кому-то канбан делаем чуть более навороченный/формализованный, кого-то переводим на скрам.
- Если в процессе разработки, с учётом аджайла, вносимые на ходу изменения начинают разваливать изначальную архитектуру проекта — происходит частичный возврат на первую стадию с водопадом. Частичный — по двум причинам. Первая: обычно к этому моменту полно задач, которые можно продолжать пилить, потому что уточнение и переработка архитектуры не повлияет на необходимость сделать эти задачи. Вторая: при использовании микросервисов требуемые изменения архитектуры обычно затрагивают относительно небольшую часть микросервисов, и разработка остальных может продолжаться.
Иными словами, методология подбирается под специфику задач и команд, и на одном проекте нередко используются разные методологии для разных этапов и задач/команд.
Я вообще себе не могу представить разработку архитектуры, R&D или админские/devops задачи по скраму. Для админских задач канбан отлично подходит, а архитектуру и R&D можно формально маскировать под канбан (просто чтобы не морочиться с настройкой JIRA под ещё один тип проектов), но по сути там будет происходить небольшой водопадик. С другой стороны, когда уже понятно что и как делать, и надо тупо пилить код, причём так, чтобы сроки были управляемыми — скрам идеально подходит.
При таком подходе все методологии находятся на своих местах, и облегчают жизнь всем, и программистам и менеджерам. А то, что предлагает автор вместо этих методологий, для меня звучит как "я нежный творческий гений, оставьте меня в покое, не указывайте мне что и как делать, и когда-нибудь я вам выкачу гениальное решение, которое принесёт компании много денег". Скажу честно, автору около тридцати лет, а у меня опыта работы около тридцати лет… да, для опытного разработчика вроде меня такой подход даже может иметь смысл, и мне работать в таком стиле приятнее, и, если повезёт, действительно можно получить обещанный результат, и ждать его придётся вовсе не вечность. Хотя стоп, о чём это я размечтался? Такое работало, очень давно. Когда один-два человека ещё вполне могли сделать серьёзный продукт. На работу команды этот подход не масштабируется, вообще никак. На постоянно меняющиеся требования со стороны бизнеса этот подход тоже не масштабируется. Вывод: чтобы это сработало нужно писать небольшой проект, который реально сделать парой человек, и заказчиком которого являешься ты сам. А в остальных случаях пока ничего лучше аджайла пока не придумали… а недостатки аджайла надо уметь обходить, применяя разные его варианты в разных ситуациях.
автор толком не понимает ни скрам ни аджайл
А кто-нибудь вообще понимает? Мои наблюдения показывают, что каждый (даже "сертифицированный эджайл/скрам/бан специалист") понимает под этим что-то своё и свято уверен, что все остальные ни черта не умеют в правоверный скрам. Я, конечно, верю, что где-то есть заповедники, где всё хорошо, но в подавляющем большинстве мест, где внедряют скрам, творится форменный карго-культ.
Например, в одной компании собрали "скрам команду" из фронта, пары бэков, тестера и оунера. Коучили её 2 недели. Всё по заветам. Вроде бы правильные вещи декларируются. Начинаем работать и выясняется:
- Без коуча всё разваливается и не работает. Без единого начальника команда не самоорганизуется, а начинает перетягивание одеяла в разные стороны. Кто как понял, тот за то и топит.
- Даже если кому-то и удастся захватить лидерство, убедив, что у него больше опыта/знаний, то он будет таковым даже в областях, в которых не компетентен.
- Кроссфункциональных людей не бывает. Кто-то ас в одном и профан в другом, кто-то наоборот. А эффект Даннинга-Крюгера часто не даёт признать другого более компетентным. Даже если специально прокачивать всех во всех областях — у всех разные способности и интересы.
- Так как у каждого по факту своя специализация, то общая компетентность команды определяется некомпетентностью большинства. Так как все "типа кроссфункциональные", то каждый имеет равное право голоса. А при демократии принимается не самое лучшее решение, а наиболее популярное. Например, если вы фронтендер и способны с закрытыми глазами писать компактные и поддерживаемые стили, то будьте готовы, что большинство, которое во фронтенде умеет лишь теги расставлять, продавит какой-нибудь твиттер бутстрап, который вы замучаетесь кастомизировать.
- Да-да, декларируемый коммитмент, либо скатывается в голосование большинством, либо приводит к ступору разработки из-за постоянных дебатов и в конечном счёте развалу команды.
- В команде у вас могут оказаться вовсе не те люди, что действительно нужны проекту. Например, если для проекта оптимальнее было бы разрабатывать на ноде и шарить часть логики между клиентом и сервером, но в команде у вас оказалось 2 пхп-шника, убеждённых, что нода сырая и ничего не умеет, потому что год назад они попробовали и что-то там не срослось, то будьте готовы к тому, что при выборе платформы именно пхп окажется оптимальным решением по всем показателям. Вместо пхп можно подставить яву, дотнет, что угодно.
Вы, конечно, можете возразить, что это мы такие дураки и ничего не понимаем настоящем аджайл. Но есть гипотеза, что таких дураков большинство и связано это с несовершенством психологии человека и их в целом различий. И даже таким вот, не способным к продуктивной самоорганизации, дуракам нужно как-то работать вместе и даже выдавать какой-то приемлемый результат.
А какое отношение все вами описанное имеет к аджайлу? То есть ну вот, например: "В команде у вас могут оказаться вовсе не те люди, что действительно нужны проекту" — поставили вы не тех людей на проект, аджайл-то как виноват?
Вот только основной момент — принятие решений на основе фидбэка после каждой итерации, этого как-то нет. То есть когда менеджмент слышит «делать больше теми же силами» в их головах это волшебство и магия которая просто будет позволять лучше планировать, контролировать и деливерить больше фич. Тогда как в реальности под этой фразой подразумевается обратное — резать фичи, приоритизировать, обрабатывать фидбэк от пользователей после каждой итерации, что позволит теми же силами доставлять пользователям больше пользы (пускай фич будет меньше даже чем обычно). Ну там объясняется это все законом Парето и прочими эмпирическими наблюдениями.
ну то есть если компания вводит аджайл — она часто вводит его весьма избирательно. То что вся эта хрень с короткими итерациями и быстрым фидбэком для минимизации рисков (мы инвестируем чуть-чуть в разработку самого ценного из фичи что бы быстро узнать стоит ли продолжать и будут ли фичей пользоваться), и что это подразумевает кординальные изменения на уровне всей организации.
Особенно радуют аутсорс компании которые практикуют скрам. Как правило у них SoW подписан на пол года работы, фиксированный бюджет и коммитменты по функционалу, но всем говорят что они аджайл.
Скрам как продукт у нас сейчас продаётся в формате таблеток от болезней, в наличии которых коуч должен убедить клиента (топ-менеджера, который вряд ли вообще знаком с людьми, для которых он этот скрам покупает). Претензии, скорее, не к скраму как концепции, а к опошлению рыночных механизмов его распространения, превращающих его в культ карго, набор «игр в офисную работу». Всех накормим анальгином, даже если голова у тебя никогда не болела!
и решение это спускается для них «сверху»
Меняется ли для команды процесс формирования бэклога?
Скрам как продукт у нас сейчас продаётся в формате таблеток от болезней
У Дэйва Томаса (один из авторов agile manifesto) есть доклад на эту тему — Agile is dead. Ну и есть очень неплохая постановка на тему типичных скрам коучей: A Retake on the Agile Manifesto • Humble, Thomas, Badiceanu, Fowler & Kirk
Манифестами и прочими теориями я обмазан изрядно, и, в целом, не против скрама как такового, и у меня есть вполне себе примеры его эффективного использования. Но это были стартапные команды не более 10-ти человек, которые и составляли контору, которые и сами себя организовывали по заветам скрама, понимая друг друга и доверяя друг другу, и целесообразно забивали на качество продукта (чтобы быстрее выйти на рынок). И это были редкие случаи подходящего, на мой взгляд, применения скрама (сработанная заранее команда + стартапные критерии эффективности, которые вовсе не о стабильности конечного продукта и процессов его рождения).
В «больших» же конторах я не видел скрама, который бы не был карго-культом, практически ни разу. Люди спорят о том, как считать сторипоинты, как сортировать приоритеты, сколько недель должен быть спринт, но совершенно не понимают, ради чего и чем отличаются варианты друг от друга. Потому что разрабатывают не «свой» продукт, и, как правильно отмечено в статье, прозрачность поэтому в больших конторах получается большей частью односторонняя, и по вполне объективным причинам это для большой конторы полезно (хоть и не очень приятно для конкретных исполнителей). Главное только скрамом не сломать эффективную иерархию распределения управляющей информации.
Мысли не было — был вопрос на который вы не ответили. От ответа на него будет зависеть то как я буду раскрывать мысль дальше.
От того откуда приходят требования и как происходит проверка эффективности фич (и происходит ли вообще) зависит взлетит скрам или нет. Причем тут речь не только про скрам — любой итеративный подход.
Ссылки же были к другой части вашего комментария (и там было согласие с мыслью что все эти scrum сертификации и треннинги это просто отдельная индустрия сама в себе).
Мысль очень простая — скрам это не про то как вы дружно там дэйлики проводите, и спринты планируете. Это все в общем то инструменты. А основная штука в приоритизации задач, выделении важных вещей, анализе фидбэка после каждой итерации (опять же для приоритизации). А потому я и спросил — с введением в команде скрама процесс формирования бэклога хоть как-то поменялся? или в целом что там что там есть некий человек который просто говорит что делать? Ну мол, есть скоуп работы скажем на квартал и вы просто пилите от спринта к спринту или все же спринтам привязываются цели?
В больших компаниях как правило процесс формирования бэклога никак не меняется от введения скрама в дев командах. От того толку от этого скрама там не много, хоть десять коучей наймите. Ну и опять же, если вся компания представлена одной маленькой скрам командой с продукт оунером, то скорее всего эта команда будет пытаться деливерить то что важно (ибо на то что не важно обычно нет денег). И тут скрам помогает.
Уж извините за скомканность мысли, но в целом мысль простая — скрам работает там, где людям важно максимально ценность для пользователя деливерить а не максимум фич (отсюда важны все эти цели спринтов, фидбэк луп и прочее). Ну и в нем нет смысла если вы и так прекрасно представляете что вам нужно заделиверить и нет нужды в эксперементах.
Не виноват, его просто нет. Если вы наняли (намеренно или ненамеренно) команду состоящую из одних (или хотя бы большинства) ангулярщиков (или даже бутстрапонгриксников), то проект ваш будет на ангуляре (+bootstrap +ngrx соответственно), даже если оно для данного проекта совершенно не подходит. Однородная команда просто не сможет самостоятельно, без внешней силы выйти из зоны комфорта исходя из целей бизнеса. И всех новичков будет либо "форматировать" под себя, либо "отлучать".
А кто-нибудь вообще понимает?
Да. Хотя людей, которые действительно понимают именно суть, и способны её донести — очень мало. Я пока нашёл ровно одного такого человека. К сожалению, у него в основном видео, поэтому времени на просмотр уйдёт некоторое количество, но оно того стоит. Именно благодаря его объяснениям я понял, что было не так с наблюдаемыми мной попытками внедрения аджайла в разных проектах и как это делать правильно, чтобы вместо страданий это приносило облегчение работы.
Для тех, кто вообще не в теме, или просто окончательно запутался в разных вариантах аджайла, есть неплохая маленькая статья — введение в скрам и канбан, основные принципы и отличия: Разбираемся в Scrum и Kanban.
Человек, о котором я писал выше — это Алексей Пименов pimenaus. К сожалению, он явно предпочитает формат живого общения, так что мне не удалось найти альтернативу его выступлениям на конференциях в виде статей. Зато его выступления посмотреть однозначно стоит! К сожалению, у меня нет списка его выступлений, которые можно было бы рекомендовать в конкретном порядке — когда я его нашёл, то смотрел все его выступления двое суток подряд (причём надо отметить, что я видео смотреть вообще не люблю, для меня это слишком медленный способ получения информации), пока в какой-то момент голове не сложилась полноценная картина про скрам и канбан на уровне, когда я стал в состоянии адекватно сам их объяснять другим. Если не путаю, то первое его видео, которое мне попалось и "зацепило", было Минимальная правильная Scrum-конфигурация Jira.
Мне больше всего нравится вот это видео:
www.youtube.com/watch?v=HZyRQ8Uhhmk
В принципе, у Вас верные ощущения. Проблема в том, что когда люди, вроде бы понимающие методологию (в теории), начинают её внедрять в конкретной команде и на конкретном проекте на практике — выясняется, что очень многое можно делать по-разному, и как именно нужно делать в данной конкретной ситуации и почему — никто не понимает. Пользуясь Вашей аналогией — понятно, что сейчас по методологии надо зажечь свечку, только вот они, оказывается, в нашей команде и на этом проекте, бывают по 10, по 20 и красные, и какую из них надо зажигать и почему именно эту — непонятно.
Именно по этой причине я убил два дня на просмотр — Пименов реально понимает эти методологии, и поэтому может объяснить как и почему именно так надо делать в любой конкретной ситуации. Чтобы из этого потока конкретных, практических примеров вытащить общее понимание методологии (из которого исходит он сам) — нужно проанализировать достаточное количество этих примеров.
Такое реверз-инженеринг сути из конкретных примеров применения сложно назвать эффективным способом обучения. Проблема в том, что я лично ничего лучше просто не нашёл — большинство тех, кто пишет про эти методологии, сами их суть либо не понимают, либо не в состоянии её объяснить другим.
1) Сейчас будет второй и последний раз когда я употребляю в этом комментарии слово «гибкий» с большой буквы и по-английски. Я полностью согласен с Allen Holub в том, что главная беда в том, что люди хотят Agile®. А это просто прилагательное. Как быть гибкими в разработке? И, главное, зачем?
2) Похоже, что Allen Holub прав ещё в одном: гибкая методология разработки подходит только для взрослых, ответственных и профессиональных людей. Для другого контингента всё очень быстро деградирует в карго-культ или очередной способ имитировать бурную деятельность. Гибкость подразумевает то, что мы идём от задачи и постоянно переосмысливаем свои практики разработки точно также, как постоянно переосмысливаем ТЗ путём постоянного контакта с заказчиком (если он есть, если ему есть что сказать и т.д.).
3) Автор статьи, которую мы здесь все обсуждаем, похоже, прав в том, что гибкие методологии в чистом виде применимы на довольно узкой категории проектов, а в остальных случаях следует сконструировать свою гибкую методологию с нуля, ориентируясь на ценности Манифеста гибкой разработки ПО.
В Манифесте есть отличная фраза:
Люди и взаимодействие важнее процессов и инструментов— грубейшим образом нарушается: люди никого не волнуют, все делаем Scrum как написано в книжке.
12 принципов:
Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.— почему все вокруг с ума сошли на двух неделях? Даже авторы Принципов допускают большой зазор в выборе длины итераций, позволяют нам быть гибкими в выборе этого срока.
На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.— представители бизнеса в смысле представители конечных пользователей программы. Это идея об уничтожении промежуточного менеджмента как испорченного телефона и источника идиотизма в принятии решений.
Над проектом должны работать мотивированные профессионалы. Чтобы— А? Что? Нет, нет, нет. Мы будем нанимать джунов, не будем их систематически обучать, будем смешивать их с профессионалами, а доверять не будем никому — каждый будет исповедоваться каждый день, а мы будем всем рассказывать какие задачи делать, за какое время и каким образом, притом гораздо подробнее, чем это было раньше.
работа была сделана, создайте условия, обеспечьте поддержку и полностью
доверьтесь им.
Непосредственное общение является наиболее практичным и эффективным— это значит «избегать совещаний». Это значит «нет менеджеров». Горизонтальное общение.
способом обмена информацией как с самой командой, так и внутри команды.
Работающий продукт — основной показатель прогресса.— А как же спринты? Стендапы? Чарты?
Инвесторы, разработчики и пользователи должны иметь возможность— БЕСКОНЕЧНО. Это значит, что технический долг как минимум не должен расти
поддерживать постоянный ритм бесконечно. Гибкие процессы разработки продвигают устойчивую разработку.
Постоянное внимание к техническому совершенству и качествуПроектирование? А мы думали это уже не модно и архитектура сама появится как человек из водоросли (правда за пару месяцев).
проектирования повышает гибкость проекта.
Простота — искусство минимизации лишней работы — крайне необходима.Да как вы смеете? То, что мы тратим 10% рабочего времени на игру в покер, ежедневные минисовещания, а каждые две недели по целому рабочему дню — это не лишняя работа, это нужно.
Самые лучшие требования, архитектурные и технические решения рождаютсяМы вам самоорганизуемся, анархисты проклятые. Всё будет проходить так как сказал Product Owner.
у самоорганизующихся команд.
Команда должна систематически анализировать возможные способы— нет, у нас Scrum по книжке и точка.
улучшения эффективности и соответственно корректировать
стиль своей работы.
Завершить хочется вот этой серией твитов:
«Великая ирония scrum и agile в том, что они были созданы инженерами, которые хотели завоевать независимость решая самим как работать, а сейчас в основном используются менеджерами для установления своего контроля, создавая для подчинённых инженеров иллюзию независимости»
… подходит только для взрослых, ответственных и профессиональных людей. Для другого контингента всё очень быстро деградирует в карго-культ или очередной способ имитировать бурную деятельность.
Так можно сказать практически про всё, аджайл просто не является исключением, и его сложно за это винить.
… методологии в чистом виде применимы на довольно узкой категории проектов, а в остальных случаях следует сконструировать свою
И это можно сказать про абсолютно любую методологию, ибо серебряной пули нет.
все делаем Scrum как написано в книжке
Потому что для того, чтобы делать как-то иначе, нужно быть в состоянии самому писать такие книжки — т.е. понимать суть и уметь адаптировать методологию в соответствии с текущей командой и проектом. Людей, которые на такое способны — очень мало.
почему все вокруг с ума сошли на двух неделях?
Насчёт всех — не знаю. Но я знаю, что чем чаще релизы — тем лучше. Из личного опыта, когда команду вёл я, то я вообще задал размер спринта в одну неделю. Основной недостаток — менеджерская нагрузка на меня была заметно выше, чем при двухнедельных спринтах, но на проекте это сказывалось положительно. Когда я передал этот процесс другому — он сделал двухнедельные спринты, и, я практически уверен, руководствовался при этом вовсе не пользой для проекта, а просто пытался уменьшить нагрузку лично на себя.
Вообще, если это подходит команде/проекту, я предпочитаю канбан — в этом случае релизы идут по готовности каждой задачи, т.е. несколько раз в день — и, на мой взгляд, это лучше всего.
Мы вам самоорганизуемся, анархисты проклятые. Всё будет проходить так как сказал Product Owner.
Ну, вообще-то PO является частью команды, и его мнение в отношении приоретизации задач является не менее экспертным, чем мнение разработчика о необходимости рефакторинга какого-то модуля системы. И самоорганизация здесь означает, что PO и разработчик должны уметь договариваться, чтобы и фичи и рефакторинг делались своевременно. Проблемы здесь, по моим наблюдениям, чаще возникают из-за того, что у разработчиков плохо с софт-скилами, и они просто не в состоянии объяснить важность технических проблем PO на понятном ему, не техническом, языке.
С остальным, в общем-то, согласен.
Пока из всего что мною было прочитано и просмотрено лидирует вот это: Surviving Your Inevitable Agile Transition — J.B. Rainsberger — сухо, никакого популизма.
Что до Холуба — мне версия Дэйва Томаса нравится больше.
А кто-нибудь вообще понимает?
Я с вами полностью согласен. Основная причина неработающего Agile заключается в том, что люди не понимают что это такое, и как его применять. Это как в притче Кент Бека про автомобиль, когда водитель заехал не туда, и начал обвинять в этом автомобиль.
Работающий Agile — это действительно редкость, особенно Scrum. Начнем с того, что Scrum — «is a framework within which you can employ various processes and techniques.». Это самое важное, что нужно знать про Scrum, и именно этим он отличается от полноценных методологий вроде XP. Итак, Scrum — это не методология, и в методологию его еще нужно превратить. Но об этом чуть позже.
Я не буду долго останавливаться на том, как и почему возник Agile, и в чем его суть. Если кому интересны подробности, то я могу предложить ссылку на свой блог-пост по этой теме "Про Agile на пальцах. Путь к быстрой разработке.". Поэтому, здесь я затрону этот вопрос только тезисно.
1. Agile во многом изобрели архитекторы. Одну из самых первых и, по сей день, одну из самых эффективных Agile методологий XP изобрел Кент Бек. Среди подписантов Agile-manifesto присутствует ряд авторитетных архитекторов.
2. Agile означает гибкий. Достижение гибкости программы — это вопрос качества проектирования. Грубо говоря, Agile — это значит достигнуть такого качества проектирования, которое позволит дешево внедрять проектные решения не заблаговременно (up-front), а итеративно, уже в процессе разработки и развития продукта, с учетом обратной связи от практического использования продукта. Иными словами, наладить Agile-разработку могут только специалисты, компетентные в вопросах проектирования и архитектуры, иначе Agile просто обречен, но не все могут это заметить на ранней стадии.
Вся суть Agile выражена в одном выражении Кент Бека: «If a flattened change cost curve makes XP possible, a steep change cost curve makes XP impossible.».
Agile — это использование бизнес-выгод, которые дает качественное проектирование. Это возможность управлять бизнес-рисками в условиях неопределенности. Правда, возможно это только в том случае, если стоимость изменения программы низкая.
А теперь самое интересное. Изначально Scrum содержал технические практики заимствованные из XP. Однако, позже решение о выборе конкретного набора технических практик было отдано на откуп самим разработчикам. Они считали, что это сдерживает проникновение Scrum в массы. Именно поэтому, Scrum — это не методология, а framework (каркас, скелет), на который еще необходимо нарастить практики.
К сожалению, в Scrum отсутствует именно то, что поддерживает стоимости изменения программы низкой и делает Agile возможным. Одним из вариантов решения этого вопроса является комбинация Scrum и XP. На практике же разработчики не уделяют этому вопросу должного внимания, и часто вообще не используют никаких технических практик, превращая Scrum в обычный Waterfall с итеративным планированием, но при этом рост графика стоимости изменения кода не позволяет сделать разработку гибкой.
Как показывает статистика, которую я знаю из авторитетных источников и по личному опыту, в среднем за 3-4 года стоимость изменения программы возрастает настолько, что дальнейшее развитие проекта становится нерентабельным, и приходится прибегать к радикальным действиям (эмиссия акций, замена руководства, закрытие проекта, сокращение штата и т.п.).
Очень тяжело сделать развернутый ответ в краткой форме, поэтому, я думаю что приведенная мною выше ссылка ответит на все, что я упустил.
Да нет, всё люди прекрасно понимают. На любом скрам коучинге вам расскажут, что "скрам — это фреймворк, а вот те другие, просто не понимают этого". Существуют ли эти "другие"? Сомнительно. И не смотря что заявляется гибкость, многие люди чисто психологически не способны быть гибкими. Они просто не так воспитаны. И никакая методология им эту гибкость не даст. А с такими людьми гибкость возможна в основном через ритуалы (яркий представитель — канбан с его "я не могу взять в работу задачу, так как у меня уже 3 висяка") или подчинение ("начальника сказала забить на это и срочно пилить то"). Осознанно ставить себе ограничения и в зависимости от приоритетов их же нарушать — не каждый способен без конфликта в сознании.
И честно сказать, я так и не понял на что и зачем вы отвечали. Процитированный мой вопрос — просто риторический, вводная для описания наблюдаемых мною явлений.
А что вы пробовали до него? Там стили жёстко завязаны на иерархию классов, конечные стили элементов зависят от комбинации классов, а сами классы имеют слишком короткие и общие имена, что даёт непредсказуемый результат. Пока нет кастомизации всё более-менее работает. Но стоит начать править стили, так сразу всё едет по швам. Плюс размер этого чуда инженерной мысли не слабый, особенно в свете того, что большая часть кода не будет использоваться вообще.
Не совсем так. В каждой области деятельности должен быть эксперт, который на основании своего опыта и знаний может сказать, грубо говоря, что хорошо, а что не очень. Но часто бывает ситуация, когда начальником (или лидером, как в скраме, что не сильно отличается по сути, лишь формально) становится человек, который пытается принимать решения в той области, в которой не компетентен. Это ведёт разработку этой части проекта под откос, вымывает из него (а то и вообще из компании) хороших специалистов, оставляя лишь посредственностей, что ещё печальней сказывается на проекте.
А кто-нибудь вообще понимает?
Скрам описан в скрам гайд. Если человек хочет обсудить, какой-то способ работы, то он должен сослаться на ту часть гайда, которая его требует или хотя бы это проверить. Если какая-то практика с его точки зрения неизбежна при интерпретации гайда, он должен обосновать почему.
Если он не хочет этим заморачиваться, то для меня он — трепло, которое не знает о чем говорит, а делает вид, что знает.
Ссылки на священное писание — ну такая себе гибкость.
Хотя с другой стороны, вы опять правы — они ограничивают в в возможности придумать какую-то отсебятину и назвать ее скамом.
Так же как некоторые придумывают какую-то свою внутренне противоречивую отсебятину и называют что-то там юнит тестами ;).
Кстати, да, спасибо, что напомнили про вкладку номер 28.
Если не обосновывать принадлежность к тому или ином способу работы, то мы теряем возможность употреблять термины, каждый раз это будет обозначать все, что угодно и надо приводить полное описание того, как была устроена работа.
Мне очень странно, что такие элементарные вещи надо объяснять программисту — ведь он-то должен знать зачем нужны идентификаторы
Данный идентификатор никак не влияет на работу команды.
С моей точки зрения, чтобы сделать такое заключение надо либо быть серьезным специалистом с опытом либо треплом. В первом случае надо еще понимать, что означает слово "скрам" иначе суждение не имеет смысла.
Ну вот есть команда, работает хорошо, но не по скраму. И что с того?
Разобраться, как это устроено и постараться позаимствовать. Чтобы разобраться надо как-то все это назвать.
В любом проекте есть куча самой разной работы. Есть сложные куски, требующие непредсказуемое время на исследования, есть архитектура, требующая отсутствия спешки… но есть и много относительно простой и механической работы.
Я обычно участвую во всех этих типах работ, потому что, с одной стороны, квалификации достаточно чтобы выполнять большую часть ролей (PM, бизнес-аналитика, архитектора, разработчика, devops, сисадмина), а с другой, как фрилансеру, часто приходится совмещать разные комбинации ролей, потому что размер и компетенция команд на разных проектах сильно отличается, и нужно "затыкать дыры".
Так вот. Да, мне больше нравятся сложные, творческие задачи, на которых меня не сильно ограничивают временными рамками. (Кто бы мог подумать, да?) Тем не менее, нужно сделать и все остальные задачи, включая простые, относительно механические, и не особо интересные. Радости они доставляют мало, но вот в чём фишка — "идеально подходящий" под такие задачи скрам заметно скрашивает работу над такими задачами. Скрам даёт размеренный ритм, само наличие которого оказывает поддержку (примерно как барабаны для гребцов), даёт понимание что поток этих скучных задачек не вечен и более-менее реалистичную оценку сколько времени уйдёт чтобы их сделать, даёт регулярные положительные подкрепления когда результат двухнедельной работы релизится, даёт защиту списка ближайших задач от внезапных изменений. Иными словами, скрам не делает скучные задачки более интересными, но он делает процесс реализации этих задач более простым, наглядным и уменьшающим стресс — и для менеджеров, и для исполнителей.
То, что Вы описываете — действительно существует, но эти проблемы вызваны не самой методологией, а её непониманием либо тем, что её название и некоторые техники используют для маскировки и реализации соковыжималки. Если проблема в непонимании — всё можно поправить. Если компания хочет соковыжималку — это её проблема, и чтобы она не стала Вашей надо сменить работу сразу, как только стало очевидно, что дело не в непонимании.
Часто задачи сложно оценить не потому, что они большие, а просто потому, что их сложно оценить. Какой-нибудь простой баг может потребовать неделю только лишь для того, чтобы понять в чём вообще проблема. У меня был такой случай. При этом я сразу сказал, что у меня нет компетенций ни для решения этой проблемы, ни даже для её понимания. Но проблема воспроизводилась ведь лишь на моей ветке, а значит я "накосячил, а потом неделю ничего не делал". Как потом выяснилось, если интересно, проблема была в том, что другая команда, что поддерживает репозиторий пакетов, втихую изменила настройки авторизации, сделав её обязательной для всего, из-за чего на самом деле сломались все ветки, но они продолжали собираться, так как пакеты для них уже были выкачаны ранее и брались из локального кеша, а настройки мавена/гредла (в которых я ни бум-бум, как и вообще в яве) или их плагины для npm написаны были так, что авторизация подцеплялась то ли асинхронно, то ли слишком поздно. Столько проблем из-за того, что кто-то решил, что использовать яву для сборки фронтенда — хорошая идея, а потом копипастил всё это из проекта в проект.
Это правда, но с этим тоже можно работать: такие задачи надо оценивать итеративно. Сначала оцениваем баг в пару часов. Через пару часов смотрим: если по-прежнему ничего неясно и видимого прогресса за эти два часа не было вообще — переоцениваем его в пару дней. Если за пару дней тоже прогресса почти нет — либо переоцениваем его в неделю либо переназначаем на более квалифицированного или имеющего экспертизу в конкретно этой области коллегу. После каждой переоценки баг возвращается в бэклог, чтобы PO имел возможность контролировать его приоритет в соответствии с изменяющейся оценкой.
Я всем советую очень простую вещь, если что то вам не нравиться в Agile которая устроила ваша компания, то на первой же ретроспективе вы должны ставить вопрос ребром, и менять правила. В этом и есть главный смысл гибких методологий. Процесс должен прогнуться/измениться под вашу команду.
Понятно что ваши изменения должны быть чем то обоснованы. Если у вас сомнения, попросите совета на ресурсах где много специалистов по Agile. Даже здесь в комментариях очень много дельных советов.
У вас были проблемы с конкретными симптомами — вы их выносили на общее обсуждение?
А при чем тут "невозможно оценить" наверное вы имели ввиду "невозможно было безошибочно предсказать".
прочитайте определение https://en.wikipedia.org/wiki/Estimation
Estimation (or estimating) is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable. The value is nonetheless usable because it is derived from the best information available.
Оценить можно все, что угодно, вопрос, с какой точностью ;)
Если я не ошибаюсь само понятие водопад появилось как пример подхода из строительной области который никогда не будет работать в разработке ПО.
Возможно водопад реально используется где в разработке авиационного ПО.
Я лично в своей карьере его ни разу не встречал
Так что Agile — это формализация итераций в общей схеме «водопада».
Нет! Вы бы хоть в вики заглянули сначала: Каскадная модель. Если кратко, то суть водопада в том, что следующий этап не начинается, пока не выполнен предыдущий. Это не противоречит возвращению на предыдущие этапы, если на следующих стало понятно, что на предыдущем что-то упустили. Типичный пример — тестирование не начинается пока продукт не готов целиком. В условиях, когда что такое "продукт целиком" никто толком не понимает и определение этого понятия непрерывно меняется — водопад требует неприемлемо много времени, значительная часть которого уходит на тщательное проектирование, разработку и тестирование функционала, который вообще не попадёт в финальный продукт.
В отличие от водопада, который не пускает нас вперёд, к следующим стадиям, аджайл наоборот, направлен на максимально быстрое достижение последней стадии (релиза), ценой пропуска всего, что только можно на предыдущих стадиях (включая сбор полных требований, детальное проектирование, поддержку крайних случаев при реализации, …) и распараллеливания этих стадий. Качество всех стадий при этом сильно страдает, но зато появляется возможность намного быстрее понять, что такое "продукт целиком", плюс практически одновременно с этим пониманием получить готовую реализацию этого продукта, пусть и с сомнительным качеством, но работающую.
Учитывая, что высокое качество, равно как и уменьшение тех.долга, бизнесу зачастую не нужны (по крайней мере на этапе создания начального продукта и попытки продавить его на рынок) — в абсолютном большинстве компаний аджайл поставил водопад на колени и жестоко убил, как всегда делает любое добро с любым злом.
Если кратко, то суть водопада в том, что следующий этап не начинается, пока не выполнен предыдущийЧто совершенно верно и в отношении к Agile. Ведь невозможно начать тестирование, если тестировать нечего. Это ограничение не является искусственным правилом Waterfall, а является причинно-следственной связью указанных стадий работы. И никто не запрещает при нахождении бага при тестировании вернуться к ранним этапам проектирования исключительно в своей голове, продумать новый механизм, тут же написать код, и снова запустить тесты. Относитесь к технологии как к инструменту, а не как к священному писанию!
Ведь невозможно начать тестирование, если тестировать нечего.
Вы ничего не слышали про TDD? Ну ладно, TDD это крайний случай, и речь не о нём.
Суть водопада в том, что тестирование не начинается пока продукт не будет готов целиком. А в аджайле тестирование выполняется по мере разработки отдельных фич/задач. В скраме оно начинается либо одновременно с разработкой (TDD), либо (чаще всего) через несколько дней после начала разработки (чтобы к завершению спринта фича была не только написана, но и протестирована), либо (в самом крайнем случае) на следующем спринте тестируются фичи реализованные на предыдущем. В канбане ещё проще — все задачи перемещаются из колонки "in progress" в колонку "testing" перед тем, как попасть в колонку "done".
Суть водопада в том, что тестирование не начинается пока продукт не будет готов целиком.
В реальном мире такого не бывает, даже если это описано в таком «непогрешимом источнике» как википедия. Такое ощущение, что вы никогда не работали в формате НИОКР, характерном для российских госпредприятий и наукоёмких областях. Все эти ТЗ, ЧТЗ, ТП, дополнения к ним (по результатам разработки или опытной эксплуатации), модели, стенды, опытные образцы. Так вот, модель waterfall является хорошим формальным приближением такого способа разработки.
Да ктож вам сказал такую ерунду? Только не надо ссылаться на википедию, а давайте лучше про реальность. Я вот за много лет никогда не видел такого, чтобы тестировщики сидели и ждали, когда же продукт будет готов целиком. И кстати, не продукт, а релиз. Они значит ждут, а работодатель им денежки платит… Смешно, право слово.
На самом деле они приступали к работе с получением спецификаций, причем еще не готовых, потому что review этих самых спецификаций входит в их задачи — чтобы оценить возможность и способы протестировать то, что аналитики напридумывали.
И точно также работали все остальные члены команды. Как только мы что-то определенное знаем о задаче, тимлид и архитектор приступают к проработке архитектуры, декомпозиции ее на задачи, оценке трудоемкости задач.
Именно так работают уже давно хорошо организованные команды. И никаким гибким словом это не называлось, при всем при том.
Во времена активного использования водопада было нормальным даже не пытаться скомпилировать проект первые несколько месяцев разработки. Да, это было давно. Да, это самый настоящий водопад. Так что тестировщики всё это время могли заниматься ревью спецификаций или играть в крестики-нолики, или тестировать другой проект… но тестировать конкретно этот проект они получали возможность за пару месяцев до релиза, когда проект уже был написан практически целиком, и были решены проблемы интеграции написанного таким жутким способом кода, чтобы проект, наконец-то, удалось скомпилировать и запустить. :)
Во времена, когда Брукс был МНС-ом, так же строился и софт. Потому что софт существовал всегда в единственном экземпляре, для конкретного компьютера. Никому не приходило в голову, что после того, как компьютер построен (за время и деньги, вполне сопоставимые со строительством моста), можно уточнить требования и начать всё заново.
Сейчас такой процесс, вероятно, возможен при проектировании уникальных научных космических зондов, направляемых куда-нибудь к Плутону: после того, как зонд улетел за орбиту Юпитера, обновление прошивки становится невозможным; поэтому 1) надо всё хорошо продумать заранее; 2) зато после преодоления орбиты Юпитера работа софтостроителей закончена, они могут вобще забыть про этот зонд и начать думать про следующий.
Во всех остальных отраслях софтостроения, актуальна присказка «программный продукт можно писать, но нельзя написать». Процесс добавления и уточнения требований не заканчивается никогда. Поэтому «одно-итерационных» процессов уже несколько десятилетий не существует. Там, где не ажайл, там никакой не водопад, а какая-нибудь «V-образная итерационная модель» (спроектировали, сконструировали, протестировали, выпустили релиз, goto 1). Которая отличается от ажайлов форматом совещаний и названиями ролей. И, главное, отсутствием хайпа.
Именно. Причем «наше время» — это скорее несколько десятилетий, как вы и пишете, чем несколько лет.
Недавно статья была про процесс разработки Windows. В наше время. У них там самый что ни на есть водопад: между релизами часть срока проектирование, часть разработка, в конце тестирование, возврата нет. Можно только отключить что-то, не прошедшее тестирование, и ждать условно полгода
Могу рассказать как это происходит у меня на работе. Я работаю в Австралии в компании Jora (но на самом деле она принадлежит компании SEEK, в одном офисе работаем). Команда стратегии показывает и рассказывает к чему мы должны стремиться, все программисты знают, какие у нас цели. Цикл у нас недельный, новые эпики независимо сначала стартуют — есть выбранные программисты которые будут над ними работать, обсуждается ход работ, есть выбранные epic owner. Задачи добавляются в спринт во время планирования, так же у нас есть постоянно работающие эпики типа technical debt, вместе с текучкой они ассайнятся на dev on call товарищей, которые ротируются каждую неделю. Эпик может длиться несколько спринтов, никто никого не пинает, не пушит, главное — эпик оунер должен обьяснить сколько еще осталось работы и почему столько. Никого не бьют за удлинение сроков, если люди в состоянии обьяснить. Вообще тут никого не бьют и не ругают, это даже странно. В планировании смотрят, какие эпики закончены, все чинно благородно.
Прямо вот странно все это читать.
— Я по Инь.
— Ну тогда я по Ян!
Как и несостоявшееся коммунистическое государство, которое уравнивает людей путём распространения бедности,
Коммунистическое государство уравнивает людей путем обобществления средств производства. Бедность — понятие относительное.
Забавно заканчивается статья лозунгом выкинуть бизнесовую разработку. А что тогда останется? Научные да фановые проекты.
Я для себя пришел к выводу что r&d, техдолг и архитектура нормально вписываются в скрамоджайл, если потратить некоторые усилия и продать их бизнесу. И это нормальная часть работы разработчика, потому что только он знает, что и когда надо переделать, какая часть системы не справляется с нагрузкой или вызывает проблемы при малейших изменениях.
Люди, не знающие, каковой должна быть методология scrum/agile/waterfall/etc, жалуются на то, как внедрили эту методологию те, кто также её не понимают, но винят саму методологию… Более того, назначают оную методологию однозначным неоспоримым злом.
Это тоже самое, что утверждать, что шурупы виноваты в том, что они у вас молотком не забиваются!
Кивайте лучше на тех, кто бездумно впаривает или внедряет. Но не надо срам скрамом называть.
У меня, вон, тоже, стажу за 20 лет, и я успел повидать разные методологии с разной степенью удобоваримости. По сути, какой-нибудь скрам — тот же фреймворк или паттерн проектирования, хорош, когда вовремя и в нужном месте, да употреблён согласно правилам, а не абы как…
Это тоже самое, что утверждать, что шурупы виноваты в том, что они у вас молотком не забиваются!
Если шурупы выглядят так, что глядя на них вам приходит в голову забивать их молотком, то таки да, они виноваты. На самом деле, шурупы так не выглядят. В отличие от Agile, который в любой компании с неумолимой определенностью всегда превращается в то, что описано в этой статье.
Э… что тут скажешь. Никто себя не любит считать ресурсом, это очевидно. Но ведь авторам этих методологий нужно было как-то "продать" их менеджерам, потому что без этого их никто бы не стал внедрять, а внедрять их однозначно стоило, потому что потенциально выиграть от этого могут все, и разработчики и бизнес. Вот и использовали приятную бизнесу терминологию. По факту, ресурс или нет — зависит исключительно от точки зрения и масштаба (расстояния, с которого ты смотришь на происходящее).
Не нравится считать себя ресурсом — не считай. Не нравится, что твой менеджер или владелец компании считает тебя ресурсом, время от времени или постоянно — старайся по-меньше об этом думать, потому что ты в любом случае не контролируешь что у них в голове. Как вариант, можно работать исключительно в небольших компаниях, тех, где сотрудников считают скорее семьёй, чем ресурсом… и увольняться из них как только это отношение приносит компании успех и она начинает активно расти.
Ну вот кстати да, с этим я соглашусь, люди часто заигрываются в такие глупости. С другой стороны и разработчики любят заигрываться в непонятых творческих гениев, которым ставить какие-то сроки — практически преступление (автор статьи похоже именно из таких). Переписыванием скрижалей это не лечится, самое эффективное средство против этой проблемы — медитация. Предложите тому ПМу помедитировать — как минимум насладитесь ещё более волшебным выражением его лица. :)
Не соглашусь ни с Вами (кто код вбивал иногда действительно не важно, но нередко имеет критическое значение для успеха продукта), ни с AZaz1 (программист далеко не главный человек в процессе разработки).
Одну и ту же "user story", исходя из одного и того же описания задачи в трекере, можно сделать очень по-разному. И когда заметное количество кода пишется не лучшим образом это приводит к серьёзным потерям бизнеса — деньгами, временем и репутацией. По этой причине (пока что) не получается построить конвейер из программистов, в котором любого можно в любой момент заменить другим без заметного влияния на результат работы этого конвейера.
Да, можно "выхолостить" задачу в трекере до состояния, когда все важные решения уже приняты, как именно надо написать код определено достаточно подробно, добавить кучку автоматизированных инструментов контроля качества (линтер, контроль покрытия тестами, приёмочные тесты)… и тогда действительно станет абсолютно неважно "кто там в конечном итоге код в редакторе вбивал". Проблема в том, что для бизнеса это ничего не изменит — на такое "выхолащивание" задач будет уходить 80% времени разработки, и люди, которые будут этим заниматься, будут ровно так же плохо заменимы, как до этого те, кто "код в редакторе вбивал". На самом деле — для бизнеса станет даже хуже, но причины мне разжёвывать сейчас лень, извините, их немало, но они не всегда очевидны.
Самый близкий к конвейеру вариант, который действительно может сработать, по крайней мере в теории, это разработка большого количества очень маленьких микросервисов. В этом случае "user story" это описание требуемого API микросервиса, приёмочные тесты контролируют корректность реализации API, дополнительно нагрузочные тесты контролируют не функциональные требования, желательно при этом ещё проконтролировать использование сервисом ресурсов (память, CPU, I/O), и его размер должен позволять реализовать его в среднем за 7-10 дней. При таком подходе "кто там в конечном итоге код в редакторе вбивал" действительно становится не важно, но… сильно увеличивается важность тех людей, которые проектируют систему из таких микросервисов, пишут для них тех.задания и приёмочные тесты. Да, этих людей будет нужно меньше, чем сейчас нужно программистов, но проблема в том, что их квалификация должна быть значительно выше средней квалификации сегодняшних архитекторов, и их всё-равно нужно будет достаточно много — сейчас столько взять тупо негде, их сначала выучить надо. А потом проверить эту теорию практикой.
По мне так единственная рабочая методология это здравый смысл и осознанный выбор подходящих методов исходя из ситуации.
Короче говоря мозги плюс опыт решают.
У нее даже есть перевод на русский
На это всё можно посмотреть вот с какой стороны. Все современные методологии, включая ажайл, придуманы прежде всего с целью превратить деятельность по разработке софта из искусства (которое даёт неизвестный заранее результат через неизвестное время за неизвестные деньги, зато даёт развернуться творческим личностям) в индустрию, которая даёт нужный результат за предсказуемые деньги и время. Ну правда, представьте предприятие по производству автомобилей, на котором производственное подразделение время от времени выдаёт фразы типа «нам нужно ещё полгода на рефакторинг» или «мы не хотим работать в таком темпе, мы же потеряем мотивацию и выгорим, это соковыжималка!».
Да, разработчик скажет, что между сборкой автомобилей и написанием софта есть большая разница. Но с точки зрения владельца бизнеса, никакой разницы нет: есть производственное подразделение, которому платят зарплату и ожидают произведённый продукт в заранее оговоренные сроки.
Поэтому, на самом деле, все комментарии вида «ажайл это соковыжималка» — это не про то, что ажайл не работает, а как раз про случаи, когда он работает хорошо (с точки зрения владельца бизнеса): он и придуман, чтобы от имеющихся наёмных работников получить максимум профита за минимум времени. На этом месте появляются не вполне однозначные рассуждения про то, что такая позиция недальновидна. Сотрудники выгорают и снижают производительность, их приходится заменять и обучать новичков. Но это можно компенсировать отлаженным механизмом обучения новичков, обязательным документированием всех знаний и приёмами TDD. И действительно, оказывается, что «рок-звёзды» и «творческие личности» типа автора статьи бизнесу неудобны: они могут выдать совершенно замечательный результат за короткий срок, а могут сказать «ой, чото я потерял мотивацию»; бизнес обычно предпочитает средний, но предсказуемый результат.
В принципе, примерно то же самое происходит и на традиционных заводах.
Это я к тому, что большая часть «жалоб на ажайл» — это на самом деле не жалобы на методологию, а жалобы пролетариев на излишне активную эксплуатацию со стороны работодателя. Ну а степень лояльности работодателя к пролетарию бывает очень разная.
Разработка новой модели инициируется бизнесом, а не производственным подразделением, исходя из положения на рынке и наличия средств на разработку.
Рефакторинг — инициируется производственным подразделением, причём либо производится этим подразделением «втихую» (за счёт увеличения сроков исполнения других задач), либо его надо суметь «продать» бизнесу (объяснить, что если его не сделать, производительность упадёт).
Мы-то с вами знаем, что сборка автомобилей отличается от написания кода тем, что написание кода — это не «реализация», эта работа гораздо больше похожа на проектирование новых моделей автомобилей, чем на сборку. Но тут мы сталкиваемся с тем фактом, что мы живём в эпоху НТР: наше время существенно отличается от старых-добрых времён тем, что «проектирование», «НИР и ОКР» — это теперь не работа НИИ и КБ, а производственная база бизнеса. А бизнесу, по большому счёту, всё равно, что производить: автомобили, программы или теоремы. Лишь бы продавалось.
за счёт увеличения сроков исполнения других задач
Правильнее сказать "за счёт незначительного увеличения сроков исполнения текущих задач ради значительного сокращения сроков исполнения будущих задач". Если бизнес ставит текущую задачу как "это прототип, все работы по которому будут прекращены через два месяца" — тогда да, любой рефакторинг "втихую" это саботаж. Но если бизнес ставит задачу как-то иначе, то в саботаж уже превращается отсутствие непрерывного фонового рефакторинга.
И нет никакой необходимости отдельно уведомлять бизнес об идущем в фоне рефакторинге — это штатная деятельность, без которой длительный проект реализовать невозможно по причине экспоненциального замедления разработки. Уведомлять нужно в ситуации, когда фоновый рефакторинг не справляется с задачей, и нужно выделить значительное количество времени (сравнимое с временем реализации пары обычных задач) исключительно под рефакторинг — вот тогда его нужно оформить таской в бэклог и отложить до момента, когда PO разрешит ей заняться.
Если команда объединена идеей, знает четко цели, задачи и методы решения проблем ей не нужны всякие прихлебатели-паразиты. Это опасный конкурент — субъект, а не объект политики. С ним нужно считаться, договариваться, либо уничтожить. Низводи лидеров, выращивай серость и посредственность. Работай на процесс, а не на результат. Разделяй и властвуй!
а пример методологии описывающий дивный мир в котором инженеры творят прекрасные продукты не парясь со сроками и не опускаясь до общения с «гуманитариями»?
Потом в контору пришел «Эджайл», и вот тут-то начался цирк. Все описанное выше автором в этом цирке присутствует. Теперь у нас дейли ради дейли, в нем собирается команда и обсуждает что было сделано, хотя к друг-другу теперь зачастую задачи отношения не имеют, и это получается просто треп, никак не помогающий каждому решить глобальную цель. Цель теперь как таковая отсутствует. Точнее она теперь выглядит вот так «сделай красивый бёрн даун», потому что это напрямую скажется на твоей премии и еще не бери нужные задачи, бери те, которые точно в спринт сделаешь, даже если они вообще никому не нужны, зато бизнес тебя похвалит что ты все успел. Для обязательно демо делаются всякие заглушки, чтобы бизнес мог увидеть как оно теперь стало, и неважно что на самом деле функционала еще нет, главное показать. А вот когда занимаешься рефакторингом — показывать нечего, поэтому рефакторинг не приветствуется.
В итоге производительность упала процентов на 30 минимум, основные задачи быстрее точно не стали делаться (скажем так они стали в работу уходить быстрее, но на выход в ПРОМ это никак не отражается). Зато периодически на ПРОМ такой сырой продукт выкатывается, что потом по выходным все это править приходится. А гибкость заключается только в отсутствии документации, потом концов не сыщешь, почему было сделано так а не так, никто ни за что ответственности не несет. Зато бизнес просто пищит от того какой он современный и как у него налажены процессы.
Стартапы с венчурным финансированием используют такие планировки для демонстрации инвесторам, чтобы офис выглядел занятым.
абсолютно согласен, такие стартапы начинают свой путь с такой вроде бы не лжи, но полу-правды. И со временем это усугубляется. По-моему лучше вообще без инвесторов и делать все самому.
В то-же время, я наблюдаю вот уже второе десятилетие размывания профессионализма на уровне Junior-Middle. В результате, на Middle-Senior выходит ежегодно, относительно, меньше народа. А знания-опыт, мягко говоря, оставляют желать лучшего. На рынке огромный деффицит профессионалов.
Благодаря этой статье, я увидел временную и причинно-следственную связь между Agile-измом и проблемой кадров.
Естественно, это не единственная причина, но теперь я рассматриваю её как очень вескую: социальная среда, создаваемая в Agile-зированных компаниях, влияет на индустрию в целом. Затрудняет профессиональный рост и преемственность знаний. Тренерует молодые кадры следовать ошибочным карьерным верктором.
Спасибо за статью и перевод!
Автор оригинала — Michael O. Church, «the most hated Ex-Googler», человек, который участвовал во всех возможных «политических» срачах компании и при этом делал мало производительной работы, уволившийся оттуда с отрицательной рекомендацией, с которой его не взяли в foursquare, короче неоправданно opinionated фрик, end of story. Особенно смешно он бегал по интернетам, пытаясь доказать, что когда наниматель звонит кому-то из бывших работодателей, кого кандидат не указал в списке рекомендаций, он нарушает право на частную жизнь и вторгается на недовзоленную территорию.
Его представления о ремесле, о рынке труда, не нуждаются в комментариях.
Никакого "настоящего скрама" не существует. Точнее, "настоящий скрам" это не методология, это фреймворк, на базе которого нужно сформировать (и корректировать по необходимости) методологию под конкретную команду/проект. Поэтому скрам у всех отличается, так задумано, иначе оно не сможет быть "гибким".
Ответ "вы не умеете готовить" означает только то, что описываемые проблемы вызваны не недостатками фреймворка, а недостатками сформированной по его мотивам методологии (часто даже не сформированной, а тупо взятой из книжки, без какой-либо попытки адаптировать её под команду/проект).
Скрам — это некая такая идеальная методология, которая лишена недостатков
Ничего подобного. В скраме, даже самом-самом настоящем и идеальном, полно недостатков — как и в любой другой методологии. Вопрос только в том, что ценой этих недостатков мы ожидаем получить определённые достоинства. В случае скрама — это стабильный, предсказуемый ритм разработки продукта, с регулярными и более-менее работающими релизами включающими нужные фичи. В случае канбана — это оптимизация среднего времени выполнения задач, но без какой-либо предсказуемости относительно конкретных задач.
Лично мне кажется что Скрам хорошо подходит для технически однообразных проектов, вроде — сделать интернет-магазин, дэйтинг… Но в сколько-нибудь сложных и долгосрочных он не так хорош.
Это не так. Безусловно, применимость скрама ограничена определёнными проектами, но "сложный" и "долгосрочный" к ним не относятся. Например, скрам очень плохо подходит для задач администрирования, поддержки, R&D, проектирования архитектуры. И не очень подходит для команды из 3-х адекватных сеньоров. А сложные и долгосрочные проекты по скраму делать ничего не мешает, просто не надо запихивать ногами проектирование архитектуры и R&D в спринты.
Если мало кто может построить из этого фреймворка подходящую для себя методологию, не пора ли задуматься что дело не только в кривых руках?
Абсолютно верно. Но никто вроде на личности не переходит, и не винит кривизну рук, ответ "вы неправильно его готовите" просто констатирует, что существует возможность решить проблему не отказываясь от скрама, а просто более адекватно его адаптируя под конкретную команду/проект.
Я лично довольно долго держался в стороне от скрама, и именно по этой причине — без хорошего понимания сути скрама и адекватной адаптации тащить его в проект это безумие. Но в какой-то момент мне повезло с ним разобраться, так что теперь для меня это просто инструмент — вполне рабочий и полезный, хотя и не могу сказать что любимый (канбан сильно проще, и зачастую его более чем достаточно).
Это тоже самое как утвержать что причиной того что было 85 фэйлов из 100 попыток сделать торт Наполеон из плохих материалов — скажем, муки из отходов (в данной аналогии это «фреймворк») всё дело в неправильных кондитерах.
Вы вряд ли хотите это услышать, но я всё-же скажу прямо: хороший кондитер не будет пытаться делать торт из говна, так что для получения такого количества фейлов нужны одновременно и плохой кондитер и недостаточно конкретный рецепт, который плохой кондитер просто не в состоянии адекватно понять и применить.
Если из фреймворка считанные люди могут выстроить себе что-то толковое, то тогда это и есть недостаток этого фреймворка — что из него мало кто может слепить себе что-то толковое :D
Полностью согласен. Проблема в том, что чего-то лучшего (я сейчас не конкретно про скрам, а в целом про гибкие методологии) пока либо не придумали, либо придумали, но не смогли раскрутить и сделать популярным, так что мы о нём не знаем.
вы вот работали с чем-то ещё кроме Скрама? Есть с чем сравнить? Например с Rational unified process.
Нет, RUP меня обошёл стороной. Как я обычно работаю описано выше, и скрам там занимает не самое главное место.
Почему?
Условный Twitter или Whatsapp. Как бы они проверили правильность своих идей по архитектуре без реальных пользователей и их активности? И без точного понимания, что пользователи чаще всего делают, и где в результате узкое место в той же архитектуре, без реального cash flow и понимания, что дороже всего в твоей инфраструктуре и пора уже оптимизироваться или еще можно новые фичи пилить.
А какое отношение всё Вами упомянутое имеет к архитектуре и R&D?
Проверку бизнес-идей на пользователях, если подойти формально, можно отнести к R&D — но обычно под этим термином подразумевается немного другое. Равно как можно, очень формально, назвать работой над архитектурой выявление узких мест в продакшне — но обычно под этим термином тоже подразумевается другое.
Типичный R&D — задача, которую команда понятия не имеет как делать, и даже как к ней подступаться, не говоря уже о том, сколько это займёт времени, и получится ли её сделать в принципе. Иногда от таких задач зависит весь проект (не получится своевременно и успешно решить задачу — проект закрывается), иногда их придумывают разработчики чтобы стало интереснее (а давайте попробуем написать следующий микросервис на новом ЯП, который никто из нас пока не знает — если повезёт, то бизнес сможет через год сэкономить кучу денег на серверах за счёт более эффективного использования ресурсов нашими микросервисами на этом ЯП).
Типичная архитектура — заранее продумать проект так, чтобы вышеупомянутые проблемы с узкими местами в продакшне просто не возникали, равно как и многие другие проблемы. А если их невозможно избежать, потому что это определится неизвестным пока поведением пользователей — заложить в архитектуру способ их решения, если они таки возникнут.
В скрам обе задачи не вписываются потому, что скрам — это про стабильный ритм разработки, а такие задачи под барабаны не делаются. Работа над архитектурой и R&D требуют непредсказуемого (как минимум — в начале работы) времени, отсутствия спешки (цена ошибки слишком высока), и готовности на любом этапе выкинуть текущие наработки и начать сначала.
Если менеджер дикий формалист, и требует чтобы всё-всё делалось по скраму, то систему просто хакают: создают на спринт задачу "продумывание архитектуры" с DoD "документировать ещё не решённые вопросы по архитектуре либо готовую архитектуру", и повторяют её в следующих спринтах пока работа не будет сделана. В случае R&D делают примерно то же самое: "изучить возможность реализации того-то" с DoD "документировать ещё не изученные возможности либо реализовать прототип либо сделать вывод о невозможности реализации" и тоже переносят в следующие спринты. Но к сути скрама этот маразм отношения не имеет, даже если при этом формально исполняются какие-то ритуалы скрама.
Основной недостаток этого подхода: дикая потеря времени. Спринты 2-4 недели, а задача может быть готова раньше, но чтобы её "принять" и воспользоваться результатами нужно ждать конца спринта, плюс такие задачи часто порождают кучу новых дополнительных задач, а их тоже нельзя брать в работу до следующего спринта… в результате теряется куча времени из-за бессмысленных ритуалов.
Основной недостаток этого подхода: дикая потеря времени. Спринты 2-4 недели, а задача может быть готова раньше, но чтобы её «принять» и воспользоваться результатами нужно ждать конца спринта, плюс такие задачи часто порождают кучу новых дополнительных задач, а их тоже нельзя брать в работу до следующего спринта… в результате теряется куча времени из-за бессмысленных ритуалов.
Смотря что понимать под «принятием» результатов.
С точки зрения бизнеса, результат это когда какой-то плюшкой пользуются клиенты. Не проведены исследования, не создан прототип, не проведены тесты, а доставлено до конечного пользователя, и он, конечный пользователь, этим пользуется. При таком раскладе, архитектура/R&D/etc просто некие возможно важные, но промежуточные шаги, и точно не самодостаточные.
И тогда спринты не становятся камнем преткновения. Даже скоротечные R&D все равно надо доставлять до клиента и получать обратную связь/анализировать метрики.
Это не отменяет того, что архитектура должна быть продумана.
Не отменяет и многих других мероприятий, в том числе R&D.
Лучше объясните каким образом в 90% ситуаций скрам используется исключительно для предоставления контрольных точек менеджменту а не, собственно, для того зачем он нужен.
Обьяснение простое. Уровень культуры другой. Если в корпоративной культуре силы и авторитарности пытаться внедрить инструмент бирюзового уровня, то в результате он либо совсем не работает, либо искажен.
Вот поэтому то надо не "внедрять" Agile, а трансформировать компанию в духе Agile. И начинать надо не с команд, а с владельца бизнеса, а потом с топ менеджмента. И вот когда они трансформировались, тогда уже и в народ запускать.
Но это всё вещи о которых в России начнут задумываться лишь через 3-5 лет. Так что пока надо только понимать природу этого феномена и практиковать стоицизм
Желтая оранжевая культуры. Лучше почитать об этом у Фредерика Лалу "Reinventing organizations".
Но в России самый распространенный вариант — организации-оборотни: красная культура, завернутая в желтую и оранжевую мантии. То есть самый худший вариант. Культура двойных стандартов. Когда вроде бы в конторе есть правила, стандарты, а в политиках прописано как люди и уважение к ним наша ценность, а на деле любые правила нарушаются руководством, из персонала, давят соки и главная парадигма "я начальник ты дурак"
Статья отличная, очень грамотно и глубоко проанализирована ситуация с Agile и Scrum внедрением. Но выводы сделаны не совсем верные.
В строчке, которую я процитировал выражена вся проблема — Agile в таком виде, какой есть в большинстве фирм сейчас, это не Agile. Это профанация. И если ваша Scrum-команда не может принять решение НЕ работать в open-space и если она не может получить обоюдную прозрачность и участвовать в принятии решений о продукте, то это не Agile. Это потогонка и микроменеджмент под нарядной драпировкой.
Ну а решение одно — внедрять ценности, а не фреймворки. А ценности — Самоорганизация и Самоуправление, Прозрачность, Психологическая безопасность и Непрерывное улучшение
Где Agile ужасен, особенно Scrum