При разработке каждого проекта важно помнить одно – для чего делается этот проект. Представлять конечную цель, вот что самое важное.
Мы пишем программу, ломаем голову над новым алгоритмом или системой взаимодействия классов, используем технологии, новые особенности языка, тратим время и силы на правильное написание. А в конце – где-то там сидит пользователь, наш клиент или клиент нашего клиента, и пользуется нашим продуктом. И он может быть ничего не знает о программировании, вообще. Есть кнопочки, экран, наше приложение или сайт – и всё. Что там внутри, его совершенно не беспокоит. Это правда, пользователю совершенно безразлично что вы применяли в программе: for или foreach. Самое даже обидное – им совершенно безразлично на чем это написано, будь-то Delphi, VB или C#. И они понятия не имеют о системах управления версиями, фреймворках, разработкой через тестирование и шаблонах проектирования.
Но без пользователей мы бы не существовали. Надо понять и принять как факт, что все эти технологии основаны на потреблении конечных пользователей. Т.е. появились они не просто так. Всё что мы делаем, чему обучаемся – всё это для пользователей. Мы делаем их жизнь проще, они платят нам деньги, мы получаем выгоду и живем на это. Электронная почта, поисковики, социальные сети, интернет, CRM-системы, бухгалтерские программы, системы управления проектами – всё для потребления пользователей.
Вот наглядный пример как далеко можно зайти пытаясь удовлетворить пользователей: http://lenta.ru/news/2007/04/09/butty/
Из технологий разработки программ выделяется две ветви:
Они на самом деле похожи, каскадная модель – это, скажем так, черновой вариант гибкой модели разработки. Вот фазы каскадной модели:
Все фазы идут одна за другой строго последовательно, т.е. на этапе «Определения требований» мы получаем список требований к ПО (функциональные спецификации), на фазе «Проектирование» на основе списка требований создается документ описывающий для программистов способы и планы реализаций данных требований. Далее создается код программы и выполняется интеграция всех частей программы, которые тестируются и после успешного тестирования, выполняется инсталляция на системе заказчика, после чего вступаем в фазу «Поддержка» куда входят обучение пользователей, снабжение документацией, томными разговорами по телефону со службой поддержки.
Заметили некоторое несоответствие? Я – да. Давайте еще раз, только проще и с учетом того, что нами всё-таки руководит принцип «всё для пользователя». Представим себе ситуацию, пользователь A. в январе 2009 года понял, что ему нужна программа, обосновал требования начальству, начальство приняло разумность требований и решила выделить часть бюджета на заказ новой программы, и заказало ее нам. Ну вы же понимаете, что разумность требований с точки зрения начальства – это дополнительные деньги. Ну т.е. заказ всей программы (+юридические документы, обучение пользователей и руководство пользователя, и 13 процентов НДС) стоит меньше, чем та прибыль, которую он собирается получить от использования нашей программы.
Пользователь А. приходит к нам и объясняет что почем, и что он хочет. Он формулирует требования нашему продакт-менеджеру. На языке понятным им, продакт-менеджер выслушивает и записывает, это фаза «Определения требований». И конечно, на основании этого уже закладывается бюджет написания программы и сроки. Тут важно понять, сколько информации теряется, теряется первоначальная цель – заработать денег на использовании программы в течении какого-то времени больше, чем будет стоить разработка самой программы. Второе, насколько продакт-менеджер вправе говорить о сроках и стоимости? Конечно, тут привлекается конкретный старший программист, или Team Leader, который прикинет и расскажет, что почем и сколько по времени, но (!) без учета юридических документов, расходов на кофе, съем и запланированный ремонт помещения фирмы и конечно же PROFITа. Старший программист озвучит цифру в человеко-днях. Допустим 400 человеко-дней (MD) или 20 человеко-месяцев (все читали?). В общем, сформировали функциональные требования, подписали договор, отпускаем пользователя А. обратно в контору трудится и просим зайти через месяцев этак 5-6 когда будет готов продукт для инсталляции.
Берем спецификации, заходим к архитектору, архитектор колдует над системой и вместе со старшим програмистом доводят до ума технические требования. Старший программист их берет, составляет план разработки в MS Project. Раздает задачи каждому программисту, когда они начинают писать саму программу, час от часу собирая их вместе проверяя движется ли всё по плану.
Собираем всё вместе на фазе «Интерграция» проверяя работу архитектора. Архитектор – одна из ключевых фигур в разработке, если он допускает ошибку, то она выявляется на более поздней стадии проверки, стоимость каждой его ошибки очень велика, которая неизбежно приведет к увеличению и сроков и стоимости, к тому же скажется на общем настроении команды. Провал этой фазы возвращает нас обратно к фазе «Проектирование» и затрагивает бюджет.
Если же всё хорошо (так никогда не бывает), переходим к фазе «Тестирование», выявление маленьких ошибок в отдельном модуле приводят к исправлению только внутри этого модуля, а вот выявление ошибки во всей системе отбрасывает нас снова на фазу «Проектирование» и это очень дорогое удовольствие.
Фаза «Инсталляция» и «Поддержка» — это та же интеграция, только для конечных пользователей. Тут нас поджидают самые сложные проблемы. Мы снова встречаемся с Пользователем А. Прошло 10 месяцев, на дворе ноябрь 2009 года. За это время может много чего измениться, и наш продукт за это время может стать невостребованным.
Технически, при выполнении всех подписанных требований за вычетов всех трат на ошибки мы получаем прибыль. Но достигли ли мы конечной цели? Конечная цель была – повышение эффективности работы фирмы с помощью использования нашей программы и вследствии этого получение дополнительной прибыли заказчиком. Если она и будет, то не настолько большой, как хотелось бы, слишком много рисков заложено в самой каскадной технологии разработки.
Следующая – итеративная модель разработки должна решить эти риски.
Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл:
Собственно, сам итеративный подход говорит за себя. Начиная разработку мы сосредотачиваем внимание на основных функциях программы и анализируем задачу. Пользователь А. с продакт-менеджером снова составляет список требований, но на этом этапе выделяется то подмножество требований, на основании которых в дальнейшем и будут строится все дальнейшие версии. Старшим программистом и архитектором разрабатывается план реализации только этой итерации. Команда разработчиков (или вначале он может быть один) реализует требования в программе и передает на тестирование и повторный анализ. Эти две фазы могут проходить одновременно. При обнаружении ошибок в программе выпускается патч (исправления в данной версии). А при обнаружении ошибок в архитектуре программы в следующую итерацию добавляется редизайн системы с учетом повторного анализа.
Итерации сами по себе – процесс достаточно короткий, но уже в самом начале мы можем выявить и решить одни из самых дорогостоящих ошибок – ошибок в архитектуре. Кроме того, для пользователя А. после первой итерации мы уже можем показать прототип программы, и получить отзыв, скорректировать требования и заложить их на реализацию в дальнейшем.
И так, шаг за шагом, итерация за итерацией мы постепенно реализовываем всю необходимую функциональность. Используя этот метод создания программного продукта, мы чаще взаимодействуем с конечным пользователем, и тем самым создаем продукт, который удовлетворит его в большей степени. Поставка продукта идет не через 10 месяцев, а частями каждые 1-2 месяца. Персонал заказчика может за это время изучить и привыкнуть к новой системе, подсказать и внести свои идеи и дополнения, тем самым помогая создать более эффективное решение.
Но тут находится очень много подводных камней, поскольку взаимоотношения с конечным пользователем выходят на первый план, а о качестве работы пользователь будет судить по программе и службе поддержки, то в процессе разработки мы должны уделять особое внимание тестированию и инсталляции продукта. Об этом в следующих статьях.
Мы пишем программу, ломаем голову над новым алгоритмом или системой взаимодействия классов, используем технологии, новые особенности языка, тратим время и силы на правильное написание. А в конце – где-то там сидит пользователь, наш клиент или клиент нашего клиента, и пользуется нашим продуктом. И он может быть ничего не знает о программировании, вообще. Есть кнопочки, экран, наше приложение или сайт – и всё. Что там внутри, его совершенно не беспокоит. Это правда, пользователю совершенно безразлично что вы применяли в программе: for или foreach. Самое даже обидное – им совершенно безразлично на чем это написано, будь-то Delphi, VB или C#. И они понятия не имеют о системах управления версиями, фреймворках, разработкой через тестирование и шаблонах проектирования.
Но без пользователей мы бы не существовали. Надо понять и принять как факт, что все эти технологии основаны на потреблении конечных пользователей. Т.е. появились они не просто так. Всё что мы делаем, чему обучаемся – всё это для пользователей. Мы делаем их жизнь проще, они платят нам деньги, мы получаем выгоду и живем на это. Электронная почта, поисковики, социальные сети, интернет, CRM-системы, бухгалтерские программы, системы управления проектами – всё для потребления пользователей.
Вот наглядный пример как далеко можно зайти пытаясь удовлетворить пользователей: http://lenta.ru/news/2007/04/09/butty/
Технологии разработки ПО.
Из технологий разработки программ выделяется две ветви:
- Каскадная (или водопадная) модель
- Итеративная модель разработки
Каскадная модель
Они на самом деле похожи, каскадная модель – это, скажем так, черновой вариант гибкой модели разработки. Вот фазы каскадной модели:
- Определение требований
- Проектирование
- Конструирование
- Интеграция
- Тестирование
- Инсталляция
- Поддержка
Все фазы идут одна за другой строго последовательно, т.е. на этапе «Определения требований» мы получаем список требований к ПО (функциональные спецификации), на фазе «Проектирование» на основе списка требований создается документ описывающий для программистов способы и планы реализаций данных требований. Далее создается код программы и выполняется интеграция всех частей программы, которые тестируются и после успешного тестирования, выполняется инсталляция на системе заказчика, после чего вступаем в фазу «Поддержка» куда входят обучение пользователей, снабжение документацией, томными разговорами по телефону со службой поддержки.
Заметили некоторое несоответствие? Я – да. Давайте еще раз, только проще и с учетом того, что нами всё-таки руководит принцип «всё для пользователя». Представим себе ситуацию, пользователь A. в январе 2009 года понял, что ему нужна программа, обосновал требования начальству, начальство приняло разумность требований и решила выделить часть бюджета на заказ новой программы, и заказало ее нам. Ну вы же понимаете, что разумность требований с точки зрения начальства – это дополнительные деньги. Ну т.е. заказ всей программы (+юридические документы, обучение пользователей и руководство пользователя, и 13 процентов НДС) стоит меньше, чем та прибыль, которую он собирается получить от использования нашей программы.
Пользователь А. приходит к нам и объясняет что почем, и что он хочет. Он формулирует требования нашему продакт-менеджеру. На языке понятным им, продакт-менеджер выслушивает и записывает, это фаза «Определения требований». И конечно, на основании этого уже закладывается бюджет написания программы и сроки. Тут важно понять, сколько информации теряется, теряется первоначальная цель – заработать денег на использовании программы в течении какого-то времени больше, чем будет стоить разработка самой программы. Второе, насколько продакт-менеджер вправе говорить о сроках и стоимости? Конечно, тут привлекается конкретный старший программист, или Team Leader, который прикинет и расскажет, что почем и сколько по времени, но (!) без учета юридических документов, расходов на кофе, съем и запланированный ремонт помещения фирмы и конечно же PROFITа. Старший программист озвучит цифру в человеко-днях. Допустим 400 человеко-дней (MD) или 20 человеко-месяцев (все читали?). В общем, сформировали функциональные требования, подписали договор, отпускаем пользователя А. обратно в контору трудится и просим зайти через месяцев этак 5-6 когда будет готов продукт для инсталляции.
Берем спецификации, заходим к архитектору, архитектор колдует над системой и вместе со старшим програмистом доводят до ума технические требования. Старший программист их берет, составляет план разработки в MS Project. Раздает задачи каждому программисту, когда они начинают писать саму программу, час от часу собирая их вместе проверяя движется ли всё по плану.
Собираем всё вместе на фазе «Интерграция» проверяя работу архитектора. Архитектор – одна из ключевых фигур в разработке, если он допускает ошибку, то она выявляется на более поздней стадии проверки, стоимость каждой его ошибки очень велика, которая неизбежно приведет к увеличению и сроков и стоимости, к тому же скажется на общем настроении команды. Провал этой фазы возвращает нас обратно к фазе «Проектирование» и затрагивает бюджет.
Если же всё хорошо (так никогда не бывает), переходим к фазе «Тестирование», выявление маленьких ошибок в отдельном модуле приводят к исправлению только внутри этого модуля, а вот выявление ошибки во всей системе отбрасывает нас снова на фазу «Проектирование» и это очень дорогое удовольствие.
Фаза «Инсталляция» и «Поддержка» — это та же интеграция, только для конечных пользователей. Тут нас поджидают самые сложные проблемы. Мы снова встречаемся с Пользователем А. Прошло 10 месяцев, на дворе ноябрь 2009 года. За это время может много чего измениться, и наш продукт за это время может стать невостребованным.
Технически, при выполнении всех подписанных требований за вычетов всех трат на ошибки мы получаем прибыль. Но достигли ли мы конечной цели? Конечная цель была – повышение эффективности работы фирмы с помощью использования нашей программы и вследствии этого получение дополнительной прибыли заказчиком. Если она и будет, то не настолько большой, как хотелось бы, слишком много рисков заложено в самой каскадной технологии разработки.
Следующая – итеративная модель разработки должна решить эти риски.
Итеративная модель разработки
Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл:
- Планирование
- Реализация
- Проверка
- Оценка
Собственно, сам итеративный подход говорит за себя. Начиная разработку мы сосредотачиваем внимание на основных функциях программы и анализируем задачу. Пользователь А. с продакт-менеджером снова составляет список требований, но на этом этапе выделяется то подмножество требований, на основании которых в дальнейшем и будут строится все дальнейшие версии. Старшим программистом и архитектором разрабатывается план реализации только этой итерации. Команда разработчиков (или вначале он может быть один) реализует требования в программе и передает на тестирование и повторный анализ. Эти две фазы могут проходить одновременно. При обнаружении ошибок в программе выпускается патч (исправления в данной версии). А при обнаружении ошибок в архитектуре программы в следующую итерацию добавляется редизайн системы с учетом повторного анализа.
Итерации сами по себе – процесс достаточно короткий, но уже в самом начале мы можем выявить и решить одни из самых дорогостоящих ошибок – ошибок в архитектуре. Кроме того, для пользователя А. после первой итерации мы уже можем показать прототип программы, и получить отзыв, скорректировать требования и заложить их на реализацию в дальнейшем.
И так, шаг за шагом, итерация за итерацией мы постепенно реализовываем всю необходимую функциональность. Используя этот метод создания программного продукта, мы чаще взаимодействуем с конечным пользователем, и тем самым создаем продукт, который удовлетворит его в большей степени. Поставка продукта идет не через 10 месяцев, а частями каждые 1-2 месяца. Персонал заказчика может за это время изучить и привыкнуть к новой системе, подсказать и внести свои идеи и дополнения, тем самым помогая создать более эффективное решение.
Но тут находится очень много подводных камней, поскольку взаимоотношения с конечным пользователем выходят на первый план, а о качестве работы пользователь будет судить по программе и службе поддержки, то в процессе разработки мы должны уделять особое внимание тестированию и инсталляции продукта. Об этом в следующих статьях.
