Гибкость — без сомнения хорошая вещь, и в манифесте Agile есть смысл. По сравнению с хрупкой практикой под названием «водопад», Agile заметно лучше. Тем не менее, на практике гибкие подходы часто наносят глубокий вред, и в действительности вряд ли здесь уместна дихотомия Agile/Waterfall.

Я видел, как множество вариантов Agile, называемых Scrum, реально убивают компанию. Под «убивают» я имею в виду не «ухудшение культуры», а скорее когда акции компании падают почти на 90% за два года.

Что такое Agile?


Agile вырос из среды веб-консалтинга, где он приносил определённую пользу: при работе с привередливыми клиентами, которые не знают, чего они хотят, обычно приходится выбирать из двух вариантов. Или одолеть клиента: установить ожидания, соответствующую оплату за переделки и поддерживать отношения равенства, а не подчинения. Или принять некорректное поведение клиента (как, скажем, приходится многим дизайнерам) и ориентировать рабочий поток вокруг клиентской дисфункции.

Программисты обычно не очень хорошо работают с клиентами. Мы слишком буквальные люди. Нам нравятся системы с чётко определённым поведением. Это усложняет нам взаимодействие с гуманитариями, потому что мы склонны воспринимать каждый запрос буквально, а не выяснять, что они хотят на самом деле. На корпоративном уровне гибкие методы (вне консалтинговой среды) идут дальше и предполагают, что инженеры недостаточно умны, чтобы понять, чего хотят их внутренние «клиенты». Это означает, что работа распыляется на «пользовательские истории» и «итерации», которые часто лишают нас удовлетворения от выполненной работы, а также любой надежды на долгосрочное видение, куда идут дела.

В целом обычно создаётся два типа работ, будь то внутри компании или для подрядчика. На высоком уровне нанимаются со стороны высококвалифицированные специалисты. На нижнем — сбрасывается на сторону вся работа, которую не хотят делать. Очевидно, что один класс консультантов получает уважение, а другой нет. Плохо управляемые консалтинговые фирмы в конечном итоге часто становятся «мусоропроводами» для низкоквалифицированной работы. Scrum будто создан для таких организаций, где отношения с клиентами настолько плохи, что за инженерами нужно наблюдать на ежедневной основе, потому что они стали отстойником для низкопробной работы, бесполезной для карьеры, которую никто не хочет делать (и вероятно, это не очень важная работа, отсюда низкие тарифы и уважение).

Насильственная прозрачность


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

Самым вопиющим примером являются офисы открытой планировки. Они не продуктивны. В них трудно сконцентрироваться. Они антиинтеллектуальны, поскольку люди боятся быть пойманными, читая книги (или просто думая) на работе. Когда вы заставляете людей притворяться продуктивными, они на самом деле теряют продуктивность. Офисы открытой планировки вообще не для продуктивности. Речь идёт о корпоративном имидже. Стартапы с венчурным финансированием используют такие планировки для демонстрации инвесторам, чтобы офис выглядел занятым. (Проще говоря, программист в открытой планировке больше ценится как офисная мебель, а не за код, который пишет). По разным культурным причинам это сделало вариант открытой планировки «крутым» и «грязным», и теперь он заражает корпоративный мир в целом.

Хорошо известно, что творческие люди теряют креативность, если их просят объясниться во время работы. То же и с программным обеспечением. Программистам часто приходится работать в условиях односторонней прозрачности. Эти системы Agile часто неправильно применяются и требуют унизительной прозрачности работы, несмотря на отсутствие взаимности. Вместо того, чтобы работать над фактическими долгосрочными проектами, которыми человек мог бы увлечься, они низведены до работы над атомизированными, функциональными «пользовательскими историями» и часто запрещают работать над улучшениями, которые не связаны с краткосрочными, непосредственными потребностями бизнеса (часто спускаемыми сверху). Этот неправильный, но распространённый вариант Agile исключает понятие собственности и расценивает программистов как взаимозаменяемые, одинаковые компоненты.

Scrum — худший вариант, с глупостью двухнедельных «итераций». Это вызывает ненужное беспокойство о микрофлуктуациях производительности человека. Нет абсолютно никаких доказательств, что такой подход действительно ускоряет или улучшает разработку в долгосрочной перспективе. Он просто заставляет людей нервничать. Многие в бизнесе думают, что это хороший подход, потому что работа «идёт быстрее». Я в IT-индустрии уже десять лет, как менеджер и как рабочая пчела. Это неправда.

Специфические недостатки Agile и Scrum


1. Бизнес-ориентированная разработка.


Agile часто подают в сравнении с «водопадом». Что такое водопад?

Подход Waterfall действительно ужасен. В нём «работа катится вниз», где каждый уровень организационной иерархии выбирает то, что он считает «интересным материалом», и передаёт дальше. Проекты определяются руководителями, архитектура проектируется архитекторами, личные сроки устанавливаются менеджерами среднего звена, реализация выполняется рабочими лошадками верхнего уровня (программистами), а затем операции и тестирование передаются лошадкам нижнего уровня. Это крайне нефункциональная схема. Когда люди чувствуют, что все важные решения уже приняты, у них нет мотивации работать как можно лучше.

Водопад воспроизводит социальную модель дисфункциональной организации с определённой иерархией. В свою очередь, Agile довольно часто реплицирует социальную модель дисфункциональной организации без чётко определённой иерархии.

У меня смешанные мнения о названиях должностей вроде «старший» и «директор», и тому подобное. Они имеют значение, и я сам, вероятно, не приму должность ниже уровня директора, но я ненавижу их значение. Если вы посмотрите на Scrum, он специально лишает прав старших, самых способных инженеров, потому что здесь они обязаны придерживаться установленных процессов (работа только над созданными задачами, 5-10 часов в неделю на планёрках). Эти процессы спроектированы для людей, которые начали программировать месяц назад.

Как и несостоявшееся коммунистическое государство, которое уравнивает людей путём распространения бедности, Scrum в своей чистейшей форме ставит всю разработку на один и тот же низкий уровень: не чётко прописанный, но явно ниже уровня деловых людей, которым дана полная власть решать, над чем работать.

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

Кремниевая долина сделала много ошибок, особенно в последние пять лет, но кое-что сделала правильно. В том числе ввела концепцию «инженерной» компании. Для инженеров не всегда лучше управлять всей компанией целиком, но когда инженеры управляют разработкой и устанавливают приоритеты, то выигрывают все: инженеры счастливы работой, которую им назначают (или, ещё лучше, сами себе назначают), а бизнес получает гораздо более высокое качество разработки.

Но у вас «бизнес-компания», это нормально. Тогда не нанимайте инженеров в штат, если вам нужен талант. Вы можете получить лучших людей в качестве консультантов (начиная с $200 в час и резко поднимаясь с этого уровня), но не в качестве штатных сотрудников «бизнес-компании». Хорошие инженеры хотят работать в фирмах, управляемых инженерами, где они будут участвовать в планировании работы без необходимости оправдываться перед «скрам-мастерами», «владельцами продукта» и несколькими уровнями менеджеров-гуманитариев.

В конечном счёте, Agile (как практикуется) и Waterfall — формы бизнес-ориентированной разработки, и поэтому ни одна из них не подходит для разработки качественного ПО или мотивации сотрудников.

2. Подчинённое положение молодых.


К сожалению, в разработке ПО развилась культура подчинённого положения молодых с (крайне ошибочной) концепцией программирования как «игрушки молодых мужчин», хотя почти никто из лучших инженеров не молод, и довольно многие из лучших вообще не мужчины.

Проблема с двухнедельными итерациями Agile (или «спринтами») и пользовательскими историями заключается в том, что нет стратегии выхода. Там нет варианта «Нам не придётся больше это делать, когда мы достигнем [X]». Предполагается, что эта система навсегда: ориентированные на бизнес митинги никогда не исчезнут. Архитектура, НИОКР и развитие продуктов уходят из работы программиста, потому что не вписываются в атомизированные «истории пользователей» и двухнедельные спринты.

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

Однажды я работал в компании, где менеджер по продуктам сказал, что разница между старшим инженером и младшим инженером — в способности давать более точные оценки по срокам. Ну, вообще-то нет. И это даже оскорбительно. Я ненавижу оценки, потому что они генерируют политики и на самом деле не делают работу быстрее или лучше (на самом деле, обычно наоборот).

Самое худшее в оценках — что они стимулируют выполнение работы, которую можно оценить. Это заставляет программистов отдавать предпочтение простым вещам низкого уровня, которые на самом деле не нужны бизнесу (даже если неуклюжие менеджеры среднего звена думают иначе), но это «безопасно». Всё, что на самом деле стoит делать, имеет ненулевой шанс неудачи и слишком много неизвестных параметров для разумной оценки сроков. Концентрация Agile на краткосрочной ценности для бизнеса в конечном итоге отталкивает людей от работы, которая действительно нужна компании, ради управления репутацией каждого программиста в режиме реального времени.

Такая культура наталкивает на мысль, что программирование — это ребячество, от которого нужно избавиться к 35 годам. Я не согласен с таким мнением. На самом деле, я думаю, что это вредная мысль. Мне 30 с небольшим, и я чувствую, что только начинаю хорошо программировать. Преследование старших программистов только потому что они достаточно опытны, чтобы знать, что этот гибкий/scrum-процесс не имеет ничего общего с информатикой и что он не добавляет ценности — это ужасная идея.

3. Слишком краткосрочный подход, что глупо и опасно.


Agile предназначен для второстепенных консалтинговых фирм, у которых нет достаточного кредита доверия, чтобы вести переговоры с клиентами на равных, и которые сталкиваются с жёсткими сроками, а каждый клиентский проект является экзистенциальным риском. Он для «маргинальных» аутсайдеров. Но вот проблема: Scrum часто развёртывают в крупных компаниях и финансируемых стартапах. Но люди идут в такие компании, потому что не хотят быть аутсайдерами. Они хотят безопасности. Вот почему они работают в этих компаниях, а не создают свои собственные. Никто не хочет быть позади, если в этом нет значительной личной выгоды. Agile в корпорации означает боль и риск без вознаграждения.

Когда каждый клиентский проект несёт экзистенциальный или серьёзный репутационный риск, Agile может оказаться подходящим решением, поскольку фокус на краткосрочных итерациях полезен, когда компания находится под угрозой и может исчезнуть в долгосрочной перспективе. Агрессивное управление проектами имеет смысл в чрезвычайной ситуации. Это не имеет смысла как постоянная договоренность; по крайней мере, не для талантливых программистов, у которых есть менее стрессовые и более приятные варианты.

В рамках Agile технический долг накапливается и не решается, потому что бизнес-люди, назначающие задания, не увидят проблемы, пока не станет слишком поздно или, по крайней мере, слишком дорого её исправить. Более того, отдельные инженеры вознаграждаются или наказываются исключительно на основе текущих двухнедельных «спринтов», то есть никто не смотрит на пять «спринтов» вперёд. Agile — всего лишь один бессмысленный, близорукий «спринт» за другим: никакого прогресса, никаких улучшений, просто тикет за тикетом, за тикетом.

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

4. Он не имеет никакого отношения к построению карьеры.


Отдельные пользовательские истории не хороши для карьеры инженеров. К 30 годам ожидается, что вы способны работать на уровне всего проекта и что вы, по крайней мере, готовы выйти за рамки такого уровня в инфраструктуру, архитектуру, исследования или руководство.

В чрезвычайной ситуации, будь то консультация, стремящаяся успокоить важного клиента или корпоративная «военная комната», мысли о резюме могут подождать. Мало кто откажется от пары недель неприятной или иной работы, не имеющей отношения к развитию карьеры, если это действительно важно для компании. Важность работы здесь приоритет. Если вы можете сказать «Я сидел в штабе и по 20 минут в день общался с гендиректором», это оправдывает выполнение тупой работы.

Но если нет чрезвычайной ситуации, программисты ожидают, что их карьерный рост будет воспринят серьёзно. Иначе они уйдут. «Я был в команде Scrum» означает, что вы груша для битья. Одно дело сделать тупую работу, потому что гендиректор признал, что неприятная задача добавит миллионы долларов стоимости (и он вознаградит её соответствующим образом). Но если вам просто назначили «пользовательские истории» и тикеты Jira — значит, вас рассматривают как лузера.

5. Цель определить низкие показатели, но при этом неприемлемо высок уровень ложноположительных результатов.


Scrum предлагается как хороший способ выявить «отстающих сотрудников». Проблема в том, что он создаёт больше неэффективно работающих программистов, чем выявляет. Это тотальная система слежки, в которой отдельные инженеры подробно показывают прогресс своей работы, с оценкой продуктивности.

В дебатах о гражданских свободах часто упоминается распространённая ошибка: аргумент «нечего скрывать». Некоторые любят утверждать, что вторжение в частную жизнь, скажем, правоохранительными органами, не является проблемой, потому что они сами не преступники. Эти люди упускают несколько ключевых вещей. Например, что законы меняются. Спросите любого, кто был евреем в Центральной Европе в 1930-х годах. Даже для респектабельных людей состояние слежки — это состояние тревоги.

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

Здесь приходит на ум ещё одна тема: чувствительность к статусу. Программисты любят притворяться, что они преодолели несколько миллионов лет эволюции приматов, связанных с социальным статусом, но факт в том, что социальный статус имеет значение, и не стыдно признать этот факт. Пожилые люди, женщины, расовые меньшинства и люди с ограниченными возможностями, как правило, чувствительны к статусу на рабочем месте, потому что для них это вопрос выживания. Постоянное наблюдение за работой указывает на отсутствие доверия и низкий социальный статус, а самые чувствительные к статусу люди (даже если они лучшие работники) первыми страдают от усиления наблюдения. Если они чувствуют, что им не доверяют (и что ещё передаётся культурой, где каждый элемент работы должен быть одобрен?), то быстро теряют мотивацию.

Agile и особенно Scrum уязвимы для ошибки «нечего скрывать». Если ты не «плохой работник», ты ведь не против ежедневных планёрок, верно? Единственные люди, кто будет возражать против ежедневных отчётов о своей работе с точки зрения краткосрочной стоимости бизнеса — это «бездельники», которые хотят украсть деньги у компании, верно? Ну, нет. Очевидно, нет.

Культура насильственной прозрачности предназначена для самых нечувствительных к статусу людей: молодых, обычно белых или азиатов, привилегированных мужчин, которых ещё никогда не прессовали на работе. Для тех, кто думает, что HR и управление — пустая трата времени, а работник должен просто проглатывать унижения и оскорбления.

Часто от внедрения Agile/Scrum страдают лучшие сотрудники, потому что R&D эффективно устраняется. Одержимость краткосрочными «итерациями» или спринтами означает невозможность опробовать нечто новое, рискованное.

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

6. Пьяный эффект.


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

С точки зрения менеджера, который не знает, как работает программное обеспечение, это может показаться приемлемым компромиссом: несколько «примадонн» уровня 7+ покинут корабль под парусом Дивного Нового Scrum, зато 3-ки и 4-ки станут вполне приемлемыми 5-ками. Проблема в том, что разница между программистами 7 и 5 существенно больше, чем между 5 и 3. Если вы потеряете своих лучших людей и своих лидеров (которые необязательно находятся на руководящих ролях), то небольшое повышение уровня некомпетентных, для которых предназначен Scrum, не приносит пользы.

Scrum и Agile играют в то, что я называю предвзятостью к смене статуса. По сути, многие люди судят о своих успехах или неудачах не объективно, а исходя из субъективных изменений в статусе. Убедить программиста уровня 5 согласиться на зарплату программиста уровня 3 в стартапе (в обмен на долю в стартапе) психологически расценивается не как потеря денег, а как серьёзная прибавка в статусе.

Agile/Scrum и культура дискриминации по возрасту в целом касаются получения наиболее впечатляющей статусной прибыли, а не фактической экономической прибыли. Её можно достичь, как правило, путём найма людей, которые принесут наибольшую ценность (даже если вы предлагаете на 50% выше рыночной ставки, потому что лучшие программисты стоят в 10-30 раз больше их рыночной ставки).

