• Культуры программных проектов: часть 2

    Posted on December 21st, 2009 Александр Орлов 3 comments

    (все выложенные на текущий момент части – здесь)

    Следуйте за своими эмоциями

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

    Отвечая на эти десять вопросов полагайтесь, в основном на свои инстинкты. Обратите внимание на то, какие ответы вас беспокоят, а с какими вы чувствуете себя комфортно. Иногда более одного ответа будут казаться правильными, а иногда ни один. Не пытайтесь углубляться в анализ – позже в книге для этого будет достаточно времени. Пока что просто выберите то, что кажется правильным.

    По окончании опросника мы рассмотрим ваши ответы. Результаты должны показать, что ваши эмоциональные реакции делают вас приверженцем одной культуры разработки и противником других.

    Десять Вопросов

    1: От кого больше всего зависит успешность проекта разработки приложений?

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

    Б: Техническая команда: Управление – это в основном администрирование, а потому мало что привносит в создание классных приложений, для чего требуются талантливые, опытные и очень техничные команды разработчиков.

    В: Заказчики: Без заказчиков не будет приложений. Только заказчики знают, что им на самом деле нужно и что представляет ценность. Поэтому заказчики должны оставаться у руля, чтобы мы могли фокусироваться на постоянном изготовлении приложений, которые имеют для заказчиков наибольшее значение и решают их наиболее актуальные задачи.

    2: Как лучше всего собирать требования?

    А: Собрать их полностью в самом начале: В идеале, заказчик даст нам подробный список требований, или же мы можем поработать с заказчиком, чтобы выявить все нужды заранее, что даст нам фиксированную чёткую цель, которой должен будет достичь проект.

    Б: Нужно дать им стабилизироваться: Вначале требования обычно не сильно чёткие, но детали проясняются со временем, по крайней мере, для наиболее важных требований, и всё больше помогают нам стабилизировать дизайн архитектуры, на которой будет строиться вся система.

    В: Будьте готовы к изменениям: Мы не можем полагать, что требования когда-либо стабилизируются. Ранее казавшиеся важными требования теряют важность со временем, а непредвиденные события приводят к появлению совершенно новых и неожиданных нужд заказчика. Мы должны фокусироваться только на тех требованиях, которые наиболее важны для заказчика на данный момент, и ожидать, что эти приоритеты будут постоянно изменяться.

    3: Где лучше всего записывать требования, дизайн и другие решения?

    А: Текстовые документы: Пишите документы, в основном текстовые, но со вспомогательными графиками и диаграммами, если нужно для более полного охвата требований, дизайна и других решений, чтобы информация была задокументирована, легко доступна для других, и не терялась.

    Б: Формальные заметки: Используя формальные графические обозначения, создавайте диаграммы, чтобы выражать требования и дизайны более чётко и ясно, чем в запутанных текстах. Можно использовать специальные приложения, умеющие работать с такими диаграммами.

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

    4: Предположим, у нас есть требования. Какова следующая цель?

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

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

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

    5: Как может помочь менеджер в ускорении прогресса проекта?

    А: Планирование и контроль: Создайте план, включая расписание, затем следите и контролируйте проект, чтобы убедиться, что он чётко следует плану, а все люди упорно работают, чтобы выполнить взятые на себя обязательства.

    Б: Руководство: Наберите в проект правильных людей, помогите им притереться, дайте им направление, если нужно, но уйдите с дороги, если они быстро выполняют задания без вашего вмешательства.

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

    6: Как лучше всего контролировать стоимость проекта?

    А: Управление проектом: Чтобы использовать все ресурсы как можно эффективнее, используйте проверенные методики управления затратами.

    Б: Наймите классных людей: Наймите самых лучших людей, так как они в десять раз эффективнее среднестатистических, а стоят всего раза в два больше.

    В: Фокус на ценности: Пишите приложение только для наиболее важных требований заказчика, чтобы постоянно удерживать высокое отношение ценности минус стоимость.

    7: Как мы можем убедиться в высоком качестве приложения?

    А: Процесс: Найдите надёжный, проверенный способ разработки приложений с серией полностью определённых и повторяемых шагов, в каждом из которых качество уже встроено. Каждому сотруднику дайте чётко определённую роль с конкретным спектром ответственности, а потом требуйте буквального соблюдения процесса.

    Б: Инструменты: Вместо того, чтобы мучить людей старым оборудованием и устаревшими принципами и практиками, дайте им наилучшие инструменты разработки приложений и образование по новейшим методикам, чтобы они могли работать как можно более продуктивно и эффективно, производя наилучшие результаты.

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

    8: Какова наилучшая структура эффективной команды разработчиков?

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

    Б: Профессионализм: Оставьте архитектуру самым умным и талантливым техническим сотрудникам. Остальные пусть приносят пользу там, где они больше всего подходят.

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

    9: Как избежать ненужной работы?

    А: Исключите брак: Работа спустя рукава выбивает людей из колеи, что приводит к переделкам. Поэтому убедитесь, что каждый сотрудник полностью исполняет свои обязательства и делает работу высокого качества, прежде чем передаёт её другим.

    Б: Уменьшить бюрократию: Не тратьте время на длинные документы, которые далеко не все будут читать. То же относится и к статус репортам, часто являющимся отписками. Вместо этого сфокусируйтесь на моделировании ядра деловой области, которую поддерживает приложение. Использование программ для записи этих моделей обеспечивает непрерывность и отслеживаемость кода через дизайн назад к требованиям.

    В: Не делайте её: Не работайте ни над чем, если заказчик не видит в этом большой ценности. Задачи с низким приоритетом не стоят предварительного исследования. А когда их ценность возрастёт так, что обстоятельства изменятся, то их всё равно придётся переделывать скорее всего.

    10: Что указывает на завершённость проекта?

    А: Завершённые задачи: Когда все запланированные задачи были выполнены правильно, проект завершён.

    Б: Стабильность: Когда дизайн приложения достаточно стабилен и надёжен, приложение может быть отдано в руки заказчика.

    В: Ценность для заказчика: Когда заказчик решит, что следующая версия приложения не даст достаточной дополнительной ценности, останавливаем работу.

    Ваши результаты.

    Некоторые ответы показались вам логичными, другие немного неполноценными или даже абсолютным бредом. Вполне возможно, что выбранные вами ответы были разбросаны между А, Б и В вариантами, но скорее всего можно проследить некую тенденцию. У большинства людей есть некий инстинкт, приводящий их к тому или иному набору ответов.

    Эти инстинкты важны, поскольку они формируют наши ощущения и реакцию на всевозможные аспекты разработки приложений. Они приводят нас к конкретным методологиям, основываясь не на анализе каждого возможного правила, а на нашем общем ощущении. Кроме того они нам помогают распознать единомышленников. Если большинство ваших ответов А как и у кого-то ещё, то с этим человеком вы очень хорошо сработаетесь. Но вам будет довольно сложно ужиться с людьми, предпочитающими ответы Б или В. Особенно в вопросах ведения проектов. Поэтому ваши ответы на опросник не только помогают раскрыть некоторые из ваших эмоциональных предпочтений, но и дают возможность определить тип культурной группы, в которой вам будет наиболее комфортно.

    Если вы выбрали в основном один тип ответов, то вполне возможно следующее будет вам тоже импонировать:

    Большинство A

    Основная масса ответов Б скорее всего потакает требованиям технарей и упускает из виду управленческий аспект, необходимый для контроля рисков проекта.

    Возможно вам кажется, что большинство из ответов В слишком интуитивно-чувственны и не  вполне базируются на лучших практиках, чтобы применяться в жизни.

    Если вы активно вовлечены в разработку приложений, то вполне возможно, что вы используете или склоняетесь к Водопадной методике, вроде методы Gane and Sarsen или Systems Analysis and Design Method (SSADM).

    Скорее всего вы хорошо впишетесь в организацию с доминирующей Заводской Культурой. Чуть позже будет краткое описание этой и двух других доминирующих культур. Лучше немного подождать, но если не терпится, то можете проскочить несколько страниц и подсмотреть.

    Большинство Б

    Возможно в прошлом вы выбрали бы больше ответов А, но со временем ваши взгляды эволюционировали, увидев как задыхаются проекты, хотя в теории всё звучит логично.

    Может и ответы В в чём-то звучат близко по духу, но недостаточно веско на ваш взгляд, и им не хватает технической твёрдости вашего собственного подхода.

    Если вы активно вовлечены в разработку приложений, то полне возможно, что вы используете или склоняетесь к Объектно-Ориентированному подходу (ООР).

    Скорее всего вы хорошо впишетесь в организацию с доминирующей Дизайнерской Культурой.

    Большинство В

    Ответы А вам кажутся несовместимыми с истинной природой разработки приложений и являются пережитком времён, когда люди недооценивали сложность правильного ведения разработки приложений.

    Возможно, ответы Б вам импонировали в прошлом и до сих пор представляют некоторую выгоду, но теперь вы считаете, что они слишком фокусируются на технических аспектах и забывают о более важной вещи – следовать за постоянно меняющимися нуждами заказчика.

    Если вы активно вовлечены в разработку приложений, то вполне возможно, что вы используете или склоняетесь к гибким методам вроде Scrum или Crystal.

    Скорее всего, вы хорошо впишетесь в организацию с доминирующей Сервисной Культурой.

    Продолжение следует…

     

    3 responses to “Культуры программных проектов: часть 2”

    1. Возможно стоит использовать вместо слов “заохотьте” и “аналист” слова “поощрите” и “аналитик”.
      А в остальном перевод очень читабельный и грамотный; переводчику большое спасибо!

      Опросник специфический. У меня А=6, Б=4 и В=4 ответов. Но я вовсе не склоняюсь к водопадной методике или заводской культуре. Наоборот, эволюционные модели мне ближе. Просто в некоторых вопросах ответы А кажутся более здравыми, чем другие предлагаемые варианты. Посмотрим, что там будет в продолжении…

    2. Спасибо и с Новым Годом от переводчика :)
      Кстати, я сам распределил ответы примерно, как и Вы. Точнее, мне очень трудно было сказать, что я однозначно в каком-то вопросе за тот или иной ответ. В каждом была толика пользы.

    3. А-1, Б-3, В-6 :)

      Спорим, Саша больше склоняется к Б? ;)

      Эти культуры ещё можно назвать: Водопад, Joel Spolsky, Agile ;)

    Leave a reply

    You must be logged in to post a comment.