пятница, 25 января 2008 г.

Инструкция превращения Junior Developer'a в Agile-профи

Если к вашему проекту подключаются новые люди, а тем более начинающие разработчики, то вам обязательно нужно провести новичков чрез терни к звездам.

Начинаем
Первым делом нужно дать сводные понятия о таких вещах как
# Agile Software Development
# Scrum
# Domain Driven Design
# Test Driven Development
# Object Oriented Design
# Enterprise Design Patterns
# Secure Development Lifecycle
# Дальше конкретные технологии (ASP.NET/BizTalk/SharePoint/WCF/WPF/etc)

Важные понятия
Чтобы стать сильным Agile объектно-ориентированным разработчиком вам обязательно нужно будет ряд простых понятий:
Separation of Concerns
Liskov Substitution Principle
Law of Demeter
Single Responsibility Principle
Open/Close Principle
Interface Segregation Principle
Dependency Inversion Principle

Закупаем литературу
Чтение статей и участие на форумах не сделает из вас сильного разработчика. Нужно обратиться к фундаментальным работам.
# Agile/Development Principles
  * Code Complete: A Practical Handbook of Software Construction (Steve McConnell)
  * Agile Software Development, Principles, Patterns, and Practices (Robert C. Martin)
  * Agile Principles, Patterns, and Practices in C# (Robert C. Martin)
  * Agile Software Development with SCRUM (Ken Schwaber)
  * User Stories Applied: For Agile Software Development (Mike Cohn)
  * Practices of an Agile Developer: Working in the Real World (Andrew Hunt)
# General Development
  * Release It!: Design and Deploy Production-Ready Software (Michael Nygard)
  * Ship it! A Practical Guide to Successful Software Projects (Jared Richardson)
  * The Pragmatic Programmer: From Journeyman to Master (Andrew Hunt)
# Design Patterns
  * Head First Object-Oriented Analysis and Design (Brett McLaughlin)
  * Patterns of Enterprise Application Architecture (Martin Fowler)
  * Design Patterns: Elements of Reusable Object-Oriented Software (GoF)
  * Head First Design Patterns (Elisabeth Freeman)
# Domain Driven Design
  * Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans)
  * Applying Domain-Driven Design and Patterns: With Examples in C# and .NET (Jimmy Nilsson)
# Test Driven Development
  * Test Driven Development: By Example (Kent Beck)
  * xUnit Test Patterns: Refactoring Test Code (Gerard Meszaros)
  * Pragmatic Unit Testing in C# with NUnit, 2nd Edition (Andrew Hunt)
# Refactoring
  * Refactoring: Improving the Design of Existing Code (Martin Fowler)
  * Refactoring to Patterns (Joshua Kerievsky)
# Secure Development Lifecycle
  * The Security Development Lifecycle (Michael Howard)
  * Writing Secure Code, Second Edition (Michael Howard)

И специализированная литература:
# C#/.NET Framework
  * CLR via C#, Second Edition (Jeffrey Richter)
  * Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Krzysztof Cwalina)

Следующий шаг
Теперь нам нужно научиться это применять, а усилит это практика "парного программирования", написание в стиле TDD. Было бы неплохо, чтобы за вами приглядывал опытный товарищ, но это не должно вас останавливать.

Источник: Starting Junior Programmers on the Right Agile Track Guidance

