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

    Posted on February 4th, 2010 Александр Орлов 1 comment

    Глава 1: Введение

    О культурах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Пример из жизни

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

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

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

    Времена конкуренции

    Не так давно я работал пару месяцев с одной известной “dot com” компанией. Дабы сохранить анонимность, будем называть её СамоСервис.

    Самосервис революционизировал индустрию, в которой промышлял, переведя её из клиент-сервис разряда в онлайновый бизнес, где люди обслуживали себя сами (Internet-based self-service). На этом СамоСервис неплохо заработал – годовой оборот составлял несколько миллиардов долларов. И тем не менее, их рыночное доминирование стало снижаться довольно высокими темпами. За прошлые два-три года несколько конкурентов стали вырываться вперёд. Они стали отхватывать куски рынка с ужасающей скоростью. Руководство СамоСервиса сказало мне, что они серьёзно озабочены. СамоСервис нанял меня, и я провёл два месяца исследуя, что же было не так.

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

    Заводская Культура

    Что-то сдерживало СамоСервис. Что-то не давало компании корректировать бизнес процессы и приложения со скоростью, которую держали конкуренты. Каждый день СамоСервис всё больше отставал.

    Они пробовали мотивационные речи; они пробовали угрозы; они пытались вливать деньги в проблемные участки; но ни один из подходов не оказался достаточно успешным. Тогда я решил порасспрашивать вокруг. Я говорил с менеджерами, я говорил с тимлидами, и говорил с рядовыми сотрудниками. В результате я обнаружил, что СамоСервис является наиболее типичным представителем Заводской Культуры, что и сдерживало бизнес.

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

    Доводы, обосновывающие Заводскую Культуру, звучат убедительно, но в этом-то и кроется проблема. Они были действительно убедительными во времена медленно развивавшегося мира бизнеса 60-70-х годов, когда Заводская Культура находилась на пике популярности в индустрии программных приложений. В те времена компьютеры в основном предназначались для технарей, занимавшихся решением алгоритмических задач в закрытых кабинетах. Бизнес процессы менялись редко. Требования к приложениям были стабильны. Кроме того, в те времена значимость программ была не так существенна.

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

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

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

    Дизайнерская Культура

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

    Удивительно, как много можно узнать о внутренних делах компании, немного порывшись вокруг. А потому я скоро узнал, что многие из конкурентов СамоСервиса отвернулись от Заводской Культуры и стали культивировать Дизайнерскую Культуру.

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

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

    Но это всё же не объясняло, почему один из конкурентов СамоСервиса опережал всех прямо-таки огромными скачками. Эта компания явно делала что-то иначе, и я решил выяснить, что же это такое.

    Сервисная Культура

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

    Отличительной чертой было то, что они отошли от Заводской и Дизайнерской Культур и объединились вокруг Сервисной Культуры.

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

    Оправдания, что некие важные изменения требований не вписываются в дизайн, не помогут клиенту. Это его только задержит. Следовательно, Сервисная Культура заставляет нас перенаправить фокус наружу и руководствоваться меняющимися нуждами клиента, а не концентрироваться внутри на стабильности структуры приложения.

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

    Почему же это имеет такое большое значение?

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

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

    Заключение

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

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

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

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

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

     

    One response to “Культуры программных проектов: глава 1”

    1. [...] Глава 1 [...]

    Leave a reply

    You must be logged in to post a comment.