Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
Константин Бажин, ТОП 10 не могу или что нужно сделать, чтобы жить по AgileScrumTrek
"Наступать на грабли - это не про нас!" - думали мы, когда ушли в разработку программного обеспечения с головой. И вроде бы все умные и прекрасно понимают как нужно делать правильно. Но! В ситуации, когда количество работы превышает количество ресурсов, а договорные обязательства никто не отменял, в какой-то момент - ЧТО-ТО ПОШЛО НЕ ТАК.
В своем докладе я расскажу как это все произошло и какие выводы мы сделали. А также опишу конкретные шаги, которые предприняли, чтобы этого избежать в дальнейшем.
Дмитрий Грибов, Трава и грибы как средства управления разработкойScrumTrek
Управление разработкой в ЛитРес: Игровые грибы на службе управления проектами Холакратия, настоенная на травах Деревянный Agile Спринты длинною в час и ежедневный релиз Рыночная игра как альтернатива микроменеджменту KPI для разработчиков, основанный на реальных результатах (сдельная оплата программистам в штате) История о том, как команда из 27-и человек эффективно поддерживает и развивать сервис с миллиардной выручкой
User Experience / UPA Europe 2009: Когда проектирование заказывать не нужно. ...Yury Vetrov
Презентация Юрия Ветрова "Когда проектирование заказывать не нужно. Памятка для клиента и проектировщика" с конференции User Experience / UPA Europe 2009.
Максим Цепков, Agile - то что на самом деле нужно гос.заказчикам!ScrumTrek
Многие доклады про использование гибких методологий разработки в проектах с государственным заказчиком рассказывают о том, как изолировать команду от заказчика для обеспечения Agile-процесса. Но нужно ли это на самом деле?
Ведь для заказчика, как правило, важно работающее программное обеспечение, а не документация на него, важно сотрудничество, а не контракты, важна готовность команды к изменениям — иными словами, те ценности, что декларирует Agile-манифест. Формальные требования воспринимаются заказчиком как дополнительная нагрузка на внутренние процессы, которые долго и сложно перестраивать. Поэтому секрет долгосрочного успешного сотрудничества — в грамотной адаптации деятельности компании-разработчика к условиям заказчика. За время доклада мы рассмотрим воплощение этого тезиса на конкретных примерах из опыта работы нашей компании с такими заказчиками, как Банк России, Газпромбанк и другими.
Александр Андронов, Engineering AssessmentScrumTrek
Улучшить можно то, что можно измерить. Это главный тезис измерения. Мы измеряем, чтобы улучшать. Мы хотим улучшать код, инженерку. Для этого нужно код измерять. Как?
Я расскажу о метриках на самом низком уровне создания IT-продуктов. О тех метриках, которые находятся на уровне инженерки, на уровне программистов и QA. Упор сделан на те, которые зависят от человеческого фактора, которые не измерить автоматическими инструментами. Работая над несколькими проектами и наблюдая за десятком других как Agile-тренеры, мы выработали 9 метрик, которые описывают текущее состояние системы с точки зрения инженерки. В динамике они помогают мгновенно реагировать, если что-то идет не так.
Проектирование Программных Систем. Лекция 01Dima Dzuba
Лекция рассказывает о базовых принципах построения программного обеспечения. Проводится сравнение гибких (Agile) и водопадных методологий разработки программного обеспечения.
Про качество и красоту кода говорят и пишут очень многие, хотя при этом довольно часто забывают, для чего существует это качество и эта красота.
Двадцать второй онлайн митап Software Craftsmanship будет посвящен Engineering Excellence. мы рассмотрим что такое Engineering Excellence, кому и для чего оно нужно на проекте, из каких частей состоит и как определить что нужно конкретному проекту.
На митапе мы рассмотрим взаимосвязь разработчиков, тестировщиков, девопсов, разберем метрики, практики и процессы необходимы для постоянного улучшения проекта.
Константин Бажин, ТОП 10 не могу или что нужно сделать, чтобы жить по AgileScrumTrek
"Наступать на грабли - это не про нас!" - думали мы, когда ушли в разработку программного обеспечения с головой. И вроде бы все умные и прекрасно понимают как нужно делать правильно. Но! В ситуации, когда количество работы превышает количество ресурсов, а договорные обязательства никто не отменял, в какой-то момент - ЧТО-ТО ПОШЛО НЕ ТАК.
В своем докладе я расскажу как это все произошло и какие выводы мы сделали. А также опишу конкретные шаги, которые предприняли, чтобы этого избежать в дальнейшем.
Дмитрий Грибов, Трава и грибы как средства управления разработкойScrumTrek
Управление разработкой в ЛитРес: Игровые грибы на службе управления проектами Холакратия, настоенная на травах Деревянный Agile Спринты длинною в час и ежедневный релиз Рыночная игра как альтернатива микроменеджменту KPI для разработчиков, основанный на реальных результатах (сдельная оплата программистам в штате) История о том, как команда из 27-и человек эффективно поддерживает и развивать сервис с миллиардной выручкой
User Experience / UPA Europe 2009: Когда проектирование заказывать не нужно. ...Yury Vetrov
Презентация Юрия Ветрова "Когда проектирование заказывать не нужно. Памятка для клиента и проектировщика" с конференции User Experience / UPA Europe 2009.
Максим Цепков, Agile - то что на самом деле нужно гос.заказчикам!ScrumTrek
Многие доклады про использование гибких методологий разработки в проектах с государственным заказчиком рассказывают о том, как изолировать команду от заказчика для обеспечения Agile-процесса. Но нужно ли это на самом деле?
Ведь для заказчика, как правило, важно работающее программное обеспечение, а не документация на него, важно сотрудничество, а не контракты, важна готовность команды к изменениям — иными словами, те ценности, что декларирует Agile-манифест. Формальные требования воспринимаются заказчиком как дополнительная нагрузка на внутренние процессы, которые долго и сложно перестраивать. Поэтому секрет долгосрочного успешного сотрудничества — в грамотной адаптации деятельности компании-разработчика к условиям заказчика. За время доклада мы рассмотрим воплощение этого тезиса на конкретных примерах из опыта работы нашей компании с такими заказчиками, как Банк России, Газпромбанк и другими.
Александр Андронов, Engineering AssessmentScrumTrek
Улучшить можно то, что можно измерить. Это главный тезис измерения. Мы измеряем, чтобы улучшать. Мы хотим улучшать код, инженерку. Для этого нужно код измерять. Как?
Я расскажу о метриках на самом низком уровне создания IT-продуктов. О тех метриках, которые находятся на уровне инженерки, на уровне программистов и QA. Упор сделан на те, которые зависят от человеческого фактора, которые не измерить автоматическими инструментами. Работая над несколькими проектами и наблюдая за десятком других как Agile-тренеры, мы выработали 9 метрик, которые описывают текущее состояние системы с точки зрения инженерки. В динамике они помогают мгновенно реагировать, если что-то идет не так.
Проектирование Программных Систем. Лекция 01Dima Dzuba
Лекция рассказывает о базовых принципах построения программного обеспечения. Проводится сравнение гибких (Agile) и водопадных методологий разработки программного обеспечения.
Про качество и красоту кода говорят и пишут очень многие, хотя при этом довольно часто забывают, для чего существует это качество и эта красота.
Двадцать второй онлайн митап Software Craftsmanship будет посвящен Engineering Excellence. мы рассмотрим что такое Engineering Excellence, кому и для чего оно нужно на проекте, из каких частей состоит и как определить что нужно конкретному проекту.
На митапе мы рассмотрим взаимосвязь разработчиков, тестировщиков, девопсов, разберем метрики, практики и процессы необходимы для постоянного улучшения проекта.
Какие вопросы встают перед руководителем разработки? Что нужно анализировать для успешного решения задач и запуска проектов? Как меняются вопросы, когда тим-лид дорастает до руководства департаментом?
Достоинства и ограничения проектных моделей водопада и гибких подходов: скрам, аджайл (scrum, agile).
Как на основе специфичных характеристик проекта подобрать модели планирования и управления ИТ проектом
ADN @ UI/UX Design Meetup Barnaul - «Эволюция процессов проектирования в веб-...ADN Digital Studio
- Боль старого подхода: Какие проблемы мы испытывали применяя старый метод, и что стало отправной точкой в поиске и разработке новых подходов к проектированию.
- Что такое “Золотой стандарт”, что мы из него взяли, и как перестроили процессы проектирования. С чем столкнулись, и что получили.
- Куда движемся: что планируем внедрять в ближайшее время, и как будем решать проблемы с проектирование крупных проектов.
Опыт госпроектов и взаимодействия с корпоративными структурамиПрофсоUX
Доклад предназначен для UX-специалистов, руководителей проектов и всех остальных.
В последнее время UX-специалисты и компании все чаще привлекаются к реализации проектов для корпораций и государственных заказчиков. На первый взгляд кажется, что при работе с ними попадаешь из мира сотрудничества в мир формальных взаимодействий. На самом деле построить с такими заказчиками настоящее сотрудничество вполне возможно. Более того, заказчик в нем заинтересован, просто не всегда представляет, как это сделать. В докладе я поделюсь практиками работы с крупными заказчиками из опыта компании CUSTIS.
Лекция посвящена последнему этапу работы над проектом, а именно его завершени. Часто случается так, что якобы выполненные проекты затягиваются на этапе сдачи. В этой лекции мы рассмотрим причины и возможные пути решения.
Ссылка на текстовую версию: http://growandmanage.com/zavershenie-proektov/
2. Разработка продукта это не только код
ТЗ на функционал и информационная архитектура
что сделать
Экранные формы
как выглядит
Начало
Информационная структура
проекта
как организовано внутри
Поверхностное проектирование
Ньюансы
аудитория, бизнес-процессы, наследование старых
технологий/контента, etc
Стоимость и сроки
3. Разработка продукта это не только код
Проектирование
Собственно, разработка
Документация
Дизайн
Середина
Верстка
Тестирование
проекта
Промежуточный контроль результата
4. Разработка продукта это не только код.
Приемка и доводка
Внедрение Конец
Инструкции
Поддержка проекта
6. Большие и средние проекты это вам не
малые
Малые Средние и большие
Заказчик это организация. Решения принимает
Заказчик это человек
комитет (долго и мучительно) или вечно занятый биг
Над проектом работает обычно 1-2
босс.
программиста, одинаковое понимание
Могут возникать проблемы с тем, что контактное лицо не
системы достигается легко, устно.
имеет полномочий или не хочет брать ответсвенность, а
Техзадание делается быстро
биг босс недоступен.
Многие стадии пропускаются или не
Большой объем предварительной работы по описанию
осознаются
системы, много коммуникации с заказчиком. Создание
Стадии легкие и быстрые,
ТЗ может тянуться месяцами.
последовательность не критична
Неправильная последовательность стадий или
Если что то забыли, можно быстро сделать
пропущенные/забытые стадии блокируют другие на
Изменения в ТЗ и переделки дешевы
недели и месяцы, затягивается весь проект
Ошибки архитектуры незаметны или
Изменения в ТЗ дороги, поиск компромисса тяжелый
дешевы
Архитектурные ошибки могут быть фатальны
Обычно затягивание сроков не так критично
Затягивание сроков чревато потерями прибыли для
для заказчика и разработчика
заказчика/гневом начальства, а для разработчика
Внедрение простое, часто делается
голодной смертью
заказчиком.
Над проектом работает команда, которой нужно единое
Приемка делается быстро
понимание системы
Практически любые проблемы могут быть
Сверхурочная работа не помогает
компенсированы сверхурочной работой.
Риск для вашей репутации и кошелька, ценность
Не получилось, ну и ладно.
заказчика.
От 1й встречи до оплаты недели/пара
От 1й встречи до оплаты месяцы
месяцев
7. Homo Заказчикус
Не знает точно чего хочет и как оно должно выглядеть
У него нет времени описывать будущую систему
Постоянно меняет требования
Обычно половину требований держит в тайне, чтобы потом
предъявить их на этапе сдачи
Хочет заранее знать сколько это стоит и сколько займет
времени
Хочет платить за готовый результат
8. Методология разработки "Водопад"
В классическом водопаде, следующие фазы идут примерно в таком
порядке:
1. Определение требований
2. Проектирование
3. Реализация
4. Интеграция
5. Тестирование и отладка (также «верификация»)
6. Инсталляция
7. Поддержка
9. Методология разработки "Водопад": есть
недостатки
Долго - пока не сформулированы все требования, а система
не спроектирована, работа не ведется.
Нельзя менять требования. (заказчик их все равно вынужден
менять и меняет, вероятность чего прямопропорциональна
длительности проекта)
Длительный и бюрократизированный подготовительный этап
(отдельно его заказчик не хочет оплачивать, не всегда проект
начинается, по крайней мере, с вами)
И заказчик, и разработчик заложники собственных планов.
Менять планы трудоемко.
...
Не решает проблем больших и средних проектов
10. Методология разработки "Scrum"
Итеративная и гибкая(agile) методология разработки.
Scrum — это набор принципов, на которых строится процесс
разработки, позволяющий в жёстко фиксированные небольшие
промежутки времени (спринты от 2 до 4 недель) предоставлять
конечному пользователю работающее ПО с новыми возможностями,
для которых определён наибольший приоритет.
11. Методология разработки "Scrum"
Использует артефакты:
Pruduct Backlog - содержит функциональные блоки(истории) для
реализации в проекте с приоритетами. Формируется всеми
участниками процесса. Приоритеты ставит заказчик.
Sprint Backlog - содержит уточненные задачи к реализации в
итерации (спринте), определяются заказчиком и командой.
Burndown Chart - индикатор прогресса, вместо диаграмм Ганнта
12. Методология разработки "Scrum"
История - задача на создание функционально завершенного, несущего пользу,
компонета системы или фичи. Содержит минимально необходимые для успешной
сдачи описание и "how to demo", и приблизительную оценку трудоемкости.
Приоритет историй определяет заказчик, принимая во внимание приблизительную
оценку команды трудоемкости
Спринт - итеративный, фиксированный период работы команды (2 - 4 недели) по
реализации взятых в работу историй. В период спринта, ТЗ на взятые в работу
истории замораживается. Спринт завершается внедрением реализованной истории в
текущую сборку системы.
Команда сама определяет, когда готова к следующему спринту
Команда сама определяет истории, которые готова взять в работу, руководствуясь
приоритетом.
Заказчик уточняет желаемый результат по заявленным к реализации историям,
формируя sprint backlog
Вместо PM Scrum-мастер. Следит за соблюдением методологии, но не управляет
вручную командой. Команда управляет собой сама
13. Методология разработки "Scrum": Решает
проблемы больших и средних проектов
Быстрый старт.
Поскольку разработка итеративна, перед каждой итерацией создается только
необходимый набор документации.
Поскольку разработка итеративна, а итерации коротки, заказчик может менять
функциональные требования к еще не реализованным историям.
Поскольку Product Backlog формируется динамически, заказчик может
добавлять истории по изменению реализованного функционала.
Поставка готового продукта происходит часто, что быстро выявляет проблемы
и минимизирует риски.
Частые итерации позволяют отказаться от ресурсоемких и сковывающих
календарных планов
Коммуникация с заказчиком более частая, более короткая, более
продуктивная. Всегда обсуждается то, что существенно в данный момент.
Любые ошибки и срывы сроков локальны и поэтому обходятся на порядок
дешевле и менее критичны. Могут быть исправлены сверхурочной работой.
Частые поставки снижают риск срыва проекта на порядок.
Заказчик совершает оплаты часто
14. О чем молчит "Scrum"
Как получить Product Backlog с историями, которые пойдут в
работу
Когда проектировать
Не говорит о обеспечении разработчиков всем необходимым
для спринта: достаточно точным ТЗ и дизайном
Когда делать приблизительные оценки историй
Что делать с ошибками
А как же поддержка внедренного функционала
15. О чем молчит "Scrum": нулевая
итерация и трек проектирования
16. О чем молчит "Scrum": нулевая итерация
Проектировщикам
Необходима для создания
приблизительной, высокоуровневой картины будущей
системы с точки зрения пользователя
Необходимо определить последовательность реализации
историй на несколько историй вперед.
Разработчикам
Необходима для минимально достаточного проектирования,
нужного для определения и оценки историй.
Прежде чем взять в работу 1ю историю, необходымы знания о
"стыковке" историй между собой
17. О чем молчит "Scrum": параллельный трек
проектирования
Идет впереди трека разработки хотя бы на одну итерацию
Высокая нагрузка на команду проектировщиков:
много взаимодействия с заказчиком,
консультации разработчиков по их текущей итерации
тестирование результата разработчиков по прошлой итерации
и его сдача заказчику
создание ТЗ, use case, прототипов и дизайна, etc для
следующей итерации разработчиков
Высокая нагрузка определяет необходимости:
делегирования проектирования реализации разработчикам.
быстрого прототипирования
18. Scrum good practicies
Проектировщикам:
Детализируйте прототипы итеративно, по мере назревающей
необходимости и доступных ресурсов. Если времени нет/мало,
лучше вначале решать задачи, блокирующие разработку.
Когда нет времени, прототипируйте на бумаге. Делайте быстрее и
проще, все что можете, без излишней детализации.
Используйте прототипы в качестве ТЗ, всегда, когда это
возможно.
19. Scrum good practicies
Разработчикам:
Управляйте конфигурацией и качеством поставок в угоду срокам.
Лучше не сделать фичи или сделать наполовину, или по
простому, чем сорвать дату поставки.
Неэффективный/некрасивый код/архитектуру можно рефакторить
в следующей итерации, если это оправдано.
Используйте магию проектирования гибких систем, дабы их
развитие не определялось их архитектурой. Откладывайте
реализацию определяющих архитектурное развитие компонент,
на сколько возможно. Уделяйте максимум внимания при
разработке фундаментальных компонент, которые не
поддадутся изменениям в будущем.
20. Резюме
Большие и средние проекты это вам не маленькие
Осознанно и правильно выбранная методология разработки это
необходимое условие успеха проекта
Scrum это гибкость и скорость
В эффективном Scrum, параллельно разработке существует трек
проектировщиков, идущий на опережение разработчиков на
несколько итераций.
В Scrum и разработчикам, и проектировщикам, и заказчику нужна
нулевая итерация.
Практикуйте хорошую практику: правильные шаги в правильной
последовательностью с правильной детализацией.