» » Agile в небольших командах — как красиво сломать себе шею

 

Agile в небольших командах — как красиво сломать себе шею

Автор: admin от 5-02-2017, 19:55, посмотрело: 229

Я весело вещал на киевской партнерке про Agile в небольших командах. Но… недовещал, а только разогрел. Хочется, все таки, закончить повествование и рассказать, наконец, правду-матку о том, как все таки красиво Agile ломает шеи разработчикам и менеджерам! Наливаем кофе и ныряем под кат, будет очень весело.

Программирование — только для умных

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

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

А самое страшное, что может тут произойти — это работать с ненастоящими программистами долго и успешно над простыми примитивными проектами, не требующих глубоких знаний, а затем заняться интересным, сложным проектом с примесью Computer Science — веселье предстоит просто улетное: все ломанутся на StackOverflow и начнут заново изобретать… алгоритмы и удивляться, что TCP отличается от IP!

Детали — важны, как никогда ранее

К сожалению, чтобы программировать правильно, нужно знать язык программирования глубоко и широко. Если это простые динамические языки типа Python, Ruby, PHP, javascript — то знать там особо нечего, тонкостей и внезапных сложностей практически нет и можно лепить что лепится и оно будет как-то работать до определенного момента.

Но чтобы писать на «настоящих» промышленных ЯП, таких как C++, Java или C# — требуется интенсивная подготовка в течении парочки лет и чтение и понимание толстых книжечек и всех тонкостей языка. Но это только начало — важно научиться программировать в парадигме ООП — а это еще тройка лет и чтение другой стопки книжечек по шаблонам проектирования.

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

Проектирование — иначе просто нельзя

Вы правда поверили сказкам, что можно размазать эмоциональный бред на листочки, а на обратной стороне написать definition of done в стиле «фи/не фи» и не проектировать? Да вы, братец, с ума сошли. Любая более-менее сложная система требует обмозговывания и потребления у доски пары десятков чашек кофе. Логическая схема сущностей, ролей, формальное описание алгоритмов — должны быть сделаны с полной алгебраической беспощадностью. Тут, как раз, пригодится знание UML. Иначе вы будете похожи на обезьяну, с пренебрежением поглядывающую на коммутационный щит с проводами с мыслью: «фигня вопрос, все тут и так понятно, главное — я такая красивая». Поэтому не позволяйте глупости и лени захватить мозг проектной команды и всегда строго формализуйте сложные вещи.

Программистами — не нужно управлять

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

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

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

Но если менеджер сознательно «включает дурачка», надевает «розовые очки» и начинает публично играться в листочки c эмоциональным бредом (ProductBacklog), досочки (Burndown), картишки (PlanningPoker) и улыбаться на Retrospective так, что ждешь, что вот вот случится каминг-аут — то, скорее всего, проект обречен и сделать уже ничего нельзя.

«Из курочки — сварит и дурочка»

Поэтому — расслабьтесь и не пытайтесь изучить и отличить "водопад" от RUP, а Scrum от Kanban — это не поможет. Сосредоточьте усилия на поиске настоящих программистов! Команда сама выберет наиболее адекватную проекту методологию, число тестировщиков, аналитиков и, что особенно важно, бригаду адаптации эмоциональных эманаций клиента в область строгой формализации и алгоритмов — всяких менеджеров разных мастей и научит их работать.

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

Agile — для спецназа

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

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

Никогда не забывайте историю появления XP и судьбу девушки-product owner, которую Kent Beck с невменяемыми заказчиками довели до паралича и нервного тика лица. Зато да, книжки написали интересные… :-)

Качество кода и сплоченность команды — превыше всего

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

А что такое красота программного кода? Это:


  • простота

  • ясность

  • лаконичность

  • последовательность

  • понимание, что происходит «под капотом» и правильное использование возможностей операционной системы и протоколов

  • расширяемость или готовность к этому

  • документация только там, где она нужна!


Человек открывает код… и ему приятно развивать его дальше, у него повышается настроение! А бывает же, что открываешь код и с трудом сдерживаешься от рвоты — это правда жизни.

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

Выводы

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

  • Сосредоточьтесь в первую очередь на поиске и наеме профессиональных, настоящих программистов и вспомогательного персонала (аналитики, тестировщики, менеджеры всех мастей)

  • Если удалось подобрать адекватную команду — пусть она сама выберет методологию разработки и знайте, что с любой методологией проект скорее всего взлетит

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


P.S.: По-секрету, говорят есть способ все таки взлететь в любом случае — работать по строгому водопаду с ТЗ, unit-тестами, жесточайшей дисциплиной и человеческими жертвоприношениями Ктулху. Но это если повезет. А иначе вы попадете в суровую атмосферу Первой мировой и будете заниматься матстатистикой — прогнозом и подсчетом потерь личного состава от лягания лошадей и вести активную борьбу с каннибализмом. Удачи!

Источник: Хабрахабр

Категория: Программирование

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

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *