CUSTIS, profile picture
Uploaded byCUSTIS
PDF, PPTX917 views

Гибкость: как правильно жить и работать?

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

Embed presentation

Download as PDF, PPTX
1 / 111
2 / 111
3 / 111
4 / 111
5 / 111
6 / 111
7 / 111
8 / 111
9 / 111
10 / 111
11 / 111
12 / 111
13 / 111
14 / 111
15 / 111
16 / 111
17 / 111
18 / 111
19 / 111
20 / 111
21 / 111
22 / 111
23 / 111
24 / 111
25 / 111
26 / 111
27 / 111
28 / 111
29 / 111
30 / 111
31 / 111
32 / 111
33 / 111
34 / 111
35 / 111
36 / 111
37 / 111
38 / 111
39 / 111
40 / 111
41 / 111
42 / 111
43 / 111
44 / 111
45 / 111
46 / 111
47 / 111
48 / 111
49 / 111
50 / 111
51 / 111
52 / 111
53 / 111
54 / 111
55 / 111
56 / 111
57 / 111
58 / 111
59 / 111
60 / 111
61 / 111
62 / 111
63 / 111
64 / 111
65 / 111
66 / 111
67 / 111
68 / 111
69 / 111
70 / 111
71 / 111
72 / 111
73 / 111
74 / 111
75 / 111
76 / 111
77 / 111
78 / 111
79 / 111
80 / 111
81 / 111
82 / 111
83 / 111
84 / 111
85 / 111
86 / 111
87 / 111
88 / 111
89 / 111
90 / 111
91 / 111
92 / 111
93 / 111
94 / 111
95 / 111
96 / 111
97 / 111
98 / 111
99 / 111
100 / 111
101 / 111
102 / 111
103 / 111
104 / 111
105 / 111
106 / 111
107 / 111
108 / 111
109 / 111
110 / 111
111 / 111
Круглый стол «Гибкость: как правильно жить и работать?» Михаил Заборов руководитель стратегических проектов 2 декабря 2013 года
Компания CUSTIS   Существует с 1996 года  Agile-like процесс – с рождения Занимается заказной разработкой промышленного корпоративного ПО 2/111
Внедрение SCRUM в CUSTIS Андрей Бибичев    Асхат Уразбаев Первое внедрение – в 2007 Внедрял Асхат Уразбаев В 2009–2010 – регулярные встречи Agile Russia на нашей территории 3/111
Сегодня   В компании 20+ человек  90% используют похожий на SCRUM процесс В компании более 20 производственных команд 4/111
Немного про меня С критическим прищуром и перпендикулярным мнением  5/111
Часто SCRUM воспринимается так: 6/111
Восприятие SCRUM Только использование канонических процессов SCRUM дает действительно существенный позитивный результат Более мягкая формулировка Практики SCRUM зависят друг от друга, образуют систему и наибольший эффект получается при их совместном использовании 7/108
В результате «Вы используете неправильный SCRUM и поэтому у вас все плохо». А СКРАМ-то НЕНАСТОЯЩИЙ!!! Это не по Scrum-у!!! 8/111
ScrumButt  «We’ve got SCRUM, but…» 9/111
Разновидность «Вы просто еще не пробовали пользоваться настоящим SCRUM – попробуйте и вы увидите разницу». 10/111
Мой опыт SCRUM в чистом виде практически бесполезен, а иногда и наносит существенный вред Его нужно адаптировать под себя. Не нужно его фетишизировать и добиваться пуританской чистоты 11/111
При этом почти ничего плохого про Agile ≠ 12/111
Agile это всего лишь манифест 13/111
И немного принципов 14/111
Обсуждение 15/111
Крупные темы которые можно обсудить  Философия    C самомотивацией все не так просто Самоорганизация от сырости не заводится Практические  Роли в SCRUM (в т.ч. про классовую вражду и немного про профессию тестировщиков)  SCRUM планирование расслабляет команду Резюме 16/111
Мелкие темы которые можно обсудить  Требования к итерациям в SCRUM избыточно жесткие  Ретроспектива по SCRUM’овски – практически бесполезное занятие  Чаще всего DSM вырождается в пустой гундеж  В SCRUM’е демонстрация упрощена до бесполезности Резюме 17/111
Где еще скрам не помогает, а иногда даже мешает     Архитектура Работа с персоналом Долгосрочное планирование Ресурсное планирование (в том числе краткосрочное увеличение/уменьшение команды) Резюме 18/111
Про самомотивацию 19/111
Про самомотивацию  Над проектом должны работать  мотивированные профессионалы Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им Agile Manifesto 20/111
Что есть самомотивация? 21/111
Системы ценностей разных людей сильно отличаются  Далеко не всегда то, за что готов платить заказчик, мотивирует разработчиков  То, что ценно для разработчика, для заказчика может быть странной, никому не нужной самореализацией (самоудовлетворение).  То, что ценно для заказчика - для программиста может быть порождением воспаленного разума и непонятная, неведомая фигня.  Люди склонны оценивать многие, даже сложные задачи как рутинные 22/111
Матрица компетентность–интерес 23/111
Ценности меняются  Цели и задачи заказчиков регулярно меняются. Agile рассчитан именно на такие проекты “ Делали учетную систему, а в результате оказалась просто интеграция ”  То, что было интересным когда-то, со временем становится рутиной “ Я всю жизнь строю эти дурацкие мосты ” 24/111
Самомотивированные на результат проекта профессионалы крайне редки  Есть много людей, которым не очень много нужно от жизни  Еще больше людей, которые не знают, чего на самом деле хотят  Нужны очень эмоционально и ментально зрелые люди. Разработчики же в основном молодежь 25/111
Примеры мотиваторов на результат проекта 26/111
Самодостаточные люди  Разобраться, как работает сложный бизнес   Сделать мир чуть лучше Помочь хорошим людям 27/111
Ориентированные на внешний мир  Получить в портфолио сделанный проект и тем самым повысить свою ценность  Получить признание уважаемых людей (друзей, родственников, коллег) Много конъюнктуры и контуженных гламуром людей  28/111
Сделать что-то «хорошее» и «клёвое» – другая мотивация  В общем случае противоречит мотивации на результат проекта  Безусловно должна присутствовать в команде 29/111
Влияние SCRUM на мотивацию 30/111
От скрама мотивация не заводится  Никакая организационная конструкция (в том числе, SCRUM) не может создать мотивацию  В начале вы набираете команду мотивированных людей, а потом заводите SCRUM 31/111
От скрама мотивация может испортиться  Мотивированные на результат люди обычно хотят напрямую видеть этот результат и влиять на него. Proxy в виде ProductOwner-а их демотивирует  Ритуалы могут утомлять. Любую хорошую идею можно довести до абсурда  Если вы хотите чистый SCRUM, вам нужно регулярно чистить команду от тех, кто «не восторженно мыслит» 32/111
Мотивированным людям и без скрама хорошо 33/111
Алистер Коберн   Нет корреляции между успехом/провалом проектов и методологиями, которые применялись в проектах Успешность программного проекта на 100% определяется людьми 34/111
Обсуждение Список Тем 35/111
Про самоорганизацию 36/111
Про самоорганизацию  Команда – черный ящик, она подстраивает   себя сама Оставьте ее в покое, и она сама решит все проблемы Единственный способ повлиять на нее – добавить/удалить людей или разогнать SCRUMевангелисты 37/111
38/108
Команда далеко не всегда самоорганизуется эффективным для производства способом Правильно ли называть это «самоорганизацией»? Самоорганизация – результат долгой кропотливой работы специальных людей 39/108
Пример: Product Owner отстранился от принятия решений  Постоянные конфликты  Непродуктивные обсуждения того, что можно не обсуждать  Команду пришлось резать по живому 40/111
Возможное объяснение из теории игр 41/111
Дилемма заключенного Молчит Молчит Сдает 3 месяца свободен 20 лет Сдает свободен 20 лет 5 лет 42
Маша тестирует задачу, сделанную Петей в условиях жестких сроков и дефицита времени 43/111
Варианты действий Маша сотрудничает Маша и Петя находят компромисс Петя В результате оба немного сотрудничает перерабатывают Продукт выходит вовремя Петя заботится о себе Петя делает работу в притык, так что времени тестирование и исправление ошибок не остается Маша работает в выходные и по ночам Часть ошибок остается неисправленными Маша заботится о себе Маша требует много времени на тестирование Петя работает в выходные и по ночам чтобы успеть к сроку Маша требует много времени на тестирование Петя делает работу впритык, так что времени на тестирование и исправление ошибок не остается Сроки срываются 44/111
Равновесие Нэша Тип решений игры, в котором ни один участник не может увеличить выигрыш, изменив своё решение в одностороннем порядке, когда другие участники не меняют решения Равновесие Парето Молчит Молчит 3 месяца Равновесие Нэша Сдает свободен 20 лет Сдает  свободен 20 лет 5 лет 45/111
Слаженность действий 46/111
Нужен выделенный координирующий человек с полномочиями  В ситуации быстро меняющихся требований нужно быстро реагировать  Все это требует координации и выделенного человека, который держит на этом фокус 47/111
Даже самомотивированным людям нужно транслировать смысл задач заказчика  В том числе :  Показывать как именно мир становится лучше  Показывать живых людей, которым становится лучше 48/111
Если у исполнителей мотивация не на результат проекта ($, комфорт, самоудовлетворение), то работать с ними нужно по другому (не чистый скрам) Работа руководителя превращать желания заказчика в мотиваторы исполнителей Том Сойер 49/108
Руководителю нужно работать с людьми индивидуально 50/111
Иногда есть прямой смысл поставить ответственного за задачу целиком Это противоречит чистому SCRUM 51/111
 На этапе начальной разработки  Для плохо проработанных задачи  Для обеспечения квалификационного роста сотрудника  Для оценки квалификации сотрудника  Для повышения ответственности и мотивации сотрудника  Для повышения эффективности и минимизации рисков  Для контроля качества исполнения  Для дублирования компетенций 52/111
