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