Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2017

Контроль or not контроль?

Том ДеМарко не нуждается в отдельном представлении, на его книгах выросло не одно поколение руководителей и разработчиков, вот лишь некоторые их этих книг:

  • 1986. Controlling Software Projects: Management, Measurement, and Estimates. Prentice Hall
  • 1987. Peopleware: Productive Projects and Teams. With Timothy Lister. Dorset House.
  • 1997. The Deadline: A Novel About Project Management. Dorset House.
  • 2003. Waltzing with Bears: Managing Risk on Software Projects. With Tim Lister. Dorset House in March, 2003.
  • Контроль над протеканием проектов разработки ПО - одна из ключевых тем его работ. Именно ему принадлежит ставшая крылатой фраза "You can’t control what you can’t measure" ("Вы не можете контролировать то, что невозможно измерить"). Однако сегодня лично мне очень приятно наблюдать, как этот действительно умный и талантливый человек меняет свою точку зрения на аспекты контроля вместе с изменением видения всего процесса в ИТ индустрии. Этот человек не боится признать, что был не прав, и статья [1] полностью посвящена такому признанию. Вот что он пишет:

    Моя ранняя книга по метрикам 'Controlling Software Projects: Management, Measurement, and Estimation' (Prentice Hall/Yourdon Press, 1982) сыграла важную роль в том, как многие инженеры-разработчики измеряли свою работу и планировали проекты. Под настроением провести некоторую рефлексию я спрашиваю себя: были бы мои советы в силе и сейчас, спустя столько времени? Верю ли я сам всё ещё, что метрики являются обязательным аспектом успешного процесса разработки ПО? Мой ответ: нет, нет и нет.

    По собственному признанию, Том не учитывал в своих работах о метриках многих важных и очевидных сегодня вещей:

    - не все метрики одинаково хороши и нужны
    - сбор качественных метрик стоит дорого (время, ресурсы)
    - метрики должны использоваться осторожно
    - разработка ПО отличается от естественных наук и её метрики намного менее точны в их попытке измерить те вещи, которые они должны отражать.

    Основной мыслью работ ДеМарко о метриках всегда было то, что контроль является пожалуй самым важным аспектом любого проекта по разработке ПО. Однако он сам признаёт сейчас, что это не так. Для понимания настоящей роли контроля, нужно различать два совершенно разных типа проектов: 

    - проект А при вложениях X приносит выгоду/прибыль 1.1*X
    - проект Б при вложениях X приносит выгоду/прибыль 50*X

    Очевидно, что контроль очень важен для проекта А и практически совершенно не важен для проекта Б. Это приводит нас к странному выводу, что строгий контроль очень важен для сравнительно бесполезных проектов и менее важен для полезных. Чем больше вы сосредотачиваетесь на контроле, тем более вероятно, что вы работаете над проектом, результирующая ценность которого сравнительно мала. Значит ли это, что можно успешно запускать проекты без особенного контроля? Вот что пишет ДеМарко: 

    Практически, да. Сначала выберите проект, в котором точный контроль не был бы так важен. Затем снизьте свои ожидания о том, как сильно вы сможете его контролировать. Как же управлять проектом без контроля? Руководите людьми и контролируйте время и деньги. Например, вы можете сказать своим тим-лидам: “У меня есть на уме дата окончания, но я даже не собираюсь вам её сообщать. Когда однажды я прийду и скажу, что проект заканчивается через неделю, вы должны быть готовы всё собрать и выпустить то, что у вас будет на тот момент как финальный продукт. Ваша задача - работать над проектом инкрементно, добавляя кусочки к целому в порядке их важности, и выполняя интерграцию, документирование и приёмочное тестирование такими же этапами.” Это может выглядеть как рецепт гибких методологий, но я ... просто проедлагаю это как подход к управлению.

    Я постепенно прихожу к выводу что software engineering - это идея, время которой пришло и ушло... Этот термин делает акцент на определённом наборе дисциплин, включая предопределённый процесс, проверки и разборы результатов, разработка требований, матрицы traceability, метрики, детальный контроль качества, строгое планирование с последующим слежением, стандарты кодирования и документирования. Всё это в целях последовательости в практиках и предсказуемости. Последовательность и предсказуемость всё ещё желательны, но они никогда не были наиболее важными вещами. Например, последние 40 лет мы мучались своей неспособностью заканчивать софтверные проекты в срок и в рамках бюджета. Но, как уже намекалось выше, это никогда не должно было быть высшей целью. Более важной целью является трансформация: создание ПО, способного изменить этот мир, или компанию, или то, как она ведёт свой бизнес. Лучше бы мы старались преуспеть в этой трансформации, пусть даже действуя вне рамок нашего контроля. Разработка софта всегда была и остаётся в чём-то экспериментальной. Само создание ПО не обязательно экспериментально, но его концепция - да. И это то, где дожен быть наш фокус. Это то, где наш фокус должен был быть всегда. 

     

    Источники

    1. Tom DeMarco Software Engineering: An Idea Whose Time Has Come and Gone?


    Posted by Vitalii Tsybulnyk on Friday, November 26, 2010 6:49 AM
    Permalink | Comments (0) | Post RSSRSS comment feed

    Add comment




      Country flag

    b i u quote
    Loading