Рубрика «agile» - 40

В продолжение поста о том, что 20% населения России к 2020 году будет работать удаленно, а также публикации прогноза J’son & Partners Consulting, которые на днях распространили многие СМИ. Сам прогноз был опубликован еще в мае, и в частности его представила на Большом Медиакоммуникационном форуме представитель 1С-Битрикс Мария Сысойкина.

Так, согласно прогнозу, уже к 2016 году в России будет работать удаленно 2,71 миллион человек, из которых 642 000 будут использовать IT-решения:

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

Принципы управления разработкой сервиса от Gov.uk - 1

В данном посте приведен список «базовых принципов» (а не набор шагов по достижению цели), который в службе электронного правительства Великобритании разработали для того, чтобы все сотрудники, занятые в создании сервисов Gov.uk, понимали, как (в общих чертах) должна происходить их работа.

Основная задача меморандума Gov.uk – объяснить сотрудникам общие «правила игры», сформировать корпоративную культуру, помочь им определиться с ожиданиями друг от друга и от работы в целом. И хотя указанные принципы могут на первый взгляд показаться банальными, возможно, их стоит иметь в виду при создании собственного внутрикорпоративного «манифеста» – а то, насколько это важно и нужно ли это небольшим стартапам, мы обсудили с резидентами Акселератора ФРИИ.Читать полностью »

Зачем вообще нужны бизнес аналитики

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

Бизнес-аналитики в Agile — зачем, почему, как - 1
Читать полностью »

image

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

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

Каждый месяц по всему миру происходят десятки, если не сотни, IT-ориентированных конференций, выставок и других мероприятий.

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

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

Идея пришла в рамках основной работы методологию разработки Agile. Подумал, почему бы не применить ее вечерком, когда в удобном кресле фрилансю?
Читать полностью »

«Мобильное приложение должно быть «живым», пользователь должен видеть, что проект развивается»
image
Мы в Redmadrobot работаем по гибким методологиям Agile и Scrum. Как известно, они предполагают значительную свободу в том, как организуются спринты по проектам, — каждая компания подбирает удобную для себя модель. Кейсов — информации о том, как организуются команды во время выполнения спиринтов — во внешних источниках крайне мало. Раскрываем свою “кухню”.
Читать полностью »

При работе с госзаказчиком или крупными коммерческими организациями с государственным участием часто наблюдается гадкая проблема: они обязаны размещать свои заказы и принимать их результаты в рамках строго определённых процедур. Добавим к этому вторую проблему: конечные пользователи в крупных организациях, как правило, очень занятые люди, и доступ исполнителя к ним весьма ограничен. Как построить agile-процесс в таких условиях?

На деле да, agile можно применять в fix-price. Одно из решений недавно было предложено ldmitry в статье «Agile с фиксированной стоимостью — это реально».

Мы воспользовались другим, более «классическим» способом: абстракцией. Поскольку заказчик в нашем случае является слабым звеном, применим абстракцию в отношении именно заказчика. Для этого мы должны ввести в проект очень аккуратного и грамотного специалиста, умеющего работать как с требованиями заказчика, так и с техническими вопросами. У нас этим занимается системный архитектор, контролирующий концепцию проекта и потому по роду деятельности чаще занимающий внутри проекта сторону заказчика, чем сторону команды проекта. Именно этот человек будет работать с заказчиком в рамках внешней fix-price-оболочки проекта и являться product owner-ом для внутреннего процесса. Заказчик абстрагируется от внутренних процессов исполнителя, но его видение результата проекта всегда совпадает с видением исполнителя.
Читать полностью »

image

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

Что происходит дальше? Если посмотреть со стороны на отношения заказчиков и аутсорсеров, то в 90% случаев они напоминают два враждующих лагеря. Одни обвиняют друг друга в вечном срыве сроков и завышении бюджетов, другие — в непрофессионализме и “саминезнаютчегохотят”.

Послушав очередные жалобы на эту тему, захотелось поделиться своим опытом заказной разработки в качестве менеджера проектов. Речь пойдет об истории 2009-2011 года. Заинтересованные в практических вопросах приглашаются в комментарии.
Читать полностью »

В чем сложность

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

  • Разработка программ — это процесс интеллектуальной деятельности. Есть типовые задачи, которые уже делались раньше, оценить такие не составляет труда. Но есть и нестандартные задачи. У нас таких обычно 20-30% работ по проекту. Эти задачи невозможно оценить, потому что неизвестно сколько они займут времени и какие могут возникнуть проблемы при их разработке. Простой пример: попробуйте ответить на вопрос: “Сколько времени займет путь из Москвы до поселка Заполицы на автобусе? И сколько стоит такая поездка?”. Вряд ли вы вообще были там раньше, поэтому для вас эта задача нестандартная, сходу и не скажешь сколько. С примером просто — позвонил на автовокзал, узнал цену и продолжительность поездки. Но даже здесь есть риск застрять в пробке. А заказчик будет звонить вам и трясти результат. И правильно сделает: пообещали — выполняйте.
  • Требования заказчика. Практически в любом проекте в ходе реализации меняют первоначальные требования. Заказчик мог что-то забыть или появились новые хотелки уже после старта проекта.
  • Еще одна проблема, вытекающая из того, что деятельность интеллектуальная — это квалификация разработчика. Профессионал может выполнить задачу в разы быстрее новичка.

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


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