Scrum и XP: заметки с передовой
Шрифт:
Совместное владение кодом (Collective code ownership)
Мы выступаем за совместное владение кодом, хотя ещё не все наши команды внедрили у себя эту практику. На собственном опыте мы убедились, что парное программирование и постоянная смена пар автоматически увеличивают уровень совместного владения кодом. А команды, у которых совместное владение кодом на высоком уровне, доказали свою высочайшую надёжность. К примеру, они никогда не проваливают спринты из-за того, что у них кто-то заболел.
Информативное
У всех команд есть доступ к доскам и незанятым стенам, которыми они действительно пользуются. Во многих комнатах стены завешаны всякого рода информацией о продукте и проекте. Самая большая проблема у нас — постоянно накапливающееся старье на стенах. Уже подумываем завести роль «домработницы» в каждой команде.
Хотя мы и поощряем использование доски задач, еще не все команды внедрили их (см. стр. 43 «Как мы обустроили комнату команды»)
Стандарты кодирования
Недавно мы начали определять стандарты кодирования. Очень полезно — жаль не сделали этого раньше. Это не займёт много времени, начни с простого и постепенно дополняй. Записывай только то, что может быть понятно не всем, при этом, по возможности, не забудь сослаться на существующие материалы.
У большинства программистов есть свой индивидуальный стиль кодирования. Мелкие детали: как они обрабатывают исключения, как комментируют код, в каких случаях возвращают null и так далее. В одних случаях эти различия не играют особой роли, в других могут привести к серьёзному несоответствию дизайна системы и трудно читаемому коду. Стандарты кодирования — идеальное решение этой проблемы, если они, конечно, регламентируют важные моменты.
Вот небольшая выдержка из наших стандартов кодирования:
• Вы можете нарушить любое из этих правил, но на то должна быть веская причина и это должно быть задокументировано.
• По умолчанию используйте стандарты кодирования Sun: http://iava.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
• Ни при каких обстоятельствах не перехватывайте исключения без сохранения полного стека вызовов программы (stack trace), либо повторной генерации исключения (rethrow). Допустимо использование log.debug, только не потеряйте стек вызовов.
• Для устранения тесного связывания между классами применяйте внедрение зависимостей на основе сеттеров (Setter Based Injection) (разумеется, за исключением случаев, когда такое связывание просто необходимо).
• Избегайте аббревиатур. Общеизвестные аббревиатуры, такие как DAO, допустимы.
• Методы, которые возвращают коллекции или массивы, не должны возвращать null. Возвращайте пустые коллекции и массивы вместо null.
Устойчивый темп / энергичная работа
Множество книг по Agile-разработке программного обеспечения утверждают, что затянувшаяся переработка ведёт к падению продуктивности.
После
Около года назад одна из наших команд (самая большая) очень-очень много работала сверхурочно. Качество кода было ужасное, и большую часть времени команда «тушила пожары». У тестировщиков (которые тоже работали сверхурочно) не было ни малейшей возможности нормально протестировать систему. Наши пользователи были в ярости, а газетчики готовы были нас растерзать.
Спустя несколько месяцев мы смогли уменьшить количество переработки до приемлемого уровня. Люди перестали работать сверхурочно (кроме редких кризисов в проекте), и — вот сюрприз! — и производительность, и качество кода заметно улучшились.
Конечно, уменьшение количества рабочих часов не было единственной причиной повышения производительности и улучшения кода. Но мы уверены, что это сыграло существенную роль.
Как мы тестируем
Это самая сложная часть. Вот только я не уверен, то ли это самая сложная часть Scrum'а, то ли разработки программного обеспечения в целом.
Организация тестирования может достаточно сильно отличаться в различных компаниях. Всё зависит от количества тестировщиков, уровня автоматизации тестирования, типа системы (просто сервер + интернет приложение или, возможно, вы выпускаете «коробочные» версии программ?), частоты релизов, критичности ПО (блог-сервер или система управления полётами) и т. д.
Мы довольно много экспериментировали, чтобы понять, как организовать процесс тестирования в Scrum'е. Сейчас я попытаюсь рассказать о том, что мы делали и чему мы успели научиться за это время.
Скорее всего, вам не избежать фазы приёмочного тестирования
В идеальном мире Scrum’а результатом каждого спринта должна быть система, потенциально готовая к использованию. Бери и устанавливай, да?
А вот и нет!
По нашему опыту, такой подход обычно не работает. Там будет куча противных багов. Если «качество» для вас хоть что-нибудь значит, тогда придётся позаботиться о ручном приёмочном тестировании. Это когда специально выделенные тестировщики, которые не являются частью команды, бомбят систему теми видами тестов, о которых Scrum-команда не могла даже и подумать, или на которые у неё не было времени, или соответствующего оборудования. Тестировщики работают с системой точно так же, как и пользователи, а значит, что это нужно делать вручную (если, конечно же, ваша система разработана для людей).