Pull to refresh
  • by relevance
  • by date
  • by rating

Госуслуги проапгрейдят по методологии SCRUM, чиновников заменят на софт

Project management *Legislation in IT
Минкомсвязь подготовила материалы по разработке 25 цифровых «суперсервисов» для взаимодействия граждан РФ с государством. По плану, к 2021 году это взаимодействие будет происходит в основном в цифровом виде. Поставлена задача довести долю цифрового взаимодействия граждан и бизнеса с властями до уровня минимум 80%. Часть чиновников заменят автоматизированные компьютерные системы.

«Дорожные карты» по каждому из сервисов должны быть готовы в июне 2019 года. Подготовкой займётся рабочая группа с участием заместителя руководителя профильного ведомства. Деятельность рабочих групп выстроится в духе SCRUM с разбиением на спринты по одной неделе, по итогам которых должно происходить приращение функциональности сервиса.
Читать дальше →
Total votes 16: ↑15 and ↓1 +14
Views 8.9K
Comments 18

Запускаем Scrum-Bootcamp

Райффайзенбанк corporate blog Project management *Agile *Studying in IT
Приглашаем вас стать участниками проекта по подготовке скрам-мастеров Scrum-Bootcamp. Вас ждут три месяца интенсивных тренингов, международные сертификационные экзамены и работа в команде банка.


Читать дальше →
Total votes 9: ↑9 and ↓0 +9
Views 1.5K
Comments 0

Scrum Community Meetup 11/02

Райффайзенбанк corporate blog Agile *Product Management *Conferences

Нельзя просто так взять и взрастить своих скрам-мастеров — есть очень много нюансов, которые стоит учесть. Об этом поговорим на онлайн-митапе со спикерами QIWI, Газпромбанка и Райффайзенбанка.

Читать далее
Total votes 4: ↑3 and ↓1 +2
Views 613
Comments 0

Scrum Community Meetup 13/04: видео и материалы встречи

Райффайзенбанк corporate blog Agile *Product Management *Conferences

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

Смотрите митап в записи

Читать далее
Total votes 3: ↑3 and ↓0 +3
Views 1.5K
Comments 0

МСК — Семинар Методология Scrum

Agile *
Сообщество AgileRussia проводит открытый семинар на тему «Методология Scrum»
13 сентября, в 19.00 на территориии офиса Luxoft

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

В нашей программе две части:
«Обзор методологии Scrum» и «Внедрение Scrum: Опыт одной компании».

Обзор методологии Scrum

1. Зачем нужен Scrum?
2. Основа методологии Scrum
3. Роли, артефакты и жизненный цикл
4. Преимущества и применимость методологии

Ведущий — Асхат Уразбаев

Внедрение Scrum: Опыт одной компании

1. Состояние до внедрения Scrum
2. Внедрение Scrum
3. Трудности, с которыми мы встретились
4. Как мы с ними справлялись
5. К чему стремимся сейчас

Ведущий — Никита Филиппов

Семинар бесплатный, чтобы на него попасть — запишитесь здесь по кнопке [Участвую], указав при регистрации в системе свои реальные ФИО (этого требует пропускная система Luxoft).

AgileRussia Community
Total votes 7: ↑5 and ↓2 +3
Views 1.9K
Comments 0

Гибкая система управления проектами Acunote

Project management *
Если вы только задумываетесь о том, что пора внедрять какую-то методологию и использовать некий специальный софт для планирования и отслеживания хода работы, возможно вам будет полезен наш вполне успешный опыт применения гибкой методологии разработки Scrum. Это очень простая и эффективная методика, а в ее применении неоценимую помощь оказывает система Acunote, о которой и пойдет речь в статье.

Читать дальше →
Total votes 38: ↑32 and ↓6 +26
Views 3.7K
Comments 71

Гибкая разработка сайта: программирование + дизайн

