Абдрахманов Руслан

В западной Европе и США число занятых в сфере обслуживания около 3/4. Чуть ниже в Японии, там что-то около 60%.

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

Что можно сказать про ИТ, с учетом вышеизложенной динамики?

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

Читать полностью »

С точки зрения Руководства PMBOK, управление проектами включает в себя 44 процесса управления проектами, объединенными в 9 групп. Эти 9 групп включают в себя управление интеграцией, содержанием, сроками, стоимостью, качеством, человеческими ресурсами, коммуникациями, рисками и поставками проекта.

Этот пост посвящен выявлению и идентификации рисков проекта — одной из самых важных и самых «размытых» групп.

«Риск может быть вызван одной или несколькими причинами и в случае возникновения может оказать влияние на один или несколько факторов» 🙂

Читать полностью »

Нашел в сети интересную статью Игоря Ашманова, относящиеся к управлению проектами: Правила Ашманова. Статья спорная, по тезисам статьи можно и нужно спорить, но больше всего мне понравилась подборка словарей ненормативной лексики в качестве приложений.

Читать полностью »

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

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

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

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

Фальшивая черепица — причина метода разработки, который называется метод копипаста. В этом случае кусок текста программы был скопирован с минимальными изменениями (или без них) для выполнения схожих (тех же) функций, что и исходный код.

Читать полностью »

В детстве прочитал одну задачу из серии ТРИЗ. Условия задачи были примерно такими: Вы — бабочка-однодневка, и в ваш единственный день, как назло, идет дождь. Предложите наилучшую стратегию поведения. В качестве решения задачи бабочке предлагалось летать не в укрытиях, защищающих бабочку от дождя, а летать следовало на открытом пространстве, лавируя между каплями дождя.
Читать полностью »

Недавно прочитал такое предложение: «Пользователь — человек, а человеку свойственно ошибаться». Если следовать этому правилу, то, наверное, программист и человек, связанный с разработкой программ, вообще, — это человек с большой буквы. 🙂
Под впечатлением от такого замечательного предложения захотелось найти и перечитать Теорию ошибок.

Итак…
Аксиома
В любой пpогpамме есть ошибки.

Читать полностью »

Как говорится, каждому танку — своя граната, а каждому проекту — свою методологию. Как выбрать методологию? Если проект измеряется человеко-годами и есть жесткие требования к качеству (ошибки ведут к серьезным потерям), то, наверное, нужно использовать «утяжеленые методологии». Если есть ряд крохотных проектов (два — три человека на пару месяцев) и нет жестких требований к качеству, то лучше облегчить процесс. Если есть постоянный контакт с заказчиком, возможность организации коротких циклов и быстрого проведения бета-тестирования, то можно обойтись без формализованного документа требований. Если же проект организован по принципу: «Когда все сделаете, посмотрим результат», — тогда нужно тратить уйму времени на создание и согласование ТЗ.

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

Основные принципы SCRUM просты и интуитивно понятны:

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

Также как и другие легкие методологии, SCRUM определяет короткие итерации (strint), в рамках которых реализуется заранее определенная функциональность, заданная в заранее зафиксированном перечне (backlog), а также предлагает механизм «обмена опытом» — ежедневные короткие совещания (scrum).

В чем же преимущества SCRUM? Посмотрите на замечательную картинку. Не правда ли из нее понятно, что SCRUM лучше других методологий? 🙂

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

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

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

Читать полностью »

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

Собственно, о разных типах деревьях, которые мы сажаем, я и хотел написать. У меня есть задумка написать о тех рисках, которым они подвержены, но боюсь, что эта тема слишком обширна, и я не смогу ее до конца когда-либо раскрыть 🙁
Читать полностью »