Еще про распределение работ в команде  Кроссфункциональность противоречит эффективности, нужен разумный баланс  Нужно дублирование, а не полная кроссфункциональность Баланс в каждом случае свой 53/111
Ситуационный менеджмент 54/111
Обсуждение Список Тем 55/111
Про роли в скраме 56/111
В противовес классическому руководителю:  PO!=Руководитель  PO не член команды. Нечего РО лезть во    внутренности Обязательно нужен Sсrum Master SM и PO не один человек У SM нет никаких полномочий SCRUMевангелисты 57/111
Почему собственно? Почему не оставить руководителей? 58/111
Мнение # 1: Менеджер – это вредный элемент. Его нужно экранировать от команды 59/108
Нужно экранировать свиней от цыплят  Свиньи создают продукт, тогда как цыплята заинтересованы, но не настолько, – ведь им всё равно, будет проект удачным или нет, на них это мало отразится  Требования, пожелания, идеи и влияние цыплят принимаются во внимание, но им не разрешают непосредственно включаться в ход SCRUM-проекта. 60/111
Четкая ассоциация менеджеров с заводской культурой Профессия тестировщика, к сожалению, тоже оттуда  Подробно 61/111
Классовая борьба 62/108
Тупые и некомпетентные менеджеры мешают делать работу компетентным исполнителям  Скрам-мастеру нельзя дать   Менеджерофобия полномочия руководителя – иначе он сразу станет тупым менеджером Пусть менеджер занимается своим менеджерскими делами, а команда займется реальным делом Команда лучше самоорганизуется без руководителя 63/111
SCRUM Команда 64/108
Команда в позиции «попробуйте меня уговорить»  «Докажи всем в команде, что твое предложение не дурацкое»  Сильное ограничение власти руководителя  Вместо сотрудничества – борьба 65/111
Плохо работает, когда руководитель – это самый сильный человек в команде (с точки зрения влияния на конечный результат) с богатым опытом проектной деятельности Руководитель 66/108
Примеры таких конструкций в жизни 67/111
 Есть мнение что, все интеллектуальные профессиональные услуги так устроены Дэвид Майстер 68/111