Project management *
О гибких (agile) методологиях по разработке программных продуктов информации довольно много. Но, мне пока нигде не попадалась информация (на русском) о применении agile для разработки сайтов. Я имею ввиду достаточно крупные проекты, например социальные сервисы, где подразумевается постоянное совершенствование продукта и где важен ранний запуск бета-версии. В частности, меня интересует вопрос планирования параллельной разработки дизайна и программной части проекта.

Рассмотрим типичную ситуацию.
Читать дальше →
Total votes 15: ↑11 and ↓4 +7
Views 1.6K
Comments 13

Панацея ли Scrum — 2!

Project management *
Этот топик, есть продолжение вот этого топика: habrahabr.ru/blogs/pm/39308

Итак. Продолжим повествование на тему Скрама.

Перед тем, как описать саму методологию, чуть коснёмся классификации. Часто приходится слышать: у нас XP методология, а у нас Скрам, а у нас Agile девелопмент. Всё это имеет право на жизнь. Но, на мой взгляд, желательно правильно соотносить эти понятия.

XP — это набор принципов и подходов, меняющих традиционное отношение к разработке современного программного продукта.

Agile – это общее название группы гибких и достаточно успешных методик организации ведения проектов. Методик, которые, как правило, опираются на принципы XP и предполагают быструю итеративную разработку, тесное общение с заказчиком и, за счёт тесного общения членов команды, минимизацию создания дополнительных сущностей (артефактов/документов), которые традиционно создавались в процессе работы над проектом. Минимизацию всего того, что создаётся помимо самого программного кода.

Scrum – это одна из конкретных Agile-методик. То есть чёткий шаблон (каркас) организации управления проектом. Со своими терминами и понятиями. Если вы близко следуете именно этому шаблону, то можно сказать, что вы ведёте разработку по Скрам.

Я часто сталкиваюсь с другой классификацией, когда XP называют Agile методологией. Сложно сказать…
Читать дальше →
Total votes 69: ↑63 and ↓6 +57
Views 5K
Comments 25

Как избежать зоопарка или дайте пользователям работающие кнопки…

Lumber room
Начинать данную статью с различных вводных матчастей о «Великой силе SCRUM'а» и «ущербности водопадной методологии» считаю пустой тратой времени, поскольку в интернете и так достаточно много ресурсов, позволяющих узнать всё: от историй предпосылок создания технологий до всех преимуществ и недостатков в текущих реализациях. Как говорится: «Кто ищет, тот всегда найдет...» (с) :-).

Хочу поделиться неким опытом и даже скорей всего своим мнением о «существующем зоопарке ПО» в некоторых ИТ-компаниях, а именно подходах и реализациях.

Итак, начнем…

Естественно, для написания нового или улучшения существующего продукта предварительно нужно исследовать рынок, проанализировать потребность заказчиков, написать кучу каких-то нелепых концепций и ТЗ, в которых для «большего страха и мощи системы» необходимо как можно больше применять такие выражения как: «… на основе существующих артефактов, разработанная метамодель поможет реальным пользователям ...», обязательно использовать только термины и аббревиатуры и конечно же обязательным условием является описание «сферических коней в вакууме». Затем надо детально проанализировать все эти концепции, обрасти еще миллионами моделей: от простых IDEF-диаграмм до огромных UML-моделей со всякими ассоциациями, агрегациями и прочей «атрибутикой». В итоге получаются все новые и новые «пауки». Конечным пользователям глубоко наплевать на эти модели, диаграммы и т.д., им нужны рабочие кнопки…

После этого начинается непосредственно разработка, программисты начинают «клепать» то задуманное, о чем писалось в ТЗ. Опустим документирование и тестирование… перейдем сразу к выходу продукта на рынок. Маркетологи разработали кучу бумажек о выходе продукта «СуперМегаСистемаПро», которая позволит не только быть «системой, автоматизирующей то-то и то-то», но также (причем без лишней скромности)… она… она… она вообще позволяет «автоматизировать весь мир» :-). Вроде все хорошо, система мощная, современная, но почему-то заказчики недовольны… вроде система обо всем, а на самом деле не о чем. В итоге существующие продукты начинают ругать все кому не лень, а внедренцы в тихоря при помощи SDK (если есть) «клепают» все новые и новые плагинчики, лишь бы заказчик был доволен. Следствие, зоопарк разрастается…

