Первое, с чем необходимо было разобраться – учет и планирование рабочего времени. Заказчики и начальство постоянно заявляли о затягивании сроков по разработке, часто подымались вопросы о том, что программисты ничем не занимаются вовсе. Одним словом, ситуация сложилась более чем критической.
Тем не менее, team leader принял решение о переводе разработки на Scrum/Agile, что, как выяснилось через некоторое время, принесло свои результаты. Вот список изменений, которые были внесены в процесс разработки:
- Спринты наше все. В буквальном смысле все. Все время разработки разделено на равномерные отрезки, которые в нашем случае длятся две недели – наиболее удобный для нас промежуток времени. Время спринта может коррелироваться в соответствии со сложностью и объемом исполняемого проекта. Но в последнее время длительность спринта так и не удавалось сократить на срок менее двух недель. От себя могу добавить, что методика разбиения времени разработчиков на спринты очень удобна и программистам и начальству, поскольку первые получают определенный список задач, ТЗ которых не изменяется на протяжении спринта, а вторые видят определенный результат после окончания итерации разработки.
- Среди разработчиков был назначен Scrum Master – один из разработчиков, на широкие плечи которого был возложен тяжелый груз общения из заказчиком, а также проведения ежедневных Daily Scrum Meeting. Теперь мы смогли более сконцентрироваться на разработке, а не на выяснении отношений со свирепыми пользователями, объясняя им, почему мы не будем решать ту или иную задачу здесь и сейчас.
- Daily Scrum Meeting – очень полезные штуки. Всего за 10 минут рабочего времени каждому нужно рассказать о том, что он сделал вчера, что получилось, а что не получилось и что он будет делать сегодня. В результате у сотрудников возросла мотивация, процесс разработки стал более интересный и качественный, поскольку можно оперативно получить помощь или критику (обоснованную) от более продвинутых коллег. Митинги проводим даже в том случае, когда один из разработчиков опоздал или в командировке (используем Skype в качестве скринкастера или звонилки). Буквально за первую неделю практики Daily Meeting наш коллектив стал более дружественный и сплоченный.
- Следующий пункт – разделение задач по категориям. В каждом проекте наши задачи делятся на категории.
- Идеи. В эту категорию попадают задачи-хотелки пользователей, у которых нету ТЗ и которые мы возможно даже не будем делать(из-за абсурдности самой задачи, или присутствием в той или иной конфигурации стандартного функционала, решающего проблему).
- Кандидаты на реализацию. Задачи, которые точно будут реализованы, но не имеют точно сформулированного ТЗ.
- Необходимо обсудить. Задачи, которые возможно будут реализованы, но хотелка пользователя непонятна для разработчика.
- Технические истории. В этот раздел попадают задачи программистов для программистов, задачи – результат выполнения которых не будет виден конечному пользователю (библиотека, оптимизация запроса).
- Product Backlog. Собственно задачи с четким ТЗ, которые точно нужно выполнить или коммерческие задачи, за которые хорошо платят.
- Каждая задача оценивается в story points (в количестве дней, которые разработчик потратит на выполнении задачи). Если задача занимает пять или больше дней – ее необходимо разбить на более мелкие задачи и желательно распараллелить мелкие задачи между несколькими разработчиками, для увеличения уровня совместного владения кодом. Количество времени, необходимое для решения задачи ставят сами разработчики, после завершения очередного спринта осуществляется переоценка задач в Product Backlog на следующий спринт, чтобы сориентировать заказчика на сроки выполнения проекта.
- Каждый спринт начинается из Planning meeting, на которым мы вместе с Product Owner (иными словами заказчиком) набираем задачи на 36 story points (4 разработчика на 9 дней разработки). Главная задача Planning meeting состоит в том, чтобы заказчик увидел объем работ, который будет выполняться в последующий отрезок времени и продукт, который он получит в результате выполнения намеченных работ.
Следующей проблемой, которую нам предстояло решить – побороть то количество ошибок, которое возникало в следствии увеличения сложности проектов и низкого уровня совместного владения кодом, проще говоря, одному разработчику было сложно разобраться с кодом, написанным другим разработчиком. В результате мы предприняли следующие меры:
- Переход на стандарты написания кода от самой 1С. Кому интересно почитать можно здесь – очень полезная методичка, в которой описано как и что правильно делать, а что делать нельзя. Также там поднимаются вопросы о производительности кода, оптимальности работы запросов, уменьшению количества клиент-серверных вызовов и многое другое, что будет полезно и начинающему программисту и человеку с большим опытом. Каждый наш разработчик потратил определенное количество времени на изучение материала, а сейчас, мы повсеместно применяем его на практике, как во внутренних проектах так и при разработке под заказ.
- Code review. Думаю, это просто необходимость в современных проектах. При написании обработок, где количество строк кода исчисляется тысячами без него не обойтись. Часто удавалось отловить злую ошибку влияющею на производительность работы всей системы еще до внедрения у клиента. В нашей команде это стало стандартом – проверять код написанный коллегой и по возможности проводить рефакторинг или оптимизацию. Да, возможно стоимость разработки возрастает, но взамен мы получаем более стабильный код, меньшее количество ошибок, быстрый тем роста новых сотрудников.
И еще несколько слов о инструментах, которые помогают нам справляться со всеми нововведениями.
http://realtimeboard.com/ - онлайн доска, которая заменяет нам обычную. На ней мы рисуем наш Burn down chart (очень важный элемент в процессе разработки, поскольку позволяет увидеть, успеваем мы с проектом или нет), разные алгоритмы, или просто комиксы, связанные с разработкой :).
http://www.redmine.org/ - опенсорсный дашбоард в котором мы и ведем все наши проекты. Удобно с точки зрения возможности подгона под наши потребности к процессу разработки с помощью разнообразных плагинов и настроек. Здесь есть и проекты, и статусы задач, и чек-листы, и многое другое.
http://www.kayako.com/ - для улучшения работы службы поддержки пользователей. С помощью программы регистрируется каждое обращение в службу поддержки (письмо по электронной почте, звонок или персональный визит).
Вот и все. Но в статье описана только вершина айсберга. А как вы, уважаемые читатели, работаете над повышением качества разработки и жизни самих разработчиков внутри своей команды?
Статья опубликована также на сайте avtomat.biz