Мнение # 2: Руководитель со всем не справляется, ему нужно помочь 69/111
Избавляем руководителя от ненужной работы  Отделяем определение «что делать» (PO) от «Как делать» (Команда)  PO должен по возможности общаться в терминах ФИЧ и проблем, которые он хотел решить  PO не нужно общаться с каждым членом команды Основные интерфейсы общения – Backlog и демонстрация  Не нужно заранее закреплять задачу на исполнителе 70/111
Почему именно так ему нужно помогать?  Понятие Product Owner – в общем-то из продуктовой разработки или InHouse  Для заказного софта подходит не очень сильно. Кто PO? Заказчик или человек из компании? 71/111
72/108
Конструкция с замотивированным на результат руководителем и небольшим ядром команды, влияющих на остальную команду, более реалистична чем вся команда ориентированная на результат Сложно искать хорошего руководителя  Найти пару PO+SM ни разу не проще! Может превратится в command&control в худшем виде  Отделение от команды только маскирует и затягивает проблему «плохих» менеджеров. Ее нужно решать в любом случаем Я не предлагаю вернуть обратно директивное управление менеджером. Я предлагаю сдвинуть баланс в сторону руководителя 73/108
PO и SM, схожие навыки  Системное мышление    Эмпатия Коммуникация Активная позиция 74/111
Обсуждение Список Тем 75/111
Про планирование 76/111
Оценка и Velocity  Необходимость оценивать задачи  в каких-либо попугаях при планировании Необходимо мерять скорость команды SCRUMевангелисты 77/111
Люди плохо оценивают время Например: Люди по разному оценивают в зависимости от того, знают ли они, кто будет делать эту задачу 78/111
Недостатки оценки  Оценка стоит денег и очень существенных  Само по себе наличие оценки вносит существенное возмущение в процесс разработки. Она влияет на реальную скорость работы и задает жесткое ограничение 79/111
Андрей Бибичев  Модель 1. Пуассоновское распределение. Поток случайных задержек, сроки отодвигаются из-за него  Модель 2. Броуновское движение. Нас бомбардируют отклонения от пути... Общая траектория становится длиннее  Модель 3. PERT. Бета-распределение. Кривая получается похожая 80/111
В результате такой график вероятности затрат на разработку Перестраховка    Оптимист - Идеальная ситуация .сделаем если ничего не предвиденного не случится Реалист – наиболее вероятное значение реальных затрат. Оценка опытных разработчиков. Вероятность, что она занижена достаточно высока (~70%) Перестраховка – если космос не рухнет на землю, то точно уложимся 81/111
 Команде выгоднее давать оценки типа «перестраховка»  Реально работа занимает все отведенное под нее время  В результате команда переходит в расслабленное состояние  «Че-то мы не успеваем. Давайте понизим фокус фактор!» 82/111
 Даже при перестраховке, все равно существует 5% вероятности, что мы не уложимся  При очень большом количестве работ, такие ситуации все равно случаются, и мы имеем очень неприятные разговоры с Закачиком:  «Вы и так многократно заложились и все равно не успели»  Это заставляет команду давать еще более консервативные оценки. Команда становится еще медленнее, но при этом более раздраженной 83/111
 Вместо того, чтобы планировать «как мы сделаем то, что нужно, к нужному сроку», мы планируем то, что успеет команда в ближайшую итерацию.  Первичным становится комфорт команды, а не потребности заказчика 84/111
Обсуждение Список Тем 85/111
Про итерации  У итерации фиксированная длина  У итерации фиксированный SCOPE 86/111
Избыточная жесткость  Итерация нужна для планирования работ группами и создания точек синхронизации  Итерации бьются из абстрактного удобства разработчика, а не удобства получения результата (точки синхронизации не тогда, когда нужно)  Регулярно прилетают неожиданные задачи, которые сдвигают сроки и скоуп. А иногда делают итерацию бессмысленной  Нет возможности «подруливать» итерацией в процессе (удалять задачи и/или увеличивать сроки) 87/111
Обсуждение Список Тем 88/111
Про ретроспективу  Нужно проводить ретро в конце каждой    итерации Ретро – это внутреннее дело команды Команда без ретро – это плохо После ретро нужно делать Бэклог на решение проблем 89/111
Про ретроспективу  Команда (да и люди вообще) чаще всего не в состоянии себя запроблематизировать  В результате обсуждается ерунда , мало влияющие на процесс  Большинство реальных рычагов изменений (нанять, уволить, поднять зарплату, поговорить по душам, выделить время, купить сервер, купить библиотеку и т.д.) – не внутри команды  Команда, которая не успевает делать свои текущие дела, вряд ли успеет сделать их одновременно с задачами из дополнительного бэклога 90/111
Обсуждение Список Тем 91/111
Про DSM  Нужно проводить DSM каждый день в одно время  Должна присутствовать вся команда  Обсуждаем кто-что сделал за день, что будет завтра и какие есть проблемы  Ограничиваем DSM пятью минутами 92/111
Про DSM  Формальное действие, которое всех несколько утомляет (ритуал)  Обычно народ бубнит себе что-то под нос, и его почти не слушают  Проблемы практически никогда не обсуждаются  Никаких решений на ДСМ не принимают. ДСМ не влияет на то, чем люди будут заниматься в рабочем процессе  Как только начинается реально интересное обсуждение – его тут же сворачивают (ДСМ – 5 минут)  Искусственная мотивация посещения ДСМ (плюшки, штрафы, кармические бонусы) 93/111
Обсуждение Список Тем 94/111
Про Демонстрацию  Демо нужно производить после каждой итерации  На демо нужно звать всех заинтересованных лиц  На демо нужно показывать все, что сделали за итерацию 95/111
Про Демонстрацию  Внешним стейкходерам зачастую скучны 60% подробностей, которые рассказываются  Членам команды, напротив, обычно интересно и полезно знать детали реализации, чтобы иметь более полную информацию о проекте  Внешним стейкхолдерам и команде результат можно показывать в разном состоянии сырости  Бесконечные баги и сбои на демо раздражают заказчиков  К внешнему демо нужно готовиться тщательнее  От членов команды, наоборот хочется получить реакцию побыстрее  Разным стейкхолдерам интересны разные вещи. Им нужны разные демо  Неправильно подстраивать внешних стейкхолдеров под внутренний ритм проекта. Демо нужно устраивать, когда им удобно 96/111
Обсуждение Список Тем 97/111
Вместо резюме  Все практики носят рекомендательный характер   Вы используете их на свой страх и риск  Вы можете изменять практики в соответствии с проектной необходимостью и собственными представлениями  При применении подключайте голову Ни одна из практик не является обязательной 98/111
Дополнительные слайды 99/111
Agile Manifesto 2.1  Teamwork & responsibility over Individuals and Interaction   Business Value over Working software  Prepare for change over Respond to Change Partnership elaboration over Customer collaboration 100/111
Разработка ПО как конвейерное производство  Энтони Лаудер. Культуры программных проектов (2008) 101/111
Спланируйте наперёд  Напишите детальные спецификации продукта, включая необходимые стандарты качества   Разбейте работу на последовательность нескольких стадий  Опишите оптимальную последовательность простых повторяемых действий, необходимых на каждом из таких рабочих мест  Посчитайте время, необходимое для выполнения каждого действия, и выработайте соответствующее расписание для каждой стадии, включая время начала и окончания для всего проекта  Определите ресурсы (материалы, стоимость труда, станки, инструменты, и т.д.), необходимые для каждого действия. Просуммируйте их, чтобы определить стоимость каждой стадии и весь бюджет проекта Определите специализированные роли для рабочих на каждой стадии 102/111
Начните производство согласно плану:  Возьмите работников из доступного персонала и назначьте их на рабочие места, определённые в плане  Прикажите рабочим выполнять повторяющиеся действия, предписанные на каждом месте, со скоростью, необходимой для завершения проекта вовремя и в рамках бюджета  Нажмите кнопку «Пуск», чтобы запустить производство 103/111
Мониторинг и Контроль: Непрерывно проверяйте:  Рабочих на местах, чтобы убедиться, что они выполняют действия согласно плану   Темпы производства, чтобы укладываться в расписание  Конечную продукцию на предмет соответствия стандартам качества Потребление экономических ресурсов, чтобы проект укладывался в бюджет Там, где инспекция находит проблемы, справьтесь с ними:      Остановите производство Исправьте причину проблемы, где возможно, путём: Починки сломанного оборудования Крика и запугивания рабочих Перезапустите производство 104/111
Мониторинг и Контроль:  Там, где причина проблемы не может быть устранена, попробуйте следующие методы:   Увеличьте бюджет      Добавьте рабочих к конвейеру Предложите экономические льготы рабочим Добавьте ещё один конвейер Увеличьте сроки проекта Измените спецификации продукта Отмените проект 105/111
Разработка ПО:  Менеджеры создают план проекта, разбивающий необходимую работу на несколько стадий с чёткими временными и стоимостными рамками для каждой стадии, а значит, и для всего проекта в целом  Рабочие берутся из имеющегося персонала и назначаются последовательно на различные стадии проекта  На каждой стадии рабочие периодически пишут status report, чтобы менеджеры могли следить за прогрессом 106/111
Стадии:      Стадия требований: cпецификации продукта заранее записываются заказчиком или другим авторизованным человеком, тем самым переводя их бизнес потребности в спецификационный документ. Стадия анализа: аналитик переводит спецификации продукта в полные фиксированные функциональные требования к программному приложению, производя документ с функциональными требованиями. Стадия дизайна: дизайнер переводит функциональные требования в чёткую и ясную архитектуру приложения, формируя технический дизайн. Стадия кодирования: программист, следуя техническому дизайну, пишет программный код. Стадия контроля качества: тестировщики проверяют функционал программного кода, чтобы удостовериться в том, что он соответствует всем требованиям из вышеупомянутых документов. Обратно 107/111
Откуда все пошло 108/111
Зачем мы внедряли SCRUM  …и получили ли то, что хотели, – тема отдельного разговора 109/111
Долгий и тяжелый путь осознания внутри компании 110/111
Спасибо! Вопросы? Михаил Заборов mzaborov@custis.ru 111/111

