Метка «управление проектами» - 16

Экстремальное программирование: Pair Programming

Парное программирование является одной из практик XP. Эта практика воплощает экстремальную (преувеличенную) идею Code Review. Если ревью позволяет улучшить качество кода, то давайте делать его постоянно, во время рефакторинга и написания нового кода.

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

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

imageВо первых перестать паниковать! Если процесс уже налажен, очень важно не наломать дров. Но с другой стороны, как новоиспеченный лид, неплохо бы разобраться в том, как и что устроено на проекте и постараться изменить к лучшему то, что считаешь неверным.
В данной статье (точнее ее первой части) я поделюсь своим видением того, что необходимо внедрить на проекте и какие ключевые правила стоит соблюдать, что бы разработка была максимально быстрой и эффективной.
Читать полностью »

Немного предыстории

Хочу рассказать уважаемому сообществу о своем первом проекте, на который я потратил это лето, и о выводах по его следам. Не то чтобы я раньше никогда не вел никаких проектов, но делались они по остаточному принципу, а сроки были очень свободные. Например, проект по переходу на Универсальный транспортный адаптер для обмена файлами с ЦБ РФ я не спеша пилил больше года (в итоге, все заработало вовремя и работает хорошо).

Надо заметить, что я не указываю названия и некоторые подробности, потому как иначе затрону информацию, относящуюся к ДСП.

Но в этом году я сменил работу с саппорта на управление проектами и понеслась. На новом месте работа над всяческими внедрениями и улучшениями идет прямо-таки в конвейерном режиме, в очень сжатые сроки. Не прошло и недели, как мне вручили1 частично проработанный проект внедрения софта, предназначенного для эммм… собирания и структурирования информации из разных источников по разным объектам – физ и юр лицам. Вручили мне его с посылом «эта штука может все, внедряй, дело верное». Разработчики тоже сказали «мы можем все!» и в подтверждение уверенно ударили себя пяткой в грудь. Я очаровался и начал работать. 2

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

Asana в деталях, и как ее использовать
Проекты над которыми трудятся разработчики можно часто рассматривать как одну (или несколько) больших задач. А чтобы было проще решать большую задачу, ее нужно разделить на более мелкие. Для этого отлично подойдет Asana — collaborative task management application. Под хабракатом описание данной системы и один use-case который мы успешно используем при разработке сайтов. Статья большая и с картинками. Кому интересно только то как мы используем Asana на работе, можете перейти сразу к примеру, или к примеру в картинках.Читать полностью »

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

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

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

В своей работе мне довольно часто приходится обсуждать вопросы подходов к учету времени, потраченного на разработку программного обеспечения. Нужно ли учитывать время по каждой задаче? Нужно ли отчитываться каждый день? Полезны ли «таймшиты» и как они должны выглядеть? Кто должен заполнять отчёты и когда? И т.д. Иногда разговор уходит к противостоянию Agile-методологий и более строгих методов управления.
Бывает, такие обсуждения переходят в спор, противостояние точек зрения, а заканчиваются примиряющей фразой: «конечно же, каждая компания имеет свою специфику и особенности, свою модель бизнеса, а значит и свои подходы к учету ресурсов». И это правильно, потому что, по большому счету, принципы учета ресурсов зависят от модели бизнеса, но я всё же хочу собрать в одном месте накопленные аргументы разных сторон и подходов, а главное — попробовать сделать «открытую статью», статью в виде диалога, в виде противостояния аргументов и точек зрения, на которую повлияют комментарии и голоса читателей.
На мой взгляд, различные варианты сводятся к трем базовым подходам:

  1. Учёт потраченных человеко-часов с разбивкой по задачам
  2. Учёт реализуемого функционала (backlog/requirements) и общая оценка стоимости работ
  3. Творческая работа без списка функционала и контроля ресурсов

Давайте рассмотрим различия и аргументы в выборе подходов для следующих аспектов:

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

Обсуждать и противопоставлять мы будем первые два подхода, потому что про третий я рассуждать не могу. Мне приходилось работать в разных компаниях и в разных проектах, на разных технологиях и в разных управленческих схемах…
И самые интересные, технологически сложные и продвинутые, самые необычные проекты делались именно по третьему подходу. Именно про эти проекты я рассказывал на собеседованиях, именно в них создавались принципиально новые продукты, а не всякая надоевшая обыденность типа база данных→бизнес-логика→бизнес-процессы→клиентские представления→отчёты. Работой в этих проектах я горжусь, вспоминаю с ностальгией, не стесняюсь сказать «вот эти архитектурные решения принял я», и именно про эти проекты обычно слушают с большим интересом. Но с другой стороны, именно эти проекты были очень дорогими и экономически сомнительными. Сейчас никакие аргументы за или против таких проектов я приводить не готов, поэтому рассмотрим только два подхода:
Читать полностью »

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

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

Отдельно я бы хотел рассказать об одном веб-приложении от российских разработчиков, основанном на связке PHP/MySQL и wiki-движка, которое наша команда держит на вооружении уже второй год. Речь идет о проекте под названием qdPM — бесплатном инструменте управления проектами с открытым кодом, отлично подходящих для небольших компаний, в особенности в сфере IT и интернет-маркетинга. qdPM полностью конфигурируем, имеет возможность настройки различных уровней доступа, а также множество подключаемых модулей и расширений.

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

— именно такое описание встречает посетителей официального сайта проекта. Читать полностью »

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

Зачем что-либо измерять?

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

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

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

А если не приходят, значит метрику можно смело выбросить ;)Читать полностью »

Для начала — начало.

Часть 1
Часть 2

С официальной частью покончено, переходим к делу.

Сразу предупрежу — сегодня я расскажу о скучной нужной теории, в следующем посте перейдем к рассмотрению методики на основании проекта — примера.

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

В нашем вузе принято на специальности программирование делать выпускные проекты. Большим плюсом считается, если «на выходе» есть прототип программного продукта. Студенты, которые занимались проектами в университете, позже занимают ключевые позиции в ИТ компаниях города и страны.

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

Начало работы

С чего все началось. Некоторые студенты изъявили желание выучить предмет «Веб-программирование» более углубленно. Причем отличительной чертой этих студентов была мотивация.

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js