![Вопросы? Шляхов Никита [email_address]](https://image.slidesharecdn.com/random-110604012835-phpapp01/85/-12-320.jpg)
More Related Content
What's hot (20)
Viewers also liked (19)
Similar to Никита Шляхов. Учёт времени разработчиков (20)
More from Svetlana Gulyaeva (13)
Никита Шляхов. Учёт времени разработчиков
- 1. Как учитывать время разработчиков? (чтобы их не тошнило) Шляхов Никита Разработка сайтов и веб-сервисов СКБ Контур
- 2. А зачем учитывать? Планирование Задачи Взаимодействие Бюджет Релизы Ресурсы … Своевременная реакция на проблемы Улучшение процессов, оптимизация
- 3. Для чего НЕ нужно Тех.поддержка Считать эффективность разработчиков(?) Материальная мотивация
- 4. Виды проектов / задач Сложность / Определённость требований «Понятные» «Мутные» Длительность Короткие (0.5-2 месяца) Длительные (3+) Заказчик Внутренний Внешний
- 5. «Понятные» проекты Фиксированные требования Небольшой набор требований Большой опыт реализации аналогичных задач Решение: «Экспертная оценка»? Плюсы: Очень точно Мало времени на планирование Возможность точного Долгосрочного планирования Минусы: «Весь дьявол в мелочах» Ответственность на одном человеке Отпуска, болезни, декреты, …. Разработчики могут быть не готовы выполнить задачи в заданные сроки. Административный стиль управления - Снижение мотивации**
- 6. Экспертная оценка Применима, для: Стандартных задач Команды «учеников» Есть лидер В ещё не сложившихся команд – демократия неприемлема Кто делает оценку Эккаунт / Аналитик Лидер / Менеджер разработки
- 7. «Мутные» проекты Неопределённые требования Высокая вероятность изменения требований Уникальная задача Серебрянная пуля: Небольшие итерации Совместная оценка сроков ( Planning poker ) Ежедневные scrum-meetings Минусы: Много времени Пассивность некоторых участников Искусственное затягивание сроков Плюсы: Снижение рисков Достаточно точно Совместная ответственность Командность
- 8. Planning Poker Применим: Практически для любых проектов. Даже для удалённых команд Когда экспертная оценка невозможна
- 9. Planning Poker. Правила: Список задач по приоритету Оценка задачи каждым разработчиком Если большой разброс оценок обсуждение (3 минуты) уточнение требований разбиение задачи повторная оценка, пока все не совпадут Оценка, пока не будет достигнута необходимая сумма – определяется опытным путём Варианты: Оценка в часах Оценка в «размере» задачи (маленькая, большая, средняя, и т.п.)
- 10. Держать руку на пульсе Burn Down Chart WhiteBoard с задачами + TFS (Jira, …)
- 11. Итого. Чтобы не тошнило: Разъяснить необходимость Вовлечь каждого в оценку сроков Включить игровые моменты Не завязывать на материальную мотивацию Правильно применять Экспертную оценку Не акцентировать на этом много внимания
- 12. Вопросы? Шляхов Никита [email_address]
Editor's Notes
- #3: Учитывать до, во время и после. Иллюстрации: * Планы * Проблема Если столько причин, неужели разработчиков может тошнить учёт времени?
- #4: Иллюстрация – много мелких задач.
- #5: Если необходимость – понятна и очевидна, тогда тошнить может от процесса оценки. А процесс зависит от проектов.
- #6: Иллюстрация: Эксперт, Дьявол, Административный стиль
- #7: Эккаунт Лидер
- #8: «Одна голова хорошо – а две лучше».