Gaperton (gaperton) wrote,
Gaperton
gaperton

Categories:

Ag;)e Checklist

Готовясь к поездке в отпуск, я упаковывал трофейный рюкзак Microsoft, появившийся в доме после одной из конференций. И в одном из отделений я с изумлением обнаружил тонкую брошюрку под названием «Ag;)e Checklist. Очень краткое описание практик гибкой разработки». За авторством Асхата Уразбаева и Никиты Филиппова.

«Вот это называется - агрессивные методы продвижения», подумал я. «Как она туда попала?» Я посмотрел на невесть откуда взявшуюся брошюрку внимательнее. Брошюрка подкупала своей толщиной — со школьную тетрадку. «Черт бы тебя побрал, Асхат!» И, не в силах побороть любопытство, сел ее читать (это заняло примерно 5 минут). Но просто читать - это же скучно. Поэтому, я буду комментировать.


«Типичный размер команды — 7 плюс-минус два. По нашему опыту, чем ближе к нижней границе, тем лучше».

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

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

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

«Команда … кроссфункциональна. В нее входят люди с дополняющими навыками».

Это очень правильно. Радикально снижает трение между специальностями, делает возможным «независимое действие», и использование mission-type tactik. Он же — Auftragstaktik.

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

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

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

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

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

Поэтому — правильно сказать так. Естественная специализация в команде должна быть по возможности отдублирована. Во временной проблемной группе — это требование излишне.

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

А вот прикладная специализация по «кластерам» предметной области — добро.

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

«Команда должна сидеть в одном месте»

Это здорово, когда команда может сидеть в одном месте, правда? Однако - есть масса практических и конкретных преимуществ в том, что члены команды имеют возможность не просиживают задницы в одном месте в одно время. Вплоть до того, что все члены команды могут жить в разных городах — как я наблюдал в замечательной компании CodEdgers (35 инженеров!).

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

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

«Физически рядом» безусловно дает массу преимуществ. И ими надо пользоваться. Т. е. если есть возможность сажать людей вместе — надо так делать. Но существенно полагаться на него в подходе — нельзя. Это выйдет боком не только при распределенке — но и просто при росте размера команды.

Пример подхода, устойчивого к распределенке (обычно такие подходы полагаются на peer-to-peer коммуникации) — Chief Programmer Team (описан в «мифическом человекомесяце» Бруксом, кажется, без ссылок на авторство, и с измененной терминологией - как «команда хирургов»). Строится, что интересно - на совсем других принципах. Это — кроссфункциональная команда (таки да), которая построена на специализации, четкой субординации, и с выделенными ролями (таки нет, совсем не скрам).

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

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

Неплохо? Лучше не злоупотреблять, конечно. Но человек 9 общего состава такая группа должна выдержать легко.

Это была первая страница. «Команда».

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

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

Скрам в варианте Асхата как система в этом смысле определенно лучше, чем XP. Он вполне работоспособен во многих ситуациях.

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

А что? :) Как говаривал Кристобаль Хозевич Хунта - «какой смысл решать задачу, у которой есть решение»? :)
Tags: agile checklist, scrum
Subscribe

Recent Posts from This Journal

  • NestedTypes 2.0 RC: прямая поддержка агрегации и ОО в JS

    Че-та сюда написать забыл. Есть набор весьма неприятных проблем, которые возникают в JS в случае, если слой данных SPA действительно сложен. Знаете,…

  • NestedReact 1.0 beta. Hierarchical Checklist Demo.

    Пример из NestedReact 1.0 beta, которая сейчас в бранче develop. Это вот такой иерархический чекист с правилом - группа выбрана тогда и только…

  • Введение в NestedTypes

    React ValueLinks, это конечно, хорошо, но пришло время рассказать о нашей основной технологии, которая лежит в основе продуктов Volicon/Verizon.…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 5 comments