Про качество и красоту кода говорят и пишут очень многие, хотя при этом довольно часто забывают, для чего существует это качество и эта красота.
Двадцать второй онлайн митап Software Craftsmanship будет посвящен Engineering Excellence. мы рассмотрим что такое Engineering Excellence, кому и для чего оно нужно на проекте, из каких частей состоит и как определить что нужно конкретному проекту.
На митапе мы рассмотрим взаимосвязь разработчиков, тестировщиков, девопсов, разберем метрики, практики и процессы необходимы для постоянного улучшения проекта.
Software craftsmanship 11 online: мотивация и эффектисность разработчикаPavel Veinik
Мы рассмотрим вопросы продуктивности, как командная работа и менеджеры влияют на продуктивность, как связаны оценки и эффективность решений разработчика, почему работа программиста является творческой, и как грамотно использовать инструменты тайм-менеджмента.
Когда-то давным давно я читала серию лекций для очень начинающих аналитиков. Вернее для студентов, которые рассматривали аналитику как возможное направление своей карьеры. Лекции большие, но предельно упрощенные. Даже сама профессия разбита на функции других, более "известных" аудитории профессий.
Про качество и красоту кода говорят и пишут очень многие, хотя при этом довольно часто забывают, для чего существует это качество и эта красота.
Двадцать второй онлайн митап Software Craftsmanship будет посвящен Engineering Excellence. мы рассмотрим что такое Engineering Excellence, кому и для чего оно нужно на проекте, из каких частей состоит и как определить что нужно конкретному проекту.
На митапе мы рассмотрим взаимосвязь разработчиков, тестировщиков, девопсов, разберем метрики, практики и процессы необходимы для постоянного улучшения проекта.
Software craftsmanship 11 online: мотивация и эффектисность разработчикаPavel Veinik
Мы рассмотрим вопросы продуктивности, как командная работа и менеджеры влияют на продуктивность, как связаны оценки и эффективность решений разработчика, почему работа программиста является творческой, и как грамотно использовать инструменты тайм-менеджмента.
Когда-то давным давно я читала серию лекций для очень начинающих аналитиков. Вернее для студентов, которые рассматривали аналитику как возможное направление своей карьеры. Лекции большие, но предельно упрощенные. Даже сама профессия разбита на функции других, более "известных" аудитории профессий.
Владимир Завертайлов. Требовательность, мозгоклюйство и провокации: уровни уп...ScrumTrek
Интерактивный мастер-класс, где будет разобрано 8 типичных, но очень не простых для любого руководителя ситуаций. 1. Провокация. 2. Продажа. 3. Жизнь после релиза. 4. Конфликт с дизайнером (я — художник, я так вижу) 5. Конфликт с программистом: требования говно! 6. Интеграция по центрирующим парадигмам 7. Учимся говорить "НЕТ!" 8. Рабочие запахи
Вторая лекция для очень начинающих аналитиков из серии, которую я читала в 2008. В ней затрагиваются функции аналитика, пересекающиеся с работой консультанта: в основном это коммуникативные навыки, умение задавать вопросы и навыки того, что делать с ответами.
Это последняя лекция в серии для очень начинающих аналитиков. Она о высоком: о творчестве, о познании, о сложных задачах, которые тоже являются частью работы аналитика. Об этой стороне редко говорят, считая ее трудно формализуемой, необязательной или считают, что это "не для всех". Но останавливаясь только на обязательных, формальных и рутинных частях работы аналитика, мы сами убиваем любовь к собственной профессии, превращая ее в колесо для белки. Так вот: учитесь видеть в своей профессии творчество!
Двенадцатый митап Software Craftsmanship пройдет онлайн и будет посвящен высоконагруженным системам. Мы систематизирует инструменты, применяемые для разработки архитектуры высоконагруженных приложений, опишем базовый алгоритм из 6 шагов проектирования нагруженной системы.
Также мы рассмотрим 3 примера нагруженных приложений - клиент для участия в Real Time Bidding аукционах, поисковик вместе с краулером для него, чат.
Мы коснемся опасностей, которые подстерегают новичков и опытных архитекторов.
Кроме того, рассмотрим подходы к построению высоконагруженных систем в стартапе и в сервисной компании.
Владимир Завертайлов. Выравнивание нагрузки в IT-компании: впихнуть невпихуемое.ScrumTrek
Доклад нацелен на подготовленных слушателей, руководителей проектов или директоров студий с десятком и более сотрудников, в общих чертах что-то слышавших про LEAN и ТОС. Выстройте поток единичных изделий, выравнивайте его и оптимизируйте скорость — говорит нам LEAN и производственная система Тойоты. Найдите ограничение и подчините ритму его работы все остальные звенья производственной цепи, Сбалансировать поток невозможно, говорит нам теория ограничений (ТОС). Все это очевидно работает, в примерах производства серийной продукции. Но и то и другое непонятно как применить на практике в сфере услуг. Тем более таких высоко кастомизируемых, как наша сфера — digital. Нам, директорам, больно смотреть, когда штатный сотрудник остаётся без задач, т.к. не готовы или не согласованы работы предыдущего этапа. Мы стремимся загрузить всех и максимально. Порой это приводит к тому, что мы хватаемся за огромное число проектов. А вдруг какой-то застрянет на согласовании — такой логикой руководствуемся мы. Это приводит либо к большим очередям (клиенты вынуждены ждать и ненавидеть it-шников за неповоротливость). Либо к необходимости перегружать сотрудников, а это приводит к повышенному проценту брака в их работе, и, как следствие, к дополнительной перегрузке, низкой скорости и ненависти к it-шникам со стороны клиента. Впихнуть невпихуемое и не стать студией, где считается преступлением быть «не затраханным». В этом докладе мы разберемся с вами, что можно автоматизировать для балансировки нагрузки. Что можно выбрать за единичное изделие. Как построить поток, визуализировать его, найти узкое звено и научиться предсказывать, где и когда у вас в
Дмитрий Матвеев, Александр Павлович. Гибкий подход к продуктовому развитию Го...ScrumTrek
Доклад про трансформацию процесса развития госуслуг: не столько и не только разработка кода портала госуслуг, сколько изменения всего процесса сервис-дизайна. А также договорная составляющая: как гибкий подход нашёл отражение в госконтрактах.
Дизайн-мышление для инноваций в бизнесе. "Лаборатория знаний" Coursera @Digit...Lumiknows Consultancy
Дизайн-мышление для инноваций в бизнесе. "Лаборатория знаний" Coursera @Digital October.
Презентация встречи #4 offline-поддержки курса Coursera "Дизайн-мышление для инноваций в бизнесе" в России. Проект "Лаборатория знаний" Coursera на базе Digital October. Кураторы: Екатерина Храмкова, Lumiknows, Алексей Николаев, Intel Russia.
Доклад на SQAdays весной 2017 в Москве. Страница доклада http://mtsepkov.org/SelfDet Проблема самоопределения, конструирования своего будущего в современном мире становится все актуальнее, в отличие от мира прошлого, в котором ты определялся всего пару раз, выбирая профессию и создавая семью, да и то это часто делали за тебя родители. А сейчас ты должен делать это регулярно, да еще - в быстро развивающемся мире, что особенно заметно в мире IT, на фоне бурного развития технологий. У меня сформировалась сборка из схем, которые помогают это делать.
Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
Искусство просить деньги. Как просить кого угодно о какой угодно сумме для ка...Burt and Co LLC
Умение просить - одна из самых важных составляющих успешного сбора пожертвований. Каждой организации требуются деньги на ее целевые проекты, на ее годичный фонд, у нее есть программы сбора крупных и плановых пожертвований и большие кампании по привлечению капитала. Единственный способ, с помощью которого группа людей может постоянно, год за годом, собирать значительные денежные средства, - личное обращение к спонсору. "Искусство просить деньги" - это всеобъемлющее руководство, которое поможет преодолеть страхи и комплексы, мешающие людям обращаться к другим с просьбой о пожертвованиях. Оно дает ценные советы на всех стадиях процесса, начиная с подготовки к встрече со спонсором и кончая приемами для получения желанного "да!" - положительного ответа на свое обращение.
Книга адресована сборщикам пожертвований для организаций любого масштаба и вида, высшим управляющим, ответственным за обеспечение финансовой устойчивости компании, благотворителям, а также всем, кто хочет научиться просить пожертвования.
Название: Искусство просить деньги. Как просить кого угодно о какой угодно сумме для какой угодно цели
Автор: Лора Фредрикс
Издательство: Олимп-Бизнес
Год: 2010
Формат: PDF (как читать и чем открыть формат PDF)
Размер файла: 13.2 Мб
Количество страниц: 336
Язык: Русский
ISBN: Олимп-Бизнес
Владимир Завертайлов. Требовательность, мозгоклюйство и провокации: уровни уп...ScrumTrek
Интерактивный мастер-класс, где будет разобрано 8 типичных, но очень не простых для любого руководителя ситуаций. 1. Провокация. 2. Продажа. 3. Жизнь после релиза. 4. Конфликт с дизайнером (я — художник, я так вижу) 5. Конфликт с программистом: требования говно! 6. Интеграция по центрирующим парадигмам 7. Учимся говорить "НЕТ!" 8. Рабочие запахи
Вторая лекция для очень начинающих аналитиков из серии, которую я читала в 2008. В ней затрагиваются функции аналитика, пересекающиеся с работой консультанта: в основном это коммуникативные навыки, умение задавать вопросы и навыки того, что делать с ответами.
Это последняя лекция в серии для очень начинающих аналитиков. Она о высоком: о творчестве, о познании, о сложных задачах, которые тоже являются частью работы аналитика. Об этой стороне редко говорят, считая ее трудно формализуемой, необязательной или считают, что это "не для всех". Но останавливаясь только на обязательных, формальных и рутинных частях работы аналитика, мы сами убиваем любовь к собственной профессии, превращая ее в колесо для белки. Так вот: учитесь видеть в своей профессии творчество!
Двенадцатый митап Software Craftsmanship пройдет онлайн и будет посвящен высоконагруженным системам. Мы систематизирует инструменты, применяемые для разработки архитектуры высоконагруженных приложений, опишем базовый алгоритм из 6 шагов проектирования нагруженной системы.
Также мы рассмотрим 3 примера нагруженных приложений - клиент для участия в Real Time Bidding аукционах, поисковик вместе с краулером для него, чат.
Мы коснемся опасностей, которые подстерегают новичков и опытных архитекторов.
Кроме того, рассмотрим подходы к построению высоконагруженных систем в стартапе и в сервисной компании.
Владимир Завертайлов. Выравнивание нагрузки в IT-компании: впихнуть невпихуемое.ScrumTrek
Доклад нацелен на подготовленных слушателей, руководителей проектов или директоров студий с десятком и более сотрудников, в общих чертах что-то слышавших про LEAN и ТОС. Выстройте поток единичных изделий, выравнивайте его и оптимизируйте скорость — говорит нам LEAN и производственная система Тойоты. Найдите ограничение и подчините ритму его работы все остальные звенья производственной цепи, Сбалансировать поток невозможно, говорит нам теория ограничений (ТОС). Все это очевидно работает, в примерах производства серийной продукции. Но и то и другое непонятно как применить на практике в сфере услуг. Тем более таких высоко кастомизируемых, как наша сфера — digital. Нам, директорам, больно смотреть, когда штатный сотрудник остаётся без задач, т.к. не готовы или не согласованы работы предыдущего этапа. Мы стремимся загрузить всех и максимально. Порой это приводит к тому, что мы хватаемся за огромное число проектов. А вдруг какой-то застрянет на согласовании — такой логикой руководствуемся мы. Это приводит либо к большим очередям (клиенты вынуждены ждать и ненавидеть it-шников за неповоротливость). Либо к необходимости перегружать сотрудников, а это приводит к повышенному проценту брака в их работе, и, как следствие, к дополнительной перегрузке, низкой скорости и ненависти к it-шникам со стороны клиента. Впихнуть невпихуемое и не стать студией, где считается преступлением быть «не затраханным». В этом докладе мы разберемся с вами, что можно автоматизировать для балансировки нагрузки. Что можно выбрать за единичное изделие. Как построить поток, визуализировать его, найти узкое звено и научиться предсказывать, где и когда у вас в
Дмитрий Матвеев, Александр Павлович. Гибкий подход к продуктовому развитию Го...ScrumTrek
Доклад про трансформацию процесса развития госуслуг: не столько и не только разработка кода портала госуслуг, сколько изменения всего процесса сервис-дизайна. А также договорная составляющая: как гибкий подход нашёл отражение в госконтрактах.
Дизайн-мышление для инноваций в бизнесе. "Лаборатория знаний" Coursera @Digit...Lumiknows Consultancy
Дизайн-мышление для инноваций в бизнесе. "Лаборатория знаний" Coursera @Digital October.
Презентация встречи #4 offline-поддержки курса Coursera "Дизайн-мышление для инноваций в бизнесе" в России. Проект "Лаборатория знаний" Coursera на базе Digital October. Кураторы: Екатерина Храмкова, Lumiknows, Алексей Николаев, Intel Russia.
Доклад на SQAdays весной 2017 в Москве. Страница доклада http://mtsepkov.org/SelfDet Проблема самоопределения, конструирования своего будущего в современном мире становится все актуальнее, в отличие от мира прошлого, в котором ты определялся всего пару раз, выбирая профессию и создавая семью, да и то это часто делали за тебя родители. А сейчас ты должен делать это регулярно, да еще - в быстро развивающемся мире, что особенно заметно в мире IT, на фоне бурного развития технологий. У меня сформировалась сборка из схем, которые помогают это делать.
Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
Искусство просить деньги. Как просить кого угодно о какой угодно сумме для ка...Burt and Co LLC
Умение просить - одна из самых важных составляющих успешного сбора пожертвований. Каждой организации требуются деньги на ее целевые проекты, на ее годичный фонд, у нее есть программы сбора крупных и плановых пожертвований и большие кампании по привлечению капитала. Единственный способ, с помощью которого группа людей может постоянно, год за годом, собирать значительные денежные средства, - личное обращение к спонсору. "Искусство просить деньги" - это всеобъемлющее руководство, которое поможет преодолеть страхи и комплексы, мешающие людям обращаться к другим с просьбой о пожертвованиях. Оно дает ценные советы на всех стадиях процесса, начиная с подготовки к встрече со спонсором и кончая приемами для получения желанного "да!" - положительного ответа на свое обращение.
Книга адресована сборщикам пожертвований для организаций любого масштаба и вида, высшим управляющим, ответственным за обеспечение финансовой устойчивости компании, благотворителям, а также всем, кто хочет научиться просить пожертвования.
Название: Искусство просить деньги. Как просить кого угодно о какой угодно сумме для какой угодно цели
Автор: Лора Фредрикс
Издательство: Олимп-Бизнес
Год: 2010
Формат: PDF (как читать и чем открыть формат PDF)
Размер файла: 13.2 Мб
Количество страниц: 336
Язык: Русский
ISBN: Олимп-Бизнес
В докладе будет рассказано и показано, как расширить возможности стандартного ASP.NET MVC3 web-приложения, используя браузерный native-плагин, написанный на языке C++. Будет показано применение фреймворка FireBreath, позволяющего легко создавать гибкие, кроссплатформенные и кроссбраузерные плагины. Будут затронуты вопросы взаимодействия managed-кода на C# с native-кодом на C++, а также показаны возможности по вызову кода на C++/C# из клиентского JavaScript-кода web-страницы. Применение вышеназванных технологий будет показано на примерах, одним из которых является разработанный для нужд системы электронного документооборота плагин, позволяющий осуществлять взаимодействие со сканером документов, подключенным к компьютеру клиента, из кода на JavaScript.
Также будет даваться краткое описание других технологий, связанных с выполнением браузером не специфичных для него функций: NaCl, Pepper, и приведено сравнение этих технологий.
В данном выступлении будет рассказно об общих принципах организации систем полнотекстового поиска на примере движка Sphinx. Будут рассмотрены структура и организация поискового индекса, на примере разобраны различные механимзы индексирования. Речь пойдет также и о продвинутых методиках работы со Sphinx: индексы реального времени, атрибуты с несколькими значениями, дельта-индексирование. Все это будет не только описано но и продемонстрировано, а желающие смогут проделывать все операции у себя на ноутбуках параллельно с докладчиком (см. описание программных требований).
Вторая часть будет посвящена непосредственно поиску и взаимодействию с движком Sphinx из программного кода на языке C#. Будут использованы механизмы обращения к Sphinx как используя нативный протокол, так и через MySQL-адаптер. Будет показано применение библиотек Sphinx.Client, Scarab и ByndyuSoft.Infrastructure.Sphinx, две из которых созданы автором мастер-класса. Также будут рассмотрены типовые ситуации использования Sphinx и шаблоны организации поиска.
Управление продажами. Управление отношениями с ключевыми клиентами.Alexey Nazarov
Систематический анализ, подбор и управление фактическими и потенциальными стратегически важными клиентами в целях достижения сравнительного конкурентного преимущества
Общая классификация космических кораблей по режиму работы. Рассмотренные проекты: бомбардировщик Эйнера Зенгера, самолёт Келдыша, орбитальный самолёт "Х-20" (Dyna Soar), авиационно-космическая система "Спираль", беспилотный орбитальный ракетоплан "БОР-4", экспериментальный пилотируемый орбитальный самолёт "ЭПОС" (МиГ 105.11), многоразовая транспортная космическая система "Space Shuttle", многоразовая космическая система "Энергия-Буран", орбитальный корабль "Hermes", многоцелевая авиационно-космическая система "МАКС". Другие проекты орбитальных самолётов: английские "Skylon" и "Hotol", советский "МГ-19" (Гурколёт), американский "X-33" (Venture Star), японский "H-2 Hope" и китайский "921-3". Замороженный проект многоцелевого пилотируемого многоразового космического корабля "Клипер" (Россия) и действующий экспериментальный беспилотный орбитальный самолёт "Х-37b" (США).
Мы - профессиональная социальная сеть для специалистов в маркетинге, рекламе и PR
Цель сообщества MarketingPeople — создать единую площадку, объединяющую маркетологов всей страны и тех, кто пользуется результатами их работы. Глобальный Маркетинговый Отдел, где каждый профессионал сможет напрямую установить контакт с нужными людьми, поделиться собственным опытом и задать вопрос крупному эксперту в своей области.
Аудитория интернета в России: еще один год. Взгляд со стороныSergey Galyonkin
Аудитория интернета в России: еще один год. Взгляд со стороны (Руслан Тагиев, TNS gallup Media) Тематический блок "Аудитория и медийная реклама". С КИБ 2008.
Прикручивание колёс на ходу. Внедрение UX процессов в уже работающий продуктПрофсоUX
Доклад рассчитан на всех, кому интересна командная работа и дизайн-системы.
У себя в компании мы внедряем дизайн-систему «по-живому» — без отрыва от производства продукта. На конференции я расскажу, зачем мы на это пошли, как доказывали пользу изменений, что уже успели сделать и к чему планируем прийти.
Инструменты разные нужны, инструменты разные важныRoman Dvornov
В мире фронтенда уже существует большое количество инструментов: как браузерных, так и консольных. Но достаточно ли этих инструментов? Мне кажется, что нет. Веб-приложения становятся все больше и сложнее, и многое остается вне нашего поля зрения. Потому фреймворки и приложения должны предоставлять дополнительные инструменты, упрощающие разработку и улучшающие понимание того, что же происходит у них там — «под капотом». В ходе доклада я расскажу о таких инструментах: какими они могут быть, какие задачи могут решать, что необходимо для их создания.
CodeFest, Новосибирск, 28 марта 2015
http://www.youtube.com/watch?v=HMTc3DERw5c
Борис Вольфсон. Почему Agile больше не работаетScrumTrek
Гибкие подходы перестали работать! По крайне мере, если судить по многочисленным публикациям, которые все чаще и чаще стали появляться. У кого-то не работает Scrum, у кого-то не прижился Канбан и, вообще, Agile не работает. В своем докладе я также приведу несколько примеров критики Agile в виде статей и докладов, разберу типичные заблуждения и ошибки, которыми оперируют критики.
Если использовать модель жизненного цикла принятия инноваций, можно спрогнозировать, что число такого негатива будет расти, потому что в России Agile начинают использовать не только инноваторы и ранние последователи, но и раннее большинство, которому трудно грамотно внедрить Agile и стать действительно гибкими.
Опытные управленцы, которые владеют гибкими подходами, обычно посмеиваются над этим негативом и пересказывают друг другу как анекдоты, а это как раз и есть та пропасть, которую Джеффри Мур описал в своей книге. Дополнительно мы обсудим, где сейчас находится Agile с точки зрения цикла зрелости технологий, так как эта модель тоже объясняет неудачный опыт использования Agile.
Agile-сообществу важно дальше вовлекать и помогать развиваться тем, кто пытается сделать свою команды, отдел или целую компанию гибкой.
Ключевые навыки успешной Agile-команды / Дмитрий Лобасев (lobasev.ru)Ontico
Динамика изменений со стороны бизнеса (наших заказчиков) сейчас настолько велика, что впереди оказываются компании, процесс разработки в которых непрерывно эволюционирует.
Эволюционный процесс позволяет научиться делать более быстрые поставки, принимать более качественные решения, а главное, поставлять с первого раза именно то, что нужно бизнесу.
Необходимый минимум для построения современных процессов разработки - это три ключевых, обязательных для освоения навыка, которым просто обязан научиться каждый участник проектной команды:
1. как можно раньше узнавать то, чего мы еще не знаем;
2. вовремя видеть, анализировать и решать возникающие проблем;
3. помогать бизнесу добиваться лучших из возможных результатов.
Во время доклада я расскажу подробно, какие инструменты вы можете использовать, чтобы выработать в своей команде эти три навыка и тем самым научиться постоянно улучшаться.
Канвас "Думай как создатель": дизайн-мышление-трендвотчинг-прототипированиеLumiknows Consultancy
Канвас "Думай как создатель" объединил инструментарий дизайн-мышления, трендвотчинга и прототипирования: 10 шагов для создания нового продукта, услуги, бизнеса.
Менеджерские школы учат, как готовить проекты правильно. А реальность говорит про 30% успешного завершения проектов. Чувствуете проблему?
Этот доклад про опыт. Про множество подходов, которые смогут помочь ускорить разработку. Никакой уличной магии нет, есть множество рецептов, приводящих к результату, который даёт на выходе работающий продукт и радует заказчика. Это факторы планирования, технологий, психологии, презентации, приоритезации и многие другие.
Приготовьтесь к изменениям!
3. Обо мне
Получил диплом инженера по специальности 230101 в
2011 году.
С сентября 2010 до февраль 2012 года работал в
компании IndyCode в должности разработчика в стеке
технологий .NET
С марта по июнь 2012 года работал в компании
DoneRight в должности web-разработчика в стеке
технологий .NET
С августа 2012 года работаю в компании ByndyuSoft в
должности ведущего разработчика / тимлида
4. Я...
Не менеджер
Не технический директор
Не внедритель Agile/Scrum/Kanban
Разработчик
6. Что я видел
Микроменеджмент переходящий в «наноменеджмент»
Провальные в своей сути попытки внедрить Agile
Переход к Kanban от Scrum’а и обратно
Kanban-board собственной разработки
Проведение ретроспектив
Проведение стендапов
Попытка уйти от стендапов
Тайм-менеджмент
Использование sticky-notes
Mind map
Roadmap
Story mapping
User stories
Тестирование силами заказчика
Заказчик в команде
Заказчик на другом конце земного шара
Взаимодействие через wiki
И много чего еще...
8. Чего НЕ произойдет после того как вы
пройдете этот тренинг
Ваши проблемы не решаться сами по себе
Вы НЕ наладите оптимальный процесс разработки
Поведенческие особенности разработчиков из ваших
команд не изменятся
9. Но!..
Вы сможете понять ваши проблемы
Вы будете знать, что вы можете сделать (и что делают
другие команды разработчиков)
Вы сможете более эффективно решать возникающие
проблемы
24. Выводы
Важно осознавать факт наличия проблемы
Необходимо понимать, в чем именно заключается
проблема
Нужно обладать набором знаний для решения
проблемы
Надо обладать навыками для эффективного
применения этих знаний на практике
25. Проблемы самосознания
Насколько я квалифицирован, чтобы что-то решать?
Что я могу решить?
Я знаю, как я могу что-нибудь гарантировано решить?
26. Матрица компетентности
путь творца Компетентность
опыт
неосознанная осознанная
компетентность компетентность обучение
да
подражание
нет да
Осознанность
неосознанная осознанная
некомпетентность некомпетентность
нет
«собирание шишек»
советы коллег
27. Матрица компетентности
Компетентность
Я не Ага, вот оно как!
понимаю, почему да
так будет
правильно, но это
правильно
нет да
Осознанность
А че там делать? О, да тут все не
просто так...
нет
29. А на самом деле...
Все правила, принципы и подходы – это просто
формализованный здравый смысл.
Нахождение в 4й стадии означает использование
собственного опыта и здравого смысла.
Здравый смысл формализуют для удобства
запоминания, чтобы совершался переход из 2й в
3ю стадию.
32. Проблемы?
Вы тратите на организацию работы команды
неоправданно большое время
Вы планируете дольше, чем разрабатываете
В процессе разработки одновременно не задействованы
все члены команды
Вы не знаете, кто и чем занимается СЕЙЧАС
33. Причины?
Неправильно построенный процесс
Неправильно выбранные инструменты
Неправильно расставленные приоритеты
34. UML – не панацея
Что дает вам применение диаграммы прецедентов?
Что дает вам применение диаграммы
последовательности?
Что дает вам применение диаграммы классов?
Что дает вам наличие нотации?
35. UML – не панацея
UML отъедает временные ресурсы команды
UML не формирует единого представления из-за
высокого уровня абстракции
UML не нужен заказчику (как правило)
UML плохо декомпозируется над подзадачи
36. Что мы делаем при разработке?
Решаем проблемы заказчика!
А не превращаем абстрактные
рисунки в код
37. Если бы программисты строили
дома
42 в мире управления процессом разработки ПО
http://bit.ly/progbuilding
38. Отсутствие единого мнения
Обсуждали проект. Сидоров предлагает крупноблочную
архитектуру. Петрович настаивает, что все надо строить по
старинке, из кирпича, не по-ламерски. Самый радикальный
проект предложил Алекс: построить несколько десятков
деревянных коттеджей и потом соединить их подземными
туннелями. На Западе сейчас так модно. Напомнили ему, что
заказчик требует именно 12-этажный дом. Пытались решить
вопрос дуэлью в Quаkе. Алекса с его коттеджами завалили
сразу, но между Петровичем и Сидоровым вышла ничья. В
итоге каждый будет строить по своему плану, а потом
попытаемся все это соединить, чтоб не рухнуло.
42. Решение проблемы заказчика
Первый этаж готов! Показали его заказчику. Он
интересовался, почему в разных комнатах разная высота
потолков, почему из стен вываливаются кирпичи и почему в
доме нет подъезда, а влезать приходится через окно.
Объяснили ему, что это специальные ограничения демо-
версии. Уходим на праздники, гордые собой.
43. Саморазвитие
Вспомнили, что у нас кран достает только до 8 этажа. Послали
Сидорова доставать новый кран. Играем в Quаkе. Алекс
замочил Петровича. Растет смена!
45. Коллективное владение информацией
Вернулся Сидоров. Кран не достал, зато достал крутой
экскаватор. Предлагает вырыть глубокую шахту и построить
дом не в высоту, а в глубину. Говорит, что нигде в контракте
не сказано, что 12 этажей должны быть над поверхностью. Еле
отговорили.
46. Ценности команды
Решение проблеммы заказчика
Саморазвитие
Явное ощущение прогресса
Коллективное владение информацией
48. Принципы Agile
Наисвысший приоритет – удовлетворение потребностей заказчика, благодаря
регулярной и ранней поставке ценного программного обеспечения.
Изменение требований приветствуется, даже на поздних стадиях разработки.
Agile-процессы позволяют использовать изменения для обеспечения заказчику
конкурентного преимущества.
Работающий продукт следует выпускать как можно чаще, с периодичностью от
пары недель до пары месяцев.
На протяжении всего проекта разработчики и представители бизнеса должны
ежедневно работать вместе.
Над проектом должны работать мотивированные...
http://agilemanifesto.org/iso/ru
55. Agile – это конструктор
Нет понятия Agile
Есть набор практически полностью изолированных друг от
друга микро-практик и принципов
Практики можно комбинировать друг с другом
Практики нужно комбинировать друг с другом
59. По какому принципу комбинировать?
Это вкусно
Это удобно
Команда уже неформально использует это
Это решает конкретную проблему
Это способствует поддержанию определенной командной
ценности
61. Итеративная разработка
Выполнение работ параллельно с непрерывным анализом
полученных результатов и корректировкой предыдущих этапов
работы. Проект при этом подходе в каждой фазе развития
проходит повторяющийся цикл: Планирование — Реализация —
Проверка — Оценка
62. Итеративная разработка
Продолжительность итерации – одна-две недели
Результат итерации – протестированная версия
разрабатываемого продукта
Итерация включает в себя процесс перехода задач итерации
из состояния в состояние
64. User stories
Способ описания требований к разрабатываемой
системе, сформулированных как одно или более предложений
на ежедневном или деловом языке пользователя.
Пример:
Я как зарегистрированный и авторизованный пользователь
Могу нажать на кнопку «Сменить пароль» после ввода нового
пароля на форме «Смена пароля»
При этом мой пароль изменяется и я получаю сообщение об
успешной смене пароля
65. User stories и Use cases
User story представляет собой описание функции системы со
стороны пользователя (заказчика)
Use case представляет собой описание функции системы со
стороны самой системы (как правило содержит большее
число технических деталей)
66. WIP (work in progress)
Количество задач (user stories, etc.), находящихся в
одновременной разработке
В идеале WIP на определенном этапе жизненного цикла
задачи не должен превышать числа членов команды,
задействованных на данном этапе
67. DoD (definition of done)
Совокупность требований к функциональности
системы, которая является критерием готовности выпуска
релиза (в т.ч. и промежуточного)
Требования выражаются на языке сценариев приемочных
тестов
Требования могут выражаться в виде пользовательских
историй
Понимание и четкое видение DoD обязательно должно быть
общим у всех членом команды
68. Agile board
Доска (физическая или виртуальная) для фиксирования
прогресса выполнения задач в рамках итерации
Каждая задача должна побывать во всех состояниях-
колонках
Примеры состояний: «Запланировано», «В
разработке», «Готово к тестированию», «В процессе
тестирования», «Готово»
69. Решения для организации Agile board
SaaS:
AgileZen – http://www.agilezen.com
YouTrack InCloud – http://www.jetbrains.com/youtrack/hosted
My agility board – http://www.myagilityboard.com
Standalone:
Atlassian JIRA – http://www.atlassian.com/software/jira
Пробковая доска ;)
72. Whole team
Команда разработчиков должна включать в себя
специалистов, которые способны выполнять весь набор
ролей, необходимых для выпуска финальной версии продукта
и поддержания жизненного цикла разработки:
разработка, тестирование, оформление документации и, что
наиболее важно, представители заказчика.
73. Collective ownership
Coding standard
Коллективное владение знаниями о проекте, техническими
деталями реализации, списом требований подразумевает
открые механизмы доступа к ним.
Коллективное владение исходным кодом подразумевает
коллективную ответственность за качество этого исходного
кода, соблюдение единого стандарта кодирование и понимание
всеми членами команды разработчиков принципов
проектирования согласно которым строится дальнейшее
развитие продукта.
74. Planning game
Служит инструментом выработки и проверки наличия
единого представления всех членов команды о
существующих задачах
Является адаптивной системой оценки сроков выполнения
задач
Оценка задач может осуществляться в любых абсолютных и
относительных единицах (минуты, дни, попугаи и т.д.)
75. Planning poker
Оценка задачи производится «в закрытую» с использованием
специальных карт оценки определенного номинала
Затем карты переворачиваются «рубашкой» вниз
Члены команды разработчиков с самой маленькой и большей
оценками высказываются о причинах подобной оценки
В случае большого несовпадения мнений карты
перекидываются
76. Small releases
В конце каждой итерации выпускается релиз –
протестированная и стабильная версия системы.
Релизы делаются как можно чаще. В идеале – каждый день.
77. Visualize the workflow
Использование любых подручных средств для визуального
представления процесса разработки:
Burndown chart
Story mapping
Agile board
78. Daily meeting (standup)
Ежедневное (иногда ограниченное по времени) собрание всех
членов команды с целью получить ответы каждого на
следующие вопросы:
Что было сделано вчера?
Какие проблемы возникли в работе? (Что мешает двигаться
дальше?)
Что будет сделано сегодня?
Некоторые из вопросов могут пропускаться
79. Daily meeting (standup)
Цели:
Формирование единого представления о прогрессе у всей
команды
Предотвращение простоев в работе
Повышение мотивации (выявление «халявщиков»)
81. Pair programming
Разработка двумя разработчиками за одним компьютером с
последовательной передачей клавиатуры между ними.
Возможна комбинация с TDD: один разработчик пишет тест –
другой реализацию.