Постигая Agile. Дженнифер Грин
Читать онлайн книгу.
продукт, который добавляет ценность организации. Например, программный продукт, на котором компания зарабатывает деньги, или ПО, обеспечивающее более эффективную деятельность сотрудников компании. Для проекта это означает, что он должен заработать или сэкономить больше денег, чем стоимость разработки программного продукта. Ценность всегда связана с деньгами, даже если никто не говорит об этом напрямую. И команда должна придавать особенное значение тому факту, что ценность ей придает сборка и поставка работающего ПО. Документация – лишь средство достижения этой цели.
Приоритет работающего ПО над всеобъемлющей документацией не означает, что документы не нужны вовсе. Среди них очень много полезных для команды. Но важно иметь в виду, что документацию и программное обеспечение зачастую пишут одни и те же люди. Документация, помогающая им заранее, прежде чем они соберут ПО, понять проблему, общаться с пользователями и исправлять недостатки, экономит больше времени и усилий, чем нужно на ее создание. Часто также мы имеем дело с документацией такого рода, как каркасная визуализация или диаграммы последовательности, которые программисты вовсе не отказываются писать.
В то же время концентрация на работающем программном обеспечении – это отличный способ убедиться, что команда находится на верном пути. Работа над документацией, которая явно нацелена на создание работающего программного обеспечения, вносит позитивный вклад в проект. На самом деле часто команде может потребоваться новый подход к работе над документацией, что позволит этой документации быть встроенной в саму программу. Например, одна из agile-практик предлагает способ разработки ПО через тестирование: программисты строят автоматизированные модульные тесты до создания программного обеспечения, для проверки которого они предназначены. Эти тесты существуют в виде кода, хранящегося вместе с остальным кодом ПО. Но он также служит в качестве документации, потому что дает разработчикам сведения о том, что код должен делать и каким должно быть ожидаемое поведение отдельных элементов программного обеспечения.
Многие, читая «условия контракта», полагают, что они нужны лишь консультантам и подрядчикам, работающим в рамках контракта. На самом деле это касается многих команд, работающих в одной компании. Когда программисты, тестировщики, владельцы бизнеса и менеджеры проектов работают в разных командах и не сотрудничают в целях реализации единой рабочей программы, они часто ведут себя так, будто работают по разным контрактам. В большинстве компаний они явно будут обсуждать SLAs (service-level agreements – соглашения об уровне обслуживания) между командами программирования, тестерами и разработчиками, а также между командами и их пользователями.
Это, конечно, снизит риск конфликтов с руководством (потому что в подобном случае легче обвинить другую команду за непоставку ПО), но не поможет достичь главной цели – получить работающее