Ещё один манифест

Эджайл то, эджайл сё. Про эджайл сейчас не говорит только ленивый. Да и ленивый говорит. Все говорят. Из каждого утюга, даже выключенного из сети, топят за эджайл. Такое ощущение, что просто эпидемия какая-то разразилась. И не подумайте, что я только про ИТ. Коучи учат неофитов проводить стендапы с ретроспективами и жить по спринтам в любых бизнес-сферах: от булочных до парикмахерских. А некоторые менеджеры, наслушавшись коучей, так увлекаются, что забывают о природе данного явления, заставляя внедрять гибкие методологии негибкими методами: «Так, с завтрашнего дня мы все становимся гибкими. Что за «хихи»? Гибкими я сказал, а то всех нагну!». Так в чем же природа эджайл, на чем он зиждется?

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

Я не настолько крут, но тем не менее у меня есть своя версия относительно того, как появился эджайл-манифест.

В 2001 году собрались 17 профессионалов-практиков в сфере ИТ (это как раз наши Моисеи, только на этот раз не на Синайском полуострове, а в штате Юта), покататься на лыжах и за одно обсудить проблемы индустрии разработки ПО. И вот начали они рассказывать друг другу, как им живется. Оказалось, что общего у них довольно много. Точнее много схожих проблем. И решили они, что надо с этими проблемами что-то делать (доколе можно терпеть, граждане?). И написали манифест…

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

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

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

И вот глядя на это все, пригорать начало уже у меня. И я подумал: «А чем я хуже? Возьму и напишу свой манифест!» И написал. Он ниже. За основу я брал официальную русскую версию манифеста agile и постарался сохранить общий подход, а где-то и части формулировок. В качестве бонуса я снабдил это дело не в меру вольными комментариями. Сразу скажу, что даже просто понять эту муть будет непросто: серьезность смешивается с иронией, а потоки сюрреалистического сумбура — с каплями квинтэссенции опыта. Ну и потом все это делится на ноль. Два раза. Для надежности. Хотя, если вы дочитали до этих строк, то вам должно быть уже нестрашно. Я в вас верю. Го!

Ценности


1. Контекст важнее лучших практик.

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

2. Общее понимание цели важнее методологических концепций.

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

3. Зафиксированное важнее воображаемого.

Концепции, какими бы прекрасными они ни были, не будут значит ничего, пока не превратятся в реальный объект. Мы бы ничего не узнали о чудесных идеях Гауди относительно собора Святого Семейства, если бы он не оставил нам мало-мальски пригодных чертежей. То, что кто-то себе думает и не формализует, само по себе ценности не несет. Давайте не будем притворяться, что это не так. Посему, фиксируйте, господа!

4. Подвижность ума важнее категоричности.

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

5. Апельсины важнее яблок.

Здесь все понятно.

Принципы


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

Комментарий: на самом деле можно и закон нарушить, только не говорите никому, а то еще буквально поймут.

2. Изменение требований означает, что требования все-таки есть. Если есть требования – ими можно управлять. Управляйте требованиями.

Комментарий: вообще требования несут столько функций, что думать о них только как о постановке задачи – преступление против человечности. Если не умеете в требования – учитесь, это важно.

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

Комментарий: только представьте себе – в определенных ситуациях вы можете быть ультра гибкими и супер-пупер эффективными на протяжении очень длительного времени (в разищи больше, чем набившие оскомину 2-х недельные спринты), выпустив при этом в результате всего лишь один релиз продукта. Без шуток. Я даже больше скажу, но это уже сложно будет выдержать: при этом еще и заказчик будет хэппи. И теперь скажу совсем невероятное: при этом и продукт будет огонь, и пользоваться им будет в радость с пользой. Конечно, это возможно не всегда и не везде. Но такое бывает, братцы, и не так редко, как вы сейчас подумали. Так что короткий релизный цикл – это, увы, не благо само по себе.

4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать. Для достижения целей проекта.

Комментарий: несмотря на кажущуюся простоту, это самый сложный для понимания пункт. Сложно понять. Сложнее – принять. Еще сложнее – начать действовать. И практически подвиг – жить согласно этому принципу. Но если вы вдруг дойдете до вершины (говорят, что дорога к вершине Эвереста просто усыпана трупами тех, кто не смог и их используют как ориентиры), то вы разорвете и выйдете из круга Сансары хождения на работу. Вы станете над ней, вне ее. И только безграничное сознание собственной всемогущности будет напоминать вам о том, что вы еще существуете. Так, простите, я тут книгу по эзотерике в параллель читаю, так что… ну, вы все поняли.

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

