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

    uzverkms
    @uzverkms
    ИТ проекты - понятие растяжимое. Есть разработка ПО, есть консалтинг, есть системная интеграция и т.д. Сначала для общего развития посмотрите вот этот вводный курс pmlead.ru/youtube.html Затем уже будет понятнее на что стоит тратить время.
    1. Выбрать "тяжелую" методологию в зависимости от реалий рынка и собственных потребностей. Скорее всего всего это будет PMI PMBoK. PRINCE2 и прочие - гораздо менее распространены. В чтении PMBoK нет ничего страшного (600 стр.). Сам стандарт занимает всего 60 страниц. Остальная часть книги (400 стр.) - как понимать стандарт и как им пользоваться.
    Далее по необходимости стоит посмотреть дополнительные книги PMI, которые упоминаются в PMBoK и более полно раскрывают какую-либо тему. Например PMI Practice Standard for Work Breakdown Structures.
    2. Посмотреть дополнительные отраслевые стандарты
    CompTIA Project+ https://certification.comptia.org/training/self-st...
    IEEE https://ddintsis.com/templates/ieee-standards-temp...
    ГОСТ 34, 19 и т.д.
    3. Посмотреть руководства по гибким методологиям. По статистике 60 % процентов проектов, реализовывавшихся по гибким методологиям, велись по Scrum. В новой 6-й редакции PMBoK, выходящей в этом году, будет больше про гибкие подходы (сейчас доступен черновик книги).
    4. Подробнее изучить частные темы. Например:
    "Требования для программного обеспечения: рекомендации по сбору и документированию" Илья Корнипаев. Совсем небольшая книга, достаточная для ликбеза.
    Руководство по документированию проектов www.pmdoc.ru/pmdoc_guide_issued
    "Системная инженерия для чайников" https://habrahabr.ru/company/ibm/blog/216307/
    Много любопытного можно подсмотреть у NASA. Презентации типа SysML для руководителей проектов.
    Куча инфографики на Pinterest.
    Куча тематических презентаций на SlideShare.

    Для общего развития не помешает реализовать вот этот план развития www.it-agency.ru/academy/jedi-plan Там и SMART задачи и прочие основы.
    Ответ написан
  • Как Вы формируете release notes?

    При использовании тэгов, создании и именовании pull requests, разработчики следуют определенному "шаблону".
    Например:
    Feature 341: Add new css style
    А потом, получить сообщения со всех merge коммитов, перед релизом, между последним тэгом и текущем HEAD (это maser ветка):
    git log --merges --pretty=format:%b v1.0.7..HEAD
    Это также можно добавить в Jenkins или Teamcity, как у нас.
    Ответ написан
  • Существует ли программа полного цикла разработки приложений?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    У вас перечислено далеко не все, что нужно в полном цикле, а некоторые вещи как-то нескладно.

    Готовых программ много, но практически все они идут отдельно стоящими компонентами, которые можно интегрировать в разных комбинациях. Если мне нравится билд сервер одного производителя, а коде ревью другого, 99% что они легко интегрируются штатными средствами или официальными плагинами. И это - хорошо.
    Ответ написан
  • Существует ли программа полного цикла разработки приложений?

    @balamut108
    Py
    Добрый день, то что Вы пишите, это некоторый частный случай разработки ПО в соответствии с принятой методологией в компании. Я бы не решился писать софт "полного цикла" в вашем представлении. Лучше выбирать специализированные продукты и потом их интегрировать через шину или другими доступными способами.

    P.S. Извините, что это не ответ на Ваш вопрос, а скорее критика самого вопроса :)
    Ответ написан
  • Как правильно решать проблемы критичных багов на проекте?

    @balamut108
    Py
    Я Team-Leader - у нас часто обновления по пятницам :))) Шутка. Давайте примем за условие, что это уже произошло и что нельзя было сработать на упреждение. Просто перед Вами ситуация, ок. Поймём, что критичный баг - этот баг, который блокирует ключевой функционал, т.е. N-пользователей не могут каждую секунду выполнить свою ежедневную работу или N-клиентов не заплатило компании денег. Это так вольные вводные, чтобы страшнее было. Какие решения мы можем принять в данной ситуации? Их всего два: сделать роллбек или пофиксить баг. Принимаю решение о роллбеке, если в milestone-версии критичный баг - это значит, что всю версию надо выкидывать в помойку - он там не единственный, если версия так себе, то фиксим, если это в течение 1-2 часов происходит, если нет, то роллбек. Основная причина таких действий - компания уже потеряла деньги/репутацию и надо выбраться из болота за меньший ценник.
    Ответ написан