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

в 11:49, , рубрики: agile, fix-price, методологии разработки по, управление проектами

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

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

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

в 7:03, , рубрики: agile, agile контракт, проекты с фиксированной ценой, управление проектами, метки: ,

image

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

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

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

в 12:09, , рубрики: agile, оценка времени, оценка сроков, управление проектами

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

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

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

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

в 18:20, , рубрики: agile, agile development, agiledays, lean, lean startup, видео докладов, конференция, Управление продуктом, управление проектами

Пару недель назад в Москве прошла AgileDays-2015 — самая крупная в РФ конференция по современным методам управления в разработке.

  • Два дня, пять треков, огромные залы московского Центра Международной Торговли (не путать с WTC).
  • Темы:
    • Agile-менеджмент — от высокоуровнего управления разработкой в неповоротливых компаниях-монстрах, до «бережливого старта» в стартапах.
    • Продуктовый аспект — как не только правильно разрабатывать, а творить именно нужное и правильное.
    • Специфические вопросы процессов и технологий — тестирование и бизнес-анализ, юзабилити и проектирование.
    • Современные архитектурные практики — *DD, и даже немного о функциональном программировании.

Вращаясь в «продвинутых» кругах часто кажется, что Agile-подходы уже «захватили весь мир», и хватит уже говорить о понятном и общеизвестном. Но в реальной жизни, все конечно гораздо запущенней — есть успешная когорта «early adopters», и как видно в широко известной картинке «дилеммы инноватора», далее идет большая пропасть, и либо те, кто совсем не в курсе, либо кому про Agile «все понятно, ибо сосед-Рабинович напел». Это видно даже по ряду недавних публикаций на мегамозге. Поэтому реальный, и даже не всегда успешный, опыт от тех, кто в теме и нашел и все грабли, и кучу ништяков — очень полезен, и гораздо более актуален, чем даже книги, как правило уже устаревающие к моменту публикации. Докладчики — не евангелисты, а практики, из крупных компаний и стартапов, хотя да, были и консультанты, рассказывающие о «сгибании несгибаемого» — типа аджайлизации банков.

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

И я, как член программного комитета, заботящийся о том, чтобы докладчики донесли свои знания до всех заинтересованных, попробую сделать серию публикаций, включающих и видео доклада, аннотации и слайды, и мой очень краткий постобзор. Слона надо есть по частям — еще готово не все видео, смонтированное надо еще отсмотреть и отрефлексировать, да и большие статьи отпугивают своим объемом и читателей и писателей — стыдно признаться, что я, за несколько заходов, но так и не смог дописать за год эпический обзор 72 видеодокладов с прошлого AgileDays-2014, а обзор 2011 осилил только через полгода. Конечно же, обзор Agile-конференции надо делать итеративно, максимально быстро отгружая value потребителям. И, как принято в Agile, возможно даже прекратить поставки, если продукт не понравится пользователям…

Итак, смотрите и решайте — такой формат ОК или нет…

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

в 6:55, , рубрики: agile, evo, интернет-маркетинг, менеджмент в IT, Управление продуктом, управление проектами

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

в 11:47, , рубрики: agile, appsworld, failover, growth hacking, gtd, himss, icit, interop, nabshow, railsconf, rsa, tnw, германия, конференции, Мероприятия, Москва, Развитие стартапа, риф, США

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

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

в 12:26, , рубрики: agile, development, distributed team, Блог компании DataArt, управление персоналом, управление проектами

Гибкие процессы и распределенные команды — секреты мастерства - 1

Пару месяцев назад я была на тренинге по Scrum. Делясь опытом с соучениками, упомянула, что у меня сейчас команда из десяти человек в восьми офисах. Мне не то чтобы не совсем не поверили, но к разговорам, что у нас нормальный процесс, отнеслись с, вероятно, оправданным скептицизмом.

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

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

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

Итак, в чем проблема распределенной команды? Коммуникации. Затруднены коммуникации на всех уровнях, что порождает веер проблем. Та самая «транспортировка», которая упомянута как один из компонентов waste (потери) в концепции Lean Software Development.

Я для себя выделила три составляющие проблемы коммуникаций:

  • Техническая: если человека рядом нет, к нему нельзя просто взять и подойти, чтобы обсудить какие-то текущие проблемы.
  • Мотивационная: если у команды нет своей комнаты, где перед глазами есть доска со стикерами, списком проблем и остальной полезный контекст, фокус и приоритеты начинают «плыть».
  • Психологическая: люди, которые не сидят рядом и не видятся каждое утро, обсуждая за кофе последние новости или успехи детей в школе, менее склонны прощать ошибки коллегам, особенно если про коллегу они знают только логин в системе контроля версий и e-mail. Может возникать концепция «мы и они» по отношению к коллегам из другого офиса и прочие неприятные штуки
  • Отдельным пунктом стоит адаптация Scrum-активностей под распределенную команду.

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

в 10:34, , рубрики: agile, gtd, pomodoro, прокрастинация, Управление продуктом

1. Самоорганизация, GTD и тайм-менеджемент — зачем это нужно?

В данной книге рассматривается реализация системы самоорганизации на основе методики GTD (Getting Things Done) и онлайн-календаря (Google Calendar и т. п.).

Самоорганизация — это процесс создания некоторой формы общего порядка или координации на основе взаимодействия между компонентами изначально неупорядоченной системы.
Наиболее близкими к понятию “персональная самоорганизация” (т. е. самоорганизация применительно к человеку) —  являются такие понятия, как “самоконтроль”, “самообладание”, “самодисциплина”.
Читать полностью »

в 13:21, , рубрики: agile, incremental, iterative, project management, rup, sdlc, Управление продуктом, управление проектами, метки:

Наверное, всякий, кто когда-либо пытался осознать специфику различных подходов к разработке программного обеспечения, задавался вопросами: в чём отличие между итеративной и инкрементальной разработкой? Agile – итеративный? RUP – инкрементальный?

Под катом очередное рассуждение на эту тему и заочный спор с Карлом Вигерсом.
Читать полностью »

в 4:40, , рубрики: agile, метки:
Что понимается под этим словом, как оценить качество и как его поддерживать.

Качество: Руководство Gov.uk - 1

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

1...1020...414243...5060...60
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js