Комментарий: многие думают, что эджайл не подразумевает управляторства. А зачем: продукт оунер задачи хоп и в бэклог записал, потом хопчик – и в сторис расписали, а тут, хоба – спланировали спринт и в разработку с автотестами и за две недели хабас – и в ПРОДас. Бывает и такое, не спорю. А бывает по-другому. И вот в этом «по-другому» без менеджера никак. Многие забывают о том, что вот эти обеспечение поддержки и условий, во многом и есть работа менеджера. А если вы еще хотите планировать, где окажетесь через два-три-шесть месяцев – тут и подавно. А если у вас еще 1-2-5-10 контрагентов, то уж точно. А если у вас и команд 5-10-20, то просто никак по-другому. До сих пор хотите без менеджмента? Видел я таких – ходят потом по собеседованиям, рассказывают, что стартап был годный, но не взлетел, ибо рынок еще не готов.

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

Комментарий: вы, должно быть, устали. Устал и я, т.к. думал, что текста на страничку напишу, а не вышло. Не выйдет и у вас, если будете ориентироваться на интуитивные представления о коммуникациях. Только в случае моей ошибки – потеря невелика, т.к. максимум этот манифест просто никто не дочитает до этих строк. А вот в реальной работе можно очень сильно поплатиться, если ваша коммуникация будет неэффективной. Потери могут быть разные: лишняя работа, испорченные отношения с заказчиком или членами команды, выбор неверного пути развития. В итоге: всегда исходите из ситуации. Иногда один звонок на минуту разговора может быть полезнее, чем гневная переписка с руководством в копии. А иногда без детальных формулировок в письменной форме или без таблицы с графиком просто невозможно передать суть ситуации и очень милые встречи face-to-face тут просто не помогут.

7. Работающий продукт сам по себе не показатель ничего.

Комментарий: а вы разве не знали?

8. Процесс работы должен способствовать устойчивому развитию. Ритм работы должен обеспечивать ее комфорт и эффективность.

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

9. Постоянное внимание к техническому совершенству и качеству проектирования снижает вероятность серьезного рефакторинга при развитии продукта.

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

10. Простота — искусство минимизации лишней работы — крайне необходима, когда она уместна.

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

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

Комментарий: простите, но в манифесте без патетики никуда. Ни в оригинальном, ни в моем.

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

Комментарий: как часто риторически вопрошает одна моя коллега «А не фигню ли мы делаем?». Ответив на ее вопрос отрицательно, я всегда чувствую острую потребность проверить «А не фигово ли мы делаем?», раз она спрашивает. Советую сделать эти два вопроса минимальным чек-листом для непрерывного анализа своей деятельности. Иначе, как у нас в народе говорят, удачи не видать.

