Все чаще в текстах вакансий упоминаются слова Agile, Scrum, книг по этой тематике за последний год тоже вышло довольно много (более 10). Раньше что-то слышал, решил недавно основательно ознакомиться с темой, во всех нюансах. Для хорошего знакомства в качестве первого источника вполне подойдут ссылки выше (Википедия), второй источник - собственный опыт в проектах.
Чтобы ознакомиться с первым - достаточно просто кликнуть по ссылкам (там же ссылки на доп. источники по теме), по поводу второго - решил написать этот пост.
Вообще сразу хочется написать "как правильно", и хорошо иллюстрирует это - разработка фреймворков у JBoss.
Выделить можно следующее:
1) JIRA. Или любая другая баг-трекинговая система. В принципе - это самая главная вещь, в технологии постановки процесса. Все должно упираться в нее (подробнее - далее).
2) Форумы, где люди могут задавать технические вопросы, а новые люди - пользоваться поиском по имеющейся информации. Если на каком-то форуме выясняется, что найден баг или что-то нужно улучшить - идем к п.1, в лаконичной форме описываем проблему.
3) Википедия. - База знаний, с обучающими роликами, с оглавлением всего и со всеми ссылками (на код, на патчи, на применение и т.д.). Если не выделяется время на нее - будут проблемы при смене разработчиков. Выделяемое время должно быть отражено в п.1.
4) Наверное еще могут быть списки рассылок, титульная страница проекта, новости проекта, публичный доступ ко скачиванию из SVN и т.д.
Организация людей:
1) Менеджер проекта - в большинстве случаев не нужен (об этом говорят многие на форумах про Agile и Scrum). Потому что не может оценить трудозатраты по времени во множестве случаев. Сами же разработчики - могут себе назначить довольн6о легкие условия, или выбить у менеджера и тут смотря кто на сколько умеет убеждать или ставить/преподносить себя. Потенциально порочная схема. Иногда под этой должностью "скрывается" специалист, совмещающий в себе несколько других ролей (далее), все это вместе для удобства называют менеджером (и у этого, на практике, свои минусы).
2) Грамотно оценить сроки выполнения, сроки исправлений - сможет только Team Lead (априори самый технологически подкованный человек в команде разработчиков). В его же обязанности входит разработка самых сложных подсистем проекта.
Каждая из итераций должна включать ВСЕ ТРИ этапа и длиться от 1 до 2 недель. Для некоторых проектов может быть по другому, здесь - для подавляющего большинства.
3) Объектно-ориентированным анализом занимаются аналитики требований. Или эту обязанность берет на себя "менеджер" из п.1.
4) Объектно-ориентированным проектированием - архитектор проекта (возможен и выделенный архитектор СУБД) + программисты + Team Lead. Обычно это делается на совещаниях-планерках, а так же на своих рабочих местах (рисование диаграмм для Википедии).
О вертикали власти в IT.
Вертикаль власти в IT есть, суть - порочное явление. Потому что где-то "вверху" (директор, акционеры) - бизнес-знания должны переходить в знания технологий. Иногда эта "смычка" бывает в лице директора (бизнес-знания) + начальник отдела (знания технологий).
Или в лице менеджера проекта, закончившего MBA (или др.) и когда-то программировавшего (и благополучно успевшего многое забыть, тем более не знающего теперь использующихся в отрасли фреймворков).
В первом случае два профи (возможно) - постоянно будут где-то друг друга не понимать и поэтому неизбежно принимать различные социально-сексуально обусловленные этим позиции.
Во втором случае мы имеем полу-профессионала в обоих областях. С вытекающим отсюда полупрофессиональным управлением.
В эту же вертикаль совершенно не вписывается отдел маркетинга. Который в принципе должен ставить бизнес-требования (на совместных планерках, или прямо в JIRA). В данном же случае - отдел маркетинга должен договариваться с каким-то элементами этой вертикальной цепочки ("бизнес" будет договариваться с "бизнесом", поэтому, вероятно, на уровне директора).
Понимаете, в чем тут удобна JIRA - ? -- Все, кто должен ставить требования - должны ставить задачи там (возможно после обсуждения с Team Lead). Все, кто должен исправлять/выполнять - брать задачи от туда.
В эту же схему отлично вписываются тестировщики. А так же отдел дизайна (или привлекаемые специалисты, в том числе и HTML-верстальщики).
А если имеется "вертикаль", то:
1) Постоянно будет непонимание "бизнеса" и "технологий". Это выливается, особенно - в планирование бизнесом затрат на разработку. А это означает, что постоянные проблемы в понимании - приводят к постоянным проблемам в разработке. С поиском крайнего и т.д. Кому это нужно?
2) Постоянное "отлынивание" различных отделений фирмы. Если от "бизнеса" поступило всего 3 пункта в JIRA в месяц - значит директор, отдел маркетинга - ПРАКТИЧЕСКИ НЕ ПРИНИМАЮТ УЧАСТИЯ. Перекуры по 30 минут, прятание за необходимостью куда-то ехать и подписывать договора и т.д. и т.п. А так бы, в JIRA если - все видно за месяц! И за пол года! Какое участие, кто там виноват, что так поставлен процесс в отделе маркетинга - начальник там не следит за специалистами, или что или как. Без JIRA всего этого не видно ВООБЩЕ. (Смягчающим фактором может быть только постоянное участие в планерках с программистами, но в этом случае, в конечном итоге - мы получили бы пункты в JIRA).
Директора/акционеры - эти тоже не дураки по отлынивать, чуть подробнее об этом. - Практически на всех фирмах директора любят работать много. Представьте, на секунду представьте - что эта фирма - ВАША. Вы будете много работать? На СЕБЯ? Скорее всего будете. И скорее всего увлечетесь. А теперь вспомните, как много раз вам говорили о переработках, нужности их, как директор отлично замечает ваше даже 2-ух минутное опоздание. Вспомнили? А то, что за эти 2 минуты - вы, частенько, вечером на 30 минут позже уходите - об этом вам приходится говорить ему, и все равно на многих фирмах "дерут" даже за двухминутное опоздание. Потому что ДИРЕКТОР ГОРИТ РАБОТОЙ. И вы бы горели. Если бы дело было вашим.
Досадная "мелочь" во всем этом - работая по 12 часов в день, через месяц, максим - два, ты "сдыхаешь". И пол месяца работаешь "абы как". А потом еще полтора месяца - на 2/3. - Директор при этом часто не появляется в офисе, то он там поехал в налоговую, то у него проблемы дома, то он на встрече. Иногда на встрече. После пары часов которой он едет домой. Полагая, что раз он работал по 12 часов в день, а вы - нет, то ему это можно.
В ИТОГЕ ДИРЕКТОР РАБОТАЕТ СТОЛЬКО ЖЕ, СКОЛЬКО И ВЫ. Он сам не замечает, когда по месяцу и по два - сознательно отлынивает от процесса. Но от вас он требует переработки.
А между тем:
1) Это НЕ ВАШЕ дело (не ваш бизнес).
2) У вас своя семья! И вы ДОЛЖНЫ уделить ВРЕМЯ ДЛЯ ВОСПИТАНИЯ, например, вашего ребенка. И для походов с женой по злачным местам. Вы ДОЛЖНЫ делать это. А не сидеть до 20-00 в офисе, придя с самого утра.
И про мать свою вы должны не забыть. Или у нас не то общество, с другими ценностями?
3) Дома вы должны еще отдохнуть, возможно - заняться самообразованием (иностранный язык, дополнительный язык программирования, сертификация ваших знания, научная работа).
Если кто-то 12 часов в день в офисе - значит он 3-4 часа из них - фактически не работает (занят другим).
Да, еще хотел сказать про отдел маркетинга, сидящий, возможно, в соц. сетях, про директоров смотрящих порнуху в своих кабинетах, но про это вы можете узнать сами. Если не попробуете что-то изменить к лучшему, дать всем возможность поработать и оценить все потом в JIRA или др. метдами. Да и при вертикали власти - кто-то может покрывать другого, такие узлы на фирмах вообще сложно распутать.
И ВСЕ НАЧИНАЕТСЯ С ДИРЕКТОРА. Если что-то на фирме идет не так - виноват, в первую очередь - директор. Это он НЕ ПОСТАВИЛ ПРОЦЕСС, не предусмотрел. Наемные работники - под его УПРАВЛЕНИЕМ.
Спасибо за внимание. :)
Чтобы ознакомиться с первым - достаточно просто кликнуть по ссылкам (там же ссылки на доп. источники по теме), по поводу второго - решил написать этот пост.
Вообще сразу хочется написать "как правильно", и хорошо иллюстрирует это - разработка фреймворков у JBoss.
Выделить можно следующее:
1) JIRA. Или любая другая баг-трекинговая система. В принципе - это самая главная вещь, в технологии постановки процесса. Все должно упираться в нее (подробнее - далее).
2) Форумы, где люди могут задавать технические вопросы, а новые люди - пользоваться поиском по имеющейся информации. Если на каком-то форуме выясняется, что найден баг или что-то нужно улучшить - идем к п.1, в лаконичной форме описываем проблему.
3) Википедия. - База знаний, с обучающими роликами, с оглавлением всего и со всеми ссылками (на код, на патчи, на применение и т.д.). Если не выделяется время на нее - будут проблемы при смене разработчиков. Выделяемое время должно быть отражено в п.1.
4) Наверное еще могут быть списки рассылок, титульная страница проекта, новости проекта, публичный доступ ко скачиванию из SVN и т.д.
Организация людей:
1) Менеджер проекта - в большинстве случаев не нужен (об этом говорят многие на форумах про Agile и Scrum). Потому что не может оценить трудозатраты по времени во множестве случаев. Сами же разработчики - могут себе назначить довольн6о легкие условия, или выбить у менеджера и тут смотря кто на сколько умеет убеждать или ставить/преподносить себя. Потенциально порочная схема. Иногда под этой должностью "скрывается" специалист, совмещающий в себе несколько других ролей (далее), все это вместе для удобства называют менеджером (и у этого, на практике, свои минусы).
2) Грамотно оценить сроки выполнения, сроки исправлений - сможет только Team Lead (априори самый технологически подкованный человек в команде разработчиков). В его же обязанности входит разработка самых сложных подсистем проекта.
Любая разработка должна последовательно, ИТЕРАЦИОННО, проходить через следующие этапы:
- Объектно-ориентированный анализ (общение с заказчиков, составление use cases)
- Объектно-ориентированное проектирование (блок-схемы, диаграммы классов и т.д.)
- Объектно-ориентированное программирование (само программирование)
3) Объектно-ориентированным анализом занимаются аналитики требований. Или эту обязанность берет на себя "менеджер" из п.1.
4) Объектно-ориентированным проектированием - архитектор проекта (возможен и выделенный архитектор СУБД) + программисты + Team Lead. Обычно это делается на совещаниях-планерках, а так же на своих рабочих местах (рисование диаграмм для Википедии).
О вертикали власти в IT.
Вертикаль власти в IT есть, суть - порочное явление. Потому что где-то "вверху" (директор, акционеры) - бизнес-знания должны переходить в знания технологий. Иногда эта "смычка" бывает в лице директора (бизнес-знания) + начальник отдела (знания технологий).
Или в лице менеджера проекта, закончившего MBA (или др.) и когда-то программировавшего (и благополучно успевшего многое забыть, тем более не знающего теперь использующихся в отрасли фреймворков).
В первом случае два профи (возможно) - постоянно будут где-то друг друга не понимать и поэтому неизбежно принимать различные социально-сексуально обусловленные этим позиции.
Во втором случае мы имеем полу-профессионала в обоих областях. С вытекающим отсюда полупрофессиональным управлением.
В эту же вертикаль совершенно не вписывается отдел маркетинга. Который в принципе должен ставить бизнес-требования (на совместных планерках, или прямо в JIRA). В данном же случае - отдел маркетинга должен договариваться с каким-то элементами этой вертикальной цепочки ("бизнес" будет договариваться с "бизнесом", поэтому, вероятно, на уровне директора).
Понимаете, в чем тут удобна JIRA - ? -- Все, кто должен ставить требования - должны ставить задачи там (возможно после обсуждения с Team Lead). Все, кто должен исправлять/выполнять - брать задачи от туда.
В эту же схему отлично вписываются тестировщики. А так же отдел дизайна (или привлекаемые специалисты, в том числе и HTML-верстальщики).
А если имеется "вертикаль", то:
1) Постоянно будет непонимание "бизнеса" и "технологий". Это выливается, особенно - в планирование бизнесом затрат на разработку. А это означает, что постоянные проблемы в понимании - приводят к постоянным проблемам в разработке. С поиском крайнего и т.д. Кому это нужно?
2) Постоянное "отлынивание" различных отделений фирмы. Если от "бизнеса" поступило всего 3 пункта в JIRA в месяц - значит директор, отдел маркетинга - ПРАКТИЧЕСКИ НЕ ПРИНИМАЮТ УЧАСТИЯ. Перекуры по 30 минут, прятание за необходимостью куда-то ехать и подписывать договора и т.д. и т.п. А так бы, в JIRA если - все видно за месяц! И за пол года! Какое участие, кто там виноват, что так поставлен процесс в отделе маркетинга - начальник там не следит за специалистами, или что или как. Без JIRA всего этого не видно ВООБЩЕ. (Смягчающим фактором может быть только постоянное участие в планерках с программистами, но в этом случае, в конечном итоге - мы получили бы пункты в JIRA).
Директора/акционеры - эти тоже не дураки по отлынивать, чуть подробнее об этом. - Практически на всех фирмах директора любят работать много. Представьте, на секунду представьте - что эта фирма - ВАША. Вы будете много работать? На СЕБЯ? Скорее всего будете. И скорее всего увлечетесь. А теперь вспомните, как много раз вам говорили о переработках, нужности их, как директор отлично замечает ваше даже 2-ух минутное опоздание. Вспомнили? А то, что за эти 2 минуты - вы, частенько, вечером на 30 минут позже уходите - об этом вам приходится говорить ему, и все равно на многих фирмах "дерут" даже за двухминутное опоздание. Потому что ДИРЕКТОР ГОРИТ РАБОТОЙ. И вы бы горели. Если бы дело было вашим.
Досадная "мелочь" во всем этом - работая по 12 часов в день, через месяц, максим - два, ты "сдыхаешь". И пол месяца работаешь "абы как". А потом еще полтора месяца - на 2/3. - Директор при этом часто не появляется в офисе, то он там поехал в налоговую, то у него проблемы дома, то он на встрече. Иногда на встрече. После пары часов которой он едет домой. Полагая, что раз он работал по 12 часов в день, а вы - нет, то ему это можно.
В ИТОГЕ ДИРЕКТОР РАБОТАЕТ СТОЛЬКО ЖЕ, СКОЛЬКО И ВЫ. Он сам не замечает, когда по месяцу и по два - сознательно отлынивает от процесса. Но от вас он требует переработки.
А между тем:
1) Это НЕ ВАШЕ дело (не ваш бизнес).
2) У вас своя семья! И вы ДОЛЖНЫ уделить ВРЕМЯ ДЛЯ ВОСПИТАНИЯ, например, вашего ребенка. И для походов с женой по злачным местам. Вы ДОЛЖНЫ делать это. А не сидеть до 20-00 в офисе, придя с самого утра.
И про мать свою вы должны не забыть. Или у нас не то общество, с другими ценностями?
3) Дома вы должны еще отдохнуть, возможно - заняться самообразованием (иностранный язык, дополнительный язык программирования, сертификация ваших знания, научная работа).
Если кто-то 12 часов в день в офисе - значит он 3-4 часа из них - фактически не работает (занят другим).
Да, еще хотел сказать про отдел маркетинга, сидящий, возможно, в соц. сетях, про директоров смотрящих порнуху в своих кабинетах, но про это вы можете узнать сами. Если не попробуете что-то изменить к лучшему, дать всем возможность поработать и оценить все потом в JIRA или др. метдами. Да и при вертикали власти - кто-то может покрывать другого, такие узлы на фирмах вообще сложно распутать.
И ВСЕ НАЧИНАЕТСЯ С ДИРЕКТОРА. Если что-то на фирме идет не так - виноват, в первую очередь - директор. Это он НЕ ПОСТАВИЛ ПРОЦЕСС, не предусмотрел. Наемные работники - под его УПРАВЛЕНИЕМ.
Спасибо за внимание. :)
