Сегодня было сложно - 8 часов и болит голова, кроме того немного выбились из графика, но на будущее есть пару выводов, и интересное наблюдение.
Для начала напомню, что при планировании я учел так называемый мной "коэффициент преувеличения". Задачи, после декомпозиции, оценивались в Саньках, и, чтобы перевести их в часы, Саньки были домножены на этот коэффициент. По последним статистическим данным 1 СанЁк равен 1.3 часа. Т.е. в среднем я оптимист, и если запланировал 10 часов на выполнение задачи, то обязательно потрачу минимум 13. Так же мы с напарницей прибавили еще 15% к общему времени на издержки парного программирования - потому, что так написано во многих источниках.
То ли я где-то промахнулся, то ли этот коэффициент при работе в паре стоит пересчитать, но сегодня мы немного вылетели из планирования. Не страшно. Видимо стоит оставлять запас в дне и планировать работы так, чтобы заканчивать ее на час раньше. Была попытка лимитировать каждую задачу во времени, но что делать, если задача вот вот конец, а уже залазит на следующую задачу в плане? Пару таких задач, и последние часы работы мы работали без плана и без перерывов. Перерывы надо делать!
И, ведь, сегодня договорились - каждый час делаем перерыв на 10 минут и меняемся местами независимо от того, какая задача. Но во второй половине дня то ли забыли это правило, то ли моя нетерплячка начала брать верх - начался хаос. На мое "уже перерыв" напарница сидя за клавиатурой сказала "если хочешь - иди, а я тут закончу". Мне так же показалось, что вот вот конец - и я остался рядом с напарницей. Но конец не наступал - еще минут через 15 предложил поменяться, ибо начал скучать. Не вставал уже до конца рабочего дня - около 2х часов сидел за баранкой без перерыва.
Выводы:
- если договорились, то что бы ни случилось и каким близким не казался конец задачи - вставать и выходить на свежий воздух.
- проветривать комнату, когда выходим на перерыв- свежий воздух кончается во второй половине дня - возможно по этой причине разболелась голова.
- сутра планировать заканчивать работу на час раньше.
Сегодня я меньше вклинивался в работу напарницы. Сидя рядом, когда возникала пауза в ее работе я задавал вопрос "что случилось?". Если же я не понимал что делаю, просил объяснить, что происходит. Часто у самого в работе за штурвалом возникает мысль "О! Блин! А что если так?" и начинаешь ее реализовывать как можно быстрее, забыв про напарника. Это не гуд. Оба должны понимать, что происходит - возможно уставать станем меньше.
Во время долгожданного коммита 2.5 дневной работы, мы проглянули все изменения и прикинули, сколько бы мы потратили на задачу 1) работай мы параллельно 2) работай каждый из нас по отдельности над задачей 3) ну и в паре, и каким был бы качественным результат. Все +/- сходится с теорией!
1) Параллельно мы бы сделали этот же объем работ быстрее, но не намного (где-то на 15-20%). Что касается качества, а подобный опыт уже был у нас раньше, скажу так. Раз в день/два либо я, либо напарница находили бы баги и сообщали друг другу, в связи с чем приходилось бы переписывать начатое или каким-то другим образом выкручиваться. Скорее всего количество багов и моментов недопонимания требований заказчика было бы больше, а выплывали бы они не сразу, а дай Бог, если к концу деливери. Деливери в конце призналась бы незаконченной и в следующей мы бы заканчивали то, что не успели сделать в этой. Сомневаюсь, что код был бы покрыт юнит-тестами так, как он покрыт сейчас - думаю тестов было бы на половину меньше. Архитектура! Т.к. в нашей команде за этот вопрос больше всех отвечаю я, то возможно в следующем деливери пришлось бы иметь дело с приведением кода к общей задумке. Это, хоть и не существенные изменения - но все же, есть большой шанс, что без рефакторинга не обошлось бы. Много времени уходило бы на общение и, в любом случае, в конце деливери мы объединили бы свои усилия чтобы хоть как-то спасти ситуацию. В общем - подобным оптом уже сыт по горло. Посмотрим, что происходит в других случаях.
2) Разработка в одиночку занимала бы однозначно в два раза больше времени. Если параллельная разработка какая никакая - командная, со всеми вытекающими плюсами, то тут о багах и неточностях скорее всего узнали бы не раньше начала-середины следующей деливери. Подобный опыт тоже был. Кроме того приходилось бы отвлекаться на консультации команде по задачам, которые вообще тебя касаются слабо. А, если недостаточно дисциплинирован, и на раскачку надо время, то на выполнение этой задачи в одиночку уходило бы до 3х времени.
3) Мы сделали это за два с половиной дня. Мы нашли приятную фичу в ИДЕ. Мы продумали совместно множество вариантов. Мы знаем о чем речь, и каждый из нас может полноценно заменить другого в случае чего. Архитектура мало того, что поддерживается - она улучшается. О ней знают двое а не один я. Код тестами покрыт хорошо. Но есть и минусы. УСТАЛОСТЬ и к концу дня хрипота - говорить приходится много - рты у нас не закрываются целый день. А если почему-то слетает процесс парного программирования, то это ведет к хаосу, из которого сложно потом вырулить - ты просто не замечаешь как погружаешься в него. Дисциплина и отдых! Думаю это поможет.
А хороший пленнинг на старте + ежедневный пленнинг на день сутра позволяет проводить скрам дейли за рекордное время - две три минуты и сводится к перемещению бумажек на доске. Раньше мы на дейли мы больше синхронизировались, теперь, когда двое из 5х членов в команде работают в паре, на синхронизацию времени уходит много меньше.
Для начала напомню, что при планировании я учел так называемый мной "коэффициент преувеличения". Задачи, после декомпозиции, оценивались в Саньках, и, чтобы перевести их в часы, Саньки были домножены на этот коэффициент. По последним статистическим данным 1 СанЁк равен 1.3 часа. Т.е. в среднем я оптимист, и если запланировал 10 часов на выполнение задачи, то обязательно потрачу минимум 13. Так же мы с напарницей прибавили еще 15% к общему времени на издержки парного программирования - потому, что так написано во многих источниках.
То ли я где-то промахнулся, то ли этот коэффициент при работе в паре стоит пересчитать, но сегодня мы немного вылетели из планирования. Не страшно. Видимо стоит оставлять запас в дне и планировать работы так, чтобы заканчивать ее на час раньше. Была попытка лимитировать каждую задачу во времени, но что делать, если задача вот вот конец, а уже залазит на следующую задачу в плане? Пару таких задач, и последние часы работы мы работали без плана и без перерывов. Перерывы надо делать!
И, ведь, сегодня договорились - каждый час делаем перерыв на 10 минут и меняемся местами независимо от того, какая задача. Но во второй половине дня то ли забыли это правило, то ли моя нетерплячка начала брать верх - начался хаос. На мое "уже перерыв" напарница сидя за клавиатурой сказала "если хочешь - иди, а я тут закончу". Мне так же показалось, что вот вот конец - и я остался рядом с напарницей. Но конец не наступал - еще минут через 15 предложил поменяться, ибо начал скучать. Не вставал уже до конца рабочего дня - около 2х часов сидел за баранкой без перерыва.
Выводы:
- если договорились, то что бы ни случилось и каким близким не казался конец задачи - вставать и выходить на свежий воздух.
- проветривать комнату, когда выходим на перерыв- свежий воздух кончается во второй половине дня - возможно по этой причине разболелась голова.
- сутра планировать заканчивать работу на час раньше.
Сегодня я меньше вклинивался в работу напарницы. Сидя рядом, когда возникала пауза в ее работе я задавал вопрос "что случилось?". Если же я не понимал что делаю, просил объяснить, что происходит. Часто у самого в работе за штурвалом возникает мысль "О! Блин! А что если так?" и начинаешь ее реализовывать как можно быстрее, забыв про напарника. Это не гуд. Оба должны понимать, что происходит - возможно уставать станем меньше.
Во время долгожданного коммита 2.5 дневной работы, мы проглянули все изменения и прикинули, сколько бы мы потратили на задачу 1) работай мы параллельно 2) работай каждый из нас по отдельности над задачей 3) ну и в паре, и каким был бы качественным результат. Все +/- сходится с теорией!
1) Параллельно мы бы сделали этот же объем работ быстрее, но не намного (где-то на 15-20%). Что касается качества, а подобный опыт уже был у нас раньше, скажу так. Раз в день/два либо я, либо напарница находили бы баги и сообщали друг другу, в связи с чем приходилось бы переписывать начатое или каким-то другим образом выкручиваться. Скорее всего количество багов и моментов недопонимания требований заказчика было бы больше, а выплывали бы они не сразу, а дай Бог, если к концу деливери. Деливери в конце призналась бы незаконченной и в следующей мы бы заканчивали то, что не успели сделать в этой. Сомневаюсь, что код был бы покрыт юнит-тестами так, как он покрыт сейчас - думаю тестов было бы на половину меньше. Архитектура! Т.к. в нашей команде за этот вопрос больше всех отвечаю я, то возможно в следующем деливери пришлось бы иметь дело с приведением кода к общей задумке. Это, хоть и не существенные изменения - но все же, есть большой шанс, что без рефакторинга не обошлось бы. Много времени уходило бы на общение и, в любом случае, в конце деливери мы объединили бы свои усилия чтобы хоть как-то спасти ситуацию. В общем - подобным оптом уже сыт по горло. Посмотрим, что происходит в других случаях.
2) Разработка в одиночку занимала бы однозначно в два раза больше времени. Если параллельная разработка какая никакая - командная, со всеми вытекающими плюсами, то тут о багах и неточностях скорее всего узнали бы не раньше начала-середины следующей деливери. Подобный опыт тоже был. Кроме того приходилось бы отвлекаться на консультации команде по задачам, которые вообще тебя касаются слабо. А, если недостаточно дисциплинирован, и на раскачку надо время, то на выполнение этой задачи в одиночку уходило бы до 3х времени.
3) Мы сделали это за два с половиной дня. Мы нашли приятную фичу в ИДЕ. Мы продумали совместно множество вариантов. Мы знаем о чем речь, и каждый из нас может полноценно заменить другого в случае чего. Архитектура мало того, что поддерживается - она улучшается. О ней знают двое а не один я. Код тестами покрыт хорошо. Но есть и минусы. УСТАЛОСТЬ и к концу дня хрипота - говорить приходится много - рты у нас не закрываются целый день. А если почему-то слетает процесс парного программирования, то это ведет к хаосу, из которого сложно потом вырулить - ты просто не замечаешь как погружаешься в него. Дисциплина и отдых! Думаю это поможет.
А хороший пленнинг на старте + ежедневный пленнинг на день сутра позволяет проводить скрам дейли за рекордное время - две три минуты и сводится к перемещению бумажек на доске. Раньше мы на дейли мы больше синхронизировались, теперь, когда двое из 5х членов в команде работают в паре, на синхронизацию времени уходит много меньше.
Сообщения
Комментариев нет:
Отправить комментарий