Мое бурное RSDN-овское прошлое на неделе подкинуло напоминание о статье Тома ДеМарко, актуальность и значимость которой, лично для меня, в последние годы многократно возросла.
Под впечатлением от ее перечитывания решил сделать перевод на русский язык. Получившийся результат под катом. За качество приношу свои извинения, оказалось, что свои небольшие знания языка я основательно подрастерял за последние годы. В каких-то местах это не дословный перевод, а пересказ близко к тексту, но "с сохранением смысла и интонации каждой фразы" (c) ;) Замечания по переводу с будут приняты с благодарностью.
Том ДеМарко
Идея, время которой пришло и ушло
Мы только что отметили 40-ю годовщину NATO-вской конференции по разработке ПО в Гармише (Германия), где разработка ПО впервые была обозначена как инженерная дисциплина. Поскольку несколько моих ранних работ стали частью этой дисциплины, то это, похоже, подходящий момент для переосмысления.
Моя ранняя книга по метрикам, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982), сыграла роль в том, как многие отнюдь не бестолковые разработчики ПО оценивали объемы задач и планировали свои проекты. Иногда я задумываюсь, были ли мои рекомендации правильными в то время, сохраняют ли они смысл сейчас и верю ли я еще в то, что эти метрики обязательны для любого проекта по разработке ПО? Мои ответы: нет, нет и нет.
Книга для меня -- это странное сборище в общем-то правильных вещей, описываемых на ее страницах, но будучи собранными вместе, они формируют мысль, которая оказывается не правильной. Как будто бы у юного автора книги вообще нет метрик, которые ему бы не нравились. Глубинная мысль книги: сбор метрик -- это хорошо, сбор еще большего количества метрик -- еще лучше, ну а сбор еще большого количества метрик -- вообще замечательно. Сегодня мы все понимаем, что метрики требуют денег и времени, и должны применяться с осторожной сдержанностью. В добавок, разработка ПО по сути своей очень сильно отличается от естественнонаучных предметов, таких как физика, и метрики намного менее точны в измерении тех вещей, для описания которых они собираются. Они должны быть приняты с настороженностью, вместо того, чтобы доверять им без тени сомнения.
Вынужденный контроль
Наиболее цитируемая часть книги -- ее первая строка: “Вы не можете контролировать то, что не можете измерить”. Эта строка содержит истинную правду, но мне все больше и больше не нравится то, как я ее использовал. В ней (как и во всей книге) неявно подразумевается, что контроль -- это очень важный аспект, может быть самый важный в любом программном проекте. Но это не так. Множество проектов выполнялось без серьезного контроля, но их итогом стало появление таких замечательных продуктов, как GoogleEarth и Wikipedia.
Для понимания реальной роли контроля вы должны различать два принципиально разных типа проектов:
- Проект A может обойтись в $1M и принести один $1.1M прибыли.
- Проект B может обойтись в $1M и принести более $50M прибыли.
Сразу же становится очевидно, что контроль действительно необходим проекту A, но практически не важен для проекта В. Это ведет нас к несколько странному выводу о том, что жесткий контроль много значит для относительно бесполезных проектов, но менее значим для по-настоящему полезных. Т.е., чем больше вы концентрируетесь на контроле, тем более вероятно, что вы работаете на проекте, итогом которого станет что-то с относительно небольшой ценностью.
По-моему, есть более важный вопрос, чем способы контроля за программным проектом, и это вопрос о том, почему же мы вообще занимаемся таким количеством проектов, имеющих столь маргинальную ценность?
Действительно ли я хочу сказать, что позволительно вести проекты без контроля или с минимальным контролем? Почти что. Я предлагаю сперва выделить проекты, где контроль не столь важен. Затем снизить свои ожидания о том, до какой степени мы сможем их контролировать, вне зависимости от того, настолько сильно мы желаем их контролировать.
Тревожная аналогия
Представьте, что вы пытаетесь воспитывать подростка. Сама идея контроля за вашим ребенком, по меньшей мере, должна вас волновать. Сложно придумать занятие, где ставки были бы выше. Если вы провалите свою задачу, если вы провалите ее полностью, то итогом могут стать разрушенные жизни. Поэтому совершенно естественно, что вы не можете совсем отказаться от контроля. Вы как фехтовальщик, который должен научиться держать свое оружие, как будто это маленькая птичка: сожмешь чуть сильнее -- и погубишь ее, сожмешь недостаточно сильно -- и она упорхнет.
А теперь примените принцип “Вы не можете контролировать то, что не можете измерить” к подростку. Большинство вещей, которые действительно имеют значение -- честь, чувство собственного достоинства, дисциплинированность, индивидуальность, сила воли, моральные качества, находчивость, верность, чувство юмора, доброта -- не поддаются измерениям. Вы должны воспитывать своего ребенка настолько хорошо, насколько вы можете, не имея никаких метрик. Это тяжело, но быть родителем вообще не просто. Хорошо еще, что хоть какие-то метрики вы получаете в виде школьных отметок. Но вы осознаете, что оценки вашего ребенка по математике лучшая метрика его знаний, чем оценки по Испанскому языку, т.к. знание математики проще поддается измерению. И его оценка по поведению с большей вероятностью расскажет вам что-нибудь об учителе, нежели о ребенке.
Так как же вам управлять проектом не имея средств контроля? Что ж, вы управляете людьми и контролируете время и деньги. К примеру, вы говорите руководителям своих команд: “У меня есть в голове дата релиза, но я не собираюсь делиться ей с вами. Когда-нибудь я приду к вам и скажу, что проект должен быть завершен в течении недели и вы должны будете собрать и выложить все, что успели сделать, как финальный продукт. Ваша задача вести разработку инкрементально, потихонечку добавляя кусочки к единому целому в порядке их относительной значимости, производя интеграцию кусков, их документирование и функциональное тестирование по мере пошагового развития проекта.”
Это может звучать как рекомендация из гибких методологий разработки, но я сегодня слишком далек от реального производства ПО, чтобы давать рекомендации на методологическом уровне. Я лишь защищаю такой подход к управлению, который может подтолкнуть команду к использованию гибких методологий, по меньшей мере к их инкрементальным аспектам.
До сих пор я обсуждал составляющую процесса разработки ПО, касающуюся метрик. Как на счет всего остального? Постепенно я прихожу к выводу, что рассмотрение разработки ПО как инженерной дисциплины -- это идея, время которой пришло и ушло. Я все еще верю, что есть большой смысл во взгляде на разработку ПО как на инженерную дисциплину. Но в итоге понятие “разработка программного обеспечения” стало означать совсем другое. Этот термин вобрал в себя множество дисциплин, включая регламенты, экспертизу и сквозной контроль, сбор и обработку требований с проверкой их достаточности и непротиворечивости, метрики, контроль качества, тщательное планирование и отслеживание прогресса, стандарты кодирования и документирования. Все это служит тому, чтобы разработка была размеренной и предсказуемой.
Но размеренность и предсказуемость никогда не были наиболее важными вещами. Например, в течении последних 40 лет, мы сами себя мучили неспособностью завершать программные проекты в срок и укладываться в отведенный бюджет. Но, как я уже намекал выше, это никогда не должно было быть основной целью. Гораздо более важная цель -- это преобразования, создание ПО, которое меняет мир или компанию, или изменяет способ ведения компанией бизнеса. Нам следовало бы быть успешными в преобразованиях, зачастую позволяя действовать за рамками нашего контроля. Разработка ПО есть и всегда будет чем-то экспериментальным. Конкретная программная разработка не обязательно будет экспериментом, но вот ее концепция -- будет. И это то, на что нам следует сфокусироваться. И это то, на чем нам всегда следовало фокусироваться.
Комментариев нет:
Отправить комментарий