Pull to refresh

Как меня учили работать. День второй

Reading time3 min
Views819
День первый

На второй день у нас был семинар посвященный SCRUM и Agile project. На нем рассказывали практическое применение Agile project при разработке ПО.



Свинья и петух

По-видимому, любимая история лектора, потому что слайд с ней встречался в презентации раз 7 :)

И так, встретились свинья и петух. Петух предложил открыть свой ресторан и назвать его «Свинина и яйца». На что свинья ответила отказом: «Ты будешь только учавствовать, а я отдавать себя целиком».

В понятиях SCRUM свиньи — это девелоперы, петух это менеджер проекта. Суть истории: свинья важнее петуха. Суть SCRUM: разработчики важнее менеджера, нельзя принебрегать мнением первых.

С чего всё началось

Руководители крупных софтверных компаний решили разработать общий стиль работы, который потом назвали Agile.
Основным документом, можно сказать, сводом заповедей, является манифест «Manifesto for Agile Software Development».
Он гласит:
Люди и взаимоотношения выше процессов и тулов (tools)
Работающий продукт лучше подробной документации
Взаимоотношения с заказчиком важнее подписанных контрактов
Готовность к изменениям важнее следования планам

In English
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Во главу угла ставится человек, потому что именно он производит продукт. Если процесс становится причиной раздражения — его следует поменять. Если инструмент неудобный — от него нужно отказаться.
Заказчик платит за рабочий проект, а не за его описание.
Важно так же быть готовым к изменениям в проекте. Команда должна быть гибкой в плане возможностей.

Принципы Agile Development


Основными принципами являются:
  • Поставки новых версий продукта должны быть регулярными, и делаться как можно раньше
  • Если заказчик хочет что-то поменять в продукте, нужно это сделать на любом этапе разработки (если это конечно возможно)
  • Важно выпускать работающий продукт как можно чаще. Желательный срок от 2х недель до 2х месяцев
  • Разработчики и бизнесмены (те кто отвечает за работы с заказчиком) должны работать вместе.
  • Хорошие условия работы. Разработчику должно быть комфортно работать
  • Больше личных встреч


Немного поясню. Agile сориентирован на заказчика. Но это не значит, что любая его прихоть должна выполняться безприкословно. Нужно обеспечить диалог между бизнес людьми, заказчиком и программистом.
Продукт должен выпускаться достаточно часто — это как с блогом — чем чаще пишешь полезные посты, тем больше народу тебя читают и из друзей не удаляют. Заказчику не нужен продукт, который обновляется раз в пол года и наращивает функционал на пару-тройку фич. Тут еще нужно помнить о конкуренции.
Ну а довольный и мотивированный программист напишет код лучше, чем если бы бы он сидел в сыром подвале и недоедал.

Есть еще два важных момента. Они технические.
1. Каждая новая версия продукта должа делать больше, чем предыдущая
2. Код нужно изначально писать хорошо, что бы потом не переписывать, и сохранять его качество. Если необходимо проводить рефакторинг.

Успех Tayot'ы или Lean thinking


Пример Tayota показательный: она купила убыточное производство одной американской компании (простите, забыл название) вместе с рабочими и оборудованием, и вывела это производство в плюс. Ключем к успеху был Lean Production.

Его принципы:
  • Избавляться от всего лишнего
  • Следить за качеством
  • Уважать людей
  • Повышать опыт
  • Откладывать решение на последний момент
  • Поставлять продукт быстро
  • Оптимизировать процесс


Зачем откладывать решение и как при этом своевременно поставлять продукт? Все просто: решение должно быть обдуманным и согласованным, это поможет избежать проблем в производстве и ускорит время выпуска продукта.

Пожалуй ключевым, является избавление от всего лишнего.
Любой лишний процесс или процедура добавляеют стоимость к продукту. Каждая область имеет свой список лишнего. Для разработки ПО это:
  • Недоделанная работа. Помним, что незавершенная фича никому не нужна. Нужно стараться все доводить до конца
  • Лишние процессы. Это те, что делаются «для галочки».
  • Дополнительные фичи. Если заказчик просит только возможность открыть текст, не надо делать возможность редактировать его.
  • Переключение между задачами. Программист не должен метаться между двумя проектами.
  • Передача продукта. Потому что это занимает лишние ресурсы.
  • Ожидание. Если проекту что-то необходимо, он не должен ждать и сидеть без дела.
  • Дефекты. Это везде плохо :)


Немножечко про SCRUM

Он является частью Agile & Lean software project development. Как я уже писал, он является частью тактического планирования.

SCRUM цикл состоит из:
1. Собственно разработки ПО. Процесс в 1-4 недели с ежедневными митингами.
2. Окончании спринта. Опять же митинг, на котором разработчики показывают всем, что они сделали.
3. Ретроспективного митинга — анализ ошибок и проблем, успехов и улучшений.

PS: на этой недели закончились все тренинг-митинги. С понедельника в бой. В целом, мы готовы. Бой покажет :)
Tags:
Hubs:
Total votes 12: ↑11 and ↓1+10
Comments5

Articles