Существующие проблемы ПО находятся прямо «на поверхности», их не надо искать, а уж тем более вытаскивать из глубины. Но тем не менее, начинаются новые обсуждения, новые концепции… в итоге «кто в лес, кто по дрова»… но главное, существующие недостатки завуалированы емкими терминами и как следствие новая система только стала еще сложнее и не понятнее. Жалко потраченного времени (2-5 лет), а уже тем более жалко выкидывать «тонны кода», ведь программисты не виноваты.

После разведенной мною демагогии о «водопадном подходе» :-) имеет смысл перейти к реально рабочей технологии SCRUM. Данная технология действительно помогает оживлять продукты и способствует разработке новых и качественных продуктов.

Инициативная группа разработки решила поработать по SCRUM, пытаясь исправить существующее положение вещей. Была сформирована команда в составе: программисты, аналитики и тестировщики, в которой как и положено технологии был ProductOwner со своим ProductBacklog'ом и SCRUM-мастер.

Процесс
Практику SCRUM мы объединили с некоторыми практиками XP (eXtreme Programming). SCRUM позволяет решить вопросы управления и организации, а XP специализируется на инженерных практиках. Из XP мы позаимствовали: парное программирование, рефакторинг, CodeReview и стилевое описание кода. Также на ретроспективах мы определили для себя ряд правил, которых мы придерживаемся. Для проектирования качественного GUI применяем практику использования персонажей.

Используем только легковесное документирование: диаграмма БД и UML-модель, которые разрастаются только в ходе разработки, соответственно — это не такие страшные пауки, как было описано выше.

Планирование
Планирование спринта в нашей команде длится практически целый день, НО если некачественно спланировать спринт, итерацию можно просто-напросто «завалить». Поэтому планирование является самой важной частью любого SCRUM-проекта.

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

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

SCRUM — митинг
Ежедневные встречи проводятся 2 раза в день возле SCRUM-доски. После встречи делается отметка на графике сгорания. Задача считается выполненной, т.е. переносится в «Done», только после тестирования. Программист может взять следующую задачу в «InProgress» только после одобрения аналитиком предыдущей задачи, взятой на выполнение. Диаграмму сгорания «подбивает» Скрам-мастер. Чтобы не превышать временной 15-минутный лимит, встреча проводится стоя. На встрече мы определяем, что мы сделали, что будем дальше делать, какие проблемы. Стараемся не обсуждать технические детали, но не всегда получается. Обычно встреча длится не более 10 минут. Если на митинге были определены некоторые технические проблемы, то их обсуждение проводится после скрам-митинга возле «стены проектирования» (доска с маркерами).

SCRUM — доска
В качестве скрам-доски мы используем обыкновенную пробковую доску. Область доски мы разделили на три части: ToDo (что надо сделать), InProgress (В работе), Done (Выполнено).

Однако, мы ведем и электронную версию доски (UserStory, задачи, % участия задействованных участников команды и т.д.) в программе. Это делается «для истории», в работе мы пользуемся только доской.

График сгорания
График сгорания является наглядным индикатором прогресса. Ось X — это ось времени. Ось Y — трудоемкость невыполненных задач. Задача считается выполненной если она проверена тестировщиком, во всех остальных случаях задача не выполнена.