More Related Content

PPTX
Московский клуб тестировщиков. Круглый стол про Agile
byМихаил Заборов
 
PDF
SECON'2017, Мелехова Анна, Архитектура как стихия. Обуздываем энтропию проекта
bySECON
 
PDF
Organizing self-organizing teams
byAgileee
 
PPTX
Management decisions 20150328
byVictoria Astapenko
 
PPTX
Активные методы ведения переговоров. Анастасия Ивко. Антон Шалейников. Вадим ...
byVadim Nareyko
 
DOCX
Rabota komandy
byvsemspasibo
 
DOCX
работа команды
byolya_kar2
 
PPTX
Подбор команды и управление ей
byРубен Мелконян
 
Московский клуб тестировщиков. Круглый стол про Agile
byМихаил Заборов
 
SECON'2017, Мелехова Анна, Архитектура как стихия. Обуздываем энтропию проекта
bySECON
 
Organizing self-organizing teams
byAgileee
 
Management decisions 20150328
byVictoria Astapenko
 
Активные методы ведения переговоров. Анастасия Ивко. Антон Шалейников. Вадим ...
byVadim Nareyko
 
Rabota komandy
byvsemspasibo
 
работа команды
byolya_kar2
 
Подбор команды и управление ей
byРубен Мелконян
 

What's hot

PDF
Менеджмент, лидерство, инициативность в сбалансированной команде
byAlexander Postnikov
 
PPT
эффективность управленцев
byErkin Dzhamanbaev
 