9 комментариев:

  1. Привет!

    Вот зачем такой список писать - показать сколько ты книг прочитал или есть другая скрытая цель?

    Что бы из перейти к гибким методологиям надо осознать их и почувствовать необходимость в них и больше НИЧЕГО. Лучше если это озарение придет к некоторым членам команды и остальные за ними потянуться (идеальный вариант). Если эти технологии никому не нужны и без них все прекрасно работает то какой в них смысл?

    Все остальное можно варьировать - на то они и гибкие.

    Спасибо!

    ОтветитьУдалить
  2. Список - это краткий курс молодого бойца. Кстати, я бы рад похвастаться, таким количеством прочитанных книг... Но это суета :)

    Ответ простой.

    1. Это уровень Shu. Без него дальше никуда. см. Shu-ha-ri подход. Читать нужно, нужно учить, нужно выполнять последовательно, это говорит первый уровень.

    2. Осознать и почувствовать - это из области фантастики. Гибкие - сложные взаимодействия, сложные решения, сложные подходы. Их не нужно чувствовать, их нужно знать. Всё очень прагматично. Это лишь бизнес :)

    3. Гибкие - это не варьирование. Гибкие это отношение к требованиям. Так что Agile это очень жесткая методология сдачи проектов в короткие сроки с отличным качеством. Этому нужно учиться у гуру. Книги это подарок мировых гуру нам... будущим гуру :)

    В общем сорвём вуаль кокетства с Agile :)

    ОтветитьУдалить
  3. Привет!
    Первый раз слышу такое определение гибких методологий. Я то думал что требования тут не при чем... Т.е. получается если я работаю надо гос проектом - то никакие гибкие методологии мне уже не подходят...вот ужас то.

    Вот нашел на гибком сайте:
    # Адаптивный процесс. В Agile не существует заранее определенного процесса, который бы описывал методы работы в проекте и диктовал команде как добиваться поставленных целей. Вместо этого команда должна сама определить тот процесс, который позволяет ей добиваться высоких результатов.

    Нельзя прийти в команду и сказать - люди вы лохи, Agile это круто и я вам сейчас тут его построю и вас заодно. Это абсолютно неверный подход и ни к чему хорошему он не ведет. Надо осознать какие проблемы в работе и как их решить (все равно в какой методологии).

    Например авторы тех книг, в своих личных блогах не выступают столь радикально. Например, если рассмотреть дизайн приложения. Пусть мы используем в своем гибком подходе XP практики - это же не означает что мы вообще должны отказаться от предварительного проектирования и сразу приступать к реализации некоторого модуля как это обозначено там (делаем только то что нужно сейчас). Поэтапный рефакторинг для достижения требуемой цели построения системы может оказаться неподъемной задачей. Или, например, возьмем другую практику - модульное тестирование. Написал модуль, написал для него кучу тестом, посмотрел что бы было полное покрытие, а на следующей итерации этот модуль переделали, и опять перелопатить кучу тестов догоняя до 100% покрытия.

    Где тут оптимальный путь? Я думаю он где-то посередине и в этом и заключается гибкость методологий и практик, а тупо следовать букве закона, совершенно не понимая и не чувствуя зачем - может быть столь же опасно как и не знание этого самого закона.

    Спасибо!

    ОтветитьУдалить
  4. Всё верно.
    Основная идея в том, что мы из бооольшого вотерфола (так как всех заколебало в конце разработки разочаровываться) превратили маленькие - вотерфольчики. Убрали икрементное добавление на итерационное.

    А дальше всё поехало. Оказалось маленькие вотерфольчики совсем не вотерфольчики классические. Нужно оптимальней, быстрей, поменьше лишнего. Начали урезать докумы до инструмента моделирования, а не протоколирования. Начали смотреть на человеческий фактор. В общем всё то о чем ты говорил.

    Но первый посыл - это изменяемость требований.

    По поводу оптимального пути. Тесты выкидываются - без сожаления. Тесты - инстумент моделирования, понимания проблематики. Тесты не должны быть обузой. Как добавляются, так и выкидываются :)
    В общем см. паттерны TDD.

    А так классные замечания - в точку.

    ОтветитьУдалить
  5. Кстати, проблема 100% переписывания кода тестов - это нормальная вестчь. И это не проблема. Это знак того что предметная область и решение было немного неполно. Это лечиться стандартными решениями: митинги, вовлечение заказчика, коллективное владение, демы, ретровспективы, сессии моделирования, в общем игра в коммуникацию и изобретения.

    Объект воздействия этих практик: ЧЕЛОВЕК.
    Цель воздействия: превратить каждого разработчика в консультанта предметной области.
    Цель превращения: адекватность решений... человек интуитивно строить модели как можно ближе к реальности... и соотвесно код меньше переписывается.

    А по первости (начало проекта) это стандартная вещь - когда куча вещей нестабильны и это требует постоянной переделки (кстати не понятно, при TDD драйве изолированность очень повышенная, и переделки носят локальный характер).

    В общем больше коммуникации -- и работы будет меньше. А форсирование этой коммуникации должно быть постоянным и жестоким, но приятным :) Agile - это работа, серъёзная, может быть иногда через силу. Но главное смочь встать на рельсы, а дальше само должно попереть...

    ОтветитьУдалить
  6. Ну раз у нас тут такая дискуссия пошла то вот еще мои мысли по поводу требований, для размышления.

    Приходит Заказчик к Программисту и говорит: "А что ты и правда можешь любой сайт написать?"
    П - Конечно, я так же применяю гибкие методологии что позволит нам сильно ускорить проект и сделать именно то что вам нужно.
    З - Круто. Давай тогда напишем мне вводилку для реестра заказчиков. Сколько мне надо на это времени и денег.
    П - Ну задача не сложная, да и наработки у меня есть. Думаю за неделю справлюсь так что с вас 500 баксов.
    З - Круто. Пойду к своему боссу, расскажу ему о поем крутой задумке, выбью деньги и потом можно начинать работать.

    Ну вот, теперь деньги выделены, сроки обговорены, работа началась, но в середине пути (на третий день), когда список тестовых контрагентов перевалил за 2 страницы до заказчика наконец дошло что по ним бы неплохо сделать поиск - ведь их будет все больше и больше в дальнейшем.

    Какие тут могут быть дальнейшие действия:
    1. З не хочет попадать на бабки и потребует с П что бы он доделал эту функциональность в установленный срок, так как перед шефом краснеть
    2. П в свою очередь не захочет наверное почти в два раза усложнять задачу, но вряд ли он сможет отвертеться, так как исходные требования вряд ли были зафиксированы и подписаны обоими сторонами.
    3. Они могут доделать так как есть и вместе попросить шефа дать еще денег на еще одну неделю и простить их таких балбесов. Однако шеф, наверное, будет сильно удивлен, так как ему сначала сказали что гибкие методологии позволяют менять требования а потом выяснилось что не все так просто. И самое главное что он не сможет получить эту вводилку контрагентов к установленному сроку.

    Так что в этом случает Программист будет супер счастлив и доволен когда исходные требования меняться не будут - во всех остальных случаях он попадает.

    Я все понимаю что задача достаточно простая, но такая ситуация абсолютно реальная и проблему в целом тут видно очень хорошо.

    Спасибо!

    Спасибо!

    ОтветитьУдалить
  7. Интересная задача.
    Но причём тут Agile? ;)

    Постановка задачи была не по-Agile. А решение требуется по Agile.

    Если кто-то хочет работать по Agile, а не прикрываться Agile. Он должен знать что это такое. В приведённом примере судя по описанию ни заказчик, ни разработчик не зрали, что такое Agile. Поэтому ответ простой - тут ничего не поможет :)

    К тому же нарушена тонна принципов и практик Agile в приведённом примере. Поэтому повторю свой ответ - в морг :)

    Приглашаю послушать тренинги по Agile ребят с AgileRussia. Например, у Асхата - и будет всё понятно. Или понятно где искать ответ на твою ситуацию :)

    ОтветитьУдалить
  8. Кратким курсом молодого бойца вы называете 24 книги, некоторые из которых содержат более тысячи страниц и требуют очень вдумчивого чтения?

    Спасибо, такой Agile нам не нужен.

    ОтветитьУдалить
  9. Блин, хотел ведь весь список написать... Похоже зря не написал, может быть заинтересовал бы :)

    заходи на http://agileguru.ru - может такой понравится :)

    ОтветитьУдалить