Выполненные задачи переносятся в раздел «Done» скрам-доски. Таким образом график отображает сумму трудоемкости задач, находящихся в разделах «ToDo» и «InProgress». После ежедневных митингов, диаграмма сгорания «подбивается» с учетом выполенных задач за день. Также информация о выполнении заносится в программу, в которой наглядно отображается дата взятия задачи в «InProgress», дата выполнения данной задачи. В продукте автоматически подсчитывается средняя скорость команды, фокус-фактор. Данная информация иногда может помочь в переоценке трудоемкости задач и фокус-фактора команды.

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

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

Для проведения ретроспективы используем доску с маркерами, которая условна разделена на 4 блока: минусы, плюсы, идеи и план. После того как все участники высказались и все идеи были записаны, мы проводим голосование путем расставления магнитных фишечек. Практически все, что было записано в блок «План» мы стараемся впоследствии соблюдать.

В результате работы по SCRUM наша команда смогла решить многие из тех проблем «на поверхности» быстро и качественно (правда систему не оживляли, писали с нуля).
Да пребудет с нами «великая сила SCRUMа» и дайте пользователям рабочие кнопки!!!
Total votes 37: ↑11 and ↓26 -15
Views 743
Comments 5

Agile Podcast #4. Сезон 1. Роли в Agile команде

Lumber room
Участники:
Алексей Кривицкий, Асхат Уразбаев, Денис Миллер, Кирилл Медведев

Темы
* Scrum-команда
* Понятие ролей, соотношение с должностями
* Кроссфункциональность и узкая специализация
* Синергия команды: 1 + 1 = 11
* Тестировщик и разработчик в Team
* Менеджер проекта
* Product Owner
* Мотивация, индивидуальные поощрения
* Scrum Master – вымирающий динозавр

Алексей Кривицкий — лидер украинского Agile сообщества, тренер Scrum.

Блог Подкаста (rss for itunes)
Total votes 5: ↑3 and ↓2 +1
Views 824
Comments 0

Scrum'd — система управления проектов в стиле Agile

GTD *
Не так давно, я открыл для себя, систему управления проектами на базе методологии Scrum Описания Scrum'd на Хабре я не разыскал, в связи с этим, под катом мое краткое описание.
Читать дальше →
Total votes 9: ↑5 and ↓4 +1
Views 2.9K
Comments 2

Сравнение Agile методологий

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

Ценности + Принципы + Практики

image

Читать дальше →
Total votes 14: ↑6 and ↓8 -2
Views 2.2K
Comments 0

Два дня мероприятий для разработчиков в Екатеринбурге

Website development *
На днях, 15 и 16 декабря в Екатеринбурге состоялись мероприятия для разработчиков и ИТ-специалистов самого разного рода занятий. Все мероприятия проводились в Уральском Государственном Университете (УрГУ).

Во-первых, компания СКБ Контур организовала бесплатную лекцию известного специалиста по agile-разработке Асхата Уразбаева. Тема лекции называлась “Гибкие методологии для построения эффективной команды разработки ПО” и  освещала принципы создания хорошей команды и как это помогают сделать гибкие методологии.
Читать дальше →
Total votes 17: ↑10 and ↓7 +3
Views 485
Comments 0

Прагматический Процесс Разработки в «не-книжных» условиях

Lumber room
Доброго времени суток.

Хочу поделиться некоторыми идеями которые помогают мне в Святой Войне с Хаосом в процессе разработки ПО. Для определенности картины добавлю несколько деталей: я — менеджер проектов, фирма средних размеров (~40 мозгов) занимается оффшорным программированием, команда смешанная (15% сеньоры, 35% девелоперы, 35 джуниоры, 15% стажеры, причем есть еще деление по специализации — разработка, качество, инфраструктура).

Процесс


Источников создания хаоса более чем достаточно — длинная цепь связи с заказчиком, неоднородная и в общем, молодая команда, «славянский менталитет» ( эксцентричное творчество и частые медитации ;) ), проблемы коммуникаций, политические игры сейлс-людей (Sales — те кто нас «продают») и т.д.
Читать дальше →
Total votes 11: ↑11 and ↓0 +11
Views 783
Comments 14