Люди, которые меньше всего осведомлены о том, какой социальный статус они «должны» иметь — это молодёжь. Вы найдете 22-летнего программиста уровня 6, который думает, что у него уровень 3 и который согласится на Scrum, но 50-летний уровень 9, вероятно, знает, что у него 9 и может неохотно принять условия уровня 8,5, но точно не опустится до 3 или даже 6. Поиск статусной прибыли, конечно, бесполезен. Эти пункты ничего не значат. Вы выигрываете в бизнесе на разнице в доходах и расходах, а не на разнице в бессмысленных пунктах статуса. Может быть, существует целая индустрия в привлечении инженеров 5-го уровня, расценивая (и оплачивая) их как 4, но в нынешних рыночных условиях гораздо выгоднее нанять 8 и относиться к нему как к 8.

7. Нечестная реклама.


Здесь я сосредоточусь на Scrum. Некоторые утверждают, что Scrum является «экстремистским вариантом Agile», а другие — что это самый далёкий вариант от истинного Agile. (Возможно, здесь проявляется одна из проблем: мы не можем договориться о том, что является и не является Agile).

Решениям вроде Scrum есть своё место: очень ограниченное, временное. Нечестно говорить, что оно работает везде и на постоянной основе.

Для чего хорош Scrum


До того, как причуда Agile сделала его постоянным процессом, Scrum означало нечто вроде «красного кода» или «чрезвычайной ситуации». Если бы возникла неожиданная, быстро развивающаяся проблема, вы бы собрали своих лучших людей и сформировали экстренную команду.

У этой команды не будет чёткого менеджера, поэтому вы выберете лидера (например, “Scrum Master”) и дадите ему полномочия. Вы не хотите, чтобы он был официальным «менеджером людей» (так как он должен быть максимально беспристрастным). Поскольку кризис носит краткосрочный характер, карьерные цели отдельных лиц могут быть приостановлены. Это считается «спринтом», потому что люди должны работать так быстро, как могут, чтобы решить проблему, и потому, что им будет разрешено вернуться к своей обычной работе, как только спринт закончится. Кроме того, в такой чрезвычайной ситуации вам нужно дать понять, что никто не оценивается индивидуально. Основное внимание уделяется миссии и только миссии.

Когда вы навязываете процесс и требуете односторонней прозрачности всех работников, люди чувствуют, что за ними наблюдают. Они понимают, что их пометят как «слабых исполнителей», если неделя за неделей отдельные показатели пойдут не так. Такое обижает людей. Это дисфункционально. С другой стороны, если вы собираете группу проверенных специалистов, чтобы справиться с конкретным и ограниченным по времени кризисом, они не возражают против частых отчётов, если понимают, что это острота ситуации, а не их собственный низкий социальный статус, стал причиной этого.

Существует два сценария, которые должны прийти на ум. Первый — это корпоративная «военная комната». Но если конкретные лица (за исключением руководителей высшего звена) проводят в таком режиме более 4 недель в год, то с компанией что-то не так, потому что чрезвычайные ситуации должны быть редкими. Во-вторых, консультанты, которые пытаются зарекомендовать себя или плохо справляются с обслуживанием клиентов и установлением независимой репутации, и поэтому должны работать в условиях постоянного чрезвычайного положения.

Две проблемы


Таким образом, Scrum признаёт идею, что иногда власть нужно делегировать «экстренным» руководителям: они будут делать всё, что считают необходимым, чтобы выполнить работу, оставив споры на потом. Всё нормально. Иногда всё должно быть именно так.

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

Честолюбивому демагогу (скрам-мастер?) легче проявить себя в схватке с драконами, чем избежать их появления. Проблема с агрессивным настаиванием Scrum на бизнес-ориентированной инженерии заключается в том, что она делает ценностями («сотрудничество с клиентами») привлечение и убийство драконов (известных как «требования»), когда может быть более разумным не выманивать тех из своих пещер.

Agile и Scrum прославляют чрезвычайные ситуации. Это их главная проблема. Некая версия того, что индустрия видеоигр называет «шоу-тайм». Это не позволяет устойчиво работать. Агрессивный акцент на индивидуальной производительности, отсутствие заботы о карьерных целях людей при распределении работы и мандат, в соответствии с которым люди работают только на заявленный высший приоритет — всё это даёт большую пользу в краткосрочной чрезвычайной ситуации, но становится токсичным и деморализующим в долгосрочной перспективе. Люди стерпят краткосрочную потерю автономии, но только если впереди будет чёткая точка, когда они её вернут.

Вторая проблема заключается в том, что эта практика подаётся нечестно. Существует целая кустарная индустрия, которая выросла вокруг обучения компаний «гибкой» разработке программного обеспечения. Проблема в том, что большинство основных идей не новы. Терминология свежая, но понятия в основном устаревшие, неудачный «научный менеджмент» (который был далёк от научного и не работал). Опять же, эти процессы иногда работают для достижения чётко определенных целей в чрезвычайных обстоятельствах, но постоянный Scrum — это катастрофа.

Если избавиться от проблем Agile и Scrum, то у меня не будет такой сильной проблемы с концепциями. Если у компании есть команда только младших разработчиков и ей нужно быстро выпускать функции, она должна рассмотреть возможность использования этих методов в течение короткого времени, с планом отхода от них по мере того, как люди растут, а временные рамки становятся менее жёсткими. Но если подавать Scrum за то, что он есть — набор чрезвычайных мер, которые нельзя использовать для постоянного повышения производительности, — то будет гораздо меньше «покупателей» для него, и консалтинговая индустрия Agile перестанет существовать. Только через нечестную рекламу этих методов (прославленное «шоу-тайм», упакованное как постоянные исправления) они становятся доступными для продажи корпоративному миру в больших масштабах.

Будущее


Этой культуре подчинённого положения молодых, низкой автономности и агрессивного управления пришло время уйти. Это не просто плохие идеи. Здесь более серьёзная опасность, потому что выросло поколение инженеров-программистов, которые поглощают их, не зная ничего лучшего. Есть слишком много молодых программистов, обречённых на посредственность из-за уверенности в том, что бизнес-ориентированная разработка и «пользовательские истории» — так всегда всё работало. Такое следует предотвратить: от этого зависит будущее нашей индустрии. Agile, по крайней мере, а такой извращённой реализации, как всё, что я видел, — полная ерунда, которая не имеет никакого отношения к программированию и, конечно же, не имеет никакого отношения к информатике. Бизнес-ориентированная разработка в целом — тупик. Её следует бросить обратно в грязь, из которой она вышла.

