Основано на книге Стив МакКонелл, "Сколько стоит программный проект"
- Цели, План, Эстимейт, Обязательства - как они взаимосвязаны?
- Переоценка и недооценка - последствия
- Основные причины ошибок в оценках
- Факторы и их влияние на оценку (COCOMO ||)
- Методы оценки
- Правильная процедура оценки
Полезные ссылки:
Classic Mistakes Enumerated -
http://www.stevemcconnell.com/rdenum.htm
CoCoMo - https://ru.wikipedia.org/wiki/COCOMO
Экстремальное программирование - https://ru.wikipedia.org/wiki/Экстремальное_программирование
2013.08.24 Антон Киселёв семинар "Agile (Scrum)"Alexey Fedorov
Антон Киселёв (Undev, Tester's Life) сделал для SPB SQA Group обзорный доклад о Agile и Scrum. В презентации много ссылок на истоки, прошлое, настоящее и тендеции будущего Scrum
Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
Основано на книге Стив МакКонелл, "Сколько стоит программный проект"
- Цели, План, Эстимейт, Обязательства - как они взаимосвязаны?
- Переоценка и недооценка - последствия
- Основные причины ошибок в оценках
- Факторы и их влияние на оценку (COCOMO ||)
- Методы оценки
- Правильная процедура оценки
Полезные ссылки:
Classic Mistakes Enumerated -
http://www.stevemcconnell.com/rdenum.htm
CoCoMo - https://ru.wikipedia.org/wiki/COCOMO
Экстремальное программирование - https://ru.wikipedia.org/wiki/Экстремальное_программирование
2013.08.24 Антон Киселёв семинар "Agile (Scrum)"Alexey Fedorov
Антон Киселёв (Undev, Tester's Life) сделал для SPB SQA Group обзорный доклад о Agile и Scrum. В презентации много ссылок на истоки, прошлое, настоящее и тендеции будущего Scrum
Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
Курс Управления Проектами.
Лекция 1- 2 .
Содержание:
Вступление
Что такое Project Management
Кто такие менеджеры проектов в IT?
Должностные обязанности менеджера проектов.
Разница между Product и Project Manager.
Перспективы развития: горизонтальная и вертикальная карьерная лестница.
Типы IT компаний.
Разница между аутсорс, аутстафф и продуктовой.
Александр Андронов, Engineering AssessmentScrumTrek
Улучшить можно то, что можно измерить. Это главный тезис измерения. Мы измеряем, чтобы улучшать. Мы хотим улучшать код, инженерку. Для этого нужно код измерять. Как?
Я расскажу о метриках на самом низком уровне создания IT-продуктов. О тех метриках, которые находятся на уровне инженерки, на уровне программистов и QA. Упор сделан на те, которые зависят от человеческого фактора, которые не измерить автоматическими инструментами. Работая над несколькими проектами и наблюдая за десятком других как Agile-тренеры, мы выработали 9 метрик, которые описывают текущее состояние системы с точки зрения инженерки. В динамике они помогают мгновенно реагировать, если что-то идет не так.
Двенадцатый митап Software Craftsmanship пройдет онлайн и будет посвящен высоконагруженным системам. Мы систематизирует инструменты, применяемые для разработки архитектуры высоконагруженных приложений, опишем базовый алгоритм из 6 шагов проектирования нагруженной системы.
Также мы рассмотрим 3 примера нагруженных приложений - клиент для участия в Real Time Bidding аукционах, поисковик вместе с краулером для него, чат.
Мы коснемся опасностей, которые подстерегают новичков и опытных архитекторов.
Кроме того, рассмотрим подходы к построению высоконагруженных систем в стартапе и в сервисной компании.
Дмитрий Грибов, Трава и грибы как средства управления разработкойScrumTrek
Управление разработкой в ЛитРес: Игровые грибы на службе управления проектами Холакратия, настоенная на травах Деревянный Agile Спринты длинною в час и ежедневный релиз Рыночная игра как альтернатива микроменеджменту KPI для разработчиков, основанный на реальных результатах (сдельная оплата программистам в штате) История о том, как команда из 27-и человек эффективно поддерживает и развивать сервис с миллиардной выручкой
Software craftsmanship 11 online: мотивация и эффектисность разработчикаPavel Veinik
Мы рассмотрим вопросы продуктивности, как командная работа и менеджеры влияют на продуктивность, как связаны оценки и эффективность решений разработчика, почему работа программиста является творческой, и как грамотно использовать инструменты тайм-менеджмента.
Константин Бажин, ТОП 10 не могу или что нужно сделать, чтобы жить по AgileScrumTrek
"Наступать на грабли - это не про нас!" - думали мы, когда ушли в разработку программного обеспечения с головой. И вроде бы все умные и прекрасно понимают как нужно делать правильно. Но! В ситуации, когда количество работы превышает количество ресурсов, а договорные обязательства никто не отменял, в какой-то момент - ЧТО-ТО ПОШЛО НЕ ТАК.
В своем докладе я расскажу как это все произошло и какие выводы мы сделали. А также опишу конкретные шаги, которые предприняли, чтобы этого избежать в дальнейшем.
Презентация доклада Максима Дроздова, менеджера проектов компании "ИСС Арт" "Контроль над распределенной командой".
Вебинар "Управление удаленной командой разработчиков".
Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...ScrumTrek
В больших компаниях обычно существует пропасть между людьми, которые делают, и людьми, которые сопровождают сделанное. Разные компетенции, разные области знаний, разная ответственность за функционирование продукта не позволяют компании эффективно разрабатывать и внедрять уникальные решения, вовремя менять часть технологического стека или весь стек целиком. Людям становится не интересно и сложно разбираться со старыми наработками, а внедрение новых сопровождается закостенелостью стандартов и инертностью компании. В рамках доклада будут рассмотрены следующие вопросы:
- что сегодня помогает закладывать нужные оси вариативности в архитектуру?
- как отделить и подружить разработку, внедрение и сопровождение?
- как замотивировать людей быть эффективными, использовать удобные инструменты?
- как дать людям свободу в их выборе и разделять ответственность за полученный результат?
а также в программе:
- Docker
- микросервисы
- закон трёх букв
User Stories vs. Use Cases
● User Stories
● Определение User Story
● Структура пользовательской истории
● Принципы проверки на качество User Story
● Use Cases
● Определение Use Cases
● Структура Use Cases
● Принципы составления Use Cases
Модуль 14. Лекция 55-56. Управление релизами и развертыванием продуктаYana Brodetski
Управление релизами и развертыванием
продукта (Release and Deployment)
● Планирование управлением поставками
продукта
● Определение артефактов
● Формирование плана конфигурации поставки
продукта
● Определение и формирование плана релиза
продукта
Курс Управления Проектами.
Лекция 1- 2 .
Содержание:
Вступление
Что такое Project Management
Кто такие менеджеры проектов в IT?
Должностные обязанности менеджера проектов.
Разница между Product и Project Manager.
Перспективы развития: горизонтальная и вертикальная карьерная лестница.
Типы IT компаний.
Разница между аутсорс, аутстафф и продуктовой.
Александр Андронов, Engineering AssessmentScrumTrek
Улучшить можно то, что можно измерить. Это главный тезис измерения. Мы измеряем, чтобы улучшать. Мы хотим улучшать код, инженерку. Для этого нужно код измерять. Как?
Я расскажу о метриках на самом низком уровне создания IT-продуктов. О тех метриках, которые находятся на уровне инженерки, на уровне программистов и QA. Упор сделан на те, которые зависят от человеческого фактора, которые не измерить автоматическими инструментами. Работая над несколькими проектами и наблюдая за десятком других как Agile-тренеры, мы выработали 9 метрик, которые описывают текущее состояние системы с точки зрения инженерки. В динамике они помогают мгновенно реагировать, если что-то идет не так.
Двенадцатый митап Software Craftsmanship пройдет онлайн и будет посвящен высоконагруженным системам. Мы систематизирует инструменты, применяемые для разработки архитектуры высоконагруженных приложений, опишем базовый алгоритм из 6 шагов проектирования нагруженной системы.
Также мы рассмотрим 3 примера нагруженных приложений - клиент для участия в Real Time Bidding аукционах, поисковик вместе с краулером для него, чат.
Мы коснемся опасностей, которые подстерегают новичков и опытных архитекторов.
Кроме того, рассмотрим подходы к построению высоконагруженных систем в стартапе и в сервисной компании.
Дмитрий Грибов, Трава и грибы как средства управления разработкойScrumTrek
Управление разработкой в ЛитРес: Игровые грибы на службе управления проектами Холакратия, настоенная на травах Деревянный Agile Спринты длинною в час и ежедневный релиз Рыночная игра как альтернатива микроменеджменту KPI для разработчиков, основанный на реальных результатах (сдельная оплата программистам в штате) История о том, как команда из 27-и человек эффективно поддерживает и развивать сервис с миллиардной выручкой
Software craftsmanship 11 online: мотивация и эффектисность разработчикаPavel Veinik
Мы рассмотрим вопросы продуктивности, как командная работа и менеджеры влияют на продуктивность, как связаны оценки и эффективность решений разработчика, почему работа программиста является творческой, и как грамотно использовать инструменты тайм-менеджмента.
Константин Бажин, ТОП 10 не могу или что нужно сделать, чтобы жить по AgileScrumTrek
"Наступать на грабли - это не про нас!" - думали мы, когда ушли в разработку программного обеспечения с головой. И вроде бы все умные и прекрасно понимают как нужно делать правильно. Но! В ситуации, когда количество работы превышает количество ресурсов, а договорные обязательства никто не отменял, в какой-то момент - ЧТО-ТО ПОШЛО НЕ ТАК.
В своем докладе я расскажу как это все произошло и какие выводы мы сделали. А также опишу конкретные шаги, которые предприняли, чтобы этого избежать в дальнейшем.
Презентация доклада Максима Дроздова, менеджера проектов компании "ИСС Арт" "Контроль над распределенной командой".
Вебинар "Управление удаленной командой разработчиков".
Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...ScrumTrek
В больших компаниях обычно существует пропасть между людьми, которые делают, и людьми, которые сопровождают сделанное. Разные компетенции, разные области знаний, разная ответственность за функционирование продукта не позволяют компании эффективно разрабатывать и внедрять уникальные решения, вовремя менять часть технологического стека или весь стек целиком. Людям становится не интересно и сложно разбираться со старыми наработками, а внедрение новых сопровождается закостенелостью стандартов и инертностью компании. В рамках доклада будут рассмотрены следующие вопросы:
- что сегодня помогает закладывать нужные оси вариативности в архитектуру?
- как отделить и подружить разработку, внедрение и сопровождение?
- как замотивировать людей быть эффективными, использовать удобные инструменты?
- как дать людям свободу в их выборе и разделять ответственность за полученный результат?
а также в программе:
- Docker
- микросервисы
- закон трёх букв
User Stories vs. Use Cases
● User Stories
● Определение User Story
● Структура пользовательской истории
● Принципы проверки на качество User Story
● Use Cases
● Определение Use Cases
● Структура Use Cases
● Принципы составления Use Cases
Модуль 14. Лекция 55-56. Управление релизами и развертыванием продуктаYana Brodetski
Управление релизами и развертыванием
продукта (Release and Deployment)
● Планирование управлением поставками
продукта
● Определение артефактов
● Формирование плана конфигурации поставки
продукта
● Определение и формирование плана релиза
продукта
It talk №23: "Если не Scrum, то что?", Екатерина ШалапановаMarina Peregud
Докладчик: Екатерина Шалапанова, деливери-менеджер финансовой практики DataArt, Петербург
О чем пойдет речь:
Что делать:
Если ваш заказчик не подписывал Agile Manifesto и не читал Scrum Guide?
Если в итерацию врываются сверхсрочные задачи?
Если бизнес-процессы не позволяют регулярные релизы?
Идеологи Scrum создавали процесс для небольших вовлеченных и нацеленных на результат команд. Что же делать, если вам приходится работать с корпорациями?
Процесс приходится строить заново, беря все самое лучшее и подстраиваясь под нужды и возможности любимых клиентов.
Я расскажу, какие подходы мы используем при создании процесса разработки, что, по моему опыту, важно, а чем можно пренебречь, ну, и обязательно о чем-нибудь еще.
Какие вопросы встают перед руководителем разработки? Что нужно анализировать для успешного решения задач и запуска проектов? Как меняются вопросы, когда тим-лид дорастает до руководства департаментом?
Similar to Марри Кантор, Управление программными проектами (20)
10. III. Экономическая модель разработки ПО ... и как уменьшить величину тудозатрат Усилие = (коллектив) * (средства) * (сложность)процесс < Коллектив < Сложность Наём и обучение, ограничение нововведений Уменьшение сложности < Средства < Процесс Автоматизация повседневных задач Уменьшение количества взаимодействий между участниками
25. V. Процесс разработки ПО Стандартный либо собственный? Отказ от стандартного процесса означает, что коллектив должен «нырнуть» в неизведанные воды – некоторые сделают это с надеждой, а другие – с чувством страха перед неизведанным. Выбрать стандартный процесс разработки – значит пойти проторенным путем. Энергия коллектива удет потрачена на движение вперёд, а не на поиск пути.
32. Если, пока шла разработка, изменились требования, приоритеты, конъюнктура рынка – что делать руководителю?.... при этой схеме у вас есть два выхода: ранняя неудача либо поздняя неудача.
33.
34. при таком подходе возможность руководителя определить риски ни увеличивается, ни уменьшается по сравнению с «ничег не деланием»... если вы руководствуетесь этим подходом, остаётся пожелать вам удачи. Она вам скоро понадобится!
35.
36. метод неприменим для разработки большим коллективом разработчиков ... в результате можно не получить ничего, кроме прототипа системы
![I. Успешный продукт Критерии ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)