Scrum is

ScrumTrek corporate blog
В блоге у Алексея Кривицкого (кстати, очень рекомендую) есть любопытная заметка о том, является ли Scrum инструментом или чем-то большим.

Леша считает, что Scrum — это не инструмент. Scrum для Алексея – это совокупность ценностей, принципов, хороших практик разработки, современных подходов лидерства и собственно, самого каркаса скрам.

Так что такое Scrum – инструмент или нечто большее?
Читать дальше →
Total votes 20: ↑12 and ↓8 +4
Views 6.8K
Comments 4

Февральские Тренинги

ScrumTrek corporate blog
Москва – управление требованиями и Scrum

10 февраля в Москве будет однодневный тренинг по Scrum. Сразу за ним 11–12 февраля двухдневный тренинг по требованиям в Agile (Agile Requirements). Вести тренинги будет Никита Филиппов.

Что будет интересного?
  • Управление продуктом
  • Жизненный цикл требований от концепции до (пере-)планирования релизов.
  • Разберемся с User Story и еще одним инновационным методом – Story Mapping.
  • Изучим контракты с фиксированной ценой и T&M
  • Затронем вопрос «полезных» метрик.
  • Ну и куча всего другого полезного

Стоимость тренинга — 3000 рублей за AD-Agile Development with Scrum и 16000 рублей за REQ-Agile Requirements Analysis.

Екатеринбург – Scrum и Test Driven Development

Еще на февраль планируется набег на Екатеринбург при поддержки компании Microsoft и «СКБ Контур». 11 февраля будет однодневный тренинг по Scrum. Его будет читать Асхат Уразбаев. А сразу за ним – однодневный тренинг по Test Driven Developement от Дмитрия Лобасева.

Тренинг по Scrum стоит 2000 рублей, по TDD — 6000 рублей
Total votes 8: ↑4 and ↓4 0
Views 888
Comments 0

Два протокола управления проектами

Project management *
Доброго времени суток.

Я пришел в управление проектами из программирования. То есть, нет так давно, я еще писал код и мне это очень нравилось. Меня мало беспокоили волнения, происходящие где-то на верху — «у менеджеров». Все поменялось в 2004, когда меня назначили тим лидом.

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

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

Следующие несколько лет я искал *супер фреймворк* для управления проектами. Но только недавно понял, что его нет и быть не может. Проблема заключается в том, что в разработке ПО одновременно используются 2 конфликтующих протокола общения между участниками Процесса.

Сейчас я расскажу о моем текущем видении проблемы, а также опишу одну из возможных стратегий совместного использования этих двух протоколов.
Читать дальше →
Total votes 84: ↑77 and ↓7 +70
Views 2.7K
Comments 39

Gantt против Backlog

Project management *
Доброго времени суток!

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

Интересность момента заключается в том, что мы переосмыслили возможности Gantt диаграммы для работы с Agile проектами. До штурма, я и мои коллеги думали об этой диаграмме как об одном из многих способов отображения плана проекта и его прогресса. В таком приближении мы имеем список задач, список разработчиков, календарь и массив отчетов от команды о прогрессе, которые можем показывать в разных представлениях — Gantt, PERT и Backlog.

Оказалось, что мы заблуждались. Кроме «локального» негативного результата мы получили довольно важные обобщения на уровне идеологии и философии управления Agile проектами.
Читать дальше →
Total votes 10: ↑4 and ↓6 -2
Views 2K
Comments 12

Конференция Agile Eastern Europe 2010

Self Promo
Agile Eastern Europe Logo

Конференция Agile Eastern Europe


8-9 октября 2010

Киев, Украина

www.agileee.org
 
Ежегодная конференция Agileee вновь собирает участников и партнеров!

Насыщенная программа — 2 дня, 4 потока, 40 докладов и воркшопов!


Читать дальше →
Total votes 27: ↑16 and ↓11 +5
Views 534
Comments 6