+7 (499) 638-64-11
Попробовать
Постановка и автоматизация процессов разработки ПО

Контрольный список для корпоративного Agile

08.02.2013 21:02

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

 

Вот о чем вам следует подумать:

  1. Ваша система укомплектования штатов. Действительно гибкий agile-проект требует того, чтобы полноценная команда была задействована на протяжении всего срока выполнения проекта в необходимых пропорциях. Поэтому на стадии планироания проекта убедитесь в том, что такая модель комплектования кадрами может быть реализована. Если она реализована быть не может, вы столкнётесь с рисками нехватки персонала. Если говорить конкретно, это означает, что:
    • Вам для работы нужны будут ваши UX-специалисты (если они вообще нужны в проекте) и ваши аналитики, как всегда, в самом начале проекта, но их присутствие в проекте требуется до самого конца.
    • Ваши тестеры, включая специалистов, тестирующих продукт с точки зрения пользователей, должны участвовать в проекте с самого начала, а не подключаться в самом конце, не понимая, куда они попали.
    • Также следует обратить внимание на то, соблюден ли правильный баланс между UX-специалистами, аналитиками, разработчиками и тестерами. Один проектировщик может уйти далеко, однако в Agile начальное предположение состоит в том, что у вас будет один аналитик и один тестировщик на каждых четырёх разработчиков. Также следует отрегулировать этот баланс, опираясь на специфику проекта и людей под вашим руководством. Так что вопрос будет стоять так: собрали ли вы необходимые ресурсы, и будут ли они в вашем распоряжении достаточно долго?
  2. Окружения. Помимо вашей среды разработки, тестинговая среда и компоновочная (staging) предпроизводственная среда должны быть настроены с самого начала и до самого выпуска финального продукта. Все эти среды должны быть настроены таким образом, чтобы вы могли вставить в них любой код по своему желанию, используя такие инструменты, как Go или Jenkins.
  3. Подготовка сотрудников. Я рекомендую готовить отобранную команду, опираясь на методологию, которую вы собираетесь использовать. Рецептов гибкости много. Когда вы приступаете к работе, необходимо выбрать один из них. Если вы действительно гибки, вы сможете меняться на ходу, и точка старта не будет иметь большого значения. Лучше всего, если члены вашей команды пройдут эту подготовку до формирования "гибкой" рабочей группы (см. пункт 5).
  4. Коучинг. Возможно, вам потребуется инструктор для каждой команды/направления работы для того, чтобы преодолеть барьеры культуры, нюансов процесса и смены инструментария. Инструкторы потребуются как минимум до стадии планирования релиза и пары первых правок, по срокам это примерно один квартал в случае, если вы работаете над проектом среднего размера, и используете 2-х недельные итерации. После первого квартала инструктор, скорее всего, не понадобится потому, что ваши команды к тому моменту будут в состоянии двигаться дальше самостоятельно. Однако, на первых этапах инструктор будет очень полезен, так как его работу делать самостоятельно весьма непросто.
  5. Семинар (workshop). Пожалуйста, используйте какой-то структурированный процесс при построении "баклога релиза" из "пользовательских историй". На фазу подготовки и планирования релиза выделите 3-4 недели, если работаете над проектом с общим сроком 3-6 месяцев.
  6. Нулевая итерация. Перед началом работы над проектом, выделите ещё 2-3 недели на подготовку окружений для разработки, тестирования, и изучение подробнейшим образом требований на первый цикл работ. Как я люблю говорить, сначала целься, потом стреляй.
  7. Гайдлайны по графическому интерфейсу. Если вы работаете над ПО, которое потребует разработки графического интерфейса, у вас должен быть некий набор правил (гайдбук) для интерфейса. Кроме того нужен человек, который сможет показать разработанные правила на примерах. Такая политика ограничит пространство для спора о том, что должно быть на экране, ведь правила это уже оговаривают.
  8. Аудит. Если с этим пунктом всё в порядке, вы всегда будете знать, что происходит, потому что присутствуете лично на стадии планирования релиза, и можете видеть план целиком и задачи, которые будут выполнены в ближайшее время на разных направлениях вашего проекта. После первого цикла и после всех последующих успешно завершенных циклов работ у вас будет работающее ПО. Если возникает проблема, то внимание на неё будет обращено в момент обнаружения, а не в последние минуты. Таким образом, с самого начала вы должны немедленно насторожиться, если:
    • Отсутствует высокоуровневая архитектура. В "гибком" проекте мы призываем разработчиков не углубляться в детали архитектуры до внесения изменений в сам код. Но с другой стороны, большие "модули" проекта должны быть хорошо продуманы и известны. Кроме того, должен существовать продуманный план включения кода из маленькой работающей программы в большую работающую программу. Отсутствие архитектуры это плохие новости.
    • Отсутствует план. Некоторые педанты от Scrum скажут вам, что вы ‛потратили деньги клиента впустую, если вы провели у него больше часа, прежде чем начали писать код.“ Для крупной компании это абсолютно неверно. Работа должна быть представлена, как ряд рабочих модулей, так называемых ‛пользовательских историй“, которые занимают в среднем по несколько дней каждая. Большие и неточные "истории" это плохой знак. Кроме того, они должны быть отслеживаемы до соотносимого с ними бизнес-процесса или экранного макета, так, чтобы любой руководитель проекта со знанием системы мог сказать, что это конкретное изменение привносит в весь проект в целом. Должен существовать план на этот случай, и он должен быть проработанным.
    • Отсутствует информационная панель (dashboard) проекта, или у вас нет к ней доступа. У вас должен быть доступ к внятной проектной информационной панели 24 часа в сутки 7 дней в неделю.
    • Вас не пригласили на собрание по планированию цикла работ и/или презентацию каждого цикла. А презентация, помимо прочего, должна показывать рабочее ПО. На каждой презентации вы должны убеждаться в том, что команда разработчиков находится там, где они должны быть по плану.
    • На стадии планирования рабочего процесса не возникает никаких проблем. Похоже, вы занимаетесь проектом "Stepford Project".
    • Команда работает безупречно на 1-й итерации. Обычно, новым agile-группам требуется 1-3 итерации для того, чтобы сработаться. Если ваша команда сдает работы по итерации 1 идеально в срок, вполне вероятно, что кто-то из них очень много работает сверхурочно, и уже звонит на работу с известием о своей внезапной болезни или вымышленном умершем родственнике, чтобы избежать давления. Мне доводилось такое видеть не раз.
    • Вашему присутствию на ежедневных "Scrum-собраниях" в качестве наблюдателя не рады. Эти собрания проходят очень быстро, и их правильная организация занимает немало времени, поэтому приходить на них и начинать болтать направо и налево это не самое лучшее решение, однако вы точно должны иметь возможность обратиться к команде после их завершения.
    • Вы не можете получить точные данные по качеству ПО (сложность кода, уровень дефектности, производительность и т.д.). У вас должна быть возможность просматривать эти цифры. Вы должны быть в курсе показателей дефектности, а когда начнётся разработка каков этот уровень у CR из-за "некачественной сборки".
  9. Стабильный темп. Сроки по проекту горят, и у вас может возникнуть искушение работать день и ночь в течение года для того, чтобы успеть вовремя. Это ставит под угрозу качество, прямо и косвенно. Уставшие люди делают больше ошибок, а текучка кадров создает условия, когда некомпетентные люди двигают весь процесс. Управлять персоналом и их графиком нужно разумно, и результат будет достойным. А ваша команда будет счастливой.
  10. Опасайтесь фанатиков. Сейчас очень много "исчерпывающей" информации о гибкой методологии разработки. Большинство классической информации было написано людьми о средах, существенно отличных от вашей. Каждый раз, когда вы видите фразу ‛это не имеет ничего общего с гибкой методологией, если…“, вам следует насторожиться. Гибкие agile-методы дают множество возможностей, но для того, чтобы извлечь из этой методологии пользу, не забывайте о здравом смысле, человеческой природе, профессиональной компетенции и крепком прагматизме. Не пользуйтесь советом до тех пор, пока человек, дающий вам его, не объяснит, почему это будет полезно конкретно в вашем случае. И эта статья не исключение!

 

Оригинал статьи

 

Об авторе

Elena Yatzeck занимает должность VP and Chief Agilist (что-то вроде самого главного по Agile), в прошлом консультант ThoughtWorks. Высокоэнергичный лидер в организации взаимодействия между сотрудниками, улучшает эффективность бизнеса путем настройки корпоративных технологий, процессов и людей. Ссылка на профиль в LinkedIn: http://www.linkedin.com/in/eyatzeck

 

Еще интересные статьи на эту тему: