Программер без учебы часть 4

27

Пожалуйста, войдите, чтоб смотреть за этим содержанием
0 Подписчики 0

· Запись добавлена Szineczek · 2 сентября 2016 г.

2013 просмотров

  • Polkomtel
  • плюс
  • игра
  • robak96
  • манатки

Часть 4 уже была там, но кому-то не приглянулся тезис, находящийся в ней, и он был удален (другими словами пропал) навечно

Часть 4, либо как смотрится ежедневная работа программера в korpo.

Юная оживленная команда. Agile. Scrum. Может быть, вы сталкивались с этими выражениями. Подобно тому, как 1-ый — обычно пиарский сервис, ловкость и схватки нередко оказываются реальностью. И они не приспособлены в компаниях, так как они вправду принесут некую пользу, а поэтому, что это на данный момент стильно, и все употребляют это. Извините.
О, если МДЗ окажется реальностью, это может быть еще ужаснее — это признак того, что команда состоит из неопытных людей, а компания сберегает на самом главном — сотрудниках. :)

Но давайте останемся со Scrum и поведаем о том, как в нем работать, каковы недочеты, достоинства и почему это вообщем для всех.

Базу этой методологии составляют независящие команды разработчиков. Не считая того, есть обладатель продукта , который является обладателем продукта, который устанавливает более принципиальные деяния в продукте в определенный период времени (к примеру, в данном квартале). Он отправляет таковой перечень команде (которая состоит из 3-9 дополнительных единиц). Команды получают таковой перечень ценностей от обладателя, но они определяют, что, сколько и как они будут делать.
Работа в Scrum заключается в проведении так именуемой спринты, другими словами маленькие периоды, в течение которых команда может обеспечить реальное улучшение продукта. Они раз в две недели с нами.
Перед полным спринтом команда вместе определяет, сколько она способна сделать, отыскивает вероятные блокировщики, которые будут препятствовать доставке вещей впору, устанавливает внутренние компетенции и демократически заявляет обладателю продукта, что они будут делать в данном спринте. В конце каждого спринта есть демо, другими словами презентация того, что было достигнуто. Во время спринта каждый денек происходит заезд (каждодневная схватка), в течение которого команда синхронизируется исходя из убеждений хода работы.

Вот и все в теории. Как это смотрится на практике? Огромное количество встреч. Скрам определяет определенное наибольшее время, которое может быть выделено для встреч. За две недели работы это:
— планирование, макс. 10%, другими словами 8 часов,
— в режиме ожидания — 15 минут * 8 дней -> 2 часа,
— демо — время,
— спринт обзор — время.
В целом, это дает нам фактически два денька без работы, чтоб остаться на два часа. Ну нет катастрофы, 8 дней непрерывного разработчика за 10 дней работы? Ха-ха, это не так отлично.
К огорчению, командам нередко не хватает компетенции по определенной теме, нужны консультации, чтоб убедиться, что мы верно сообразили тему, сигнализирую обладателю продукта либо блокировщикам , отсутствию нужных инструментов — что угодно. И в то же время это время продлевается (и вам придется запутаться в мейкапе: |).
Но это не останавливается там. Конфигурации ценностей не должны происходить, но если это так, то , что спринт , не в процессе. Как вы сможете додуматься — это не тот случай. Мы нередко получаем несколько бросков, так как «это займет некое время», «вы сможете поглядеть на это», «и вы связываете эту тему», «ну, как вы уже смотрели, похлопочите об этом» и т. Д., И т. Д., И, как следует, нередко основной план спринта не Можно сохранить и еще ряд вопросов «но как это», «извлечь урок из этого спринта», «попытаться предупредить такую ​​ситуацию еще раз». ;|
;|
Другое дело, что команда как команда должна соединить усилия в работе над задачками. В текущее время большая часть итераций основаны на том принципе, что команда является формальным творением, а каждый участник работает над кое-чем другим. А потом время для ожидания и синхронизации — естественно, половина команды не знает, что я делаю с технической стороны (они знают только заголовок задачки), в свою очередь, я не знаю, что делает другая половина команды. :) Так не должно быть.

Ворачиваясь к планированию и другому нарушению правил Scrum — команда должна найти себе, что они будут делать в данный период, а потом сказать об этом обладателю. Не так давно было принято постановление о том, что линейный управляющий (другими словами конкретный управляющий) также должен участвовать в планировании и, может быть, оказывать влияние на окончательное обязательство обеспечить 100% -ую отдачу от спринта. Вы понимаете, чем это завершилось? Так что команды объявляют абсолютный минимум, а другие делают «черным», так как, если какая-то незапланированная вещь появится опять, она будет сиять красноватым «сверху». ;)
Очередной пример из реальной жизни: ПО бросило нам темы на четверть, и мы должны были их воплотить сами. Круто, мы уже знаем, что мы желаем сделать, у нас есть предложения по внедрению, но нам необходимо проконсультироваться с системным архитектором, чтоб обеспечить соответствующую производительность и малое воздействие на ресурсы сервера. На 3 спринта мы зарезервировали время для этого — у нас никогда не было конструктора, и эти заявленные часы теряются из-за того, что мы ничего не делаем. Это любопытно? Решай сам.

Это все о Scrum. Я отлично работаю в этом? Да — пока соблюдаются его правила и нет никаких сюрпризов. Так никогда. :P Водопад еще более привлекателен для меня, другими словами предопределенные требования и одно огромное планирование, и получение деталей на постоянной базе — но он работает в маленьких проектах (раз в год?), А не 20-летняя кобыла :)

  • 6

Пожалуйста, войдите, чтоб смотреть за этим содержанием
0 Подписчики 0