Комментарии (159)


  1. oisee
    23.11.2018 19:21
    -4

    Это усложняет нам взаимодействие с гуманитариями
    Опять это потливое противопоставление «нас, программистов» против «них, гуманитариев». Откуда это вообще?

    В оригинале
    «This makes working with non-technical people harder for us than it needs to be»
    «Non-technical» переводится не так.

    Поздравляю вас, гражданин, соврамши!


    1. Slavik_Kenny
      23.11.2018 21:22

      Опять это потливое противопоставление «нас, программистов» против «них, гуманитариев». Откуда это вообще?

      Представьте себе — это из реальной жизни.


      1. oisee
        23.11.2018 21:44
        +5

        Да, свой (тем более болезненный) опыт ближе к телу.

        Но не всё что с кем-то приключилось имеет ценность настолько высокую, что может подменить здравый смысл и заставить исказить смысл источника.

        Физики и лирики, блин =)


    1. Moskus
      23.11.2018 23:36
      +2

      Интересно, что такое возражение (по сути — верное, потому что перевод неточен) выдвинуто с таким количеством эмоциональных и образных оборотов, которому позавидует иной человек творческого склада ума и творческой профессии.

      На самом деле, действительно, употреблять термин «гуманитарий» в таком случае — неверно. Те, о ком идет речь, опираются в принятии решений на ощущения, чувства, а не на логику, абстрактное мышление и систематизацию. Гуманитарные науки вполне могут требовать использовать логику и систематизацию. А тех, кому эти инструменты недоступны, называть «гуманитариями» — это поднимать их на уровень выше с их уровня слабого развития абстрактного мышления.


  1. andreyons
    23.11.2018 19:36
    +2

    А может кто рассказать, обратную сторону, то есть не «бизнес-ориентированную». Это как вообще? Я как раз из этих молодых, которые не понимают, полагаю.


    1. crmMaster
      24.11.2018 15:19
      -9

      Да не существует этой не «бизнес-ориентированной» стороны. Автор статьи возомнил себя художником, «творческой» личностью, а по факту программист — ремесленник, удовлетворяющий потребности бизнеса, ничем особо от кассира в маке не отличающийся, за исключением определенных знаний, за которые ему готовы платить большую зарплату и терпеть его «то не хочу, это не буду» при условии, что он зарабатывет или экономит бизнесу хотя бы размер своей зарплаты.


    1. powerman
      24.11.2018 15:51

      crmMaster сильно перегнул в одну сторону, попробую это компенсировать. Да, не «бизнес-ориентированной» стороны обычно не существует. Исключений не так много: можно разрабатывать собственные опенсорс проекты или участвовать в существующих (но за это обычно не платят), изредка попадаются чисто исследовательские/научные задачи, можно открыть собственный бизнес (это даст возможность самому определять "бизнес-ориентированность", но совмещать это с программированием вряд ли получится)… но самый реальный вариант, за который и деньги платят, и "бизнес-ориентированность" присутствует минимально — внутренние проекты компании.


      Ещё один вариант, достаточно специфический, это совмещать роли архитектора и бизнес-аналитика. Это даёт достаточно рычагов воздействия на бизнес, чтобы в значительность степени влиять на определение "бизнес-ориентированности" на этом проекте. А если ты что-то контролируешь — всё выглядит уже совсем не так плохо, как когда оно контролирует тебя.


      1. Jef239
        25.11.2018 18:44

        А какая бизнес-идея в написании новых языков программирования? Какой бизнес в научных и НИРовских работах? Очень многое делается на вырост. Да, оно через 5-10 лет пойдет в бизнес. Но пока не пошло — бизнес-ориентированности нет.


        1. powerman
          25.11.2018 18:55

          Смотря какие языки. Многие разрабатывались как опенсорс-проекты, и из разработку никто не оплачивал. Либо разработчик имел невероятно прокачанные софт-скилы и умудрялся "продать" своему начальнику идею, что позволить ему тратить рабочее время на разработку нового ЯП — это хорошая мысль. Некоторые языки, например Go, разрабатывались вполне осознанно под нужды конкретного бизнеса.


          Научные разработки обычно спонсируются, поэтому есть возможность и деньги получить и работать без особого давления бизнес-ориентированности (хотя нельзя сказать, что давления вообще нет — если долго не будет хоть каких-то полезных результатов, то финансирование прикроют).


          1. Jef239
            25.11.2018 19:31

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

            Поскольку Go не продается, а раздается — его бизнес-ориентированность не больше, чем у линукса.

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

            Фишка в том, что фундаментальные исследования, лишь изредка давая применимый в бизнесе результат, все равно выгодны. Точно так же с НИР и НИОКР, включающими в себя написание кода. Пишется оно по госзаказу и пишется. Вроде и госзаказ дурацкий и пишется в стол. А потом бац — оп-па, а у нас для бизнеса все кирпички готовы. Перекомпоновали — и можно продавать.


        1. ggo
          26.11.2018 09:36

          Т.е. появление go, rust, typescript, etc — это чистой воды филантропия Google, Facebook, Microsoft, etc?


    1. Jef239
      25.11.2018 18:39

      Ядро линукс, например. А вообще — много всего. Начиная с НИРовских работ, где непонятно, получим мы результат и, если да, то каким путем. Ну и кончая АСУТП, где надежность -важнее денег. Госзаказы те же.

      Ещё пример — автовождение. Да, будет бизнес, но не через год, а лет через 5. Но куча команд работает. Мы, например, случайно автовождение комбайна сделали. Хотя для нас основное — это высокоточный GPS.


  1. dipsy
    23.11.2018 20:24
    +2

    Согласен с тем, что нужно больше свободы и меньше контроля. Ежедневные отчеты это безумие, как и часы работы строго с 9 до 18, со штрафами за опоздание. Творчество (которого много в «программировании») любит свободу, как любит её и стремится к ней любой разумный индивидуум. Из-под палки от забора и до обеда можно копать траншею, писать гавнокод, но не создавать полезный продукт.


    1. mkshma
      23.11.2018 20:41
      -3

      Творчество (которого много в «программировании»)

      Откуда ему там взяться? У вас есть алгоритм, который вам нужно закодить. Все! От того, что он зачастую размытый и данных у вас сильно меньше чем надо, творческой работа не становится.


      1. Kiel
        23.11.2018 20:55
        +8

        Вы написали «откуда взяться творчеству» и тут же привели пример откуда. Если бы данных было достаточно, то да — не творческая. А когда надо извернуться и сделать так, чтобы из ничего сделать что-то, да так, что при любом отклонении от нормы было адекватное поведение в минимум строк кода с максимальным масштабированием — задача сразу становится еще какой творческой.


      1. maybe_im_a_leo
        23.11.2018 22:55
        +3

        Иногда никакого алгоритма нет, и вообще область не исследована, с пару-тройкой публикаций на тему.


      1. chupasaurus
        24.11.2018 01:02
        +1

        Расскажите про универсальный алгоритм кеширования данных, внесите неоценимый вклад в Computer Science.


      1. vadim_bv
        25.11.2018 11:48

        После фразы «Экспертиза промышленной безопасности — процесс творческий и нелинейный», сказанной одним из моих коллег-«экспертов», у которых всё зарегламентировано до запятой (а то ведь и рванет), я считаю, что программисты — это если не Да Винчи в плане творчества, то Ван Гог как минимум


      1. shikhalev
        25.11.2018 18:40

        Простите, но с уровня мидл- (джуниор+) появляется свобода выбирать как минимум сочетание алгоритмов (реализация в чистом виде уже известного алгоритма — это учеба). И вот этот выбор сочетания алгоритмов в рамках задачи — вполне творческая часть.


  1. usego
    23.11.2018 20:27
    -1

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


    1. dipsy
      23.11.2018 20:38
      +5

      Да вообще надо программистов убирать из процесса разработки ПО, слишком много о себе возомнили, творческие они, посмотри-ка! Наверняка умные менеджеры придумают со временем какой-нибудь Agile-SCRUM, чтобы убрать все лишние звенья, не поддающиеся систематизации и строгому контролю.


      1. Fesor
        24.11.2018 00:38
        +1

        > творческие они, посмотри-ка!

        Ну всю эту движуху что мол на конвейере у вас не совсем уж дураки стоят начали еще в 70-х и далеко не в IT. Мол, зачем надсмотрщики, выдайте людям секундамеры и ответственности о они сами будут пытаться оптимизировать свой участок работы.

        Ну там всякие книжки на эту тему вроде знаменитого The Goal и всякие там книжки про безотходное производство (toyota way, lean)…


  1. fcoder
    23.11.2018 20:55
    +1

    В статье очень плохо с пониманием скрама. Начнем с того, что опен офисы не имеют к нему никакого отношения. скрам — это про процесс, а не про передвигание кроватей.

    Долгие истории означают что вы не умеете планировать. «долгая» задача без детализации, без обсуждения с коллегами, без понимания трейд оффов — это кот в мешке и детский сад (рискованно и непрофессионально). А еще, за время выполнения, требования слегка изменились, и теперь нужно еще половина времени, чтобы ее подогнать. А еще мастер-ветка за пол-года изменилась до неузнаваемости. За более чем 10 лет опыта разработки я видел буквально единицы «долгих» историй, которые хотя бы не выбрасывали на помойку.

    Идем дальше, Скрам-мастер не лидер, а фасилитатор и коуч. Лидером же в скрам-команде является продукт овнер.

    Для того чтобы команда понимала что они делают и зачем, в скраме существуют несколько механизмов — участие стейк-холдеров в грумингах, бизнес поинты на задачах, демо…

    Если у тебя инженерное/архитектурное улучшение или ресёрч — обсуди его на груминге вместе с командой и положи в беклог. Ещё ни разу не видел, чтобы полезные для продукта задачи там залёживались.

    P.S.: Прошу прощения за транслит английских терминов.


    1. questor
      23.11.2018 21:40
      +6

      Судя по статье претензии к скраму весьма простые и понятные: никто не думает на пять спринтов, вымывается R&D. Если вы хорошо разбираетесь в скраме попробуйте ответить простыми словами, где и как скрам НЕ вымывает R&D и НЕ приводит к стратегической слепоте. Право, это будет много лучше, чем говорить «скрам-мастер — не лидер, а фасилитатор и коуч». Ну хорошо, и коуч. И чё? Каким образом это избавляет от вымывания R&D?

      Я без стёба, просто мне действительно интересно, а вы сказали, что разбираетесь в скраме.


      1. fcoder
        23.11.2018 22:18
        +1

        Очень странно слышать, что никто не думает на пять спринтов вперед, потому что специально для этого стратегию развития продукта разбивают по эпикам, которые стараются распланировать как-раз минимум на квартал вперед (обычно до какого-то мажорного релиза). На собеседованиях продукт-овнерам такие задачки на детализацию эпиков даже дают в качестве тестовых.

        Помимо планирования, можно по стори-поинтам прямо между спринтами смотреть, насколько мы укладываемся в распланированное расписание и, соответственно выкидывать/докидывать необязательные фичи, сдвигать релизы и так далее.

        R&D отлично ложится на скрам. Вот у нас шаблон примерно такой: Сначала у тебя история ресёрча — 1-2 спринта под уточнение что конкретно хочет бизнес, пруф оф концепт, время сравнить разные варианты имплементации и записать алгоритм. Затем — история дизайна (согласовал контракты API, хранения данных с другими командами), и, наконец, имплементация — у тебя уже почти всё есть, просто надо вставить в существующую систему, протестировать и выкатить в прод.


        1. AEP
          24.11.2018 00:19
          +3

          Вопрос про R&D на самом деле стоит несколько иначе. R&D = «мы сейчас не знаем, как это сделать».

          1. Как отличить необходимость проделывать этот самый R&D силами текущей команды от необходимости нанять человека, который уже знает все, что надо?

          2. Как перейти от стадии «понять, что хочет бизнес» к стадии «proof of concept»? Распространенная проблема — конечные исполнители не могут начать делать этот «proof of concept», поскольку вообще не знают, как это делается, а других нет. И ответственный за «распиливание» задачи (т.е. за детализацию эпика) ровно в том же положении.

          3. Как отличить «мы не знаем, как это делается» от «никто не знает» и от «это невозможно на текущем уровне развития технологии»? Кто вообще может принять решение отказаться от непонятной мегазадачи?

          Как надуманный пример — команда раньше вообще не занималась алгоритмами цифровой обработки звука, и тут с бухты-барахты стоит задача автоматически убрать излишнее эхо (не то, которое от попадания звука от динамиков в микрофон, а которое от многократных отражений от стен комнаты) из архива звукозаписей. Реализации этого дела в принципе есть, но (условно) под неприемлемыми лицензиями, поэтому надо писать свою. Научные работы в открытом доступе есть, но их еще надо понять, и они ссылаются друг на друга (т.е. для каждой статьи еще непонятно, сколько ссылок надо прочитать, чтобы понять конкретно эту статью), и там заумная алгебра, с которой проблемы.

          Как такой эпик заскрамить?


          1. Paskin
            24.11.2018 00:50
            +1

            Элементарно. Создаются задачи вроде «Прочитать книжку и оценить пути реализации» с ДоД «написать отчет». Дальше создается следующая, зависимая задача «выбрать алгоритм и набросать PoC». И так далее. При этом Product Owner должен понимать что в процессе PoC выбранный алгоритм может оказаться неудачным и расставлять приоритеты соответствующим образом (вплоть до полной деприоритизации — т.е. отказа от этого feature из-за высокого риска).


            1. napa3um
              24.11.2018 10:52
              +1

              Получился продукт-овнер как минимум из нобелевских лауреатов, кажется.


            1. opencloser
              24.11.2018 11:32

              А где задача по привлечению нужных спецов, или консультаций с другими командами партнеров(или заказчиков или просто знакомых)? =) Прочитать книжку — это сразу один из менее выгодных вариантов, т.к. проиграем время и спецы заточены на другие проблемы, следовательно выбор может пасть не на правильный путь и будет скрывать множество деталей вначале. Вот следующая задача «зависимая» ну уж точно не должна создаваться так рано, может её не будет или будет совсем другая? Второй задачей вы ограничили пути решения. Видимые риски нужно сразу убивать, что бы потом пожары не тушить=)


              1. Fesor
                24.11.2018 14:29

                А причем тут agile/scrum? Хотите привлечь отдельного специалиста — привлекайте.

                > не должна создаваться так рано

                Тут все упирается в то сколько у вас сейчас есть денег, сколько вы можете вложить и как быстро сможете понять стоит ли оно того дополнительных вливаний средств или нет.

                Если вам удалось найти специалиста и вы условились скажем в 2 недели на R&D дабы по результатам уже смотреть окупится ли дальнейшая разработка данной фичи — ну сделайте так. Если денег много и потенциальный профит перевешивает плюсы, и вы можете взять специалиста на пол года, почему нет.

                Все же R&D с точки зрения планирования проще организовывать за счет фиксированных итераций, ибо оценить такие задачи адекватно невозможно. две недели ресерч, анализ результата, решение копать дальше или забить.


            1. tuxi
              24.11.2018 14:40

              Напомнило «Задача по оценке временных затрат требуемых для проведения оценки основной задачи»


            1. Gorthauer87
              24.11.2018 15:20

              И на эту бюрократию все время тратится. На проработку эпиков на квартал вперед тоже куча времени уходит.
              А потом через месяц выясняется, что всю эту работу можно сливать в унитаз потому что по результатам реальной разработки все оказалось не таким как казалось в спайках.
              Я уже молчу про то что очень часто возникают мелкие задачи, которые решаются за время меньшее, чем возня с бюрократией.
              А в случае с r&d вообще может оказаться, что нужно делать совсем другую задачу, чем в спринте описана.
              В общем если работа чуть более сложная чем гребля на галере, то это все только снижает эффективность и приводит к эмоциональному выгоранию.


              1. fcoder
                25.11.2018 03:55

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

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

                Далее по тексту: Если в результате спайка нет пруф-оф-концепта и документации, заапрувленой аналитиком, значит работа не сделана.

                В случае с R&D без скрама, ты узнаешь, что нужно делать другую задачу не через 2 недели, а через 4 месяца (и я много раз это наблюдал).

                Минимум 90% разработки любого продукта — это «гребля на галере» причем весьма тупым способом. Остальное — плод работы скорее системного аналитика с архитектором в попытке решить бизнес-задачу с минимально приемлемым результатом.


                1. Gorthauer87
                  25.11.2018 11:53

                  Вот в случае когда в целом работа не попадавет в эти 90 процентов галерного типа, это все не работает. Не работает еще и потому что сам аналитик не может все предсказать и знать на перед.
                  Результаты спайков приводят к PoC, но он совсем не похож на реальный продукт. Слишком много подводных камней за один спринт не увидишь.
                  Вообще вся эта схема плохо работает когда их много.


              1. KostaArnorsky
                25.11.2018 03:58
                +1

                А расскажите, как вы эту проблему в waterfall решите и какая разница будет с agile? И луче слить в унитаз результаты одного спринта, чем пол-года пилить то, что никому не нужно.


                1. Gorthauer87
                  25.11.2018 11:54

                  Проработка эпиков на полгода вперед больше на waterfall по своей сути похожа.


            1. AndriyKravchenko
              25.11.2018 11:48

              «вплоть до полной деприоритизации — т.е. отказа от этого feature из-за высокого риска» — ну вот оно, вымывание R&D.


    1. groundhog
      24.11.2018 11:15

      Не прощаю :) зачем писать по-русски когда не можете сформулировать на русском языке?


  1. AZaz1
    23.11.2018 21:22
    -1

    Уважаемый автор, вы украли мои мысли :)
    я за свою длинную карьеру (начиная с перфокарт — многие не знают что это и еще не были рождены) попробовал все варианты организации работ.
    Последние годы работал в «крутых» компаниях в «крутых» офисах и по модным ныне методологиям глупо повторяемых организацию труда западных людей.
    Точно могу подтвердить ваши тезисы о странной односторонней «прозрачности» программистов, о кране низкой эффективности труда в опенспейсах и напрасной трате куче времени на дежурные и бесполезные совещания в рамках эджайла и самое главное — о выгорании и отвращении к работе нормальных ребят.
    Давно известно, что то что хорошо для немца (заметка: немец на славянском — чужой — не мы) — у нас не работает!
    А многие даже не понимая, что и для чего просто пытаются, как некоторые наши младшие собраться, копировать чужие наработки в абсолютно другой среде с абсолютно другой ментальностью и целями!
    Особенно меня умиляет обилие иностранных терминов в этом процессе :))
    попробуйте их заменить на нормальные русские слова — и вы сразу увидите абсурдность и ненужность и вредность для команды многого из того что привносят эти методики для организации труда на западе! :)


    1. SHVV
      23.11.2018 21:30
      +4

      Это же перевод. И судя по всему автор — американец. Так что не только в России так.


      1. AZaz1
        23.11.2018 21:36

        возможно — тогда он точно подметил все главные минусы современных тенденций в разработке — за что ему огромное спасибо!
        тем более его мысли подтверждают основные выводы, что слепое следование манускриптам эджайла и подражание западным компаниям не только не полезно но и вредно!

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


    1. Paskin
      24.11.2018 00:42
      +3

      Я чуть помладше — начал учиться когда перфокарты как раз списывали. И тоже прошел все стадии от «студента на пару часов в неделю» до менеджера и архитектора — работая в разных странах с разными же культурами. Кстати, даже сертифицированный Аджайл специалист — фирма организовала курс и оплатила экзамен, довольно несложный.
      Так вот — Аджайл (как и демократия) сам по себе не очень, но лучше пока ничего не придумали. Важно только не превращать его в карго-культ (что происходит во многих местах) — когда вроде все по книге, но и программисты и бизнес ходят недовольные. Отличная школа Аджайла — это стартапы вообще, особенно когда вас уже 10-20 человек и есть один-два клиента.


    1. vazic
      24.11.2018 13:00

      Понятно. А правильно делать как?


      1. AZaz1
        24.11.2018 14:02

        а правильно — это взять ценную идею и адаптировать ее под наш менталитет и условия.

        условия и атмосфера в каждом коллективе разные — поэтому одним трафаретом это все не замажешь — но основная идея — нельзя так просто взять и натянуть не натягиваемое — оно потом все равно разлезется.

        это большая тема для обсуждения, но из моего опыта скажу:

        — офис должен быть многокомнатным для команд максимум до 5-7 человек — я помню когда впервые попал в опенспейс и не мог работать и сосредоточиться и нервничал около полугода и дела не очень ладились хотя работу я свою знал хорошо. Даже проработав там более 3х лет могу подтвердить слова исследований что моя продуктивность была не выше 40%.

        — система спринтов не работает или «работает» но разработчики устают от такой работы, выгорают и уходят либо приспосабливаются и делают работу для галочки.
        Вообще мне все это напоминает то как в Союзе выпуск чего-то значимого обязательно подгоняли под какой-нибудь советский праздник :)
        Как правило наблюдал такой феномен когда вся пирамида эджайла после неудавшегося релиза приходила к разработчику и распинала его на эшафоте при этом никто из пирамиды сверху не ответил за неверные сроки, за не правильную идею, за не точную постановку, за не верный дизайн и многое другое — потому что нет этого в эджайле по-определению :) это технология управления РЕСУРСАМИ а не людьми.
        Планирование должно быть не по неделям или дням, а по функционалу — разработчика сделать главным по нему, он же и ответственный. Сроки важны но это не догма — иначе у вас выбор: сделаете в срок но лишь бы сделать и потом потратите кучу времени на баги и рефакторинг или сделать все как надо но естественно без не перебарщивая — при этом и разработчик будет в азарте и доволен и бизнес не пострадает.

        — сам был и в роли разработчика и потом в роли руководителя в системе эджайла — вынес из всего этого — 80% всех митингов прописанных в эджайле рано или поздно превращаются просто в профанацию — не нужно тупо следовать бумажке — слепое следование бумажке у всех вызывает зевоту и включает защитный механизм «ну ладно поиграем и в эту глупую игру но заметьте не я это первым начал» :)
        минимум совещаний и по делу а не по графику или по-методичке.

        — в коллективе где есть хоть 2 разработчика 3м обязательно должен быть психолог!
        меня поражает детсадовский подход в так называемом карьерном росте разработчиков во всех IT компаниях — типа из разработчика в тимлиды. Да ни за что! без вердикта психолога о том что человек по своей психологии является лидером и руководителем ни в коем случае такое делать нельзя — иначе потом горе тому коллективу.
        Психолог в коллективе разработчиков необходим как воздух — он помогаем многим найти мотивацию, помогает человеку обрести уверенность, руководителям подскажет как продуктивнее работать с человеком чтобы весь коллектив был счастлив, решает конфликты несоответствия и взаимодействия и т.д. и т.п.
        Чуть не забыл — и предотвращает прием на работу людей с опасными отклонениями — типа психопатии (к сожалению таким персонажей полно в нашей индустрии где «программистом» может стать и домохозяйка, но из-за отсутствия фундаментальных знаний у нее из=за постоянного стресса некомпетентности развивается опасный синдром)
        Психолог в IT — это мама коллектива и без него все превратится в эджайл!!! :)
        эджайл всего лишь попытка не профессионалов в сфере управления и общения людьми без фундаментальных знаний в этой области пытаться работать и управлять людьми.
        на западе это прокатывает — там все с детства понимают что они ресурс, у нас же (по-крайней мере динозавры моего возраста) считают себя людьми и не согласны быть ресурсом — это и накладывает большие ограничения на эту методологию.

        многое еще остается, что можно было бы сказать но это тема для долгого разговора…


        1. AZaz1
          24.11.2018 14:55

          и упустил самое главное — в каждом коллективе должен быть свой «аджайл», учитывающий уровень подготовки компетентности участников, психологию и специфику бизнеса!
          не бывает одного эджайла на всех! как и не бывает одного размера штанов на всех :)


        1. dvaletin
          24.11.2018 21:22

          Я вот специально залогинился через 5 лет молчания чтобы ответить:

          — офис должен быть многокомнатным для команд максимум до 5-7 человек

          Думается что 5-7 это неверный критерий. Мне видится критерий «скрам-команда в своем офисе» более верным. Скрам команда обычно небольшая, чтобы накормить 2-мя пиццами :-)
          Как правило наблюдал такой феномен когда вся пирамида эджайла после неудавшегося релиза приходила к разработчику и распинала его на эшафоте при этом никто из пирамиды сверху не ответил за неверные сроки, за не правильную идею, за не точную постановку, за не верный дизайн и многое другое — потому что нет этого в эджайле по-определению :) это технология управления РЕСУРСАМИ а не людьми.

          Вся пирамида аджайла как раз устроена таким образом, чтобы:
          1) контролировать фокус. Я заметил что после 3-х недель фокус людей начинает смещаться в сторону от первоначальной идеи. Как правило после 4-х недель от первоначальной идеи не остается и следа: программист сам придумывает себе задачу, сам творчески с ней справляется и бодро рапортует о проделанной работе. В большинстве случаев та проблема которую он себе придумал не имеет никакого практического значения: либо экономия 1% ресурсов, либо решение несуществующей проблемы.
          2) Контролировать прогресс: ежедневные стендапы направлены на то чтобы контролировать прогресс и не терять фокуса проблемы. Если ваши задачи разбиты на 2-х дневные участки, то вы легко сможете контролировать прогресс, а значит раньше отреагировать на возможные проблемы. Пример из жизни: разработчик потратил полтора дня на разворачивания environment для имплементации функции. Моя вина — на стендах он про это молчал. В результате вместо 4-х часов на задачу было потрачено 2 дня. Как инсайт — никого не уволили, договорились что на стендапах рано рапортуем о проблемах. Кстати, ретроспективы для этого и предназначены, чтобы выявлять внутренние проблемы, мешающие работе.
          3) Груминг (или декомпозиция) предназначены для того, чтобы все участники процесса получили правильное понимание того, что разрабатываем. Для этого на груминг собираются не только программисты, но и продуктологи. Продуктологи рассказывают что они хотят получить, а программисты предлагают простые решения этой проблемы. Там же легко выявить «неточную постановку» просто потому, что мы неточную постановку в разработку не берем (у нас встроено определение «ready for development» без формального соблюдения которого задача в работу не идет).

          Из преведенной мною цитаты я могу сделать вывод, что, к сожалению, вы попали как раз на карго культ скрама, а не на скрам. Скрам — это как раз про людей, про то как они взаимодействуют, как они планируют свое время (а вот это уже ресурс) и договоренность о том что же они делают. Для меня скрам — это механизм самоуправления в команде, когда команда сама принимает решения о том что и как делать.

          — в коллективе где есть хоть 2 разработчика 3м обязательно должен быть психолог!
          меня поражает детсадовский подход в так называемом карьерном росте разработчиков во всех IT компаниях — типа из разработчика в тимлиды. Да ни за что! без вердикта психолога о том что человек по своей психологии является лидером и руководителем ни в коем случае такое делать нельзя — иначе потом горе тому коллективу.

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


          1. AZaz1
            25.11.2018 00:11

            разочарую вас — вы делаете не верные выводы:

            начну сзади — тимлидом не станет народный вождь потому что он люб люду — для этого психотип соответствующий нужен

            никто не говорит о самодеятельности и длинных сроках реализации, но то что вы приводите и то где я работал очень подходит под меткое определение одного из комментаторов — «цифровой концлагерь для разработчиков» — не спешите возмущаться поставьте себя на место разработчика и помедитируйте подольше :)

            по рассказанному вами могу сделать выводы:

            — процесс общения у вас не налажен или он скорее всего официально-формальный типа я начальник — ты дурак — человек боится сказать что он не может среду настроить!!!

            — если вам необходимо ежедневно контролировать разработчиков — значит либо вы им не доверяете либо они у вас не самостоятельные маленькие детки за которыми нужен глаз да глаз

            — ретроспективы напоминают мне собрания склеротиков или клуб анонимных алкоголиков :) люди вспоминают то из-за чего у них были проблемы день или 2 назад. Неужели забыли и никто не помнит как сообща с нервами боролись за релиз!
            а если все прошло гладко то что говорить то???
            вот и вырождаются такие собрания в формальность

            — про фокусы думаю все понятно — тут и обсуждать нечего


        1. vintage
          26.11.2018 09:12

          предотвращает прием на работу людей с опасными отклонениями — типа психопатии

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


  1. questor
    23.11.2018 21:42

    Статья очень неплохая, во многом коррелирует с собственными наблюдениями. Я, прямо говоря не ожидал этого заходя в статью с таким желтушным заголовком, играющим на рептильных участках головного мозга.
    Но по мере чтения понял, что материал шикарный и понял, что надо будет перечитать ещё раз на свежую голову.


  1. StriganovSergey
    23.11.2018 22:34
    +1

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


    1. lagudal
      24.11.2018 01:16
      -1

      Психиатрическая лечебница просто какая-то.

      Вот чем отличается психиатрическая лечебница от какого-либо другого учреждения? Ведь не здание же самое главное… наверное главное это персонал и контингент.
      Так и тут, дело не в названии и не в методологии, любую идею можно испохабить…
      У нас вообще даже слова не подберу — чистый сюр какой то… Один новый «эффективный менеджер» внедряет agile и scrum вообще вне контекста разработки it-продукта.
      Представьте себе — фирма не IT, производство печатной продукции, из it отдела несколько сисадминов, 3 на бакенде — PHP в основном, и я один на фронтенде. Чисто для поддержки своих сайтов и веб шопов. И вот данный субъект приходит со скрамом, вернее, приезжает на коне. Создают команду: 1 бак,1 фронт, 1 вообще контент с точки зрения СЕО и один практикант. Плюс скрам мастер — младшая секретарша компании, в IT как свинья в помидорах. Тема — оптимизация — разная — данных сайтов. Что творится в процессе, что на daily, что в конце концов выходит — без содрогания не рассказать. Да и не надо.
      Важно что — вот поменяю я скажем в каком то обозримом будущем работу на чисто it-ную, и возможно и команда будет компететная, и методология будет ей подходить, но я уже ненавижу все это лютой ненавистью…
      пс. И это не Россия (Европа, мать ее..)


      1. andreysmind
        25.11.2018 10:47

        Вот чем отличается психиатрическая лечебница от какого-либо другого учреждения?

        «В психиатрии как? Кто первый халат надел — тот и доктор.»


  1. dmxrand
    24.11.2018 01:29

    Совершенно правильно подмечено. Я сейчас работаю в такой компании. На входе опрашивают о сложностях алгоритмов, а внутри ад. Работать в опенспейс просто не хочется. Это каторга. Смотришь на код и ужасаешься. Самые лучшие разработчики научились БЫСТРО выполнять таски. Но смотришь код и там просто кошмар. Видно что человек БЫСТРО выполнил задачу заложив там 10 мин замедленного действия. Нормально проверить наличие поста от юзера с помощью return posts.filter(user=user).count() > 0


  1. datacompboy
    24.11.2018 03:28
    +1

    — Агиль!
    — Не умею!
    — Агиль как умеешь!
    — Scrum, Scrum, Scrum…


  1. Druu
    24.11.2018 04:08
    +1

    Какой-то странный у автора scrum. Смысл ежедневных митингов и ревью по итерациям не в том, чтобы кто-то кого-то оценивал, а в том, чтобы как можно быстрее донести до команды и менеджмента факт возникновения какой-либо проблемы и, с-но, в возможности потом максимально оперативно на эту проблему отреагировать. То есть это не сдача физических нормативов с результатом "Вася мало отжался и слишком медленно пробежал кросс", а опрос вида "как здоровье? температура нормальная, никто не кашляет? ок, продолжаем работу".
    Если же митинги воспринимать как какие-то "отчеты" — тут, конечно, будет все плохо.


    1. aunoor
      24.11.2018 11:32
      -1

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


      1. dipsy
        24.11.2018 11:38
        +1

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


        1. aunoor
          24.11.2018 11:58

          Какой чатик, какие 30 секунд?
          Там где я работал ввели типа скрам. Т.к. время прихода на работу не фиксированное, то собрания назначались на время, когда все должны уже быть на месте. В итоге люди, приходившие за час, два до начала встречи фактически работой не занимались, потому что смысл глубоко погружаться в работу, если все равно потом вставать и на долго прерываться. На самой встрече выступление человека занимало около пяти минут, потому что это же настоящий скрам(!) и надо доложить о том как идут дела. Вот каждый натужно и выдавал что он сделал вчера.
          В итоге стоишь и просто теряешь время. Особый привкус бесполезно потерянного времени придавало то, что продукт состоял из двух частей, связанных между собой неким API, и мне было абсолютно не интересно что происходит внутри чужой стороны, повлиять я на это все равно не мог, так же как и они на происходящее внутри моей.
          А все проблемы связи между двумя половинками решались вне этих встреч, напрямую между мной и человеком, ответственным за внешний интерфейс.
          Ну и конечно же таски в Джире никто не отменял, так же как и ежедневные отчеты по проделанной работе.
          И да, каждая вторая пятница, а иногда и каждая первая, у той половины команды была не рабочая. Они весело проводили время за большим столом «играя» в скрам-покер и называя это планированием спринта.


          1. powerman
            24.11.2018 13:09
            +2

            Я подтверждаю: чатик и/или 30 секунд на человека.
            Чатик очень удобен тем, что каждый может скинуть свой отчёт когда ему это удобно, а так же в ситуациях когда на митинг не успеваешь.
            30 секунд на человека вполне достаточно, чтобы убедиться, что у всех единое понимание текущих задач и приоритетов, что никто не свернул нечаянно делать что-то не то или не так, плюс проконтролировать, что в команде нет коммуникационных проблем (а-ля когда один ждёт другого, а тот и не в курсе).
            Если на митинге вскрывается проблема, и её не удаётся решить минутным (буквально!) обсуждением — её дальнейшее обсуждение переносится на отдельный митинг, на котором уже присутствуют только те, кого эта проблема реально затрагивает, и на котором уже нет жёстких временных рамок на обсуждение.


            При таком подходе исчезает описанная Вами проблема, когда люди не погружаются в работу из-за того, что ждут начала митинга — описываемый мной вариант митинга не требует ни заметного времени (обычно укладывается в 5 минут), ни траты внимания (если отчёт о вчерашней работе/сегодняшних задачах и проблемах сложный то его проще заранее отправить в чатик и выкинуть из головы). В результате митинг слушается краем уха, и отвлекает от текущей задачи не сильнее, чем не вовремя заданный коллегой вопрос.


            Тем не менее, не смотря на "краем уха" и быстро-формальный процесс — польза от таких митингов есть. Впрочем, я лично их практикую далеко не всегда — если команда небольшая и адекватная, то проблемы, для выявления/решения которых используется этот митинг, проще решать по ходу в чатике, без митингов.


      1. Druu
        25.11.2018 00:42
        +1

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

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


    1. tangro
      25.11.2018 22:06

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

      Вместо это я (скорее всего ещё ДО дейлика) напомню Васе о проблеме, попрошу оценку времени выполнения. Если Вася отреагирует адекватно — буду ждать или предложу помощь, если нет — подключу к обсуждению нашего общего менеджера (да, это тоже лучше, чем мордой в грязь перед всей командой). А потом мы все пойдём на дейлик, где дальше будем рассказывать друг другу сказки.

      Долгосрочная работа в проекте требует предусматривать возможности протягивать людям руку помощи, а также давать им возможность сохранять лицо. Скрам таких возможностей не предусматривает.


      1. ApeCoder
        25.11.2018 22:26

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

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


        1. tangro
          26.11.2018 00:44

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


          1. powerman
            26.11.2018 01:32
            +1

            Сейчас прозвучит непопулярное мнение, но: лучший способ сохранить лицо — делать свою работу хорошо, чтобы не приходилось потом заметать под ковёр недоделки и скрывать потенциально важную информацию от команды (тем более, что скрыть по-настоящему что-то довольно сложно — коммиты-то в репо видят все). А если кто-то делает свою работу плохо, то не стоит помогать ему сохранить лицо — этим Вы только покажете, что его плохая работа Вас полностью устраивает, и он может и дальше работать в том же стиле (а это значит, что если он работает меньше, то всем остальным либо придётся работать больше, либо огребать за его факапы всей командой).


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


            Если в ответ на мою честность кто-то перевозбудится, и полезет с претензиями — он пойдёт лесом, потому что во-первых я всё это говорил не для того, чтобы меня в ответ покритиковали, а чтобы у команды было корректное понимание текущего состояния проекта, и во-вторых — не нравится как я работаю — сначала сделай лучше (или найди того, кто сделает лучше — если претензии высказывает менеджер), а потом вернёмся к вопросу критики.


            Но обычно ничего такого не происходит, все реагируют вполне адекватно — либо просто принимают к сведению, либо поднимают вопрос что нужно поправить в наших процессах чтобы такие проблемы в будущем не повторялись. Собственно, именно в этом смысл отчёта о текущем прогрессе и проблемах.


            Если Вам так принципиально сохранить Васю в команде, при том, что он не в состоянии ни работу нормально делать, ни честно об этом рассказывать… что тут скажешь, бывает, может у Вас с ним любовь — тогда работайте и за себя и за него, делая двойной объём работы за то же время, потому что из-за Вашей любви к Васе остальная команда и проект страдать, по-хорошему, не должны. Если более реалистично — нужно перестать грузить Васю работой, с которой он не справляется, и подобрать ему такие задачи, с которыми он будет справляться… но чтобы это сделать сначала нужно выяснить, что он не справляется с текущими задачами, а вы с ним, пытаясь сохранить ему лицо, эту информацию скрываете, и тем самым закапываете его ещё глубже.


            1. tangro
              26.11.2018 11:22

              Разные бывают ситуации. Если рассматривать вариант «меня бросили на проект с незнакомой командой и надо его сдать за 2 месяца и уйти» — то да, я буду тыкать пальцем в раздолбаев, поскольку проект важен, а раздолбаи — нет. Если же речь идёт о идущем годами аутсорс-проекте или работе в продуктовой компании, то тут человеческие отношения выступают на первый план. Вам с этими людьми работать и завтра, и через год. Поэтому хорошие отношения в команде стратегически дают больше пользы (и вам, и проекту), чем истерика по поводу затянутого на пару часов выполнения текущей задачи.


              1. powerman
                26.11.2018 13:08

                Я с этим и не спорил. Люди важнее. Но это вовсе не означает, что они могут творить вообще любую фигню, а окружающие должны им в этом помогать.


                Если есть проблема — можно помочь человеку её решить, и вовсе не обязательно сопровождать эту помощь моральными издевательствами в процессе. Но чтобы проблему решить — сначала её надо выявить и признать. Ваш подход "сохранить лицо" направлен на противоположное — сопротивляться выявлению и признанию проблемы. Говоря проще — я считаю что Ваши действия в этой ситуации больше всего вредят самому Васе. Не обижать людей из-за каких-то мелких текущих проблем с очередным проектом — это абсолютно правильно. Закапывать проблемы, пусть даже мелкие и относящиеся только к текущему проекту — не правильно.


                Если у Васи серьёзные проблемы с психикой (или он вырос в Японии, например, и ещё не адаптировался в нашей культуре), и публичное признание своих проблем для него категорически неприемлемо, и приведёт к гораздо худшим проблемам в его жизни и/или работе, чем сейчас — то проблемой является именно этот факт, и Васю нужно или переводить на другую работу (где не будет скрама), или отправлять к психологу решать эту проблему.


      1. Fesor
        26.11.2018 02:24

        > Скрам таких возможностей не предусматривает.

        Простите, а чего вы ожидали? Скрам — это вам не детально проработанный процесс, это фреймворк на базе которого вы должны выстраивать свои процессы. Он вам дает основу для ведения итеративной разработки. Дальше уж извольте додумывать процессы самостоятельно, для этого вам даются ретроспективы. Хотите инструмент для выявления проблем — добавьте к скраму канбан (ограничения на колонки) и многие проблемы будут вылазить сами по себе. Опять же если команда будет соблюдать выбранные ограничения.

        Ну и опять же — у вас поквартальное планирование, вы не собираете фидбэк после каждой итерации, вы не анализируете приносит ли функционал ценности? Может вам вовсе не нужен скрам?

        Описанная же вами ситуация — это исключительно про взаимодействие людей в команде. Ибо в целом так смысла в дэйли нету, если все вопросы можно тэт-а-тэт порешать. Скрам у вас, XP, FDD или RUP — проблема остается.

        Если вы спросите у Васи на дэйли в чем проблема, то это ни сколечки не «обмакнет» его в глазах команды. Всегда будут люди, которые будут до последнего пытаться решить проблемы своими силами. Скрам или не скрам — климат вы выстраиваете тот который выстраиваете, выбранный фреймворк для ваших процессов на это не влияет (не должен влиять)


        1. tangro
          26.11.2018 11:27

          Скрам — это вам не детально проработанный процесс

          Ох, как я люблю этот аргумент. В каждом первом проекте по скраму получается одно из двух: если проект удался — «ну, это потому, что скрам!», если не удался — «ну, это потому, что скрам это не детально проработанный процесс, нужно выстраивать процессы, ля-ля-ля». С тем же успехом можно предложить методологию разработки «писать код ночью голым в лесу при полной луне» — и точно так же можно будет объяснять успешные результаты — следованию методологии, а провалы — тем, что «ну, процессы были неправильно выстроены».


          1. Fesor
            26.11.2018 12:45

            В каждом первом проекте по скраму получается одно из двух

            Заметили ли вы что обычно когда все идет хорошо процессы хвалят те кто их внедрял, а в случае неудачи ругают те кто по ним работал? Если да — тогда наша статистика в целом совпадает (такая же у меня например в случае с kanban)


            Но все же, повторюсь. Описанная вами ситуация будет воспроизводиться и в случае с каким-нибудь RUP, как минимум потому что речь идет о проблема коммуникаций между людьми в рамках одной задачи. Ну то есть я не понимаю почему для вас спросить на дэйли у человека в чем проблема и как ему помочь — это мокнуть его перед командой.


            можно будет объяснять успешные результаты

            главное не попасться в классическую ошибку выжевшего.


            p.s. если что, я не особо люблю скрам, в основном потому что обычно его применяют бездумно и просто так, мне больше по душе какой-нибудь канбан или FDD. Но менеджмент обычно даже не вкурсе про существование чего-бы то ни было еще помимо скрама.


  1. powerman
    24.11.2018 04:57

    Почитал комментарии… странно. У меня сложилось прямо противоположное впечатление: статья токсична, автор толком не понимает ни скрам ни аджайл, описанные проблемы либо надуманы, либо невероятно утрированы, либо проистекают от непонимания методологий, и я дико сочувствую компании, которая наймёт автора на должность "не ниже директорской".


    Но, судя по другим комментариям, существуют очень разные "заповедники".
    Автору и многим комментаторам явно не повезло попасть в один тип заповедников, в котором скрам внедрили без понимания его смысла и сути, а точнее в попытке натянуть "сову на глобус" — применить технические приёмы скрама для исполнения мечты многих менеджеров о превращении неуправляемых творческих программистов в винтики конвейера.
    А мне повезло попадать в другой тип заповедников, где скрам или канбан применяются для облегчения жизни и программистов и менеджеров, причём ровно в том объёме, в котором вред от них не начинает перевешивать пользу.


    Чисто для примера, на моих проектах применение методологий схематично выглядит примерно таким образом:


    • Начинается всё со стадии проектирования, обычно включающей бизнес-анализ, архитектуру, возможно R&D и/или мелкого прототипирования по самым сомнительным элементам. В лучших традициях… водопада. Точнее, водопадика. Очень маленького такого, не страшного. Маленького потому, что эта часть работы изначально и принципиально ограничена небольшим объёмом — у этой стадии на выходе принятые решения и документы (крайне редко — алгоритмы и кусочки кода), причём только те, которые нет возможности отложить на потом без явного ущерба для архитектуры проекта. Если для проекта подходит микросервисная архитектура, то сначала эта стадия выполняется для всего проекта в целом, чтобы определить какие микросервисы нужны, а потом повторяется для каждого микросервиса. Получается кучка небольших водопадов, которые не отбирают так уж много времени, неплохо распараллеливаются, и очень положительно сказываются на дальнейшем развитии проекта.
    • Дальше обычно начинается работа по простому канбану, чтобы избежать траты ресурсов на более тяжёлый скрам и просто посмотреть, какие у нас типы задач, как команда их выполняет, какие возникают проблемы.
    • Используя данные, полученные за пару-тройку недель простого канбана, дальше разделяем задачи и/или команды на разные группы: кто-то остаётся на простом канбане, кому-то канбан делаем чуть более навороченный/формализованный, кого-то переводим на скрам.
    • Если в процессе разработки, с учётом аджайла, вносимые на ходу изменения начинают разваливать изначальную архитектуру проекта — происходит частичный возврат на первую стадию с водопадом. Частичный — по двум причинам. Первая: обычно к этому моменту полно задач, которые можно продолжать пилить, потому что уточнение и переработка архитектуры не повлияет на необходимость сделать эти задачи. Вторая: при использовании микросервисов требуемые изменения архитектуры обычно затрагивают относительно небольшую часть микросервисов, и разработка остальных может продолжаться.

    Иными словами, методология подбирается под специфику задач и команд, и на одном проекте нередко используются разные методологии для разных этапов и задач/команд.


    Я вообще себе не могу представить разработку архитектуры, R&D или админские/devops задачи по скраму. Для админских задач канбан отлично подходит, а архитектуру и R&D можно формально маскировать под канбан (просто чтобы не морочиться с настройкой JIRA под ещё один тип проектов), но по сути там будет происходить небольшой водопадик. С другой стороны, когда уже понятно что и как делать, и надо тупо пилить код, причём так, чтобы сроки были управляемыми — скрам идеально подходит.


    При таком подходе все методологии находятся на своих местах, и облегчают жизнь всем, и программистам и менеджерам. А то, что предлагает автор вместо этих методологий, для меня звучит как "я нежный творческий гений, оставьте меня в покое, не указывайте мне что и как делать, и когда-нибудь я вам выкачу гениальное решение, которое принесёт компании много денег". Скажу честно, автору около тридцати лет, а у меня опыта работы около тридцати лет… да, для опытного разработчика вроде меня такой подход даже может иметь смысл, и мне работать в таком стиле приятнее, и, если повезёт, действительно можно получить обещанный результат, и ждать его придётся вовсе не вечность. Хотя стоп, о чём это я размечтался? Такое работало, очень давно. Когда один-два человека ещё вполне могли сделать серьёзный продукт. На работу команды этот подход не масштабируется, вообще никак. На постоянно меняющиеся требования со стороны бизнеса этот подход тоже не масштабируется. Вывод: чтобы это сработало нужно писать небольшой проект, который реально сделать парой человек, и заказчиком которого являешься ты сам. А в остальных случаях пока ничего лучше аджайла пока не придумали… а недостатки аджайла надо уметь обходить, применяя разные его варианты в разных ситуациях.


    1. vintage
      24.11.2018 07:15

      автор толком не понимает ни скрам ни аджайл

      А кто-нибудь вообще понимает? Мои наблюдения показывают, что каждый (даже "сертифицированный эджайл/скрам/бан специалист") понимает под этим что-то своё и свято уверен, что все остальные ни черта не умеют в правоверный скрам. Я, конечно, верю, что где-то есть заповедники, где всё хорошо, но в подавляющем большинстве мест, где внедряют скрам, творится форменный карго-культ.


      Например, в одной компании собрали "скрам команду" из фронта, пары бэков, тестера и оунера. Коучили её 2 недели. Всё по заветам. Вроде бы правильные вещи декларируются. Начинаем работать и выясняется:


      1. Без коуча всё разваливается и не работает. Без единого начальника команда не самоорганизуется, а начинает перетягивание одеяла в разные стороны. Кто как понял, тот за то и топит.
      2. Даже если кому-то и удастся захватить лидерство, убедив, что у него больше опыта/знаний, то он будет таковым даже в областях, в которых не компетентен.
      3. Кроссфункциональных людей не бывает. Кто-то ас в одном и профан в другом, кто-то наоборот. А эффект Даннинга-Крюгера часто не даёт признать другого более компетентным. Даже если специально прокачивать всех во всех областях — у всех разные способности и интересы.
      4. Так как у каждого по факту своя специализация, то общая компетентность команды определяется некомпетентностью большинства. Так как все "типа кроссфункциональные", то каждый имеет равное право голоса. А при демократии принимается не самое лучшее решение, а наиболее популярное. Например, если вы фронтендер и способны с закрытыми глазами писать компактные и поддерживаемые стили, то будьте готовы, что большинство, которое во фронтенде умеет лишь теги расставлять, продавит какой-нибудь твиттер бутстрап, который вы замучаетесь кастомизировать.
      5. Да-да, декларируемый коммитмент, либо скатывается в голосование большинством, либо приводит к ступору разработки из-за постоянных дебатов и в конечном счёте развалу команды.
      6. В команде у вас могут оказаться вовсе не те люди, что действительно нужны проекту. Например, если для проекта оптимальнее было бы разрабатывать на ноде и шарить часть логики между клиентом и сервером, но в команде у вас оказалось 2 пхп-шника, убеждённых, что нода сырая и ничего не умеет, потому что год назад они попробовали и что-то там не срослось, то будьте готовы к тому, что при выборе платформы именно пхп окажется оптимальным решением по всем показателям. Вместо пхп можно подставить яву, дотнет, что угодно.

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


      1. Druu
        24.11.2018 08:47
        +1

        А какое отношение все вами описанное имеет к аджайлу? То есть ну вот, например: "В команде у вас могут оказаться вовсе не те люди, что действительно нужны проекту" — поставили вы не тех людей на проект, аджайл-то как виноват?


        1. sshikov
          24.11.2018 11:00

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


          1. Fesor
            26.11.2018 02:49

            Я обычно наблюдаю чуть другое. Вот услышал кто-то из менеджеров про скрам (потому что в целом, если быть честными, про другие фреймворки как-то не очень слышно, если не искать), прочитал пару статей про то как скрам позволяет делать больше теми же силами и решил что «ништяк, надо вводить!»

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

            ну то есть если компания вводит аджайл — она часто вводит его весьма избирательно. То что вся эта хрень с короткими итерациями и быстрым фидбэком для минимизации рисков (мы инвестируем чуть-чуть в разработку самого ценного из фичи что бы быстро узнать стоит ли продолжать и будут ли фичей пользоваться), и что это подразумевает кординальные изменения на уровне всей организации.

            Особенно радуют аутсорс компании которые практикуют скрам. Как правило у них SoW подписан на пол года работы, фиксированный бюджет и коммитменты по функционалу, но всем говорят что они аджайл.


        1. napa3um
          24.11.2018 11:06

          В каком-то смысле — виноват, он накладывает дополнительные (явные и неявные) ограничения на возможные темпераменты членов команды и их «софт-скиллс». Люди, как правило, на проект поставлены до того, как их пытаются «отскрамить», и решение это спускается для них «сверху», а не рождается естественная потребность и понимание «изнутри» своих проблем.

          Скрам как продукт у нас сейчас продаётся в формате таблеток от болезней, в наличии которых коуч должен убедить клиента (топ-менеджера, который вряд ли вообще знаком с людьми, для которых он этот скрам покупает). Претензии, скорее, не к скраму как концепции, а к опошлению рыночных механизмов его распространения, превращающих его в культ карго, набор «игр в офисную работу». Всех накормим анальгином, даже если голова у тебя никогда не болела!


          1. Fesor
            26.11.2018 02:54

            и решение это спускается для них «сверху»

            Меняется ли для команды процесс формирования бэклога?


            Скрам как продукт у нас сейчас продаётся в формате таблеток от болезней

            У Дэйва Томаса (один из авторов agile manifesto) есть доклад на эту тему — Agile is dead. Ну и есть очень неплохая постановка на тему типичных скрам коучей: A Retake on the Agile Manifesto • Humble, Thomas, Badiceanu, Fowler & Kirk


            1. napa3um
              26.11.2018 02:56

              Вам лучше бы было как-то более явно выразить свою мысль (видимо, возражение моему комментарию?), а не отсылать просматривать просторы интернета в попытках понять, что именно вы имеете ввиду и на чём ставите акценты.

              Манифестами и прочими теориями я обмазан изрядно, и, в целом, не против скрама как такового, и у меня есть вполне себе примеры его эффективного использования. Но это были стартапные команды не более 10-ти человек, которые и составляли контору, которые и сами себя организовывали по заветам скрама, понимая друг друга и доверяя друг другу, и целесообразно забивали на качество продукта (чтобы быстрее выйти на рынок). И это были редкие случаи подходящего, на мой взгляд, применения скрама (сработанная заранее команда + стартапные критерии эффективности, которые вовсе не о стабильности конечного продукта и процессов его рождения).

              В «больших» же конторах я не видел скрама, который бы не был карго-культом, практически ни разу. Люди спорят о том, как считать сторипоинты, как сортировать приоритеты, сколько недель должен быть спринт, но совершенно не понимают, ради чего и чем отличаются варианты друг от друга. Потому что разрабатывают не «свой» продукт, и, как правильно отмечено в статье, прозрачность поэтому в больших конторах получается большей частью односторонняя, и по вполне объективным причинам это для большой конторы полезно (хоть и не очень приятно для конкретных исполнителей). Главное только скрамом не сломать эффективную иерархию распределения управляющей информации.


              1. Fesor
                26.11.2018 12:38

                > Вам лучше бы было как-то более явно выразить свою мысль

                Мысли не было — был вопрос на который вы не ответили. От ответа на него будет зависеть то как я буду раскрывать мысль дальше.

                От того откуда приходят требования и как происходит проверка эффективности фич (и происходит ли вообще) зависит взлетит скрам или нет. Причем тут речь не только про скрам — любой итеративный подход.

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


        1. vintage
          26.11.2018 11:26

          Не виноват, его просто нет. Если вы наняли (намеренно или ненамеренно) команду состоящую из одних (или хотя бы большинства) ангулярщиков (или даже бутстрапонгриксников), то проект ваш будет на ангуляре (+bootstrap +ngrx соответственно), даже если оно для данного проекта совершенно не подходит. Однородная команда просто не сможет самостоятельно, без внешней силы выйти из зоны комфорта исходя из целей бизнеса. И всех новичков будет либо "форматировать" под себя, либо "отлучать".


      1. powerman
        24.11.2018 12:50

        А кто-нибудь вообще понимает?

        Да. Хотя людей, которые действительно понимают именно суть, и способны её донести — очень мало. Я пока нашёл ровно одного такого человека. К сожалению, у него в основном видео, поэтому времени на просмотр уйдёт некоторое количество, но оно того стоит. Именно благодаря его объяснениям я понял, что было не так с наблюдаемыми мной попытками внедрения аджайла в разных проектах и как это делать правильно, чтобы вместо страданий это приносило облегчение работы.


        Для тех, кто вообще не в теме, или просто окончательно запутался в разных вариантах аджайла, есть неплохая маленькая статья — введение в скрам и канбан, основные принципы и отличия: Разбираемся в Scrum и Kanban.
        Человек, о котором я писал выше — это Алексей Пименов pimenaus. К сожалению, он явно предпочитает формат живого общения, так что мне не удалось найти альтернативу его выступлениям на конференциях в виде статей. Зато его выступления посмотреть однозначно стоит! К сожалению, у меня нет списка его выступлений, которые можно было бы рекомендовать в конкретном порядке — когда я его нашёл, то смотрел все его выступления двое суток подряд (причём надо отметить, что я видео смотреть вообще не люблю, для меня это слишком медленный способ получения информации), пока в какой-то момент голове не сложилась полноценная картина про скрам и канбан на уровне, когда я стал в состоянии адекватно сам их объяснять другим. Если не путаю, то первое его видео, которое мне попалось и "зацепило", было Минимальная правильная Scrum-конфигурация Jira.


        1. evocatus
          25.11.2018 04:59
          +2

          Смотрю начало лекции Пименова «Введение в Agile». Ощущения такие: «2000 лет назад Иисус произнёс Нагорную проповедь. А теперь к свечкам: есть по 10 рублей и по 20 рублей, а ещё красные, но они только на Пасху, о них позже»

          Мне больше всего нравится вот это видео:
          www.youtube.com/watch?v=HZyRQ8Uhhmk


          1. powerman
            25.11.2018 12:35
            +1

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


            Именно по этой причине я убил два дня на просмотр — Пименов реально понимает эти методологии, и поэтому может объяснить как и почему именно так надо делать в любой конкретной ситуации. Чтобы из этого потока конкретных, практических примеров вытащить общее понимание методологии (из которого исходит он сам) — нужно проанализировать достаточное количество этих примеров.


            Такое реверз-инженеринг сути из конкретных примеров применения сложно назвать эффективным способом обучения. Проблема в том, что я лично ничего лучше просто не нашёл — большинство тех, кто пишет про эти методологии, сами их суть либо не понимают, либо не в состоянии её объяснить другим.


            1. evocatus
              25.11.2018 16:38
              +4

              Я давно слежу за дискуссией по поводу Agile (с тех пор как она вообще появилась в Рунете, наверное), смотрю западные презентации иногда, читаю статьи с восхвалениями, проклятиями, рекомендациями… Возникло несколько мыслей

              1) Сейчас будет второй и последний раз когда я употребляю в этом комментарии слово «гибкий» с большой буквы и по-английски. Я полностью согласен с Allen Holub в том, что главная беда в том, что люди хотят Agile®. А это просто прилагательное. Как быть гибкими в разработке? И, главное, зачем?

              2) Похоже, что Allen Holub прав ещё в одном: гибкая методология разработки подходит только для взрослых, ответственных и профессиональных людей. Для другого контингента всё очень быстро деградирует в карго-культ или очередной способ имитировать бурную деятельность. Гибкость подразумевает то, что мы идём от задачи и постоянно переосмысливаем свои практики разработки точно также, как постоянно переосмысливаем ТЗ путём постоянного контакта с заказчиком (если он есть, если ему есть что сказать и т.д.).

              3) Автор статьи, которую мы здесь все обсуждаем, похоже, прав в том, что гибкие методологии в чистом виде применимы на довольно узкой категории проектов, а в остальных случаях следует сконструировать свою гибкую методологию с нуля, ориентируясь на ценности Манифеста гибкой разработки ПО.

              В Манифесте есть отличная фраза:

              Люди и взаимодействие важнее процессов и инструментов
              — грубейшим образом нарушается: люди никого не волнуют, все делаем Scrum как написано в книжке.

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

              На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
              — представители бизнеса в смысле представители конечных пользователей программы. Это идея об уничтожении промежуточного менеджмента как испорченного телефона и источника идиотизма в принятии решений.

              Над проектом должны работать мотивированные профессионалы. Чтобы
              работа была сделана, создайте условия, обеспечьте поддержку и полностью
              доверьтесь им
              .
              — А? Что? Нет, нет, нет. Мы будем нанимать джунов, не будем их систематически обучать, будем смешивать их с профессионалами, а доверять не будем никому — каждый будет исповедоваться каждый день, а мы будем всем рассказывать какие задачи делать, за какое время и каким образом, притом гораздо подробнее, чем это было раньше.

              Непосредственное общение является наиболее практичным и эффективным
              способом обмена информацией как с самой командой, так и внутри команды.
              — это значит «избегать совещаний». Это значит «нет менеджеров». Горизонтальное общение.

              Работающий продукт — основной показатель прогресса.
              — А как же спринты? Стендапы? Чарты?

              Инвесторы, разработчики и пользователи должны иметь возможность
              поддерживать постоянный ритм бесконечно. Гибкие процессы разработки продвигают устойчивую разработку.
              — БЕСКОНЕЧНО. Это значит, что технический долг как минимум не должен расти

              Постоянное внимание к техническому совершенству и качеству
              проектирования повышает гибкость проекта.
              Проектирование? А мы думали это уже не модно и архитектура сама появится как человек из водоросли (правда за пару месяцев).

              Простота — искусство минимизации лишней работы — крайне необходима.
              Да как вы смеете? То, что мы тратим 10% рабочего времени на игру в покер, ежедневные минисовещания, а каждые две недели по целому рабочему дню — это не лишняя работа, это нужно.

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

              Команда должна систематически анализировать возможные способы
              улучшения эффективности и соответственно корректировать
              стиль своей работы.
              — нет, у нас Scrum по книжке и точка.

              Завершить хочется вот этой серией твитов:
              «Великая ирония scrum и agile в том, что они были созданы инженерами, которые хотели завоевать независимость решая самим как работать, а сейчас в основном используются менеджерами для установления своего контроля, создавая для подчинённых инженеров иллюзию независимости»


              1. powerman
                25.11.2018 17:14

                … подходит только для взрослых, ответственных и профессиональных людей. Для другого контингента всё очень быстро деградирует в карго-культ или очередной способ имитировать бурную деятельность.

                Так можно сказать практически про всё, аджайл просто не является исключением, и его сложно за это винить.


                … методологии в чистом виде применимы на довольно узкой категории проектов, а в остальных случаях следует сконструировать свою

                И это можно сказать про абсолютно любую методологию, ибо серебряной пули нет.


                все делаем Scrum как написано в книжке

                Потому что для того, чтобы делать как-то иначе, нужно быть в состоянии самому писать такие книжки — т.е. понимать суть и уметь адаптировать методологию в соответствии с текущей командой и проектом. Людей, которые на такое способны — очень мало.


                почему все вокруг с ума сошли на двух неделях?

                Насчёт всех — не знаю. Но я знаю, что чем чаще релизы — тем лучше. Из личного опыта, когда команду вёл я, то я вообще задал размер спринта в одну неделю. Основной недостаток — менеджерская нагрузка на меня была заметно выше, чем при двухнедельных спринтах, но на проекте это сказывалось положительно. Когда я передал этот процесс другому — он сделал двухнедельные спринты, и, я практически уверен, руководствовался при этом вовсе не пользой для проекта, а просто пытался уменьшить нагрузку лично на себя.


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


                Мы вам самоорганизуемся, анархисты проклятые. Всё будет проходить так как сказал Product Owner.

                Ну, вообще-то PO является частью команды, и его мнение в отношении приоретизации задач является не менее экспертным, чем мнение разработчика о необходимости рефакторинга какого-то модуля системы. И самоорганизация здесь означает, что PO и разработчик должны уметь договариваться, чтобы и фичи и рефакторинг делались своевременно. Проблемы здесь, по моим наблюдениям, чаще возникают из-за того, что у разработчиков плохо с софт-скилами, и они просто не в состоянии объяснить важность технических проблем PO на понятном ему, не техническом, языке.


                С остальным, в общем-то, согласен.


          1. Fesor
            26.11.2018 02:56

            Пока из всего что мною было прочитано и просмотрено лидирует вот это: Surviving Your Inevitable Agile Transition — J.B. Rainsberger — сухо, никакого популизма.


            Что до Холуба — мне версия Дэйва Томаса нравится больше.


      1. staticlab
        24.11.2018 13:29

        Кроссфункциональных людей не бывает.

        Кроссфункциональной должна быть команда, а не участник. Задумано это с целью снижения количества внешних зависимостей.


      1. emacsway
        24.11.2018 18:33

        А кто-нибудь вообще понимает?

        Я с вами полностью согласен. Основная причина неработающего 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 года стоимость изменения программы возрастает настолько, что дальнейшее развитие проекта становится нерентабельным, и приходится прибегать к радикальным действиям (эмиссия акций, замена руководства, закрытие проекта, сокращение штата и т.п.).

        Очень тяжело сделать развернутый ответ в краткой форме, поэтому, я думаю что приведенная мною выше ссылка ответит на все, что я упустил.


        1. vintage
          26.11.2018 10:38

          Да нет, всё люди прекрасно понимают. На любом скрам коучинге вам расскажут, что "скрам — это фреймворк, а вот те другие, просто не понимают этого". Существуют ли эти "другие"? Сомнительно. И не смотря что заявляется гибкость, многие люди чисто психологически не способны быть гибкими. Они просто не так воспитаны. И никакая методология им эту гибкость не даст. А с такими людьми гибкость возможна в основном через ритуалы (яркий представитель — канбан с его "я не могу взять в работу задачу, так как у меня уже 3 висяка") или подчинение ("начальника сказала забить на это и срочно пилить то"). Осознанно ставить себе ограничения и в зависимости от приоритетов их же нарушать — не каждый способен без конфликта в сознании.


          И честно сказать, я так и не понял на что и зачем вы отвечали. Процитированный мой вопрос — просто риторический, вводная для описания наблюдаемых мною явлений.


      1. babylon
        24.11.2018 19:09

        Лично для меня бутстрап показался наиболее легким в кастомизации чем всё, что было до него. Ну да флексбокс это больше про лейаут, но я в глаза не видел ни одного фреймворка, где бы лейаут удачно сочетался с иерархией элементов. И никого это не парит. Была надежда на флеш, но флеш не выжил. Всё, что осталось болтается в рекламе.


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


        1. vintage
          26.11.2018 11:04

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


          Не совсем так. В каждой области деятельности должен быть эксперт, который на основании своего опыта и знаний может сказать, грубо говоря, что хорошо, а что не очень. Но часто бывает ситуация, когда начальником (или лидером, как в скраме, что не сильно отличается по сути, лишь формально) становится человек, который пытается принимать решения в той области, в которой не компетентен. Это ведёт разработку этой части проекта под откос, вымывает из него (а то и вообще из компании) хороших специалистов, оставляя лишь посредственностей, что ещё печальней сказывается на проекте.


      1. ApeCoder
        25.11.2018 22:22

        А кто-нибудь вообще понимает?

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


        Если он не хочет этим заморачиваться, то для меня он — трепло, которое не знает о чем говорит, а делает вид, что знает.


        1. vintage
          26.11.2018 11:12

          Ссылки на священное писание — ну такая себе гибкость.


    1. AZaz1
      24.11.2018 15:02

      давайте уточним к кому идеально подходит?
      позвольте я отвечу? :)
      он идеально подходит управленцам но не исполнителям, а если мы пытаемся выстроить процесс, то тут нужно как и любви — взаимность — иначе без нее просто механика — секс! :)


      1. powerman
        24.11.2018 15:38

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


        Я обычно участвую во всех этих типах работ, потому что, с одной стороны, квалификации достаточно чтобы выполнять большую часть ролей (PM, бизнес-аналитика, архитектора, разработчика, devops, сисадмина), а с другой, как фрилансеру, часто приходится совмещать разные комбинации ролей, потому что размер и компетенция команд на разных проектах сильно отличается, и нужно "затыкать дыры".


        Так вот. Да, мне больше нравятся сложные, творческие задачи, на которых меня не сильно ограничивают временными рамками. (Кто бы мог подумать, да?) Тем не менее, нужно сделать и все остальные задачи, включая простые, относительно механические, и не особо интересные. Радости они доставляют мало, но вот в чём фишка — "идеально подходящий" под такие задачи скрам заметно скрашивает работу над такими задачами. Скрам даёт размеренный ритм, само наличие которого оказывает поддержку (примерно как барабаны для гребцов), даёт понимание что поток этих скучных задачек не вечен и более-менее реалистичную оценку сколько времени уйдёт чтобы их сделать, даёт регулярные положительные подкрепления когда результат двухнедельной работы релизится, даёт защиту списка ближайших задач от внезапных изменений. Иными словами, скрам не делает скучные задачки более интересными, но он делает процесс реализации этих задач более простым, наглядным и уменьшающим стресс — и для менеджеров, и для исполнителей.


        1. AZaz1
          24.11.2018 15:48

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


          1. powerman
            24.11.2018 15:59

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


            1. AZaz1
              24.11.2018 16:03

              в самой методологии есть некоторые полезные идеи, но к сожалению как и везде специалистов в данной сфере — единицы, а все остальные адепты — любители которые следуют буква в букву какой-либо и прочитанных статей в инете и не понимают что и зачем да им на это и времени и сил не хватает, поэтому используют рекомендации как инструкцию и магию которая должна что-то там улучшить! )


          1. Windev
            25.11.2018 11:48

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


            1. vintage
              26.11.2018 11:58

              Часто задачи сложно оценить не потому, что они большие, а просто потому, что их сложно оценить. Какой-нибудь простой баг может потребовать неделю только лишь для того, чтобы понять в чём вообще проблема. У меня был такой случай. При этом я сразу сказал, что у меня нет компетенций ни для решения этой проблемы, ни даже для её понимания. Но проблема воспроизводилась ведь лишь на моей ветке, а значит я "накосячил, а потом неделю ничего не делал". Как потом выяснилось, если интересно, проблема была в том, что другая команда, что поддерживает репозиторий пакетов, втихую изменила настройки авторизации, сделав её обязательной для всего, из-за чего на самом деле сломались все ветки, но они продолжали собираться, так как пакеты для них уже были выкачаны ранее и брались из локального кеша, а настройки мавена/гредла (в которых я ни бум-бум, как и вообще в яве) или их плагины для npm написаны были так, что авторизация подцеплялась то ли асинхронно, то ли слишком поздно. Столько проблем из-за того, что кто-то решил, что использовать яву для сборки фронтенда — хорошая идея, а потом копипастил всё это из проекта в проект.


              1. powerman
                26.11.2018 13:19

                Это правда, но с этим тоже можно работать: такие задачи надо оценивать итеративно. Сначала оцениваем баг в пару часов. Через пару часов смотрим: если по-прежнему ничего неясно и видимого прогресса за эти два часа не было вообще — переоцениваем его в пару дней. Если за пару дней тоже прогресса почти нет — либо переоцениваем его в неделю либо переназначаем на более квалифицированного или имеющего экспертизу в конкретно этой области коллегу. После каждой переоценки баг возвращается в бэклог, чтобы PO имел возможность контролировать его приоритет в соответствии с изменяющейся оценкой.


    1. Amokmorg
      25.11.2018 11:48
      -4

      это очередной «сумеречный гений» писал, который любит сидеть в уголке один и кодить, кодить, кодить, и главное что бы никто не мешал. но на выходе в 99% выйдет никому ненужное гавно. печально, что на хабре до сих пор такой колхоз пользуется популярностью


  1. sved
    24.11.2018 06:26

    Интересно а много ли людей рассуждающих о «водопаде» реально видели его в реальной жизни?
    Если я не ошибаюсь само понятие водопад появилось как пример подхода из строительной области который никогда не будет работать в разработке ПО.
    Возможно водопад реально используется где в разработке авиационного ПО.
    Я лично в своей карьере его ни разу не встречал


    1. ryo_oh_ki
      24.11.2018 08:00

      Действительно, очень часто люди вообще не знают, что такое «водопад», и представляют реальный водопад с его односторонним движением. Хотя даже Ройс (чья публикация предположительно впервые описывает его) предполагал итеративную природу разработки, т.е.возвращение на предыдущий шаг разработки при выявлении недостатков в текущем. «Водопад» скорее описывает общие этапы разработки ПО, не вдаваясь в подробности технологии итераций, как 7-уровневая модель OSI описывает общие принципы сетевых стеков, не вдаваясь в подробности устройства маршрутизаторов, например. Так что Agile — это формализация итераций в общей схеме «водопада».


      1. powerman
        24.11.2018 13:34
        +1

        Так что Agile — это формализация итераций в общей схеме «водопада».

        Нет! Вы бы хоть в вики заглянули сначала: Каскадная модель. Если кратко, то суть водопада в том, что следующий этап не начинается, пока не выполнен предыдущий. Это не противоречит возвращению на предыдущие этапы, если на следующих стало понятно, что на предыдущем что-то упустили. Типичный пример — тестирование не начинается пока продукт не готов целиком. В условиях, когда что такое "продукт целиком" никто толком не понимает и определение этого понятия непрерывно меняется — водопад требует неприемлемо много времени, значительная часть которого уходит на тщательное проектирование, разработку и тестирование функционала, который вообще не попадёт в финальный продукт.


        В отличие от водопада, который не пускает нас вперёд, к следующим стадиям, аджайл наоборот, направлен на максимально быстрое достижение последней стадии (релиза), ценой пропуска всего, что только можно на предыдущих стадиях (включая сбор полных требований, детальное проектирование, поддержку крайних случаев при реализации, …) и распараллеливания этих стадий. Качество всех стадий при этом сильно страдает, но зато появляется возможность намного быстрее понять, что такое "продукт целиком", плюс практически одновременно с этим пониманием получить готовую реализацию этого продукта, пусть и с сомнительным качеством, но работающую.


        Учитывая, что высокое качество, равно как и уменьшение тех.долга, бизнесу зачастую не нужны (по крайней мере на этапе создания начального продукта и попытки продавить его на рынок) — в абсолютном большинстве компаний аджайл поставил водопад на колени и жестоко убил, как всегда делает любое добро с любым злом.


        1. ryo_oh_ki
          24.11.2018 15:07

          Если кратко, то суть водопада в том, что следующий этап не начинается, пока не выполнен предыдущий
          Что совершенно верно и в отношении к Agile. Ведь невозможно начать тестирование, если тестировать нечего. Это ограничение не является искусственным правилом Waterfall, а является причинно-следственной связью указанных стадий работы. И никто не запрещает при нахождении бага при тестировании вернуться к ранним этапам проектирования исключительно в своей голове, продумать новый механизм, тут же написать код, и снова запустить тесты. Относитесь к технологии как к инструменту, а не как к священному писанию!


          1. powerman
            24.11.2018 16:06

            Ведь невозможно начать тестирование, если тестировать нечего.

            Вы ничего не слышали про TDD? Ну ладно, TDD это крайний случай, и речь не о нём.


            Суть водопада в том, что тестирование не начинается пока продукт не будет готов целиком. А в аджайле тестирование выполняется по мере разработки отдельных фич/задач. В скраме оно начинается либо одновременно с разработкой (TDD), либо (чаще всего) через несколько дней после начала разработки (чтобы к завершению спринта фича была не только написана, но и протестирована), либо (в самом крайнем случае) на следующем спринте тестируются фичи реализованные на предыдущем. В канбане ещё проще — все задачи перемещаются из колонки "in progress" в колонку "testing" перед тем, как попасть в колонку "done".


            1. ryo_oh_ki
              25.11.2018 07:54

              Я знаю что такое TDD, и это не крайний случай, а обычная программная технология, если стоимость ошибки очень велика, по разным причинам, включая, недавно обсуждаемый здесь отвратительный дизайн наследного кода (забавная причина).

              Суть водопада в том, что тестирование не начинается пока продукт не будет готов целиком.


              В реальном мире такого не бывает, даже если это описано в таком «непогрешимом источнике» как википедия. Такое ощущение, что вы никогда не работали в формате НИОКР, характерном для российских госпредприятий и наукоёмких областях. Все эти ТЗ, ЧТЗ, ТП, дополнения к ним (по результатам разработки или опытной эксплуатации), модели, стенды, опытные образцы. Так вот, модель waterfall является хорошим формальным приближением такого способа разработки.


            1. sshikov
              25.11.2018 18:15

              >тестирование не начинается пока продукт не готов целиком.

              Да ктож вам сказал такую ерунду? Только не надо ссылаться на википедию, а давайте лучше про реальность. Я вот за много лет никогда не видел такого, чтобы тестировщики сидели и ждали, когда же продукт будет готов целиком. И кстати, не продукт, а релиз. Они значит ждут, а работодатель им денежки платит… Смешно, право слово.

              На самом деле они приступали к работе с получением спецификаций, причем еще не готовых, потому что review этих самых спецификаций входит в их задачи — чтобы оценить возможность и способы протестировать то, что аналитики напридумывали.

              И точно также работали все остальные члены команды. Как только мы что-то определенное знаем о задаче, тимлид и архитектор приступают к проработке архитектуры, декомпозиции ее на задачи, оценке трудоемкости задач.

              Именно так работают уже давно хорошо организованные команды. И никаким гибким словом это не называлось, при всем при том.


              1. powerman
                25.11.2018 18:24

                Во времена активного использования водопада было нормальным даже не пытаться скомпилировать проект первые несколько месяцев разработки. Да, это было давно. Да, это самый настоящий водопад. Так что тестировщики всё это время могли заниматься ревью спецификаций или играть в крестики-нолики, или тестировать другой проект… но тестировать конкретно этот проект они получали возможность за пару месяцев до релиза, когда проект уже был написан практически целиком, и были решены проблемы интеграции написанного таким жутким способом кода, чтобы проект, наконец-то, удалось скомпилировать и запустить. :)


                1. sshikov
                  25.11.2018 18:38

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


                  1. powerman
                    25.11.2018 18:59

                    Видел в начале 90-х.


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

                    С позиции сегодняшнего дня это очевидно, но тогда это было не так.


  1. Portnov
    24.11.2018 08:15

    Интересно, что ажайл всё время противопоставляют водопаду, хотя водопадов-то, в общем-то, почти и не бывает в наше время. По структуре, водопад есть одноразовый процесс: проектирование, конструирование, тестирование, конец. Этот процесс действительно пришёл из других индустрий, таких как строительство тех же мостов. Никому не приходит в голову, что после того, как мост построен и сдан в эксплуатацию, можно уточнить требования и начать ещё одну итерацию. Кроме того, мосты обладают таким свойством, что практически не нуждаются в поддержке со стороны конструкторов и проектировщиков после окончания строительства: нужен текущий ремонт, но для него не нужно проектирование и конструирование, надо только бригаду штукатуров нанять.
    Во времена, когда Брукс был МНС-ом, так же строился и софт. Потому что софт существовал всегда в единственном экземпляре, для конкретного компьютера. Никому не приходило в голову, что после того, как компьютер построен (за время и деньги, вполне сопоставимые со строительством моста), можно уточнить требования и начать всё заново.
    Сейчас такой процесс, вероятно, возможен при проектировании уникальных научных космических зондов, направляемых куда-нибудь к Плутону: после того, как зонд улетел за орбиту Юпитера, обновление прошивки становится невозможным; поэтому 1) надо всё хорошо продумать заранее; 2) зато после преодоления орбиты Юпитера работа софтостроителей закончена, они могут вобще забыть про этот зонд и начать думать про следующий.
    Во всех остальных отраслях софтостроения, актуальна присказка «программный продукт можно писать, но нельзя написать». Процесс добавления и уточнения требований не заканчивается никогда. Поэтому «одно-итерационных» процессов уже несколько десятилетий не существует. Там, где не ажайл, там никакой не водопад, а какая-нибудь «V-образная итерационная модель» (спроектировали, сконструировали, протестировали, выпустили релиз, goto 1). Которая отличается от ажайлов форматом совещаний и названиями ролей. И, главное, отсутствием хайпа.


    1. sshikov
      24.11.2018 11:02

      >водопадов-то, в общем-то, почти и не бывает в наше время.
      Именно. Причем «наше время» — это скорее несколько десятилетий, как вы и пишете, чем несколько лет.


      1. shikhalev
        25.11.2018 18:51

        Пара-тройка десятилетий. Немного по сравнению с промышленным развитием человечества. Но и промышленность очень сильно поменяла способы работы и отношения в процессе по сравнению с феодално-крестьянским хозяйством…


    1. Rast1234
      24.11.2018 13:53

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


    1. vdshat
      25.11.2018 02:16
      -1

      Беда современных программистов в том, что они, в подавляющем большинстве, не являются инженерами и мало что понимают в технике, да и вреальном мире. И про мосты, строительство, да и про производство ничего не знают. Архитектор моста, как стратегического объекта, несет пожизненную ответственность. Компания-подрядчик также обслуживает, пока не передаст на баланс другой. Мост или другой строительный объект имеет такой же жизненный цикл и может модернезироваться и развиваться.


  1. Kirhgoff
    24.11.2018 10:01

    Мне кажется, автор оригинальной статьи замешал в кучу много вещей, которые мало имеют отношения к Scrum, например культуру компании (оценки и опен спейс офис). Отстутствие стратегии опять же — это все от компании зависит. Культура здесь — ключевое понятие, как к людям относятся и как они влияют на процесс.

    Могу рассказать как это происходит у меня на работе. Я работаю в Австралии в компании Jora (но на самом деле она принадлежит компании SEEK, в одном офисе работаем). Команда стратегии показывает и рассказывает к чему мы должны стремиться, все программисты знают, какие у нас цели. Цикл у нас недельный, новые эпики независимо сначала стартуют — есть выбранные программисты которые будут над ними работать, обсуждается ход работ, есть выбранные epic owner. Задачи добавляются в спринт во время планирования, так же у нас есть постоянно работающие эпики типа technical debt, вместе с текучкой они ассайнятся на dev on call товарищей, которые ротируются каждую неделю. Эпик может длиться несколько спринтов, никто никого не пинает, не пушит, главное — эпик оунер должен обьяснить сколько еще осталось работы и почему столько. Никого не бьют за удлинение сроков, если люди в состоянии обьяснить. Вообще тут никого не бьют и не ругают, это даже странно. В планировании смотрят, какие эпики закончены, все чинно благородно.

    Прямо вот странно все это читать.


  1. titov_andrei
    24.11.2018 11:04

    — Семёнов, ты водку по какой системе пить будешь?
    — Я по Инь.
    — Ну тогда я по Ян!


  1. Tepex
    24.11.2018 12:03
    +2

    Как и несостоявшееся коммунистическое государство, которое уравнивает людей путём распространения бедности,

    Коммунистическое государство уравнивает людей путем обобществления средств производства. Бедность — понятие относительное.


    1. napa3um
      24.11.2018 13:10

      У скрама тоже благие намерения :).


    1. tangro
      26.11.2018 00:52

      Кстати, хорошее замечание. Вот и реальный скрам от «книжного» отличаются примерно как «книжный» коммунизм от реального.


  1. Rast1234
    24.11.2018 14:00
    +1

    Забавно заканчивается статья лозунгом выкинуть бизнесовую разработку. А что тогда останется? Научные да фановые проекты.


    Я для себя пришел к выводу что r&d, техдолг и архитектура нормально вписываются в скрамоджайл, если потратить некоторые усилия и продать их бизнесу. И это нормальная часть работы разработчика, потому что только он знает, что и когда надо переделать, какая часть системы не справляется с нагрузкой или вызывает проблемы при малейших изменениях.


    1. AZaz1
      24.11.2018 15:09

      продать — уже звучит как обмануть, впарить :)


      1. Rast1234
        24.11.2018 15:21
        +1

        Не знаю, у нас это обосновать, объяснить. А как иначе? Бизнесовым людям впринципе пофиг на архитектурные вопросы (пока все не упадет совсем), и это наша ответственность поддерживать непонятную магию в рабочем состоянии непонятными ритуалами


        1. AZaz1
          24.11.2018 15:25

          по че-ловечески и с любовью :)
          когда кому-то из участников процесса, который к тому же производится за деньги, пофиг — вы сами понимаете что это уже не любовь, а чистая механика :)
          тут уже никакой эджайл со скрамами и водопадами не поможет!


  1. Mikluho
    24.11.2018 14:17
    +1

    Опять этот эффект жалобной книги…
    Люди, не знающие, каковой должна быть методология scrum/agile/waterfall/etc, жалуются на то, как внедрили эту методологию те, кто также её не понимают, но винят саму методологию… Более того, назначают оную методологию однозначным неоспоримым злом.
    Это тоже самое, что утверждать, что шурупы виноваты в том, что они у вас молотком не забиваются!

    Кивайте лучше на тех, кто бездумно впаривает или внедряет. Но не надо срам скрамом называть.

    У меня, вон, тоже, стажу за 20 лет, и я успел повидать разные методологии с разной степенью удобоваримости. По сути, какой-нибудь скрам — тот же фреймворк или паттерн проектирования, хорош, когда вовремя и в нужном месте, да употреблён согласно правилам, а не абы как…


    1. sheshanaag
      24.11.2018 17:07

      Это тоже самое, что утверждать, что шурупы виноваты в том, что они у вас молотком не забиваются!

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


      1. Mikluho
        24.11.2018 19:44

        Вот мне не приходит в голову такие идеи. И если вас кто-то учит забивать шурупы — то тоже не шурупы виноваты.
        А если все компании, которые вы видели, забивают шурупы — то это у вас выборка такая :)


  1. AZaz1
    24.11.2018 15:16
    +2

    я считаю что главный просчет данных методичек — это считать разработчиков РЕСУРСОМ, человеком нижней касты — отсюда и проистекают все те не верные методики и подходы.
    Когда ты главного человека, ответственного за качество продукта, считаешь ресурсом и строишь процесс соответственно — он адекватно отвечает такой системе и саботажем и прокрастинацией и наплевательским подходом к своей работе.


    1. powerman
      24.11.2018 16:18

      Э… что тут скажешь. Никто себя не любит считать ресурсом, это очевидно. Но ведь авторам этих методологий нужно было как-то "продать" их менеджерам, потому что без этого их никто бы не стал внедрять, а внедрять их однозначно стоило, потому что потенциально выиграть от этого могут все, и разработчики и бизнес. Вот и использовали приятную бизнесу терминологию. По факту, ресурс или нет — зависит исключительно от точки зрения и масштаба (расстояния, с которого ты смотришь на происходящее).


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


      1. AZaz1
        24.11.2018 16:22

        вопрос не в том что не хочешь — не считай себя ресурсом, вопрос в том что тебя уже все в пирамиде считают ресурсом — хочешь ты того или нет — у них ты простой ресурс и не трепыхайся — так написано в скрижалях )
        и когда пытаешься образумить некоторых ПМов что разработчики не твои «рабы» а равноправные участники процесса — вызывает долгую паузу, дурацкое выражение лица с втф ) и это не потому что они плохи пмы а просто они полностью погрузились в эту игру с эджайлом


        1. powerman
          24.11.2018 16:36

          Ну вот кстати да, с этим я соглашусь, люди часто заигрываются в такие глупости. С другой стороны и разработчики любят заигрываться в непонятых творческих гениев, которым ставить какие-то сроки — практически преступление (автор статьи похоже именно из таких). Переписыванием скрижалей это не лечится, самое эффективное средство против этой проблемы — медитация. Предложите тому ПМу помедитировать — как минимум насладитесь ещё более волшебным выражением его лица. :)


          1. AZaz1
            24.11.2018 16:43

            а это уже проблема игры в эджайл — у вас есть роли расписанные за вас и по ролям есть действия и вы в них играете, но нет нормального взаимодействия — тебе как руководителю важны сроки и не интересуют проблемы разработчика а у разработчика ужас — ему и задачу в срок надо сделать и рефакторинг нужно сделать без которого все будет плохо. И вы говорите друг с другом фразами предписанными ролями из скрижалей и не понимаете друг друга. а все потому что у разработчика пассивная роль ресурса и он не может защитить свои нужды и потребности — не описано в скрижалях!!!
            а отступать от букв скрижалях — это анафема! :)


    1. FoxCanFly
      24.11.2018 17:36

      Хм, любой линейный персонал является, как вы говорите, нижней кастой компании. Программисты особенные какие то? За эффективность продукта ответственно грамотное управление, стратегия, маркетинг, прогнозирование рынка. А кто там в конечном итоге код в редакторе вбивал — где то в конце списка.


      1. AZaz1
        24.11.2018 17:46

        ну вот, а потом возникают недоуменные вопросы: мы все сделали по бумажке но ничего не работает! почему?
        да потому, что главного человека в процессе разработки сделали самым последним, загнали под кровать поставили над ним кучу начальников и еще потом веником бьют если чо :)
        занавес!


      1. powerman
        24.11.2018 18:20

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


        Одну и ту же "user story", исходя из одного и того же описания задачи в трекере, можно сделать очень по-разному. И когда заметное количество кода пишется не лучшим образом это приводит к серьёзным потерям бизнеса — деньгами, временем и репутацией. По этой причине (пока что) не получается построить конвейер из программистов, в котором любого можно в любой момент заменить другим без заметного влияния на результат работы этого конвейера.


        Да, можно "выхолостить" задачу в трекере до состояния, когда все важные решения уже приняты, как именно надо написать код определено достаточно подробно, добавить кучку автоматизированных инструментов контроля качества (линтер, контроль покрытия тестами, приёмочные тесты)… и тогда действительно станет абсолютно неважно "кто там в конечном итоге код в редакторе вбивал". Проблема в том, что для бизнеса это ничего не изменит — на такое "выхолащивание" задач будет уходить 80% времени разработки, и люди, которые будут этим заниматься, будут ровно так же плохо заменимы, как до этого те, кто "код в редакторе вбивал". На самом деле — для бизнеса станет даже хуже, но причины мне разжёвывать сейчас лень, извините, их немало, но они не всегда очевидны.


        Самый близкий к конвейеру вариант, который действительно может сработать, по крайней мере в теории, это разработка большого количества очень маленьких микросервисов. В этом случае "user story" это описание требуемого API микросервиса, приёмочные тесты контролируют корректность реализации API, дополнительно нагрузочные тесты контролируют не функциональные требования, желательно при этом ещё проконтролировать использование сервисом ресурсов (память, CPU, I/O), и его размер должен позволять реализовать его в среднем за 7-10 дней. При таком подходе "кто там в конечном итоге код в редакторе вбивал" действительно становится не важно, но… сильно увеличивается важность тех людей, которые проектируют систему из таких микросервисов, пишут для них тех.задания и приёмочные тесты. Да, этих людей будет нужно меньше, чем сейчас нужно программистов, но проблема в том, что их квалификация должна быть значительно выше средней квалификации сегодняшних архитекторов, и их всё-равно нужно будет достаточно много — сейчас столько взять тупо негде, их сначала выучить надо. А потом проверить эту теорию практикой.


        1. AZaz1
          24.11.2018 18:28
          -1

          конечно же тут всплывает проблема найма нормальных людей — психолог в помощь!

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


  1. Gorthauer87
    24.11.2018 15:24

    По мне так единственная рабочая методология это здравый смысл и осознанный выбор подходящих методов исходя из ситуации.
    Короче говоря мозги плюс опыт решают.


  1. sheshanaag
    24.11.2018 16:46
    +1

    Гениальная статья, спасибо!


  1. khdavid
    24.11.2018 17:43
    -1

    Такое впечатление, что автор не очень знаком со скрамом. Вот это видео лучшее, что я видел про скрам. 15 минут и все расставляется по местам:


  1. alaskanebraska
    24.11.2018 20:28

    В статье очень много обобщений, с каждым из которых она становится все менее информативной.


  1. Portnov
    24.11.2018 20:48

    Ещё немного покапитаню.
    На это всё можно посмотреть вот с какой стороны. Все современные методологии, включая ажайл, придуманы прежде всего с целью превратить деятельность по разработке софта из искусства (которое даёт неизвестный заранее результат через неизвестное время за неизвестные деньги, зато даёт развернуться творческим личностям) в индустрию, которая даёт нужный результат за предсказуемые деньги и время. Ну правда, представьте предприятие по производству автомобилей, на котором производственное подразделение время от времени выдаёт фразы типа «нам нужно ещё полгода на рефакторинг» или «мы не хотим работать в таком темпе, мы же потеряем мотивацию и выгорим, это соковыжималка!».
    Да, разработчик скажет, что между сборкой автомобилей и написанием софта есть большая разница. Но с точки зрения владельца бизнеса, никакой разницы нет: есть производственное подразделение, которому платят зарплату и ожидают произведённый продукт в заранее оговоренные сроки.
    Поэтому, на самом деле, все комментарии вида «ажайл это соковыжималка» — это не про то, что ажайл не работает, а как раз про случаи, когда он работает хорошо (с точки зрения владельца бизнеса): он и придуман, чтобы от имеющихся наёмных работников получить максимум профита за минимум времени. На этом месте появляются не вполне однозначные рассуждения про то, что такая позиция недальновидна. Сотрудники выгорают и снижают производительность, их приходится заменять и обучать новичков. Но это можно компенсировать отлаженным механизмом обучения новичков, обязательным документированием всех знаний и приёмами TDD. И действительно, оказывается, что «рок-звёзды» и «творческие личности» типа автора статьи бизнесу неудобны: они могут выдать совершенно замечательный результат за короткий срок, а могут сказать «ой, чото я потерял мотивацию»; бизнес обычно предпочитает средний, но предсказуемый результат.
    В принципе, примерно то же самое происходит и на традиционных заводах.

    Это я к тому, что большая часть «жалоб на ажайл» — это на самом деле не жалобы на методологию, а жалобы пролетариев на излишне активную эксплуатацию со стороны работодателя. Ну а степень лояльности работодателя к пролетарию бывает очень разная.


    1. AZaz1
      25.11.2018 00:19
      +1

      вы тут лукавите сопоставляя производство автомобиля с производством кода!
      в автоиндустрии рефакторинг называется моделью и на него не один год выделяется!

      а на линии сборки идет обычный CI/CD процесс :)

      в общем не удачную аналогию вы придумали — от того она и не катит!


      1. Portnov
        25.11.2018 14:31

        А по-моему, как раз плохая аналогия между разработкой новой модели и рефакторингом :)
        Разработка новой модели инициируется бизнесом, а не производственным подразделением, исходя из положения на рынке и наличия средств на разработку.
        Рефакторинг — инициируется производственным подразделением, причём либо производится этим подразделением «втихую» (за счёт увеличения сроков исполнения других задач), либо его надо суметь «продать» бизнесу (объяснить, что если его не сделать, производительность упадёт).

        Мы-то с вами знаем, что сборка автомобилей отличается от написания кода тем, что написание кода — это не «реализация», эта работа гораздо больше похожа на проектирование новых моделей автомобилей, чем на сборку. Но тут мы сталкиваемся с тем фактом, что мы живём в эпоху НТР: наше время существенно отличается от старых-добрых времён тем, что «проектирование», «НИР и ОКР» — это теперь не работа НИИ и КБ, а производственная база бизнеса. А бизнесу, по большому счёту, всё равно, что производить: автомобили, программы или теоремы. Лишь бы продавалось.


        1. powerman
          25.11.2018 16:40

          за счёт увеличения сроков исполнения других задач

          Правильнее сказать "за счёт незначительного увеличения сроков исполнения текущих задач ради значительного сокращения сроков исполнения будущих задач". Если бизнес ставит текущую задачу как "это прототип, все работы по которому будут прекращены через два месяца" — тогда да, любой рефакторинг "втихую" это саботаж. Но если бизнес ставит задачу как-то иначе, то в саботаж уже превращается отсутствие непрерывного фонового рефакторинга.


          И нет никакой необходимости отдельно уведомлять бизнес об идущем в фоне рефакторинге — это штатная деятельность, без которой длительный проект реализовать невозможно по причине экспоненциального замедления разработки. Уведомлять нужно в ситуации, когда фоновый рефакторинг не справляется с задачей, и нужно выделить значительное количество времени (сравнимое с временем реализации пары обычных задач) исключительно под рефакторинг — вот тогда его нужно оформить таской в бэклог и отложить до момента, когда PO разрешит ей заняться.


  1. vdshat
    25.11.2018 02:37
    -1

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


  1. lxsmkv
    25.11.2018 06:28

    Много эмоций, и практически ничего по делу. Манера повествования — ничем не подкрепленные утверждения. Все посты автора написаны в негативном, жалобно-обличительном, критическом ключе. Сплошная обида. Тут налицо нездоровый сдвиг восприятия у человека.


  1. Haanz
    25.11.2018 11:48

    похоже на дешевую демагогию

    а пример методологии описывающий дивный мир в котором инженеры творят прекрасные продукты не парясь со сроками и не опускаясь до общения с «гуманитариями»?


  1. dralexnone
    25.11.2018 11:48

    Хорошая статья. Главная мысль — использование той или иной методики зависит от проекта и той команды, которая есть у вас. Если у вас 3 стажера, то разбиение задачи на короткие этапы и ежедневные получасовые встречи — это то, что нужно. Если же в вашей команде 3 профессионала, то подобный подход погубит проект.


  1. cup_of_tea_1
    25.11.2018 11:48

    Очень хорошая статья, спасибо за перевод. Темы, поднятые автором, действительно являются актуальными и наболевшими в современном мире. На мой взгляд сегодня мы наблюдаем рост тенденции, некого запроса на изменение положения текущих дел от людей, которым действительно некомфортно (мягко сказано) работать в таком режиме. Остается надеяться, что это понимание придет и к другим сотрудникам многочисленных компаний.


  1. hotiron
    25.11.2018 11:49

    Вот раньше мы работали по «водопаду». При этом устраивали дейли митинги, чтобы понять где мы сейчас, какие у нас проблемы и что нам надо и чтобы идти дальше. И эта схема отлично работала. Запланированные сроки никогда не факапили, на выходе был более-менее качественный продукт.
    Потом в контору пришел «Эджайл», и вот тут-то начался цирк. Все описанное выше автором в этом цирке присутствует. Теперь у нас дейли ради дейли, в нем собирается команда и обсуждает что было сделано, хотя к друг-другу теперь зачастую задачи отношения не имеют, и это получается просто треп, никак не помогающий каждому решить глобальную цель. Цель теперь как таковая отсутствует. Точнее она теперь выглядит вот так «сделай красивый бёрн даун», потому что это напрямую скажется на твоей премии и еще не бери нужные задачи, бери те, которые точно в спринт сделаешь, даже если они вообще никому не нужны, зато бизнес тебя похвалит что ты все успел. Для обязательно демо делаются всякие заглушки, чтобы бизнес мог увидеть как оно теперь стало, и неважно что на самом деле функционала еще нет, главное показать. А вот когда занимаешься рефакторингом — показывать нечего, поэтому рефакторинг не приветствуется.
    В итоге производительность упала процентов на 30 минимум, основные задачи быстрее точно не стали делаться (скажем так они стали в работу уходить быстрее, но на выход в ПРОМ это никак не отражается). Зато периодически на ПРОМ такой сырой продукт выкатывается, что потом по выходным все это править приходится. А гибкость заключается только в отсутствии документации, потом концов не сыщешь, почему было сделано так а не так, никто ни за что ответственности не несет. Зато бизнес просто пищит от того какой он современный и как у него налажены процессы.


  1. StarTrinity_CEO
    25.11.2018 11:49

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


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


  1. wheredevel
    25.11.2018 11:49
    +1

    Я никогда не понимал хайп вокруг Agile. Многократный опыт в разных компаниях давал всегда лишь одно объяснение: это отговорка для руководителей, которые раньше просто не умели, а теперь они «Agile»! (слава богу, есть, например, стартапы, где пока не занимаются подобными глупостями — мы там...)

    В то-же время, я наблюдаю вот уже второе десятилетие размывания профессионализма на уровне Junior-Middle. В результате, на Middle-Senior выходит ежегодно, относительно, меньше народа. А знания-опыт, мягко говоря, оставляют желать лучшего. На рынке огромный деффицит профессионалов.

    Благодаря этой статье, я увидел временную и причинно-следственную связь между Agile-измом и проблемой кадров.

    Естественно, это не единственная причина, но теперь я рассматриваю её как очень вескую: социальная среда, создаваемая в Agile-зированных компаниях, влияет на индустрию в целом. Затрудняет профессиональный рост и преемственность знаний. Тренерует молодые кадры следовать ошибочным карьерным верктором.

    Спасибо за статью и перевод!


  1. ApeCoder
    25.11.2018 12:22
    +1

    habr.com/company/abbyy/blog/232825/#comment_7858095

    Автор оригинала — Michael O. Church, «the most hated Ex-Googler», человек, который участвовал во всех возможных «политических» срачах компании и при этом делал мало производительной работы, уволившийся оттуда с отрицательной рекомендацией, с которой его не взяли в foursquare, короче неоправданно opinionated фрик, end of story. Особенно смешно он бегал по интернетам, пытаясь доказать, что когда наниматель звонит кому-то из бывших работодателей, кого кандидат не указал в списке рекомендаций, он нарушает право на частную жизнь и вторгается на недовзоленную территорию.

    Его представления о ремесле, о рынке труда, не нуждаются в комментариях.


  1. difference
    25.11.2018 14:03

    заметил что аргументы многих комментаторов в защиту скрама по сути сводятся к тому что либо мало кто знает что такое правильный, настоящий Скрам, либо же что мало кто умеет его готовить, и где-то есть те кто знают…
    На аргумент вида «вы не умеете готовить Х» легко возразить, в общем-то ..., а что ещё важнее — при таком количестве исключений, — т.е. когда «настоящий Скрам» не реализован/не работает почти нигде, — что тогда считать правилом? Если почти нигде нет «настоящего Скрама» то в чем тогда смысл?
    То что я наблюдаю, так это как адепты Скрама схватываются между собой и порой готовы спорить до посинения что же такое этот настоящий Скрам.
    На любое замечание о недостатках Скрама обычно отвечают что «в настоящем скраме такого нет». Т.е. по итогу Скрам — это некая такая идеальная методология, которая лишена недостатков которые ты мог назвать вчера, сегодня, завтра… Короче — розовый единорог

    Лично мне кажется что Скрам хорошо подходит для технически однообразных проектов, вроде — сделать интернет-магазин, дэйтинг… Но в сколько-нибудь сложных и долгосрочных он не так хорош. К слову сказать, киты рынка вроде Microsoft, Google, Facebook не применяют Скрам для разработки и развития своих продуктов, по меньшей мере не в чистом виде, а в некоем гибридно-смешанном (так что опа, снова не «настоящий Скрам»!)


    1. powerman
      25.11.2018 17:45

      Никакого "настоящего скрама" не существует. Точнее, "настоящий скрам" это не методология, это фреймворк, на базе которого нужно сформировать (и корректировать по необходимости) методологию под конкретную команду/проект. Поэтому скрам у всех отличается, так задумано, иначе оно не сможет быть "гибким".


      Ответ "вы не умеете готовить" означает только то, что описываемые проблемы вызваны не недостатками фреймворка, а недостатками сформированной по его мотивам методологии (часто даже не сформированной, а тупо взятой из книжки, без какой-либо попытки адаптировать её под команду/проект).


      Скрам — это некая такая идеальная методология, которая лишена недостатков

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


      Лично мне кажется что Скрам хорошо подходит для технически однообразных проектов, вроде — сделать интернет-магазин, дэйтинг… Но в сколько-нибудь сложных и долгосрочных он не так хорош.

      Это не так. Безусловно, применимость скрама ограничена определёнными проектами, но "сложный" и "долгосрочный" к ним не относятся. Например, скрам очень плохо подходит для задач администрирования, поддержки, R&D, проектирования архитектуры. И не очень подходит для команды из 3-х адекватных сеньоров. А сложные и долгосрочные проекты по скраму делать ничего не мешает, просто не надо запихивать ногами проектирование архитектуры и R&D в спринты.


      1. difference
        25.11.2018 18:16

        >Ответ «вы не умеете готовить» означает только то, что описываемые проблемы вызваны не недостатками фреймворка, а недостатками сформированной по его мотивам методологии

        ну то что это не вызвано недостатками фреймворка — это ведь не аксиома и не доказанный факт, разве нет?
        Если мало кто может построить из этого фреймворка подходящую для себя методологию, не пора ли задуматься что дело не только в кривых руках? Это тоже самое как утвержать что причиной того что было 85 фэйлов из 100 попыток сделать торт Наполеон из плохих материалов — скажем, муки из отходов (в данной аналогии это «фреймворк») всё дело в неправильных кондитерах.
        Представьте что я — клиент, который просит вас разработать мне методологию. Мне не нужны оправдания в виде «что-то сделали не так», мне надо чтобы это эффективно работало, и если этот фреймворк смогли хорошо построить только в считанных случаях, то дайте мне другой фреймворк, который будут строить успешней.
        Если из фреймворка считанные люди могут выстроить себе что-то толковое, то тогда это и есть недостаток этого фреймворка — что из него мало кто может слепить себе что-то толковое :D

        Про то что построили что-то не то, да скрам не тот, не тру и тд — это всё напоминает историю истинные ирландцы так не поступают

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

        как это доказать? Для этого надо сделать один и тот же проект двумя примерно одинаковыми командами но разными подходами. По-моему, будет лукавством сказать что это работает и эффективно только потому что Водопад — плох. Из того что Водопад плох, не следует что Скрам — хорош.
        вы вот работали с чем-то ещё кроме Скрама? Есть с чем сравнить? Например с Rational unified process.


        1. powerman
          25.11.2018 18:46

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

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


          Я лично довольно долго держался в стороне от скрама, и именно по этой причине — без хорошего понимания сути скрама и адекватной адаптации тащить его в проект это безумие. Но в какой-то момент мне повезло с ним разобраться, так что теперь для меня это просто инструмент — вполне рабочий и полезный, хотя и не могу сказать что любимый (канбан сильно проще, и зачастую его более чем достаточно).


          Это тоже самое как утвержать что причиной того что было 85 фэйлов из 100 попыток сделать торт Наполеон из плохих материалов — скажем, муки из отходов (в данной аналогии это «фреймворк») всё дело в неправильных кондитерах.

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


          Если из фреймворка считанные люди могут выстроить себе что-то толковое, то тогда это и есть недостаток этого фреймворка — что из него мало кто может слепить себе что-то толковое :D

          Полностью согласен. Проблема в том, что чего-то лучшего (я сейчас не конкретно про скрам, а в целом про гибкие методологии) пока либо не придумали, либо придумали, но не смогли раскрутить и сделать популярным, так что мы о нём не знаем.


          вы вот работали с чем-то ещё кроме Скрама? Есть с чем сравнить? Например с Rational unified process.

          Нет, RUP меня обошёл стороной. Как я обычно работаю описано выше, и скрам там занимает не самое главное место.


      1. ggo
        26.11.2018 10:05

        В комментариях несколько раз прозвучало, что проектирование архитектуры и R&D плохо совмещается со Scrum.
        Почему?

        Условный Twitter или Whatsapp. Как бы они проверили правильность своих идей по архитектуре без реальных пользователей и их активности? И без точного понимания, что пользователи чаще всего делают, и где в результате узкое место в той же архитектуре, без реального cash flow и понимания, что дороже всего в твоей инфраструктуре и пора уже оптимизироваться или еще можно новые фичи пилить.