Если кто помнит, в первой части своей статьи о гарантиях я упоминал о «подразумеваемых гарантиях» (Implied Warranties), которые автоматически являются частью контрактов на разработку ПО, т.к. они закреплены законодательно. В британском законодательстве эти гарантии закреплены в The Sale of Goods Act 1979 и The Supply of Goods and Services Act 1982. Напомню, что к «Implied Warranties» относятся: 1) Warranty of Title, 2) Infringement Warranty, 3) Warranty of Merchantability, 4) Warranty of fitness for а specific Purpose.Мы говорили о том, что если прямо не исключить действие этих гарантий, то они будут распространяться на правоотношения в рамках этого контракта. Теперь я предлагаю рассмотреть варианты исключения действия этих подразумеваемых гарантий.

В первую очередь стоит отметить, что если мы говорим о праве Великобритании, то все исключения «warranties» должны соответствовать требованиям, которые предъявляет UTCA (Unfair Contract Terms Act 1977). В соответствии с UTCA, некоторые «implied warranties» вообще не могут быть исключены (например, «Warranty of Title»), а некоторые, могут быть исключены только целесообразно — «only if reasonable» (например, «Warranty of fitness for а specific Purpose»). Если суд придет к выводу о том, что условие об исключении гарантии идет в разрез с требованиями этого нормативного акта, то это условие будет считаться недействительным. Во избежание рисков, связанных с нарушением UTCA, и в целях обеспечения исключения максимального числа гарантийных обязательств, разработчик может воспользоваться следующей конструкцией: «Other warranties are excluded to the maximum extent permitted by law».

Введение

В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив — автор книги «Software Estimation. Demystifying The Black Art» — одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно — милости прошу в комментарии, можно будет меня поправить.

В Deadline, Том Демарко пишет о том, что для управления проектом, достаточно управлять его рисками. Действительно, всю работу ПМа можно свести к одному — борьба с рисками, которые могут помешать проекту завершиться в срок, в бюджет и с необходимым уровнем качества. Если, по какой-то причине, рисков в проекте нет, то нет и предмета работы ПМа.

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

Сегодня мы с уверенностью можем сказать, что отказались от разработки сложных и дорогих интернет-проектов в пользу бюджетных, простых решений за 12 000 рублей. Вместо одного недовольного клиента, мы получаем десять довольных, а сам бизнес стал стабильным, рентабельным и, главное, прогнозируемым и предсказуемым. Я давно обещал рассказать, как нам это удается. В декабре мы перешагнули планку «21 сайт в месяц», и готовы поделиться своими секретами.

О системе

Фирма, в которой я работаю, разработала свою трейдинговую платформу типа MTF. В этой системе ежесекундно производятся десятки тысяч торговых операций, и с помощью паттерна Disruptor, средняя скорость выполнения трейда не превышает 20.5 миллисекунд. В проекте задействованы сложнейшие интеграции с третьими сторонами — крупными банками, Лондонским Домом Клиринга LCH и другими корпорациями.

На разработку проекта ушло около 3 лет и команда из примерно 20 инженеров. В проекте нету и не было ни одного руководителя проекта, координатора, планов проекта, диаграмм Гантта, документов архитектуры, спецификаций требований, и планов тестирования.

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

Это первая статья из серии «Сети для самых маленьких». Мы с товарищем thegluck долго думали с чего начать: маршрутизация, VLAN'ы, настройка оборудования.
В итоге решили начать с вещи фундаментальной и, можно сказать, самой важной: планирование. Поскольку цикл рассчитан на совсем новичков, то и пройдём весь путь от начала до конца.

Предполагается, что вы, как минимум читали о эталонной модели OSI (то же на англ.), о стеке протоколов TCP/IP (англ.), знаете о типах существующих VLAN’ов (эту статью я настоятельно рекомендую к прочтению), о наиболее популярном сейчас port-based VLAN и о IP адресах (более подробно). Мы понимаем, что для новичков «OSI» и «TCP/IP» — это страшные слова. Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем вам придётся встречаться каждый день, поэтому в течение этого цикла мы постараемся раскрыть их смысл и отношение к реальности.



Начнём с постановки задачи. Есть некая фирма, занимающаяся, допустим, производством лифтов, идущих только вверх, и потому называется ООО «Лифт ми ап». Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак у них катастрофическая потребность в сетевой инфраструктуре и денег куры не клюют, что даёт вам возможность безграничного выбора. Это чудесный сон любого инженера. А вы вчера выдержали собеседование и в сложной борьбе по праву получили должность сетевого администратора. И теперь вы в ней первый и единственный в своём роде. Поздравляем! Что дальше?

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

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

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

Одно время я работал на free-lance.ru. С утра я обычно мониторил заказы, а после обеда непосредственно работал. Однажды я наткнулся на заказ, сумма за выполнение которого была очень аппетитной. Я сразу отписался по заказу, и буквально через минуту получил ТЗ на проект в личку. Поначалу меня удивила скорость ответа, и то что меня сразу выбрали исполнителем, но с другой стороны такое уже частенько бывало. Файл с ТЗ мне показался странным, в него была встроена ссылка на flash ролик. Проверив файл на вирусы и получив ответ, что угроз не обнаружено, я таки усыпил свою бдительность и щелкнул по ссылке на flash ролик. А щелкать не стоило.

Как и многие сейчас, мы решили попробовать внедрить agile для развития одного из наших решений. Точнее, поскольку в мире разработки ПО нет «черного» и «белого», мы решили «не внедрить agile», а перейти от использования менее гибких подходов к использованию более гибких.

В данном топике я хотел бы описать проблемы, с которыми мы столкнулись, а также привести соображения, как некоторых из этих проблем можно было бы избежать. Написание топика продиктовано желанием способствовать переводу дискуссии про agile из плоскости «как наконец заставить этих старомодных менеджеров перейти к прогрессивным методологиям» в плоскость «как работать по agile наиболее эффективно».

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

Основное:

• Численность команды разработчиков — 7 человек;
• Длительность спринта — примерно две недели;
• Стендапы каждый день;
• Организацонные вещи хранятся в Acunote, google docs и MindMap;
• Код хранится в SVN, новая фича — новая ветка, над одной фичей трудятся несколько разработчиков;
• Тестирование — через unit-tests.

Два года — это очень длинный марафон, поэтому каждому важно правильно получать задачи и видеть конкретные результаты их выполнения. Для этого мы ввели систему коротких периодов, различения целей и задач плюс предельной конкретизации последних. Самая короткая ставящаяся задача — 2 минуты, самая длинная — 3 часа.

Неспособность рассуждать о коде

«Рассуждать о коде» значит понимать порядок исполнения инструкций («исполнять программу в голове»), зная, каково предназначение кода.

Симптомы

• Наличие «волшебного», «вуду» кода или кода, который не имеет никакого отношения к целям программы, но всё равно тщательно поддерживается (например, инициализация переменных, которые никогда не используются, вызов функций, не имеющих отношения к цели, создание выходных данных, которые не используются, и т.д.).
• Многократные вызовы идемпотентных функций (например, вызов save() по нескольку раз, «чтобы уж точно»).
• Исправление ошибок написанием избыточного кода, который замещает данные, полученные при исполнении неисправного кода.
• «Йо-йо код», который конвертирует значения в различные представления, а потом конвертирует их обратно ровно в то же представление, с которого начинали (например, преобразование десятичного числа в строку, а потом обратно в десятичное число, или padding строчки с последующим trim'ом).
• «Бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще (высокая когезия).