PDF
Записная книжка мистера Томпкинса (из книги Тома Демарко "Deadline: роман об ...
byMikhail Galushko
 
PDF
2008-04-15-scrum-from-custis-show
byStas Fomin
 
PDF
Мифы и реалии самоорганизующихся команд - AgileBaseCamp@Kharkov
byTimofey (Tim) Yevgrashyn
 
PDF
Самоорганизующиеся команды
byITCP Community
 
PPTX
Воркшоп по управлению командой проекта в Академии ПВТ
byAliaksei Minkevich
 
PPSX
Игорь Лужанский “Потери в процессе разработки ПО”
byAgile Base Camp
 
Менеджмент, лидерство, инициативность в сбалансированной команде
byAlexander Postnikov
 
эффективность управленцев
byErkin Dzhamanbaev
 
Записная книжка мистера Томпкинса (из книги Тома Демарко "Deadline: роман об ...
byMikhail Galushko
 
2008-04-15-scrum-from-custis-show
byStas Fomin
 
Мифы и реалии самоорганизующихся команд - AgileBaseCamp@Kharkov
byTimofey (Tim) Yevgrashyn
 
Самоорганизующиеся команды
byITCP Community
 
Воркшоп по управлению командой проекта в Академии ПВТ
byAliaksei Minkevich
 
Игорь Лужанский “Потери в процессе разработки ПО”
byAgile Base Camp
 

Similar to Гибкость: как правильно жить и работать?

PDF
Agile Talks: Scrum Cookbook. Применение вне ИТ-сферы
byLuxoftAgilePractice
 
PPTX
Agile Talks: Scrum Cookbook. Применение вне ИТ-сферы
byLuxoftAgilePractice
 
PDF
Презентация "Scrum с нуля"
byЕлена Коптева
 
PPTX
Agile Talks: Scrum Cookbook - Внедрение Скрам: ошибки и решения
byLuxoftAgilePractice
 
PDF
Юрий Соболев. Проблемы и решения Scrum на практике
byScrumTrek
 
PPTX
Как контролировать работу? Вадим Нарейко
byVadim Nareyko
 
PPTX
Agile Scrum Start / Старт используя Scrum
byAndrei Prokoshev
 
PDF
Киев. Как внедрить SCRUM без трупов и остаться довольным
byVladimir Zavertaylov
 
PPT
Введение в Scrum
byDmitry Sidorenko
 
PPT
Scrum
byValeriya Kulikova
 
PPT
Agile, SCRUM, Планирование – что в этом для программистов?
byFedor Malyshkin
 
PDF
ук 03.005.02 2011
byetyumentcev
 
PPTX
Теория Agile, практика Scrum простым языком с кейсами
byAlexey Ruchkin
 
PDF
Agile в производственных компаниях
byECOPSY Consulting
 
PPT
внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11
byANDREY ZAKHODYAYCHENKO
 
PPT
Как внедрить ALM/ Упр. командами разработки по (agile (scrum))
byAndrey Zakhodyaychenko
 
PDF
SCRUM:open iDOM, report from Product Owner
byAlexey Krivitsky
 
PPTX
Agile
byEgor DOLGALEVETS
 
PPTX
Scrum framework
bySergey Gelmetdinov
 
PPTX
Введение в Agile
byВасилий Савунов
 
Agile Talks: Scrum Cookbook. Применение вне ИТ-сферы
byLuxoftAgilePractice
 
Agile Talks: Scrum Cookbook. Применение вне ИТ-сферы
byLuxoftAgilePractice
 
Презентация "Scrum с нуля"
byЕлена Коптева
 
Agile Talks: Scrum Cookbook - Внедрение Скрам: ошибки и решения
byLuxoftAgilePractice
 
Юрий Соболев. Проблемы и решения Scrum на практике
byScrumTrek
 
Как контролировать работу? Вадим Нарейко
byVadim Nareyko
 
Agile Scrum Start / Старт используя Scrum
byAndrei Prokoshev
 
Киев. Как внедрить SCRUM без трупов и остаться довольным
byVladimir Zavertaylov
 
Введение в Scrum
byDmitry Sidorenko
 
Scrum
byValeriya Kulikova
 
Agile, SCRUM, Планирование – что в этом для программистов?
byFedor Malyshkin
 
ук 03.005.02 2011
byetyumentcev
 
Теория Agile, практика Scrum простым языком с кейсами
byAlexey Ruchkin
 
Agile в производственных компаниях
byECOPSY Consulting
 
внедрение Alm суп командами разработки по (agile (scrum)) 4 3 11
byANDREY ZAKHODYAYCHENKO
 
Как внедрить ALM/ Упр. командами разработки по (agile (scrum))
byAndrey Zakhodyaychenko
 
SCRUM:open iDOM, report from Product Owner
byAlexey Krivitsky
 
Agile
byEgor DOLGALEVETS
 
Scrum framework
bySergey Gelmetdinov
 
Введение в Agile
byВасилий Савунов
 

More from CUSTIS

PDF
Три истории микросервисов, или MSA для Enterprise
byCUSTIS
 
PPTX
Долгоживущие ИТ в динамичном ритейле
byCUSTIS
 
PDF
Будущее уже наступило: от Agile к бирюзовым организациям
byCUSTIS
 
PDF
Как выбрать для проекта практики проектирования и работы с требованиями
byCUSTIS
 
PDF
Диаграммы учета как средство для наглядного и целостного отображения правил у...
byCUSTIS
 
PPTX
Сотрудничество с корпорациями: рецепты из практики
byCUSTIS
 
PPTX
Agile — ответ на вызовы третьей промышленной революции
byCUSTIS
 
PPTX
Опыт построения микросервисной архитектуры в цифровом банке
byCUSTIS
 
PDF
Золотая лихорадка MSA: почему нам не подошли микросервисы?
byCUSTIS
 
PPT
Барьеры микросервисной архитектуры
byCUSTIS
 
PPTX
Три истории микросервисов
byCUSTIS
 
PPTX
От монолитных моделей предметной области — к модульным
byCUSTIS
 
PPTX
Проблемы управления правами доступа к информационным системам крупной торгово...
byCUSTIS
 
PDF
Будущее omni-channel маркетинга: инструменты, кейсы и цифры
byCUSTIS
 
PPTX
Agile и управление знаниями в ИТ-проектах
byCUSTIS
 
PDF
State of the .Net Performance
byCUSTIS
 
PPTX
Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять
byCUSTIS
 
PDF
Опыт применения метода ATAM для оценки архитектуры
byCUSTIS
 
PPTX
Гибридный подход к управлению правами доступа: когда стандартного IDM не хватает
byCUSTIS
 
PPTX
Собираем кубик Рубика: восстановление архитектурного описания корпоративной р...
byCUSTIS
 
Три истории микросервисов, или MSA для Enterprise
byCUSTIS
 
Долгоживущие ИТ в динамичном ритейле
byCUSTIS
 
Будущее уже наступило: от Agile к бирюзовым организациям
byCUSTIS
 
Как выбрать для проекта практики проектирования и работы с требованиями
byCUSTIS
 
Диаграммы учета как средство для наглядного и целостного отображения правил у...
byCUSTIS
 
Сотрудничество с корпорациями: рецепты из практики
byCUSTIS
 
Agile — ответ на вызовы третьей промышленной революции
byCUSTIS
 
Опыт построения микросервисной архитектуры в цифровом банке
byCUSTIS
 
Золотая лихорадка MSA: почему нам не подошли микросервисы?
byCUSTIS
 
Барьеры микросервисной архитектуры
byCUSTIS
 
Три истории микросервисов
byCUSTIS
 
От монолитных моделей предметной области — к модульным
byCUSTIS
 
Проблемы управления правами доступа к информационным системам крупной торгово...
byCUSTIS
 
Будущее omni-channel маркетинга: инструменты, кейсы и цифры
byCUSTIS
 
Agile и управление знаниями в ИТ-проектах
byCUSTIS
 
State of the .Net Performance
byCUSTIS
 
Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять
byCUSTIS
 
Опыт применения метода ATAM для оценки архитектуры
byCUSTIS
 
Гибридный подход к управлению правами доступа: когда стандартного IDM не хватает
byCUSTIS
 
Собираем кубик Рубика: восстановление архитектурного описания корпоративной р...
byCUSTIS
 

Гибкость: как правильно жить и работать?

  • 1.
    Круглый стол «Гибкость: какправильно жить и работать?» Михаил Заборов руководитель стратегических проектов 2 декабря 2013 года
  • 2.
    Компания CUSTIS   Существует с1996 года  Agile-like процесс – с рождения Занимается заказной разработкой промышленного корпоративного ПО 2/111
  • 3.
    Внедрение SCRUM вCUSTIS Андрей Бибичев    Асхат Уразбаев Первое внедрение – в 2007 Внедрял Асхат Уразбаев В 2009–2010 – регулярные встречи Agile Russia на нашей территории 3/111
  • 4.
    Сегодня   В компании 20+человек  90% используют похожий на SCRUM процесс В компании более 20 производственных команд 4/111
  • 5.
    Немного про меня Скритическим прищуром и перпендикулярным мнением  5/111
  • 6.
  • 7.
    Восприятие SCRUM Только использованиеканонических процессов SCRUM дает действительно существенный позитивный результат Более мягкая формулировка Практики SCRUM зависят друг от друга, образуют систему и наибольший эффект получается при их совместном использовании 7/108
  • 8.
    В результате «Вы используетенеправильный SCRUM и поэтому у вас все плохо». А СКРАМ-то НЕНАСТОЯЩИЙ!!! Это не по Scrum-у!!! 8/111
  • 9.
    ScrumButt  «We’ve gotSCRUM, but…» 9/111
  • 10.
    Разновидность «Вы просто ещене пробовали пользоваться настоящим SCRUM – попробуйте и вы увидите разницу». 10/111
  • 11.
    Мой опыт SCRUM вчистом виде практически бесполезен, а иногда и наносит существенный вред Его нужно адаптировать под себя. Не нужно его фетишизировать и добиваться пуританской чистоты 11/111
  • 12.
    При этом почтиничего плохого про Agile ≠ 12/111
  • 13.
    Agile это всеголишь манифест 13/111
  • 14.
  • 15.
  • 16.
    Крупные темы которыеможно обсудить  Философия    C самомотивацией все не так просто Самоорганизация от сырости не заводится Практические  Роли в SCRUM (в т.ч. про классовую вражду и немного про профессию тестировщиков)  SCRUM планирование расслабляет команду Резюме 16/111
  • 17.
    Мелкие темы которыеможно обсудить  Требования к итерациям в SCRUM избыточно жесткие  Ретроспектива по SCRUM’овски – практически бесполезное занятие  Чаще всего DSM вырождается в пустой гундеж  В SCRUM’е демонстрация упрощена до бесполезности Резюме 17/111
  • 18.
    Где еще скрамне помогает, а иногда даже мешает     Архитектура Работа с персоналом Долгосрочное планирование Ресурсное планирование (в том числе краткосрочное увеличение/уменьшение команды) Резюме 18/111
  • 19.
  • 20.
    Про самомотивацию  Надпроектом должны работать  мотивированные профессионалы Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им Agile Manifesto 20/111
  • 21.
  • 22.
    Системы ценностей разныхлюдей сильно отличаются  Далеко не всегда то, за что готов платить заказчик, мотивирует разработчиков  То, что ценно для разработчика, для заказчика может быть странной, никому не нужной самореализацией (самоудовлетворение).  То, что ценно для заказчика - для программиста может быть порождением воспаленного разума и непонятная, неведомая фигня.  Люди склонны оценивать многие, даже сложные задачи как рутинные 22/111
  • 23.
  • 24.
    Ценности меняются  Целии задачи заказчиков регулярно меняются. Agile рассчитан именно на такие проекты “ Делали учетную систему, а в результате оказалась просто интеграция ”  То, что было интересным когда-то, со временем становится рутиной “ Я всю жизнь строю эти дурацкие мосты ” 24/111
  • 25.
    Самомотивированные на результат проектапрофессионалы крайне редки  Есть много людей, которым не очень много нужно от жизни  Еще больше людей, которые не знают, чего на самом деле хотят  Нужны очень эмоционально и ментально зрелые люди. Разработчики же в основном молодежь 25/111
  • 26.
  • 27.
    Самодостаточные люди  Разобраться, какработает сложный бизнес   Сделать мир чуть лучше Помочь хорошим людям 27/111
  • 28.
    Ориентированные на внешниймир  Получить в портфолио сделанный проект и тем самым повысить свою ценность  Получить признание уважаемых людей (друзей, родственников, коллег) Много конъюнктуры и контуженных гламуром людей  28/111
  • 29.
    Сделать что-то «хорошее» и«клёвое» – другая мотивация  В общем случае противоречит мотивации на результат проекта  Безусловно должна присутствовать в команде 29/111
  • 30.
    Влияние SCRUM намотивацию 30/111
  • 31.
    От скрама мотивацияне заводится  Никакая организационная конструкция (в том числе, SCRUM) не может создать мотивацию  В начале вы набираете команду мотивированных людей, а потом заводите SCRUM 31/111
  • 32.
    От скрама мотивацияможет испортиться  Мотивированные на результат люди обычно хотят напрямую видеть этот результат и влиять на него. Proxy в виде ProductOwner-а их демотивирует  Ритуалы могут утомлять. Любую хорошую идею можно довести до абсурда  Если вы хотите чистый SCRUM, вам нужно регулярно чистить команду от тех, кто «не восторженно мыслит» 32/111
  • 33.
    Мотивированным людям и безскрама хорошо 33/111
  • 34.
    Алистер Коберн   Нет корреляциимежду успехом/провалом проектов и методологиями, которые применялись в проектах Успешность программного проекта на 100% определяется людьми 34/111
  • 35.
  • 36.
  • 37.
    Про самоорганизацию  Команда– черный ящик, она подстраивает   себя сама Оставьте ее в покое, и она сама решит все проблемы Единственный способ повлиять на нее – добавить/удалить людей или разогнать SCRUMевангелисты 37/111
  • 38.
  • 39.
    Команда далеко невсегда самоорганизуется эффективным для производства способом Правильно ли называть это «самоорганизацией»? Самоорганизация – результат долгой кропотливой работы специальных людей 39/108
  • 40.
    Пример: Product Ownerотстранился от принятия решений  Постоянные конфликты  Непродуктивные обсуждения того, что можно не обсуждать  Команду пришлось резать по живому 40/111
  • 41.
  • 42.
  • 43.
    Маша тестирует задачу, сделаннуюПетей в условиях жестких сроков и дефицита времени 43/111
  • 44.
    Варианты действий Маша сотрудничает Маша иПетя находят компромисс Петя В результате оба немного сотрудничает перерабатывают Продукт выходит вовремя Петя заботится о себе Петя делает работу в притык, так что времени тестирование и исправление ошибок не остается Маша работает в выходные и по ночам Часть ошибок остается неисправленными Маша заботится о себе Маша требует много времени на тестирование Петя работает в выходные и по ночам чтобы успеть к сроку Маша требует много времени на тестирование Петя делает работу впритык, так что времени на тестирование и исправление ошибок не остается Сроки срываются 44/111
  • 45.
    Равновесие Нэша Тип решенийигры, в котором ни один участник не может увеличить выигрыш, изменив своё решение в одностороннем порядке, когда другие участники не меняют решения Равновесие Парето Молчит Молчит 3 месяца Равновесие Нэша Сдает свободен 20 лет Сдает  свободен 20 лет 5 лет 45/111
  • 46.
  • 47.
    Нужен выделенный координирующий человекс полномочиями  В ситуации быстро меняющихся требований нужно быстро реагировать  Все это требует координации и выделенного человека, который держит на этом фокус 47/111
  • 48.
    Даже самомотивированным людям нужнотранслировать смысл задач заказчика  В том числе :  Показывать как именно мир становится лучше  Показывать живых людей, которым становится лучше 48/111
  • 49.
    Если у исполнителеймотивация не на результат проекта ($, комфорт, самоудовлетворение), то работать с ними нужно по другому (не чистый скрам) Работа руководителя превращать желания заказчика в мотиваторы исполнителей Том Сойер 49/108
  • 50.
    Руководителю нужно работать слюдьми индивидуально 50/111
  • 51.
    Иногда есть прямойсмысл поставить ответственного за задачу целиком Это противоречит чистому SCRUM 51/111
  • 52.
     На этапеначальной разработки  Для плохо проработанных задачи  Для обеспечения квалификационного роста сотрудника  Для оценки квалификации сотрудника  Для повышения ответственности и мотивации сотрудника  Для повышения эффективности и минимизации рисков  Для контроля качества исполнения  Для дублирования компетенций 52/111
  • 53.
    Еще про распределениеработ в команде  Кроссфункциональность противоречит эффективности, нужен разумный баланс  Нужно дублирование, а не полная кроссфункциональность Баланс в каждом случае свой 53/111
  • 54.
  • 55.
  • 56.
    Про роли вскраме 56/111
  • 57.
    В противовес классическому руководителю: PO!=Руководитель  PO не член команды. Нечего РО лезть во    внутренности Обязательно нужен Sсrum Master SM и PO не один человек У SM нет никаких полномочий SCRUMевангелисты 57/111
  • 58.
    Почему собственно? Почему неоставить руководителей? 58/111
  • 59.
    Мнение # 1:Менеджер – это вредный элемент. Его нужно экранировать от команды 59/108
  • 60.
    Нужно экранировать свиней отцыплят  Свиньи создают продукт, тогда как цыплята заинтересованы, но не настолько, – ведь им всё равно, будет проект удачным или нет, на них это мало отразится  Требования, пожелания, идеи и влияние цыплят принимаются во внимание, но им не разрешают непосредственно включаться в ход SCRUM-проекта. 60/111
  • 61.
    Четкая ассоциация менеджеров сзаводской культурой Профессия тестировщика, к сожалению, тоже оттуда  Подробно 61/111
  • 62.
  • 63.
    Тупые и некомпетентныеменеджеры мешают делать работу компетентным исполнителям  Скрам-мастеру нельзя дать   Менеджерофобия полномочия руководителя – иначе он сразу станет тупым менеджером Пусть менеджер занимается своим менеджерскими делами, а команда займется реальным делом Команда лучше самоорганизуется без руководителя 63/111
  • 64.
  • 65.
    Команда в позиции«попробуйте меня уговорить»  «Докажи всем в команде, что твое предложение не дурацкое»  Сильное ограничение власти руководителя  Вместо сотрудничества – борьба 65/111
  • 66.
    Плохо работает, когдаруководитель – это самый сильный человек в команде (с точки зрения влияния на конечный результат) с богатым опытом проектной деятельности Руководитель 66/108
  • 67.
  • 68.
  • 69.
    Мнение # 2:Руководитель со всем не справляется, ему нужно помочь 69/111
  • 70.
    Избавляем руководителя от ненужнойработы  Отделяем определение «что делать» (PO) от «Как делать» (Команда)  PO должен по возможности общаться в терминах ФИЧ и проблем, которые он хотел решить  PO не нужно общаться с каждым членом команды Основные интерфейсы общения – Backlog и демонстрация  Не нужно заранее закреплять задачу на исполнителе 70/111
  • 71.
    Почему именно такему нужно помогать?  Понятие Product Owner – в общем-то из продуктовой разработки или InHouse  Для заказного софта подходит не очень сильно. Кто PO? Заказчик или человек из компании? 71/111
  • 72.
  • 73.
    Конструкция с замотивированнымна результат руководителем и небольшим ядром команды, влияющих на остальную команду, более реалистична чем вся команда ориентированная на результат Сложно искать хорошего руководителя  Найти пару PO+SM ни разу не проще! Может превратится в command&control в худшем виде  Отделение от команды только маскирует и затягивает проблему «плохих» менеджеров. Ее нужно решать в любом случаем Я не предлагаю вернуть обратно директивное управление менеджером. Я предлагаю сдвинуть баланс в сторону руководителя 73/108
  • 74.
    PO и SM,схожие навыки  Системное мышление    Эмпатия Коммуникация Активная позиция 74/111
  • 75.
  • 76.
  • 77.
    Оценка и Velocity Необходимость оценивать задачи  в каких-либо попугаях при планировании Необходимо мерять скорость команды SCRUMевангелисты 77/111
  • 78.
    Люди плохо оцениваютвремя Например: Люди по разному оценивают в зависимости от того, знают ли они, кто будет делать эту задачу 78/111
  • 79.
    Недостатки оценки  Оценкастоит денег и очень существенных  Само по себе наличие оценки вносит существенное возмущение в процесс разработки. Она влияет на реальную скорость работы и задает жесткое ограничение 79/111
  • 80.
    Андрей Бибичев  Модель 1. Пуассоновскоераспределение. Поток случайных задержек, сроки отодвигаются из-за него  Модель 2. Броуновское движение. Нас бомбардируют отклонения от пути... Общая траектория становится длиннее  Модель 3. PERT. Бета-распределение. Кривая получается похожая 80/111
  • 81.
    В результате такойграфик вероятности затрат на разработку Перестраховка    Оптимист - Идеальная ситуация .сделаем если ничего не предвиденного не случится Реалист – наиболее вероятное значение реальных затрат. Оценка опытных разработчиков. Вероятность, что она занижена достаточно высока (~70%) Перестраховка – если космос не рухнет на землю, то точно уложимся 81/111
  • 82.
     Команде выгоднее даватьоценки типа «перестраховка»  Реально работа занимает все отведенное под нее время  В результате команда переходит в расслабленное состояние  «Че-то мы не успеваем. Давайте понизим фокус фактор!» 82/111
  • 83.
     Даже приперестраховке, все равно существует 5% вероятности, что мы не уложимся  При очень большом количестве работ, такие ситуации все равно случаются, и мы имеем очень неприятные разговоры с Закачиком:  «Вы и так многократно заложились и все равно не успели»  Это заставляет команду давать еще более консервативные оценки. Команда становится еще медленнее, но при этом более раздраженной 83/111
  • 84.
     Вместо того,чтобы планировать «как мы сделаем то, что нужно, к нужному сроку», мы планируем то, что успеет команда в ближайшую итерацию.  Первичным становится комфорт команды, а не потребности заказчика 84/111
  • 85.
  • 86.
    Про итерации  Уитерации фиксированная длина  У итерации фиксированный SCOPE 86/111
  • 87.
    Избыточная жесткость  Итерациянужна для планирования работ группами и создания точек синхронизации  Итерации бьются из абстрактного удобства разработчика, а не удобства получения результата (точки синхронизации не тогда, когда нужно)  Регулярно прилетают неожиданные задачи, которые сдвигают сроки и скоуп. А иногда делают итерацию бессмысленной  Нет возможности «подруливать» итерацией в процессе (удалять задачи и/или увеличивать сроки) 87/111
  • 88.
  • 89.
    Про ретроспективу  Нужнопроводить ретро в конце каждой    итерации Ретро – это внутреннее дело команды Команда без ретро – это плохо После ретро нужно делать Бэклог на решение проблем 89/111
  • 90.
    Про ретроспективу  Команда(да и люди вообще) чаще всего не в состоянии себя запроблематизировать  В результате обсуждается ерунда , мало влияющие на процесс  Большинство реальных рычагов изменений (нанять, уволить, поднять зарплату, поговорить по душам, выделить время, купить сервер, купить библиотеку и т.д.) – не внутри команды  Команда, которая не успевает делать свои текущие дела, вряд ли успеет сделать их одновременно с задачами из дополнительного бэклога 90/111
  • 91.
  • 92.
    Про DSM  Нужнопроводить DSM каждый день в одно время  Должна присутствовать вся команда  Обсуждаем кто-что сделал за день, что будет завтра и какие есть проблемы  Ограничиваем DSM пятью минутами 92/111
  • 93.
    Про DSM  Формальноедействие, которое всех несколько утомляет (ритуал)  Обычно народ бубнит себе что-то под нос, и его почти не слушают  Проблемы практически никогда не обсуждаются  Никаких решений на ДСМ не принимают. ДСМ не влияет на то, чем люди будут заниматься в рабочем процессе  Как только начинается реально интересное обсуждение – его тут же сворачивают (ДСМ – 5 минут)  Искусственная мотивация посещения ДСМ (плюшки, штрафы, кармические бонусы) 93/111
  • 94.
  • 95.
    Про Демонстрацию  Демонужно производить после каждой итерации  На демо нужно звать всех заинтересованных лиц  На демо нужно показывать все, что сделали за итерацию 95/111
  • 96.
    Про Демонстрацию  Внешним стейкходерамзачастую скучны 60% подробностей, которые рассказываются  Членам команды, напротив, обычно интересно и полезно знать детали реализации, чтобы иметь более полную информацию о проекте  Внешним стейкхолдерам и команде результат можно показывать в разном состоянии сырости  Бесконечные баги и сбои на демо раздражают заказчиков  К внешнему демо нужно готовиться тщательнее  От членов команды, наоборот хочется получить реакцию побыстрее  Разным стейкхолдерам интересны разные вещи. Им нужны разные демо  Неправильно подстраивать внешних стейкхолдеров под внутренний ритм проекта. Демо нужно устраивать, когда им удобно 96/111
  • 97.
  • 98.
    Вместо резюме  Все практикиносят рекомендательный характер   Вы используете их на свой страх и риск  Вы можете изменять практики в соответствии с проектной необходимостью и собственными представлениями  При применении подключайте голову Ни одна из практик не является обязательной 98/111
  • 99.
  • 100.
    Agile Manifesto 2.1  Teamwork& responsibility over Individuals and Interaction   Business Value over Working software  Prepare for change over Respond to Change Partnership elaboration over Customer collaboration 100/111
  • 101.
    Разработка ПО какконвейерное производство  Энтони Лаудер. Культуры программных проектов (2008) 101/111
  • 102.
    Спланируйте наперёд  Напишите детальныеспецификации продукта, включая необходимые стандарты качества   Разбейте работу на последовательность нескольких стадий  Опишите оптимальную последовательность простых повторяемых действий, необходимых на каждом из таких рабочих мест  Посчитайте время, необходимое для выполнения каждого действия, и выработайте соответствующее расписание для каждой стадии, включая время начала и окончания для всего проекта  Определите ресурсы (материалы, стоимость труда, станки, инструменты, и т.д.), необходимые для каждого действия. Просуммируйте их, чтобы определить стоимость каждой стадии и весь бюджет проекта Определите специализированные роли для рабочих на каждой стадии 102/111
  • 103.
    Начните производство согласно плану:  Возьмитеработников из доступного персонала и назначьте их на рабочие места, определённые в плане  Прикажите рабочим выполнять повторяющиеся действия, предписанные на каждом месте, со скоростью, необходимой для завершения проекта вовремя и в рамках бюджета  Нажмите кнопку «Пуск», чтобы запустить производство 103/111
  • 104.
    Мониторинг и Контроль: Непрерывнопроверяйте:  Рабочих на местах, чтобы убедиться, что они выполняют действия согласно плану   Темпы производства, чтобы укладываться в расписание  Конечную продукцию на предмет соответствия стандартам качества Потребление экономических ресурсов, чтобы проект укладывался в бюджет Там, где инспекция находит проблемы, справьтесь с ними:      Остановите производство Исправьте причину проблемы, где возможно, путём: Починки сломанного оборудования Крика и запугивания рабочих Перезапустите производство 104/111
  • 105.
    Мониторинг и Контроль:  Там,где причина проблемы не может быть устранена, попробуйте следующие методы:   Увеличьте бюджет      Добавьте рабочих к конвейеру Предложите экономические льготы рабочим Добавьте ещё один конвейер Увеличьте сроки проекта Измените спецификации продукта Отмените проект 105/111
  • 106.
    Разработка ПО:  Менеджеры создаютплан проекта, разбивающий необходимую работу на несколько стадий с чёткими временными и стоимостными рамками для каждой стадии, а значит, и для всего проекта в целом  Рабочие берутся из имеющегося персонала и назначаются последовательно на различные стадии проекта  На каждой стадии рабочие периодически пишут status report, чтобы менеджеры могли следить за прогрессом 106/111
  • 107.
    Стадии:      Стадия требований: cпецификациипродукта заранее записываются заказчиком или другим авторизованным человеком, тем самым переводя их бизнес потребности в спецификационный документ. Стадия анализа: аналитик переводит спецификации продукта в полные фиксированные функциональные требования к программному приложению, производя документ с функциональными требованиями. Стадия дизайна: дизайнер переводит функциональные требования в чёткую и ясную архитектуру приложения, формируя технический дизайн. Стадия кодирования: программист, следуя техническому дизайну, пишет программный код. Стадия контроля качества: тестировщики проверяют функционал программного кода, чтобы удостовериться в том, что он соответствует всем требованиям из вышеупомянутых документов. Обратно 107/111
  • 108.
  • 109.
    Зачем мы внедрялиSCRUM  …и получили ли то, что хотели, – тема отдельного разговора 109/111
  • 110.
    Долгий и тяжелыйпуть осознания внутри компании 110/111
  • 111.