13. Подписывайте манифест… и выкидывайте его.

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

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

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

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

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

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

              0
              «Проект это ограничение по времени предприятие, целью которого является удовлетворение интересов заказчика»

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

                0
                Подождите, а мы точно об одном знаменателе говорим?
                Я говорил о том, что в некоторых случаях заказчик может быть удовлетворен, если результат проекта достигнут только на бумаге. То есть не было существенных трудозатрат ни с одной стороны. И все стороны довольны. Для бизнеса исполнителя — это манна небесная.
                  –1

                  К проектному бизнесу это уже не имеет никакого отношения и называется просто распил бабла.

                    0
                    Распил, всё же, нечто большее чем простое освоение бюджета.
            +2
            такое бывает, братцы, и не так редко, как вы сейчас подумали.

            И сразу прикладывайте пруфы, пожалуйста. Я вот не знаю таких примеров, что бы долгий релизный цикл шел продукту на пользу. Зато много примеров, где короткий релизный цикл помогает. Ну, например, фиск багов :)

              0
              Да легко. Мы в текущем проекте длительное время делали релизы каждые две недели. Пока не поняли простую вещь — чтобы эти релизы были полезны нашему потребителю — он должен за нами тривиально успевать.

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

              Про фиск багов ;) — не вопрос. Но даже в этом случае выпуск новой функциональности вполне может проходить по совсем другому, более длинному циклу.
                +1

                Продукту может быть и нет, но проекту — вполне. Часто лучше потратить пару месяцев на ТЗ, согласовать его, чтобы потом иметь железобетонные рамки, ограничивающие бесконечную фантазию заказчика.

                  0
                  Если мы говорим про agile, то:
                  1. Заказчик все-таки ваш друг, пусть и немного больной.
                  2. Ничто не мешает согласовывать ТЗ параллельно тому, как идет разработка, если у вас таки команда.
                0
                Пиши манифест и бросай его в воду (с)
                  +2
                  >Наивысшим приоритетом является удовлетворенность заказчика

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

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

                  «Розовые щеночки» (локальный мем среди дизайнеров — когда заказчик пытается удовлетворить, в первую очередь, своё ощущение «правильности» продукта в ущерб привлекательности продукта для потребителя) станут появляться на рынке реже тогда, когда заказчики поймут, что всё меньше исполнителей соглашаются изготовлять подобный отстой.
                    +1
                    Может Гугл придумает новый манифест — гуглфест…
                    И лжепророки эджайл будут каяться…
                      +7
                      Дано: цель, удаленная от старта на 30 км. (марафонская дистанция)
                      Требуется: добежать до цели всей командой, за минимально-возможное время

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

                      Аджайл: У нас есть марафонская дистанция, и есть толпа сильных профессионалов! Отлично!
                      Что есть марафонская дистанция? Это ничто иное, как триста спринтерских дистанций! Отлично! Измеряем скорость каждого члена команды на стометровке — она намного выше чем скорость рекордсменов-марафонцев. Видите какой отличный у нас подход! Все получится, ведь мы самая лучшая, сильная команда замотивированных профессионалов!!!
                      Стартуем! Заодно, что-бы не было скучно, давайте в конце каждой стометровки будем менять конечную цель, отодвигать ее немного, ну заодно и маршрут поменяем.
                      Что случилось!? Почему команда крепких, замотивированных профессионалов лежит на земле, тяжело дышит и на требования подняться и бежать, шлет всех матерно? Мы ведь не пробежали еще и километра! Плохая команда, плохие профессионалы! Нам нужны другие люди, а не эти ленивые жопы!

                      Шутка, конечно, но в каждой шутке…
                        0
                        Измеряем скорость каждого члена команды на стометровке — она намного выше чем скорость рекордсменов-марафонцев.

                        Вроде обычно скорость команды измеряется целиком. Я правда только про скрам и канбан знаю.

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

                              Agile это скорее про добавление pacemaker в вашу команду, который будет выдерживать плановый темп на разных участках. В беге не так заметно, но например в speedskating роликовый пак едет сильно быстрее отдельного спортсмена…

                            0
                            Одна, но важная поправка: в марафоне 42 км 195 м, то есть почти 420 стометровок. И самое интересное (по ощущению бегуна) начинается именно после 30 км. Говорю как практик.
                              0
                              В данном контексте это не принципиально, но за поправку спасибо.
                              Меня как-то после армейских маршбросков на 10 км., в полной выкладке, на марафонские дистанции не тянет бегать, как-то не слишком приятные воспоминания, хотя и понимаю что марафон бегут налегке. Поэтому даже и не интересовался раньше, сколько там конкретно километров.
                            +1
                            Стартуем! Заодно, что-бы не было скучно, давайте в конце каждой стометровки будем менять конечную цель, отодвигать ее немного, ну заодно и маршрут поменяем.

                            В конце каждой трехсотметровки помимо прочего еще и ленточку рвать нужно, интервью раздавать, самому опрашивать зрителей о том все ли им понравилось, и в зависимости от их ответов менять стратегию, технику и темп бега на следующем участке.
                              +3
                              Да, еще через каждые десять метров каждый член команды должен громко и с позитивным настроем отчитаться о том как он пробежал эти десять метров и как он планирует пробежать следующие десять.
                              +1
                              В 90% случаев все забивают на требование «компактная команда из профессионалов», начинают слепо выполнять ритуалы и даже верить, что они помогли. А потом разводить дискуссии на километры, карго-культ это или нет.
                              Если команда изначально состоит из профи, то в некоторых случаях эта методология может приносить пользу. Что совершенно не обозначает обязательности её применения всегда и на всех проектах. Решать нужно по ситуации, как работать.
                                +1

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

                                  0
                                  Про реальный мир — согласен полностью.
                                  И вот исходя из этой предпосылки, разве не следует, что область применения Agile должна быть серьёзно пересмотрена? Командам из сильных профессионалов оставить право использовать её или нет, в сборных командах из разноуровневых специалистов перестать её навязывать. А в некоторых случаях давать по рукам манагерам, которые по разным причинам просто рвутся внедрить ритуалы, без понимания основ.
                                +1
                                Очень часто вижу «релизы раз в две недели». Разве есть где-то такое в гайдах по аджайлу, скраму и т. п.? Релизы могут быть десять раз на дню, а может быть один за несколько лет, но при этом двухнедельные спринты никак этому не противоречат.
                                  0
                                  Вы очень правильно написали. «Разве есть где-то...?» Это не важно, т.к. есть такое понятие, как практика применения. И вот в этой практике огромное количество команд выпускает (или очень стремится к этому) релиз в конце спринта, как правило двухнедельного. Можно соглашаться с правильностью такого подхода или нет, но так есть сейчас.
                                    0
                                    Ну, не знаю. Много где сейчас CI/CD внедряется, наряду со SCRUM с одной стороны, с другой релизы могут планироваться на значительно бОльшие сроки, например, два раза в год, при наличии всех или большинства атрибутов скрам.
                                  0
                                  Впитывай все, что есть. Пропускай через себя. Выбирай. Проверяй. Улучшай. Повторяй. Полностью согласен с вашими тезисами. За юмор спасибо.
                                    0

                                    Спасибо за внимание и внимательность.

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

                                  Самое читаемое