Где Agile ужасен, особенно Scrum

Автор оригинала: Michael O. Church
  • Перевод
Гибкость — без сомнения хорошая вещь, и в манифесте 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]». Предполагается, что эта система навсегда: ориентированные на бизнес митинги никогда не исчезнут. Архитектура, НИОКР и развитие продуктов уходят из работы программиста, потому что не вписываются в атомизированные «истории пользователей» и двухнедельные спринты.

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

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

Самое худшее в оценках — что они стимулируют выполнение работы, которую можно оценить. Это заставляет программистов отдавать предпочтение простым вещам низкого уровня, которые на самом деле не нужны бизнесу (даже если неуклюжие менеджеры среднего звена думают иначе), но это «безопасно». Всё, что на самом деле стóит делать, имеет ненулевой шанс неудачи и слишком много неизвестных параметров для разумной оценки сроков. Концентрация 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, по крайней мере, а такой извращённой реализации, как всё, что я видел, — полная ерунда, которая не имеет никакого отношения к программированию и, конечно же, не имеет никакого отношения к информатике. Бизнес-ориентированная разработка в целом — тупик. Её следует бросить обратно в грязь, из которой она вышла.
Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

Комментарии 214

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

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

    Поздравляю вас, гражданин, соврамши!
      –7
      Опять это потливое противопоставление «нас, программистов» против «них, гуманитариев». Откуда это вообще?

      Представьте себе — это из реальной жизни.
        +4
        Да, свой (тем более болезненный) опыт ближе к телу.

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

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

        На самом деле, действительно, употреблять термин «гуманитарий» в таком случае — неверно. Те, о ком идет речь, опираются в принятии решений на ощущения, чувства, а не на логику, абстрактное мышление и систематизацию. Гуманитарные науки вполне могут требовать использовать логику и систематизацию. А тех, кому эти инструменты недоступны, называть «гуманитариями» — это поднимать их на уровень выше с их уровня слабого развития абстрактного мышления.
        +2
        А может кто рассказать, обратную сторону, то есть не «бизнес-ориентированную». Это как вообще? Я как раз из этих молодых, которые не понимают, полагаю.
          –9
          Да не существует этой не «бизнес-ориентированной» стороны. Автор статьи возомнил себя художником, «творческой» личностью, а по факту программист — ремесленник, удовлетворяющий потребности бизнеса, ничем особо от кассира в маке не отличающийся, за исключением определенных знаний, за которые ему готовы платить большую зарплату и терпеть его «то не хочу, это не буду» при условии, что он зарабатывет или экономит бизнесу хотя бы размер своей зарплаты.
            +2

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


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

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

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


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

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

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

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

                  Фишка в том, что фундаментальные исследования, лишь изредка давая применимый в бизнесе результат, все равно выгодны. Точно так же с НИР и НИОКР, включающими в себя написание кода. Пишется оно по госзаказу и пишется. Вроде и госзаказ дурацкий и пишется в стол. А потом бац — оп-па, а у нас для бизнеса все кирпички готовы. Перекомпоновали — и можно продавать.
                  0
                  Т.е. появление go, rust, typescript, etc — это чистой воды филантропия Google, Facebook, Microsoft, etc?
                0
                Ядро линукс, например. А вообще — много всего. Начиная с НИРовских работ, где непонятно, получим мы результат и, если да, то каким путем. Ну и кончая АСУТП, где надежность -важнее денег. Госзаказы те же.

                Ещё пример — автовождение. Да, будет бизнес, но не через год, а лет через 5. Но куча команд работает. Мы, например, случайно автовождение комбайна сделали. Хотя для нас основное — это высокоточный GPS.
                +5
                Согласен с тем, что нужно больше свободы и меньше контроля. Ежедневные отчеты это безумие, как и часы работы строго с 9 до 18, со штрафами за опоздание. Творчество (которого много в «программировании») любит свободу, как любит её и стремится к ней любой разумный индивидуум. Из-под палки от забора и до обеда можно копать траншею, писать гавнокод, но не создавать полезный продукт.
                  –12
                  Творчество (которого много в «программировании»)

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

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

                        +5
                        Расскажите про универсальный алгоритм кеширования данных, внесите неоценимый вклад в Computer Science.
                          0
                          После фразы «Экспертиза промышленной безопасности — процесс творческий и нелинейный», сказанной одним из моих коллег-«экспертов», у которых всё зарегламентировано до запятой (а то ведь и рванет), я считаю, что программисты — это если не Да Винчи в плане творчества, то Ван Гог как минимум
                            0
                            Простите, но с уровня мидл- (джуниор+) появляется свобода выбирать как минимум сочетание алгоритмов (реализация в чистом виде уже известного алгоритма — это учеба). И вот этот выбор сочетания алгоритмов в рамках задачи — вполне творческая часть.
                          0
                          Опять это восприятие скрама исключительно как метода выпаса программистов, мешающего вольным художникам творчески работать. Программисты лишь часть процесса, причём часто очень далёкого от творчества и чем дальше, тем больше.
                            +4
                            Да вообще надо программистов убирать из процесса разработки ПО, слишком много о себе возомнили, творческие они, посмотри-ка! Наверняка умные менеджеры придумают со временем какой-нибудь Agile-SCRUM, чтобы убрать все лишние звенья, не поддающиеся систематизации и строгому контролю.
                              +2
                              > творческие они, посмотри-ка!

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

                              Ну там всякие книжки на эту тему вроде знаменитого The Goal и всякие там книжки про безотходное производство (toyota way, lean)…
                            +4
                            В статье очень плохо с пониманием скрама. Начнем с того, что опен офисы не имеют к нему никакого отношения. скрам — это про процесс, а не про передвигание кроватей.

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

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

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

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

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

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

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

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

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

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

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

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

                                  Как такой эпик заскрамить?
                                    0
                                    Элементарно. Создаются задачи вроде «Прочитать книжку и оценить пути реализации» с ДоД «написать отчет». Дальше создается следующая, зависимая задача «выбрать алгоритм и набросать PoC». И так далее. При этом Product Owner должен понимать что в процессе PoC выбранный алгоритм может оказаться неудачным и расставлять приоритеты соответствующим образом (вплоть до полной деприоритизации — т.е. отказа от этого feature из-за высокого риска).
                                      +6
                                      Получился продукт-овнер как минимум из нобелевских лауреатов, кажется.
                                        0
                                        А где задача по привлечению нужных спецов, или консультаций с другими командами партнеров(или заказчиков или просто знакомых)? =) Прочитать книжку — это сразу один из менее выгодных вариантов, т.к. проиграем время и спецы заточены на другие проблемы, следовательно выбор может пасть не на правильный путь и будет скрывать множество деталей вначале. Вот следующая задача «зависимая» ну уж точно не должна создаваться так рано, может её не будет или будет совсем другая? Второй задачей вы ограничили пути решения. Видимые риски нужно сразу убивать, что бы потом пожары не тушить=)
                                          0
                                          А причем тут agile/scrum? Хотите привлечь отдельного специалиста — привлекайте.

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

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

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

                                          Все же R&D с точки зрения планирования проще организовывать за счет фиксированных итераций, ибо оценить такие задачи адекватно невозможно. две недели ресерч, анализ результата, решение копать дальше или забить.
                                          0
                                          Напомнило «Задача по оценке временных затрат требуемых для проведения оценки основной задачи»
                                            –1
                                            вполне себе адекватная задача. Всяко лучше, чем «мы будем делать Х, фиг знает что получится и никто не скажет сколько это займет». В своей практике я видел пару раз такой подход. Оба раза приводил к закрытию компаний.
                                            +1

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

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

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

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

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

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

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

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

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

                                                    0
                                                    Вы не ответили на вопрос.
                                                    Есть такой принцип, который явно показывает, где ответственный человек, а где — поболтать пришел.
                                                    Критикуешь — предлагай. Предлагаешь — делай.
                                                      0
                                                      Иначе говоря «Не нравится? Сделай сам». Прекрасный подход, чтоб перевесить свою ответственность на других.
                                                        0
                                                        Вы не забывайте предлагать. Идеальная критика диаметром 1м и массой 1 кг в вакууме бесполезна. Сравнивайте. Говорите «так недо», но не забывайте продолжать «а надо так-то».
                                                          0
                                                          Не нужно быть поваром, чтобы чувствовать вкус блюд.
                                                          Но нужно быть поваром, чтобы советовать что изменить.
                                                            0
                                                            Конечно!
                                                            Так вы сравните вкус в итоге?
                                                              0
                                                              Да. Я могу сказать «подгорело». Я не могу сказать надо ли добавить больше масла, меньше температуру, или другую сковороду.
                                                              Но да, я спокойно попробую вторую попытку.
                                                              И да, она всё еще может быть подгоревшей.
                                                                0
                                                                Так вы сравните вкус хлеба испеченного в одном месте с хлебом испеченном в другом месте?
                                                                Или может быть сравните не с хлебом а с мамалыгой?
                                                                Или может быть сравните хлеб испеченный в разных печах?
                                                                Если раз за разом делать одно и тоже то и результат будет такой же.
                                                                  0
                                                                  Нет, я скажу подгорело. И да, если в ответ на критику «сделай лучше» — я просто уйду в другую пекарню.
                                                                  До тех пор, пока не найду ту, где умеют готовить и слушают если что-то идёт не так. :)
                                                        –1
                                                        0
                                                        Проработка продакт овнером!= разработка. Он тратит на это время один, с полной готовностью слить свою работу в унитаз, при изменении внешнего мира или каких- либо внутренних изменений/вскрывшихся подробностей.
                                                          0
                                                          > Он тратит на это время один

                                                          он не получает фидбэк, потому в целом какая разница? В этом же собственно основная проблема ватерфола, а не в том что «нет спринов». Нет фидбэка — приоритизация происходит на основе «я так вижу». А при таком раскладе можно и более ватерфольные штуки использовать (FDD то же)

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

                                                            У него может не хватить квалификации все проработать.

                                                      0
                                                      «вплоть до полной деприоритизации — т.е. отказа от этого feature из-за высокого риска» — ну вот оно, вымывание R&D.
                                                –2
                                                Не прощаю :) зачем писать по-русски когда не можете сформулировать на русском языке?
                                                +4
                                                Уважаемый автор, вы украли мои мысли :)
                                                я за свою длинную карьеру (начиная с перфокарт — многие не знают что это и еще не были рождены) попробовал все варианты организации работ.
                                                Последние годы работал в «крутых» компаниях в «крутых» офисах и по модным ныне методологиям глупо повторяемых организацию труда западных людей.
                                                Точно могу подтвердить ваши тезисы о странной односторонней «прозрачности» программистов, о кране низкой эффективности труда в опенспейсах и напрасной трате куче времени на дежурные и бесполезные совещания в рамках эджайла и самое главное — о выгорании и отвращении к работе нормальных ребят.
                                                Давно известно, что то что хорошо для немца (заметка: немец на славянском — чужой — не мы) — у нас не работает!
                                                А многие даже не понимая, что и для чего просто пытаются, как некоторые наши младшие собраться, копировать чужие наработки в абсолютно другой среде с абсолютно другой ментальностью и целями!
                                                Особенно меня умиляет обилие иностранных терминов в этом процессе :))
                                                попробуйте их заменить на нормальные русские слова — и вы сразу увидите абсурдность и ненужность и вредность для команды многого из того что привносят эти методики для организации труда на западе! :)
                                                  +5
                                                  Это же перевод. И судя по всему автор — американец. Так что не только в России так.
                                                    +1
                                                    возможно — тогда он точно подметил все главные минусы современных тенденций в разработке — за что ему огромное спасибо!
                                                    тем более его мысли подтверждают основные выводы, что слепое следование манускриптам эджайла и подражание западным компаниям не только не полезно но и вредно!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                0

                                                                Был вроде бы такой старый анекдот про подходы набора группы скрипачей:


                                                                • Только евреев
                                                                • Только русских
                                                                • Большинство евреев, но несколько русских
                                                                • Большинство русских, но несколько евреев
                                                                • Пополам

                                                                И резюме: "Все подходы расистские. Брать надо тех кто на скрипке лучше играет".

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


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

                                                                За мои скромные 18 лет работы в IT, я не видел ни одной компании (РФ + EU + US), где можно было выделить отдельного «психолога», который бы вердикт выносил — быть ли кому-то тим-лидом.
                                                                (отмечу еще, что у психологии, как науки есть серьезные проблемы, так что на поверку, все ваши «мамы коллектива» работают на интуиции и чутье в социальных отношениях, что никак не гарантирует хороших результатов...)
                                                                  0
                                                                  у некоторых возникаю вопросы и не понимание всех людей в agile процессе и сам процесс… бывает.
                                                                  проходит время и приходит понимание!
                                                                  время — хороший учитель )
                                                            0
                                                            Статья очень неплохая, во многом коррелирует с собственными наблюдениями. Я, прямо говоря не ожидал этого заходя в статью с таким желтушным заголовком, играющим на рептильных участках головного мозга.
                                                            Но по мере чтения понял, что материал шикарный и понял, что надо будет перечитать ещё раз на свежую голову.
                                                              +6
                                                              Прекрасная статья, все слово в слово так. К сожалению, сам видел в жизни каждый пункт. Психиатрическая лечебница просто какая-то.
                                                              Ох, уж это стремительное накопление технического долга, которым никто и никогда не будет заниматься, и героическое решение миллиона проблем, после сырого релиза. Проблем, которые вообще не имеют права и возможности возникнуть, если хоть чуть лучше все продумать и реализовать. Но некогда.
                                                                –3
                                                                Психиатрическая лечебница просто какая-то.

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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


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


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


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


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

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

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


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


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

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

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


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


                                                                                        P.S. Совсем забыл упомянуть про документацию — в Go её наличие контролирует линтер, вот я и расслабился.

                                                                                          0
                                                                                          в случае, если этот разработчик имеет в собственности 100% компании, вопроса с доверием к разработчику не возникает. я понимаю, практически все тут — наемные программисты, без своего бизнеса, я говорю здесь про себя
                                                                                            0

                                                                                            Я успел заглянуть к Вам в профиль, так что ждал подобного ответа. :) Моё мнение — это Вам пока так кажется, потому что пока это работает.


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

                                                                                              0
                                                                                              либо компания начнёт хорошо зарабатывать и Вы увлечётесь гоночными машинами вместо программирования

                                                                                              это же мой истинный интерес, как такое может случиться?

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

                                                                                              я против разрастания компании при наличии больших денег, это не моя цель

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

                                                                                    Эти обвиняшки таким образом будут блокировать вам любое общее обсуждение. Вне зависимости, скрам это или нет.

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

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

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

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

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

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

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

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


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


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

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


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

                                                                                +13

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


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


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


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

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


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


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

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

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


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


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

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

                                                                                    +2

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

                                                                                            0
                                                                                            Кажется, один из самых важных факторов применимости технологии — это именно наличие специалистов. Т.е., то, что вы говорите, не срыв покровов, а естественный ход вещей, странно бы было искать Идеальную Технологию в отрыва от специалистов, которые в ней должны шарить. Вера в собственный плюрализм и непредвзятой взгляд на технологии, конечно, лишь иллюзия. Прост бывают люди поопытнее, бывают мене опытными, и из этого опыта они делают выбор, и относительно именно этого опыта он может быть правильный или неправильный.
                                                                                              0
                                                                                              А я разве утверждал что раскрываю какую-то страшную тайну? Специалистов много разных. А чтобы разобраться в очередной либе, фреймворке, тулзе и даже не слишком маргинальном языке не надо 5 лет торчать за партой. И если какой-нибудь условный опытный техлид может проанализировать требования, инструменты и выбрать тот, что лучше всего подходит и подобрать соответствующих людей, или уже существующим сказать, что пора изучить другую технологию. То в «самоорганизующейся» команде столь радикальные перемены попросту не возможны, если, конечно, вы не попали в команду к любителям экспериментировать. Но тут уже другая крайность — тратится куча времени на то, чтобы попробовать заведомо не подходящие вещи.
                                                                                                0
                                                                                                Да, с этим соглашусь, тоже склонен видеть в некоторых известных примерах внедрения скрама излишне разрушительную «демократию» и культивацию не инженерной культуры, а какого-то литературного кружка.
                                                                                          +3
                                                                                          А кто-нибудь вообще понимает?

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


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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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


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


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

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


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

                                                                                                0

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


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

                                                                                                  0
                                                                                                  Спасибо. Видео (Rainsberger) очень понравилось.
                                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                0
                                                                                                А кто-нибудь вообще понимает?

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

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

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


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

                                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                    0

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


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

                                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                    0
                                                                                                    А кто-нибудь вообще понимает?

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


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

                                                                                                      +1

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

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

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

                                                                                                        Так же как некоторые придумывают какую-то свою внутренне противоречивую отсебятину и называют что-то там юнит тестами ;).
                                                                                                          0
                                                                                                          Да какая разница что является скрамом, а что им не является? Важно лишь что работает, а что нет. И именно работоспособность в конкретном проекте и конкретной команде надо обосновывать, а не принадлежность к той или иной методологии.

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

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

                                                                                                            Мне очень странно, что такие элементарные вещи надо объяснять программисту — ведь он-то должен знать зачем нужны идентификаторы
                                                                                                              0
                                                                                                              Данный идентификатор никак не влияет на работу команды. Ну вот есть команда, работает хорошо, но не по скраму. И что с того?
                                                                                                                0
                                                                                                                Данный идентификатор никак не влияет на работу команды.

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


                                                                                                                Ну вот есть команда, работает хорошо, но не по скраму. И что с того?

                                                                                                                Разобраться, как это устроено и постараться позаимствовать. Чтобы разобраться надо как-то все это назвать.

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

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


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


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

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

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

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

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

                                                                                                                0

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

                                                                                                                  0
                                                                                                                  А причём тут Agile если вы всё сделали не по Agile. В спринт нельзя брать задачи которые невозможно оценить. У нас в компании для супорта назначались программисты, причём каждый спринт они менялись. Они не были включены в команду и в спринт, так как их задачи непредсказуемы по времени. Но всё равно они отчитывались каждый день, если кто то зависал на задаче больше чем нужно, он должен был просить помощи у более компетентных или сменить задачу.
                                                                                                                  Я всем советую очень простую вещь, если что то вам не нравиться в Agile которая устроила ваша компания, то на первой же ретроспективе вы должны ставить вопрос ребром, и менять правила. В этом и есть главный смысл гибких методологий. Процесс должен прогнуться/измениться под вашу команду.
                                                                                                                  Понятно что ваши изменения должны быть чем то обоснованы. Если у вас сомнения, попросите совета на ресурсах где много специалистов по Agile. Даже здесь в комментариях очень много дельных советов.
                                                                                                                    0
                                                                                                                    А при чём тут эджайл? Я отвечал на конкретный тезис, никак с эджайлом не связанный.

                                                                                                                    0
                                                                                                                    А в команде не было людей, которые это знали? Почему они вам не помогли?
                                                                                                                      0
                                                                                                                      Что знали? В NPM особо никто не рубил, что проблема в настройках репозитория и явовском обвесе — никто не знал.
                                                                                                                        0

                                                                                                                        У вас были проблемы с конкретными симптомами — вы их выносили на общее обсуждение?

                                                                                                                          0
                                                                                                                          Разумеется. Спасибо за желание помочь, но это дело давно минувших дней, где накосячили, наверно, все, кто мог. И сейчас разбираться кто больше виноват нет никакого смысла. Я лишь проиллюстрировал, что декомпозиция не всегда возможна.
                                                                                                                            +1
                                                                                                                            Я не разбираюсь кто больше виноват мне это вообще не интересно. Просто интересно получить представление о команде и стиле коммуникации.
                                                                                                                      0

                                                                                                                      А при чем тут "невозможно оценить" наверное вы имели ввиду "невозможно было безошибочно предсказать".


                                                                                                                      прочитайте определение https://en.wikipedia.org/wiki/Estimation


                                                                                                                      Estimation (or estimating) is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable. The value is nonetheless usable because it is derived from the best information available.

                                                                                                                      Оценить можно все, что угодно, вопрос, с какой точностью ;)

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

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


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


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

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

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


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

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

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


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

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

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

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

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

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

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

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


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

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

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

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