Почти каждую IT компанию на определённом этапе развития посещают мысли о том, как бы сделать так, чтобы грамотно организовать процессы, происходящие в компании и какие технологии надо для этого использовать. Чем раньше будет внедрена инфраструктура в компании, тем лучше.
Конкретный набор технологий и их взаимодействие друг с другом зависят от деятельности конкретной компании. Я рассмотрю совмещение технологий на примере нашей компании, занимающейся разработкой программного обеспечения, и активно применяющей Agile методики. Этой теме будут посвящены следующие несколько постов.
вторник, 1 декабря 2009 г.
среда, 7 октября 2009 г.
Вышла новая JIRA 4
Свершилось! Как утверждает Кен Олофсен в продуктовом блоге JIRA после 13 месяцев разработки, 4 месяцев бета-тестирования и 1000 выполненных задач (jira issues) Atlassian выпустила самый большой релиз в своей истории - JIRA 4.
Что нового
Прежде всего следует отметить новую систему лицензирования. Больше никаких Standard или Professional, все лицензии имеют функциональность Enterprise, различаются только количеством пользователей. Подробная информация о лицензировании здесь.
Теперь по фичам. Здесь можно посмотреть обзорное видео.
Smart UI - полностью переработанный UI оставляет весьма приятное впечатление. Улучшенная навигация с функцией быстрого создания линков (link) в хедере и браузере проектов, которая запоминает, какой тип задач был создан последним. Улучшенный браузер задач позволяет также осуществлять общие действия прямо из результатов поиска.
Activity Streams - просматривайте недавнюю активность для любой задачи, проекта или пользователя. Создавайте пользовательские потоки активностей (activity streams) для вашего JIRA дэшборда (dashboard) или подписывайтесь на них через RSS.
JIRA Query Language - JQL это новый мощный поисковик, упрощающий создание сложных (и действительно полезных) поисков. Добавьте это в гаджеты на ваш дэшборд, или настройте уведомление по email, чтобы оставаться в курсе.
New dashboards - в расшариваемых дэшбордах нет ничего нового, но теперь вы можете перетаскивать гаджеты по множеству гибких шаблонов лейаутов. Просмотрите папку с гаджетами, выберите гаджеты, настройте цвета, установки и многое другое.
OpenSocial gadgets - так как большинство продуктов Atlassian теперь делают гаджеты OpenSocial, и новые JIRA дэшборды тоже выполнены как OpenSocial контейнеры, вы можете комбинировать данные из JIRA, Confluence, FishEye и даже популярных приложений, например Remember the Milk, в одном месте. Вы даже можете их добавить на свой Gmail или iGoogle страницу!
В JIRA 4 еще много всего.Проверьте release notes для подробностей, а также просматривайте JIRA Product Blog, где разработчики обещают рассказывать о новых возможностях по мере их появления.
А ещё и GreenHopper 4!
Также вышла новая версия GreenHopper,обеспечивающая agile project management для JIRA. В GreenHopper 4 появилась поддержка kanban, а также много других функций и улучшений UI.
Что нового
Прежде всего следует отметить новую систему лицензирования. Больше никаких Standard или Professional, все лицензии имеют функциональность Enterprise, различаются только количеством пользователей. Подробная информация о лицензировании здесь.
Теперь по фичам. Здесь можно посмотреть обзорное видео.
Smart UI - полностью переработанный UI оставляет весьма приятное впечатление. Улучшенная навигация с функцией быстрого создания линков (link) в хедере и браузере проектов, которая запоминает, какой тип задач был создан последним. Улучшенный браузер задач позволяет также осуществлять общие действия прямо из результатов поиска.
Activity Streams - просматривайте недавнюю активность для любой задачи, проекта или пользователя. Создавайте пользовательские потоки активностей (activity streams) для вашего JIRA дэшборда (dashboard) или подписывайтесь на них через RSS.
JIRA Query Language - JQL это новый мощный поисковик, упрощающий создание сложных (и действительно полезных) поисков. Добавьте это в гаджеты на ваш дэшборд, или настройте уведомление по email, чтобы оставаться в курсе.
New dashboards - в расшариваемых дэшбордах нет ничего нового, но теперь вы можете перетаскивать гаджеты по множеству гибких шаблонов лейаутов. Просмотрите папку с гаджетами, выберите гаджеты, настройте цвета, установки и многое другое.
OpenSocial gadgets - так как большинство продуктов Atlassian теперь делают гаджеты OpenSocial, и новые JIRA дэшборды тоже выполнены как OpenSocial контейнеры, вы можете комбинировать данные из JIRA, Confluence, FishEye и даже популярных приложений, например Remember the Milk, в одном месте. Вы даже можете их добавить на свой Gmail или iGoogle страницу!
В JIRA 4 еще много всего.Проверьте release notes для подробностей, а также просматривайте JIRA Product Blog, где разработчики обещают рассказывать о новых возможностях по мере их появления.
А ещё и GreenHopper 4!
Также вышла новая версия GreenHopper,обеспечивающая agile project management для JIRA. В GreenHopper 4 появилась поддержка kanban, а также много других функций и улучшений UI.
вторник, 15 сентября 2009 г.
Planning Poker
Всем разработчикам требуется уметь оценивать свои трудозатраты на реализацию той или иной функциональности в проекте. Planning Poker - этой мощный и в то же время очень простой инструмент, который делает оценку более точной.
Как оценивать задачи с покером - читать тут.
Для распределённых команд можно использовать инструмент Online Planning Poker.
Простой и понятный интерфейс. Требуется регистрация только одного человека (модератора), остальные подключаются по ссылке. Модератор создаёт проект и истории, входящие в этот проект и запускает таймер, участники выставляют свои оценки, обсуждают расхождения в оценках (рекомендую в процессе оценки задач c онлайн-покером использовать skype) и приходят к общему мнению по каждой истории. Результаты оценки историй, входящих в проект, могут быть сохранены в форматах html или csv.
Как оценивать задачи с покером - читать тут.
Для распределённых команд можно использовать инструмент Online Planning Poker.
Простой и понятный интерфейс. Требуется регистрация только одного человека (модератора), остальные подключаются по ссылке. Модератор создаёт проект и истории, входящие в этот проект и запускает таймер, участники выставляют свои оценки, обсуждают расхождения в оценках (рекомендую в процессе оценки задач c онлайн-покером использовать skype) и приходят к общему мнению по каждой истории. Результаты оценки историй, входящих в проект, могут быть сохранены в форматах html или csv.
воскресенье, 23 августа 2009 г.
Лайфхакинг
Лайфхакинг - это полезные советы о том, как эффективно (продуктивно, с пользой, с удовольствием, экономией времени) работать и отдыхать.
Шикарную подборку советов на IT-тематику можно найти на блоге lifehacker.ru
Ещё парочка блогов, собирающих рекомендации и советы не только по теме IT, но и на ряд других тем - lifehack.su и lifehack.ru
Шикарную подборку советов на IT-тематику можно найти на блоге lifehacker.ru
Ещё парочка блогов, собирающих рекомендации и советы не только по теме IT, но и на ряд других тем - lifehack.su и lifehack.ru
пятница, 14 августа 2009 г.
Scrum и XP: заметки с передовой
А для тех, кто английского не знает, но познать Agile хочет, есть замечательная книжка Хенрика Книберга Scrum and XP from the Trenches, перевод которой сделали участники сообщества Agile Ukraine, за что им огромное спасибо.Скачать книгу Scrum и XP: заметки с передовой
В оригинале книгу можно скачать здесь:
http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
Книги по Agile тематике
Те, кто знают английский, найдут здесь отличную подборку материалов по Agile-тематике.
Список того, что можно найти, приведён ниже
Список того, что можно найти, приведён ниже
- Agile Java Development with Spring Hibernate and Eclipse
- Agile and Iterative Development A Manager's Guide
- Agile Database Techniques Effective Strategies for the Agile Software Developer
- Agile Estimating and Planning
- Agile Java Crafting Code with Test-Driven Development
- Agile Management for Software Engineering Applying the Theory of Constraints for Business Results
- Agile Project Management Creating Innovative Products
- Agile Project Management How to Succeed in the Face of Changing Project Requirements
- Agile Project Management with Scrum
- Agile Retrospectives
- Agile Software Construction
- Agile Software Development Ecosystems
- Agile Software Development Evaluating The Methods for Your Organization
- Agile Software Development
- Agile Web Development with Rails 2nd Edition
- Lean Software Development An Agile Toolkit
- Practices of an Agile Developer
- Sustainable Software Development An Agile Perspective
- The Object Primer Agile Model-Driven Development with UML 2.0 3rd Edition
- User Stories Applied for Agile Software Development
пятница, 7 августа 2009 г.
Kanban, Flow and Cadence
С любезного разрешения Карла Скотланда (Karl Scotland) я публикую здесь перевод его замечательной статьи Kanban, Flow and Cadence и дополню его своими комментариями (будут выделены красным курсивом).
Kanban, Flow and Cadence
Kanban - контроллируемая работа
Flow - эффективная работа
Cadence - надёжная работа
Kanban
Kanban - это механизм управления работой в системе разработки программного обеспечения. Kanban переводится как "visual card" и выглядит как на следующей картинке (это автору написал Кенжи Хиранабе на конференции Agile 2008).
Родоначальником Kanban является Toyota Production System.
Kanban реализует пул-систему для работы точно к указанному сроку (just-in-time).
Пул-система - это система, согласно которой имеется некий пул задач на выбор для разработчиков. Команда тянет (от англ. pull - тянуть) задачи из пула и определяет состав итерации.
Это выглядит очень похоже на типичную Agile доску задач (Task Board), в то же время здесь есть ещё один важный элемент, который определяет всю систему Канбан - ограничения. Существует два основных ограничения - лимит очереди и лимит WIP (Work in progress - работа в процессе).
Лимиты очереди нужны для того, чтобы исключить преждевременную работу. Это служит для выполнения работы "точно в срок". Лимит должен быть достаточно большим, чтобы обеспечивать занятость команды (например, в очереди всегда что-то есть для команды, чтобы начать над этим работать), но достаточно маленьким, чтобы избежать предварительной приоритезации (когда задачи "сидят" в очереди очень долго, перед тем, как их начнут делать). Т.е. если очередь очень большая, то новые пришедшие задачи могут получить более высокий приоритет, а более ранние задачи будут долго ждать своего часа.
В идеале очередь задач должна быть FIFO (First in - first out), хотя это скорее рекомендация, чем строгое правило, так как это не всегда возможно с имеющимися навыками и ресурсами. Ограничивать WIP необходимо для уменьшения многозадачности (одновременного выполнения задач), увеличения производительности и улучшения командной работы.
Уменьшение многозадачности полезно по двум причинам.
1) 20% времени теряется на контекстные переключения между задачами, соответственно, меньше задач означает меньше потерь времени (из книги Gerald Weinberg, Quality Software Management: Systems Thinking)
2) Выполнение задач последовательно даёт результаты быстрее. Как показано на диаграмме внизу, в случае одновременного выполнения A, B и С (сверху), задача A выполняется намного позже и даже С выполняется чуть позже, чем в случае последовательного выполнения (внизу).
Превосходный пример для демонстрации эффекта многозадачности описал Кларк Чинг.
Производительность также увеличивается с уменьшением WIP. Простые примеры этого эффекта - пробки на дорогах, где с увеличением трафика уменьшается скорость трафика, и загрузка процессора, где производительность приложения снижается с увеличением загрузки процессора. Эффект можно объяснить на следующем законе (закон Литтла для теории очередей):
Общее время цикла = Число объектов в процессе / Средняя скорость выполнения
Следовательно, для уменьшения времени цикла есть 2 способа: уменьшить число объектов в процессе или увеличить среднюю скорость выполнения. Из двух, уменьшение числа объектов в процессе - более простое, поэтому сначала применяем это, а потом можно и другие стимулирующие изменения для увеличения скорости выполнения.
Наконец, имея меньшее количество рабочих задач в процессе, команда может больше сфокусироваться на больших целях и меньше на индивидуальных, таким образом поощряется эффект толпы и улучшается командная работа.
Ограничение WIP может быть необычным для команд, и часто возникает озабоченность, что члены команды будут простаивать, потому что они свои задачи выполнили, но пока не могут взять любую новую задачу. В этой ситуации будут полезны следующие рекомендации.
1. Можете ли вы помочь на имеющейся задаче? Займитесь этим.
2. У вас нет подходящих навыков? Найдите это узкое место и работайте над этим.
3. У вас нет подходящих навыков? Возьмите задачу из очереди.
4. Не можете начать ничего в очереди? Есть ли какая-нибудь низко-приоритетная задача, чтобы начать её исследовать?
5. Нет ничего низко-приоритетного? Найдите другую интересную работу. (Здесь конечно имеется в виду "другую интересную задачу", хотя другая работа - это тоже решение :) )
Ключевой вопрос здесь следующий - что имеет более низкий приоритет, исследовательская работа или другая интересная работа? По сути, исследовательская работа, это работа, которая не создаёт какой-нибудь результат в очереди других работ, обычно это работа для улучшения производительности в будущем, и она может быть приостановлена сразу же, как стала доступна другая работа, относящаяся к Канбан-системе задач.
Низко-приоритетной задачей может быть анализ известной предстоящей задачи. Другая интересная работа - это рефакторинг, инструмента автоматизации, персональное развитие или инновации.
Размер лимита WIP может зависеть от типа работы и размера команды и должен регулироваться для достижения максимального flow (движения). Один способ - начать с небольшого значения (например, лимит в 1) и увеличивать при необходимости. Другой - начать с большого значения (например, половина размера команды) и уменьшать, пока не достигнута максимальная эффективность.
Результаты использования системы Канбан -
1) можно отказаться от Product Backlog'а, так как единственный интерес представляет ближайшая очередь задач.
2) можно отказаться от ограниченных по времени итераций (спринтов в Scrum), так как задачи берутся по необходимости.
3) можно избавиться от оценки трудозатрат на задачи, так как работа не планируется по итерациям.
Flow
Kanban - даёт более гибкий список задач на выполнение, это может быть хорошим плюсом, всё равно заказчик часто хочет добавить функциональность посреди итерации. Но целиком избавиться от ограниченных по времени итераций и оценок по времени не получится. Всё равно есть как минимум одна большая итерация - сделать проект к определённому сроку. И какая-то оценка трудозатрат всё равно должна производиться, чтобы понимать, успеет ли команда сделать желаемую фукнциональность в срок (не делать каждый раз оценку можно только имея представление о производительности команды, об этом говорит Cadence).
Flow или Value Stream - говорит о том, что надо создавать продукт не мелкими, непонятно как разбитыми кусочками, а целыми маркетинговыми наборами функций (MMF), чтобы клиент мог сразу же продавать эту версию продукта. В принципе это логично, и я лишь добавлю, что с клиентом должен быть налажен очень хороший контакт, чтобы всегда иметь от него актуальную информацию о приоритетах.
Cadence говорит о том, что в налаженном темпе работы нужно оценивать производительность команды для определённого размера задач (а если задачи отличаются по размеру, то иметь несколько оценок для различных размеров MMF).
Оценка производительности позволяет брать на себя обязательства и обеспечивать надёжность скорости разработки.
Kanban, Flow and Cadence
Kanban - контроллируемая работа
Flow - эффективная работа
Cadence - надёжная работа
Kanban
Kanban - это механизм управления работой в системе разработки программного обеспечения. Kanban переводится как "visual card" и выглядит как на следующей картинке (это автору написал Кенжи Хиранабе на конференции Agile 2008).
Родоначальником Kanban является Toyota Production System.
Kanban реализует пул-систему для работы точно к указанному сроку (just-in-time).
Пул-система - это система, согласно которой имеется некий пул задач на выбор для разработчиков. Команда тянет (от англ. pull - тянуть) задачи из пула и определяет состав итерации.
Как выглядит Канбан-система для разработки ПО? Очень просто, существует очередь работ, которая проходит через несколько стадий разработки, пока не будет выполнена. Когда работа на определённом этапе завершена, она переходит в конец очереди на следующем этапе. Когда кому-либо требуется начать новую работу, он тянет себе карточку из начала очереди. Это можно проиллюстрировать следующим образом.
Это выглядит очень похоже на типичную Agile доску задач (Task Board), в то же время здесь есть ещё один важный элемент, который определяет всю систему Канбан - ограничения. Существует два основных ограничения - лимит очереди и лимит WIP (Work in progress - работа в процессе).
Лимиты очереди нужны для того, чтобы исключить преждевременную работу. Это служит для выполнения работы "точно в срок". Лимит должен быть достаточно большим, чтобы обеспечивать занятость команды (например, в очереди всегда что-то есть для команды, чтобы начать над этим работать), но достаточно маленьким, чтобы избежать предварительной приоритезации (когда задачи "сидят" в очереди очень долго, перед тем, как их начнут делать). Т.е. если очередь очень большая, то новые пришедшие задачи могут получить более высокий приоритет, а более ранние задачи будут долго ждать своего часа.
В идеале очередь задач должна быть FIFO (First in - first out), хотя это скорее рекомендация, чем строгое правило, так как это не всегда возможно с имеющимися навыками и ресурсами. Ограничивать WIP необходимо для уменьшения многозадачности (одновременного выполнения задач), увеличения производительности и улучшения командной работы.
Уменьшение многозадачности полезно по двум причинам.
1) 20% времени теряется на контекстные переключения между задачами, соответственно, меньше задач означает меньше потерь времени (из книги Gerald Weinberg, Quality Software Management: Systems Thinking)
2) Выполнение задач последовательно даёт результаты быстрее. Как показано на диаграмме внизу, в случае одновременного выполнения A, B и С (сверху), задача A выполняется намного позже и даже С выполняется чуть позже, чем в случае последовательного выполнения (внизу).
Превосходный пример для демонстрации эффекта многозадачности описал Кларк Чинг.
Производительность также увеличивается с уменьшением WIP. Простые примеры этого эффекта - пробки на дорогах, где с увеличением трафика уменьшается скорость трафика, и загрузка процессора, где производительность приложения снижается с увеличением загрузки процессора. Эффект можно объяснить на следующем законе (закон Литтла для теории очередей):
Общее время цикла = Число объектов в процессе / Средняя скорость выполнения
Следовательно, для уменьшения времени цикла есть 2 способа: уменьшить число объектов в процессе или увеличить среднюю скорость выполнения. Из двух, уменьшение числа объектов в процессе - более простое, поэтому сначала применяем это, а потом можно и другие стимулирующие изменения для увеличения скорости выполнения.
Наконец, имея меньшее количество рабочих задач в процессе, команда может больше сфокусироваться на больших целях и меньше на индивидуальных, таким образом поощряется эффект толпы и улучшается командная работа.
Ограничение WIP может быть необычным для команд, и часто возникает озабоченность, что члены команды будут простаивать, потому что они свои задачи выполнили, но пока не могут взять любую новую задачу. В этой ситуации будут полезны следующие рекомендации.
1. Можете ли вы помочь на имеющейся задаче? Займитесь этим.
2. У вас нет подходящих навыков? Найдите это узкое место и работайте над этим.
3. У вас нет подходящих навыков? Возьмите задачу из очереди.
4. Не можете начать ничего в очереди? Есть ли какая-нибудь низко-приоритетная задача, чтобы начать её исследовать?
5. Нет ничего низко-приоритетного? Найдите другую интересную работу. (Здесь конечно имеется в виду "другую интересную задачу", хотя другая работа - это тоже решение :) )
Ключевой вопрос здесь следующий - что имеет более низкий приоритет, исследовательская работа или другая интересная работа? По сути, исследовательская работа, это работа, которая не создаёт какой-нибудь результат в очереди других работ, обычно это работа для улучшения производительности в будущем, и она может быть приостановлена сразу же, как стала доступна другая работа, относящаяся к Канбан-системе задач.
Низко-приоритетной задачей может быть анализ известной предстоящей задачи. Другая интересная работа - это рефакторинг, инструмента автоматизации, персональное развитие или инновации.
Размер лимита WIP может зависеть от типа работы и размера команды и должен регулироваться для достижения максимального flow (движения). Один способ - начать с небольшого значения (например, лимит в 1) и увеличивать при необходимости. Другой - начать с большого значения (например, половина размера команды) и уменьшать, пока не достигнута максимальная эффективность.
Результаты использования системы Канбан -
1) можно отказаться от Product Backlog'а, так как единственный интерес представляет ближайшая очередь задач.
2) можно отказаться от ограниченных по времени итераций (спринтов в Scrum), так как задачи берутся по необходимости.
3) можно избавиться от оценки трудозатрат на задачи, так как работа не планируется по итерациям.
Flow
Процесс описывает, как работа в системе может принести максимальную ценность. Как написали Mary и Tom Poppendieck,
“В бережливых (lean) предприятиях, традиционные организационные структуры уступают место новым командно-ориентированным организациям, нацеленным на процесс получения результата, а не на функциональную квалификацию."
Lean придаёт особое значение "One Piece Flow". Это означает движение одной части работы в момент времени между этапами техпроцесса, в отличие от движения целой кучи работ между этапами. One Piece в системе Канбан для разработки ПО может быть реализована как Minimal Marketable Feature (MMF, минимальный маркетинговый набор функциональностей). Как описано в книге M Denne и H Clelan-Huang Software by Numbers:
“Минимальный маркетинговый набор функциональностей - это некоторое количество функциональностей, которое реализует подмножество требований клиента, и которое представляет ценность для клиента будучи выпущенным как независимая сущность”.
Карточки с задачами должны быть минимальными, как можно меньше, для того, чтобы обеспечить прогрессивную доставку результатов, чтобы скорее выпустить продукт. Необходимо уменьшить раздувание функций и сфокусироваться на ключевых важнейших функциях, а также снизить сложность, так как каждая функция имеет цену для пользователя.
Карточки с задачами должны быть "рыночными" и обеспечивать следующие результаты:
- Table Stakes - эти результаты обеспечивают равенство в конкурентной борьбе, т.е. являются необходимым минимумом в игре.
- Differentiators- дифференцируют продукт среди конкурентов и радуют пользователя.
- Spoilers – обнуляют выделяющиеся результаты конкурентов и повышают планку равенства.
- Cost Reducers – уменьшают цену и увеличивают размер прибыли
Карточки с задачами должны быть ясными, поставляемыми и заметными функциями. Описанный Биллом Вейком акроним INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) также может быть полезен применительно к MMF. (Ну и не забываем ещё про критерии SMART для любых задач - Specific, Measurable, Achievable, Result-oriented, Time-bounded)
Маркетинговый элемент MMF, означает что эти функции ценны именно вместе. Типичные User Stories, разбивающие работу на составные части, которые реализуются постепенно, не имеют большой рыночной ценности сами по себе. Важно понимать Ценностный поток MMF (Value Stream), чтобы разрабатывать и поставлять целый MMF как можно быстрее. Ценностный поток описывает шаги, задержки и информацию, необходимую для выполнения продукта, и часто может использоваться для определения шагов на начальных этапах системы Канбан. Я описываю как может быть достигнут продолжительный процесс (Flow) с MMF в статье The Anatomy of an MMF.
Есть несколько приёмов, которые могут помочь наладить отношения между MMF и User Stories для получения выгод от обеих техник. Один из них User Story Mapping, описанный Джеффом Паттоном.
Недавно я работал в среде, где цели и подцели пользовательских сценариев (User Case) обеспечивали MMF, с детально описанными шагами, реализующими дополнительные детали.
Дальнейшее улучшение - использовать двух-рядные Канбаны, один ряд для MMF, и другой для User Stories.
В результате применения концепции Flow акцент ставится на использование больших сфокусированных на ценность MMF, чем маленьких постепенно увеличивающихся Stories.
Cadence
Cadence служит для достижения обязательств и надёжности в системе Канбан. Мне часто задают следующий вопрос:
"Если команда не оценивает и не планирует в фиксированных временных рамках, то как она может надёжно выполнять обязательства?"
Опять цитируя Mary и Tom Poppendieck,“Регулярный ритм, или ‘сердцебиение’, создает у команды возможность надёжно выпускать рабочее ПО на надёжной скорости. В организации, обеспечивающей регулярный ритм, уже установлены процессы, и она может легко измерять свою производительность.”
Ограниченная по времени итерация - одна из форм создания ритма, объединяющая в себе планирование, проверку и выпуск. Канбан система разбивает эти сущности и позволяет им иметь отдельные ритмы, а также добавляет две дополнительные. Пропускная способность - количество результатов процесса в заданный период времени, и Время цикла - количество времени для завершения процесса. Отношение между этими двумя величинами такое:
Пропускная способность = WIP / Время цикла
Пропускная способность позволяет прогнозировать будущую производительность без необходимости указывать, что конкретно должно быть выполнено. Время цикла позволяет установить обязательства, заключая SLA (Service Level Agreement) с заказчиком (см. Kanban Commitment). Если размер работ меняется, от больших новых функций до небольших исправлений и запросов на изменения, может применяться классификация MMF, для определения целого ряда времён цикла (cycle-times). И для пропускной способности и для времени цикла можно построить график и отследить тренд (как для скорости в методике XP) для поощрения команды на дальнейшие улучшения. Диаграмма Cumulative Flow Diagram также делает видимым рабочий процесс в системе и высвечивает узкие места в проекте.
Для долговременного прогнозирования ритм квартального планирования направлен на квартальные цели и задачи. Для MMF могут последовательно выставляться приоритеты, чтобы выполнить эти цели и задачи. Регулярный ритм выпуска продуктов создаст уверенность, что команда будет работать с полной отдачей и производительностью.
Другие ритмы - stand-up митинги, регулярные ретроспективы и Обзоры Операций описаны Дэвидом Андерсоном. Некоторые команды используют Retrospective Kanban, чтобы сигнализировать, когда необходима ретроспектива. Я об этом уже кратко писал в статье Kanban and Retrospectives.
В результате Cadence достигается обязательство и надёжность через измерения, а не планирование.
Итоги:
- Kanban система организует рабочий процесс таким образом, что можно избавиться от Product Backlog'а, временных итераций и оценок трудозатрат.
- Flow позволяет эффективно производить максимальную ценность для клиента, направлен на создание больших MMF.
- Cadence позволяет разъединить вход и выход итерации и достигать обязательства и надёжности через измерения, а не планирование.
Kanban - даёт более гибкий список задач на выполнение, это может быть хорошим плюсом, всё равно заказчик часто хочет добавить функциональность посреди итерации. Но целиком избавиться от ограниченных по времени итераций и оценок по времени не получится. Всё равно есть как минимум одна большая итерация - сделать проект к определённому сроку. И какая-то оценка трудозатрат всё равно должна производиться, чтобы понимать, успеет ли команда сделать желаемую фукнциональность в срок (не делать каждый раз оценку можно только имея представление о производительности команды, об этом говорит Cadence).
Flow или Value Stream - говорит о том, что надо создавать продукт не мелкими, непонятно как разбитыми кусочками, а целыми маркетинговыми наборами функций (MMF), чтобы клиент мог сразу же продавать эту версию продукта. В принципе это логично, и я лишь добавлю, что с клиентом должен быть налажен очень хороший контакт, чтобы всегда иметь от него актуальную информацию о приоритетах.
Cadence говорит о том, что в налаженном темпе работы нужно оценивать производительность команды для определённого размера задач (а если задачи отличаются по размеру, то иметь несколько оценок для различных размеров MMF).
Оценка производительности позволяет брать на себя обязательства и обеспечивать надёжность скорости разработки.
среда, 5 августа 2009 г.
Почувствуй себя Scrumy!
Scrumy - отличный сервис, представляющий из себя доску для "наклеивания" на неё карточек с задачами (Kanban так и переводится - visual card). Доска прекрасно подходит и для любителей Scrum и для Kanban.
Сервис чрезвычайно прост в управлении. Под каждый проект удобно заводить новую доску. Слева создаёте группы задач, так называемые Stories. Внутри создаёте задачи на эту итерацию, назначаете исполнителей на задачу, и дальше в соответствии с прогрессом проекта исполнители расставляют задачи в нужные колонки.
Todo - планируется сделать
In progress - над задачей работают сейчас
Verify - задача тестируется
Done - задача выполнена
При ежедневном обновлении доски, эта штука является отличным инструментом для отслеживания состояния дел в проекте. К тому же весь минимальный набор функций, описанный выше, является бесплатным.
Платная версия Scrumy Pro также присутствует и стоит 7$ в месяц за доску (или 60$ в год).
В платной версии услуги доступны всякие удобные фишки: burndows графики, настраиваемые цвета, защита доски паролем, обновление доски в режиме он-лайн, временная динамика доски, и другие. Все улучшения можно просмотреть тут
https://scrumy.com/about
Сервис чрезвычайно прост в управлении. Под каждый проект удобно заводить новую доску. Слева создаёте группы задач, так называемые Stories. Внутри создаёте задачи на эту итерацию, назначаете исполнителей на задачу, и дальше в соответствии с прогрессом проекта исполнители расставляют задачи в нужные колонки.
Todo - планируется сделать
In progress - над задачей работают сейчас
Verify - задача тестируется
Done - задача выполнена
При ежедневном обновлении доски, эта штука является отличным инструментом для отслеживания состояния дел в проекте. К тому же весь минимальный набор функций, описанный выше, является бесплатным.
Платная версия Scrumy Pro также присутствует и стоит 7$ в месяц за доску (или 60$ в год).
В платной версии услуги доступны всякие удобные фишки: burndows графики, настраиваемые цвета, защита доски паролем, обновление доски в режиме он-лайн, временная динамика доски, и другие. Все улучшения можно просмотреть тут
https://scrumy.com/about
четверг, 23 июля 2009 г.
Kanban vs. Scrum
7 июля состоялось собрание сообщества AgileRussia, посвященного сравнению методологий разработки Scrum и Kanban. Позже я обязательно напишу свои комментарии к такому сравнению, а пока наслаждаемся отчетом о встрече и видео
http://team.custis.ru/2009/07/kanban-vs-scrum.html
http://team.custis.ru/2009/07/kanban-vs-scrum.html
среда, 1 июля 2009 г.
Lean Software Development
Стремительно набирающая популярность методология "бережливой" разработки ПО (Lean Software Development) в рунете представлена очень скудным количеством материалов. Фактически, интересующемуся человеку придется собирать информацию по крупицам или с англоязычных ресурсов (хорошо, что для меня это не препятствие).
Немного облегчу задачу читателю и представлю здесь ссылки на некоторые найденые мной ресурсы, а также своё понимание.
http://lobasev.ru/2008/01/lean-software-development.html
http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf
http://availagility.wordpress.com/2008/10/28/kanban-flow-and-cadence/
http://en.wikipedia.org/wiki/Lean_software_development
http://www.leancor.ru/article2.phtml?m=10160
Название Lean Software Development произошло из названия одноимённой книги авторов Mary и Tom Poppendieck, изложивших в книге основные Lean принципы, 22 инструмента для реализации этих принципов, а также их применение к Agile-практикам.
Итак, Lean Software Development - это даже не методология, а скорее набор принципов улучшения процесса разработки и повышения его эффективности.
Ключевые процессы Lean-разработки таковы:
1. Eliminate waste
Необходимо избавиться от waste (или muda в оригинальном лексиконе компании Тойота),
т.е. от всего, что не приносит ценности (value) заказчику
- необязательный код или функциональность
- задержки в процессе разработки ПО
- неясные требования
- бюрократия
- неоперативные внутренние коммуникации
2. Amplify learning
Разработка ПО требует постоянного обучения команды и накопления знаний. Полученные в процессе разработки знания используются как best practices в последующих проектах.
3. Decide as late as possible
Принимать решения как можно позднее, особенно это касается необратимых решений.
Чем позднее принимаются решения, тем больше информации у вас есть, и тем меньше надо будет потом переделывать.
4. Deliver as fast as possible
Чем быстрее вы покажете результаты разработки заказчику, тем быстрее получите от него обратную связь, и он быстрее получит продукт со всеми доработками.
5. Empower the team
Человеческий фактор - решает! Во многих отраслях существует традиционное заблуждение о процессе принятия решений - менеджеры говорят рабочим, как им надо делать их работу. Опытные же руководители проектов сформулировали рецепт успешного проекта просто - "Найди хороших людей и позволь им делать их работу!".
Другая порочная практика - относиться к людям как к ресурсам. В разработке ПО, как и в любом организационном бизнесе людям нужно нечто большее, чем просто список задач и уверенность в том, что их не потревожат во время выполнения этих задач. Людям нужна мотивация и достижимые цели, осознание собственной значимости и своего вклада в проект, нужно признание людьми важности создаваемого проекта. Здесь большую роль играет team leader, который оказывает поддержку и помощь в трудных ситуациях (это также может осуществлять project manager).
6. Build integrity in
Целостность - это то, как отдельные компоненты системы работают в целом вместе, с балансом гибкости (flexibility), удобства сопровождения (maintainability), эффективности (effectiveness) и способности к реагированию (responsiveness). Это осуществляется выявлением и решением проблемных областей на самых ранних стадиях.
Инструменты достижения целостности - рефакторинг и полное автоматизированное тестирование (и со стороны разработчиков и со стороны заказчика).
7. See the whole
Система это не сумма составляющих её частей, но продут их взаимодействия.
Чем больше система, тем больше организаций принимают участие в разработке, тем больше частей разрабатывается разными командами и тем большее значение имеет взаимодействие между разными вендорами.
Поэтому для команды очень важно понимать, как идет процесс разработки и стратегию продукта в целом.
Для воплощения в реальном проекте принципы lean разработки должны хорошо пониматься всеми участниками проекта. Важность понимания области применения и пригодности lean принципов суммирует следующий слоган - Think big, act small, fail fast; learn rapidly - Думать широко, действовать маленькими шагами, заваливать скоро, учиться быстро.
Немного облегчу задачу читателю и представлю здесь ссылки на некоторые найденые мной ресурсы, а также своё понимание.
http://lobasev.ru/2008/01/lean-software-development.html
http://www.crisp.se/henrik.
http://availagility.wordpress.
http://en.wikipedia.org/wiki/Lean_software_development
http://www.leancor.ru/article2.phtml?m=10160
Название Lean Software Development произошло из названия одноимённой книги авторов Mary и Tom Poppendieck, изложивших в книге основные Lean принципы, 22 инструмента для реализации этих принципов, а также их применение к Agile-практикам.
Итак, Lean Software Development - это даже не методология, а скорее набор принципов улучшения процесса разработки и повышения его эффективности.
Ключевые процессы Lean-разработки таковы:
1. Eliminate waste
Необходимо избавиться от waste (или muda в оригинальном лексиконе компании Тойота),
т.е. от всего, что не приносит ценности (value) заказчику
- необязательный код или функциональность
- задержки в процессе разработки ПО
- неясные требования
- бюрократия
- неоперативные внутренние коммуникации
2. Amplify learning
Разработка ПО требует постоянного обучения команды и накопления знаний. Полученные в процессе разработки знания используются как best practices в последующих проектах.
3. Decide as late as possible
Принимать решения как можно позднее, особенно это касается необратимых решений.
Чем позднее принимаются решения, тем больше информации у вас есть, и тем меньше надо будет потом переделывать.
4. Deliver as fast as possible
Чем быстрее вы покажете результаты разработки заказчику, тем быстрее получите от него обратную связь, и он быстрее получит продукт со всеми доработками.
5. Empower the team
Человеческий фактор - решает! Во многих отраслях существует традиционное заблуждение о процессе принятия решений - менеджеры говорят рабочим, как им надо делать их работу. Опытные же руководители проектов сформулировали рецепт успешного проекта просто - "Найди хороших людей и позволь им делать их работу!".
Другая порочная практика - относиться к людям как к ресурсам. В разработке ПО, как и в любом организационном бизнесе людям нужно нечто большее, чем просто список задач и уверенность в том, что их не потревожат во время выполнения этих задач. Людям нужна мотивация и достижимые цели, осознание собственной значимости и своего вклада в проект, нужно признание людьми важности создаваемого проекта. Здесь большую роль играет team leader, который оказывает поддержку и помощь в трудных ситуациях (это также может осуществлять project manager).
6. Build integrity in
Целостность - это то, как отдельные компоненты системы работают в целом вместе, с балансом гибкости (flexibility), удобства сопровождения (maintainability), эффективности (effectiveness) и способности к реагированию (responsiveness). Это осуществляется выявлением и решением проблемных областей на самых ранних стадиях.
Инструменты достижения целостности - рефакторинг и полное автоматизированное тестирование (и со стороны разработчиков и со стороны заказчика).
7. See the whole
Система это не сумма составляющих её частей, но продут их взаимодействия.
Чем больше система, тем больше организаций принимают участие в разработке, тем больше частей разрабатывается разными командами и тем большее значение имеет взаимодействие между разными вендорами.
Поэтому для команды очень важно понимать, как идет процесс разработки и стратегию продукта в целом.
Для воплощения в реальном проекте принципы lean разработки должны хорошо пониматься всеми участниками проекта. Важность понимания области применения и пригодности lean принципов суммирует следующий слоган - Think big, act small, fail fast; learn rapidly - Думать широко, действовать маленькими шагами, заваливать скоро, учиться быстро.
вторник, 30 июня 2009 г.
Конференция Agile Eastern Europe
Друзья, 18-19 сентября 2009 года в Киеве нас ожидает очень интересное событие - конференция Agile Eastern Europe, посвящённая (как нетрудно догадаться из названия) гибким методикам разработки ПО.
До 15 июля стоимость конференции составит 160$. Тем, кто зарегистрируется позднее, конференция будет стоить 210$.
Программа конференции обещает быть очень насыщенной. Доклады будут вестись одновременно в 3 залах, и неумение мною создавать собственных клонов сможет компенсироваться лишь видеозаписью докладов, которая, я надеюсь, будет организована.
В числе докладчиков Мери Поппендик (Mary Poppendieck) - автор методологии "бережливой" разработки ПО (Lean Software Development) и серии книг по Lean тематике, среди которых бестселлер: Implementing Lean Software Development: From Concept to Cash
Ютта Екштайн (Jutta Eckstein), автор книги Agile Software Development in the Large расскажет о построении эффективных моделей распределенной разработки с элементами Agile.
А еще Boris Gloger, David Hussman, Robin Dymond и многие другие.
Компания ScrumTrek организует поездку российских участников на конференцию, помогает оформить оплату участникам и поможет с проживанием. Подобнее здесь.
Лично меня на этой конференции привлекает большое количество докладов, затрагивающих вопросы успешного применения гибкой разработки в распределенной среде. Эти вопросы более чем актуальны как для всего Российского рынка, так и для нашей компании в частности, а опыт, полученный из первых уст, является очень ценным. Посмотрим, оправдаются ли мои ожидания.
До 15 июля стоимость конференции составит 160$. Тем, кто зарегистрируется позднее, конференция будет стоить 210$.
Программа конференции обещает быть очень насыщенной. Доклады будут вестись одновременно в 3 залах, и неумение мною создавать собственных клонов сможет компенсироваться лишь видеозаписью докладов, которая, я надеюсь, будет организована.
В числе докладчиков Мери Поппендик (Mary Poppendieck) - автор методологии "бережливой" разработки ПО (Lean Software Development) и серии книг по Lean тематике, среди которых бестселлер: Implementing Lean Software Development: From Concept to Cash
Ютта Екштайн (Jutta Eckstein), автор книги Agile Software Development in the Large расскажет о построении эффективных моделей распределенной разработки с элементами Agile.
А еще Boris Gloger, David Hussman, Robin Dymond и многие другие.
Компания ScrumTrek организует поездку российских участников на конференцию, помогает оформить оплату участникам и поможет с проживанием. Подобнее здесь.
Лично меня на этой конференции привлекает большое количество докладов, затрагивающих вопросы успешного применения гибкой разработки в распределенной среде. Эти вопросы более чем актуальны как для всего Российского рынка, так и для нашей компании в частности, а опыт, полученный из первых уст, является очень ценным. Посмотрим, оправдаются ли мои ожидания.
понедельник, 29 июня 2009 г.
Кратко о SCRUM
SCRUM является одной из самых популярных методологий гибкой (agile) разработки ПО. Хорошую подробную статью о SCRUM можно прочитать на AgileRussia в статье Асхата Уразбаева, я же здесь добавлю несколько комментариев к этой статье от себя.
Про длительность итерации
SCRUM рекомендует делать итерации (спринты) длительностью 15-30 дней. Итерация в 30 дней лично мне представляется неоправданно длительной даже для больших проектов. Ощущение завершённости очень важно для команды и выпуск "лишней" промежуточной версии повысит её мотивацию.
Для небольших же проектов и прототипов длительностью от нескольких недель до 1-2 месяцев длительность спринта может быть вообще 7 дней. Также небольшая длительность спринтов оправдана в самом начале внедрения методик гибкой разработки, пока налаживаются процессы и команда привыкает к новому режиму.
Про удалённый SCRUM
Рекомендуется размещать команду в одной общей комнате для улучшения взаимодействия. Удалённо-распределённый SCRUM возможен, однако имеет свои тонкости. Можно связывать всех участников daily-митинга через Skype или другое средство IP-телефонии. Skype позволяет подключить участника к митингу, даже если у него нет в данный момент доступа к сети интернет - оплаченная услуга Skype-out позволяет звонить на мобильный телефон. Однако надо понимать, что от каждого участника распределённой команды требуется ещё большая самоорганизация и ответственность.
Управлять распределённой командой сложнее. Определённую помощь как менеджерам, так и разработчикам в данном случае может принести использование системы управления проектами. Такую разработку сейчас ведёт компания Флексис, проект сейчас находится в стадии прототипирования, и о результатах я смогу рассказать в этом блоге уже в ближайшее время.
Про длительность итерации
SCRUM рекомендует делать итерации (спринты) длительностью 15-30 дней. Итерация в 30 дней лично мне представляется неоправданно длительной даже для больших проектов. Ощущение завершённости очень важно для команды и выпуск "лишней" промежуточной версии повысит её мотивацию.
Для небольших же проектов и прототипов длительностью от нескольких недель до 1-2 месяцев длительность спринта может быть вообще 7 дней. Также небольшая длительность спринтов оправдана в самом начале внедрения методик гибкой разработки, пока налаживаются процессы и команда привыкает к новому режиму.
Про удалённый SCRUM
Рекомендуется размещать команду в одной общей комнате для улучшения взаимодействия. Удалённо-распределённый SCRUM возможен, однако имеет свои тонкости. Можно связывать всех участников daily-митинга через Skype или другое средство IP-телефонии. Skype позволяет подключить участника к митингу, даже если у него нет в данный момент доступа к сети интернет - оплаченная услуга Skype-out позволяет звонить на мобильный телефон. Однако надо понимать, что от каждого участника распределённой команды требуется ещё большая самоорганизация и ответственность.
Управлять распределённой командой сложнее. Определённую помощь как менеджерам, так и разработчикам в данном случае может принести использование системы управления проектами. Такую разработку сейчас ведёт компания Флексис, проект сейчас находится в стадии прототипирования, и о результатах я смогу рассказать в этом блоге уже в ближайшее время.
Пуск!
Этот блог будет посвящён науке, ремеслу и искусству управления проектами.
В нём я буду затрагивать такие темы как Agile, Scrum, PMI, project management, командообразование, мотивация, лидерство, маркетинг, разработка ПО, тайм-менеджмент, системы управления проектами, методологии, а также многие другие вопросы, непосредственно касающиеся управления.
Мои и чужие мысли, знания, открытия, озарения, споры, комментарии, возражения, бред, "блин, я понял!", цитаты, концепции и прочее будут вариться в этом блоге-котле, постепенно превращаясь в уникальный опыт, полезный как для меня, так и для других читателей, и рождая новые замечательные идеи!
Начнём!
В нём я буду затрагивать такие темы как Agile, Scrum, PMI, project management, командообразование, мотивация, лидерство, маркетинг, разработка ПО, тайм-менеджмент, системы управления проектами, методологии, а также многие другие вопросы, непосредственно касающиеся управления.
Мои и чужие мысли, знания, открытия, озарения, споры, комментарии, возражения, бред, "блин, я понял!", цитаты, концепции и прочее будут вариться в этом блоге-котле, постепенно превращаясь в уникальный опыт, полезный как для меня, так и для других читателей, и рождая новые замечательные идеи!
Начнём!
Подписаться на:
Сообщения (Atom)
